Sample CodeiOS, iPadOS, Mac Catalyst, macOS, tvOSReviewed 2026-07-21View on Apple Developer

Culling occluded geometry using the visibility result buffer

At a glance

Item Summary
Purpose Draw a scene without rendering hidden geometry by checking whether each object in the scene is visible.
App architecture Objective-C host code with Metal shaders; AAPLViewController hands work to AAPLRenderer, which owns visibility-query buffer management before occlusion-tested draw calls.
Main patterns Renderer boundary, Two-phase visibility pipeline, Host-shader data contract
Scope High-level review of 11 scanned source files and 11 detected declarations; build assets are omitted.

Project structure

Source bundle/
├── Renderer/
│   ├── AAPLRenderer.m
│   ├── AAPLShaders.metal
│   └── AAPLShaderTypes.h
└── Application/
    ├── AAPLViewController.m
    ├── main.m
    ├── WindowSceneDelegate.m
    ├── AAPLAppDelegate.h
    ├── AAPLAppDelegate.m
    └── AAPLViewController.h

Structure observations

  • The entry/composition boundary and renderer or operation boundary are separate in the source; AAPLRenderer is the principal feature coordinator.
  • GPU-specific logic stays in Metal shader files; shared headers bridge host/shader layouts where present.
  • The tree above is intentionally pruned to composition, resource, and shader files.

Overall architecture

Reference code

Renderer/AAPLRenderer.m:568 — per-object visibility query encoding

    for (size_t i = 0; i < AAPLNumObjectsXYZ; ++i)
    {
        [_renderEncoder setVisibilityResultMode:MTLVisibilityResultModeBoolean
                                         offset:i * sizeof(uint64_t)];
        [self renderMeshWithIndex:(uint32_t)i];
    }

Interpretation

This is the dominant control/data path: platform code composes AAPLRenderer; that object controls visibility-query buffer management; GPU-visible work ends in occlusion-tested draw calls. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

Ownership evidence

Application/AAPLViewController.m:57AAPLViewController creates and stores _renderer

    _renderer = [[AAPLRenderer alloc] initWithMetalKitView:_view];
    NSAssert(_renderer, @"Renderer failed initialization");

    [_renderer drawableSizeWillChange:_view.bounds.size];

    // The view controller needs to update state for the renderer, so use this class's `MTKView` methods first.
    _view.delegate = self;
Owner Object or state Relationship Mutation authority
AAPLViewController _renderer / AAPLRenderer Creates and stores; the diagram uses composition because construction is source-visible. The declaring scope performs setup and replacement.
AAPLRenderer Feature-specific framework and Metal resources Operation-local calls or stored state; exclusive lifetime is not assumed beyond cited evidence. Feature setup/encoding code controls mutation and command submission.

Class and protocol design

Type Responsibility Depends on or conforms to Source
AAPLViewController selects/configures the view and composes the feature objects. PlatformViewController, MTKViewDelegate Application/AAPLViewController.h:20
AAPLRenderer owns pipeline/resource setup and per-frame command encoding. NSObject Renderer/AAPLRenderer.h:11
AAPLAppDelegate handles application/window lifecycle callbacks. PlatformAppDelegate Application/AAPLAppDelegate.h:24
WindowSceneDelegate handles application/window lifecycle callbacks. UIResponder, UIWindowSceneDelegate Application/WindowSceneDelegate.h:13

Framework delegate conformance is a callback seam; the source does not justify calling the whole app protocol-oriented.

Access control

Symbol Access Verified effect Design reason
AAPLAppDelegate header-visible available to translation units that import the header; this is not Swift public. Keep the usable surface no wider than the collaboration requires. (Application/AAPLAppDelegate.h:24)
AAPLRenderer implementation details implementation-only native helpers, stored state, or registration code stays out of the imported header contract. Hide native implementation details from importing translation units. (Renderer/AAPLRenderer.m:1)
AAPLShaders entry points Metal library boundary host code resolves named shader entry points; Swift access modifiers do not apply. Expose only named shader entry points needed by pipeline creation. (Renderer/AAPLShaders.metal:37)

