Rendering a scene with deferred lighting in C++

At a glance

Project structure

Source bundle/
├── Application/
│   ├── AAPLViewController.mm
│   ├── main.m
│   ├── WindowSceneDelegate.m
│   └── AAPLAppDelegate.h
└── Renderer/
    ├── Shaders/
    │   ├── AAPLBufferExamination.metal
    │   └── AAPLShaderTypes.h
    ├── AAPLViewAdapter.mm
    ├── AAPLRenderer.cpp
    └── AAPLViewAdapter.h

Structure observations

• The entry/composition boundary and renderer or operation boundary are separate in the source; AAPLViewAdapter 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["AAPLViewController"]
    N2["AAPLViewAdapter"]
    N3["Objective-C++ view adapter and metal-cpp renderer"]
    N4["deferred G-buffer and lighting passes"]
    N1 --> N2
    N2 --> N3
    N3 --> N4

Reference code

Application/AAPLViewController.mm:107 — feature handoff or setup anchor

@implementation AAPLViewController
// ...
    AAPLViewAdapter rendererView( (__bridge void *)_view );
// ...
@end

Interpretation

This is the dominant control/data path: platform code composes AAPLViewAdapter; that object controls Objective-C++ view adapter and metal-cpp renderer; GPU-visible work ends in deferred G-buffer and lighting passes. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

classDiagram
    AAPLViewController *-- Renderer_SinglePassDeferred : _pRenderer

Ownership evidence

Application/AAPLViewController.mm:73 — AAPLViewController creates and stores _pRenderer

@implementation AAPLViewController
// ...
        _pRenderer = new Renderer_SinglePassDeferred( _pDevice );
// ...
@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/Shaders/AAPLBufferExamination.metal:24 — representative GPU entry/helper

vertex LightInfoData

Design patterns

Naming conventions

• Role suffixes make ownership visible: AAPLViewController, AAPLViewAdapter, Renderer, BufferExaminationManager, AAPLAppDelegate, WindowSceneDelegate.
• Method names describe setup or encoding actions: loadMetal, loadScene, populateLights, updateLights, updateWorldState, drawableSizeWillChange, drawMeshes.
• Shader entry points use stage/operation names: gbuffer_vertex, gbuffer_fragment, skybox_vertex, skybox_fragment, fairy_vertex, fairy_fragment.
• 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; AAPLViewAdapter is the owner of Objective-C++ view adapter and metal-cpp renderer.
• Treat deferred G-buffer and lighting passes as a separate execution/compilation boundary with explicit resource and data-layout contracts.
• The verified ownership edge is AAPLViewController → _pRenderer; 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