Rendering terrain dynamically with argument buffers

At a glance

Project structure

Source bundle/
├── Renderer/
│   ├── AAPLTerrainRenderer.mm
│   ├── AAPLParticleRenderer.metal
│   └── AAPLDebugRenderer.mm
└── Application/
    ├── AAPLGameViewController.mm
    ├── main.m
    ├── WindowSceneDelegate.mm
    ├── AAPLAppDelegate.h
    ├── AAPLGameViewController.h
    └── AAPLAppDelegate.mm

Structure observations

• The entry/composition boundary and renderer or operation boundary are separate in the source; AAPLMainRenderer 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

flowchart LR
    N1["AAPLGameViewController"]
    N2["AAPLMainRenderer"]
    N3["specialized terrain/vegetation/particle renderers"]
    N4["Metal passes"]
    N1 --> N2
    N2 --> N3
    N3 --> N4

Reference code

Renderer/AAPLMainRenderer.mm:284 — main renderer composes specialized renderers

    _vegetationRenderer = [[AAPLVegetationRenderer alloc] initWithDevice: device
                                                                 library: library];

    _terrainRenderer = [[AAPLTerrainRenderer alloc] initWithDevice: device
                                                           library: library];

#if TARGET_OS_OSX
    _particleRenderer = [[AAPLParticleRenderer alloc] initWithDevice: device
                                                             library: library];
#endif

Interpretation

This is the dominant control/data path: platform code composes AAPLMainRenderer; that object controls main renderer coordinating specialized renderers; GPU-visible work ends in terrain, vegetation, and particle shader passes. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

classDiagram
    AAPLGameViewController *-- AAPLMainRenderer : _renderer

Ownership evidence

Application/AAPLGameViewController.mm:208 — AAPLGameViewController creates and stores _renderer

@implementation AAPLGameViewController
// ...
    _renderer = [[AAPLMainRenderer alloc] initWithDevice:_view.device size:_view.drawableSize];
// ...
@end

Class and protocol design

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

Access control

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

Shader boundary reference

Renderer/AAPLParticleRenderer.metal:109 — representative GPU entry/helper

kernel void AnimateAndCleanupOldParticles

Design patterns

Naming conventions

• Role suffixes make ownership visible: AAPLGameViewController, AAPLDebugRenderer, AAPLMainRenderer, AAPLParticleRenderer, AAPLTerrainRenderer, AAPLVegetationRenderer, AAPLGameView.
• Method names describe setup or encoding actions: acceptsFirstResponder, acceptsFirstMouse, ModifyTerrain, application, applicationDidFinishLaunching, applicationWillTerminate, applicationShouldTerminateAfterLastWindowClosed.
• Shader entry points use stage/operation names: SpawnNewParticles, ParticleVs, ParticlePs, LightingVs, LightingPs, mousePositionUpdate.
• 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 AAPLGameViewController focused on composition; AAPLMainRenderer is the owner of main renderer coordinating specialized renderers.
• Treat terrain, vegetation, and particle shader passes as a separate execution/compilation boundary with explicit resource and data-layout contracts.
• The verified ownership edge is AAPLGameViewController → _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

• Official Apple documentation