This sample does not use Swift private, fileprivate, or public for its native boundary. Objective-C/Objective-C++ use header versus implementation placement, C++ uses access specifiers/linkage, Python uses module conventions, and Metal entry points cross a compiled-library boundary; these are not Swift access levels.

Logic ownership and placement

Logic Owning type or file Why it lives there
Selects/configures the view and composes the feature objects AAPLViewControllerApplication/AAPLViewController.h:20 The type’s callbacks and stored state align with this responsibility.
Owns pipeline/resource setup and per-frame command encoding AAPLRendererRenderer/AAPLRenderer.h:11 The type’s callbacks and stored state align with this responsibility.
Handles application/window lifecycle callbacks AAPLAppDelegateApplication/AAPLAppDelegate.h:24 The type’s callbacks and stored state align with this responsibility.
Handles application/window lifecycle callbacks WindowSceneDelegateApplication/WindowSceneDelegate.h:13 The type’s callbacks and stored state align with this responsibility.
Visibility-query buffer management AAPLRenderer / Renderer/AAPLRenderer.m:568 Keeps visibility-result offsets and proxy draws in the renderer’s encoding path.
Occlusion-tested draw calls Renderer/AAPLShaders.metal:37 GPU-parallel code remains in the Metal compilation boundary.

Shader boundary reference

Renderer/AAPLShaders.metal:37 — representative GPU entry/helper

vertex RasterizerData vertexShader(const device vector_float4* positions [[buffer(AAPLBufferIndexPositions)]],
                                   constant AAPLFrameData& frameData [[buffer(AAPLBufferIndexFrameData)]],
                                   constant MeshIndexData& meshIndex [[buffer(AAPLBufferIndexMeshIndex)]],
                                   uint vertexID [[vertex_id]])
{
    // ...
}

Design patterns

Pattern Source evidence Purpose or tradeoff
Renderer boundary Renderer/AAPLRenderer.m:568 UI/lifecycle code composes a renderer while GPU state and visibility encoding stay together.
Two-phase visibility pipeline Application/AAPLViewController.m:57 Makes the sample’s visibility-query buffer management an explicit, reviewable boundary.
Host-shader data contract Renderer/AAPLRenderer.h:9 Shared indices/structs and matching bindings couple host encoding to shader signatures deliberately.

Naming conventions

  • Role suffixes make ownership visible: AAPLViewController, AAPLRenderer, AAPLAppDelegate, WindowSceneDelegate.
  • Method names describe setup or encoding actions: application, viewDidLoad, optionChanged, modeChanged, toggleMode, drawInMTKView, mtkView.
  • Shader entry points use stage/operation names: vertexShader, fragmentShader.
  • AAPL is a sample namespace prefix, not a recommendation for production module naming; retain semantic suffixes such as Renderer, Manager, Scene, or Adapter.

Architecture takeaways

  • Keep AAPLViewController focused on composition; AAPLRenderer is the owner of visibility-query buffer management.
  • Treat occlusion-tested draw calls as a separate execution/compilation boundary with explicit resource and data-layout contracts.
  • The verified ownership edge is AAPLViewController_renderer; broader exclusive ownership is not inferred.
  • Access-control rationale follows concrete language boundaries rather than translating every header or shader symbol into Swift terms.

Source map

Source file Architectural role
Renderer/AAPLRenderer.m AAPLRenderer
Application/AAPLViewController.m AAPLViewController
Renderer/AAPLShaders.metal RasterizerData, MeshIndexData
Application/main.m entry point or feature implementation
Application/WindowSceneDelegate.m WindowSceneDelegate
Renderer/AAPLShaderTypes.h entry point or feature implementation
Application/AAPLAppDelegate.h AAPLAppDelegate
Application/AAPLAppDelegate.m AAPLAppDelegate, AAPLAppDelegate
Application/AAPLViewController.h AAPLViewController