Adjusting the level of detail using Metal mesh shaders

At a glance

Project structure

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

Structure observations

• The entry/composition boundary and renderer or operation boundary are separate in the source; AAPLRendererAdapter 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["AAPLRendererAdapter"]
    N3["metal-cpp renderer through an Objective-C++ adapter"]
    N4["object and mesh shader stages"]
    N1 --> N2
    N2 --> N3
    N3 --> N4

Reference code

MeshShadersMetalCPP/Renderer/AAPLRenderer.cpp:468 — feature handoff or setup anchor

    pRenderEncoder->drawMeshThreadgroups(MTL::Size(AAPLNumObjectsX, AAPLNumObjectsY, AAPLNumObjectsZ),
                                         MTL::Size(AAPLMaxTotalThreadsPerObjectThreadgroup, 1, 1),
                                         MTL::Size(AAPLMaxTotalThreadsPerMeshThreadgroup, 1, 1));

    pRenderEncoder->endEncoding();
    pCommandBuffer->presentDrawable(pView->currentDrawable());
    pCommandBuffer->commit();

Interpretation

This is the dominant control/data path: platform code composes AAPLRendererAdapter; that object controls metal-cpp renderer through an Objective-C++ adapter; GPU-visible work ends in object and mesh shader stages. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

classDiagram
    AAPLRendererAdapter *-- AAPLRenderer : _pRenderer

Ownership evidence

MeshShadersMetalCPP/Adapter/AAPLRendererAdapter.mm:39 — AAPLRendererAdapter creates and stores _pRenderer

@implementation AAPLRendererAdapter
// ...
        _pRenderer = new AAPLRenderer( *((__bridge MTK::View *)pMtkView) );
// ...
@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

MeshShadersMetalCPP/Renderer/AAPLShaders.metal:81 — representative GPU entry/helper

[[object, max_total_threads_per_threadgroup(AAPLMaxTotalThreadsPerObjectThreadgroup), max_total_threadgroups_per_mesh_grid(AAPLMaxThreadgroupsPerMeshGrid)]]
void meshShaderObjectStageFunction(object_data payload_t& payload            [[payload]],
                                   mesh_grid_properties meshGridProperties,
                                   constant AAPLMeshInfo* meshes             [[buffer(AAPLBufferIndexMeshInfo)]],
                                   constant AAPLVertex* vertices             [[buffer(AAPLBufferIndexMeshVertices)]],
                                   constant AAPLIndexType* indices           [[buffer(AAPLBufferIndexMeshIndices)]],
                                   constant float4x4*   transforms           [[buffer(AAPLBufferIndexTransforms)]],
                                   constant float3*     colors               [[buffer(AAPLBufferIndexMeshColor)]],
                                   constant float4x4&   viewProjectionMatrix [[buffer(AAPLBufferViewProjectionMatrix)]],
                                   constant uint&       lod                  [[buffer(AAPLBufferIndexLODChoice)]],
                                   uint3                positionInGrid       [[threadgroup_position_in_grid]])
{
    // ...
}

Design patterns

Naming conventions

• Role suffixes make ownership visible: AAPLViewController, AAPLRendererAdapter, AAPLAppDelegate, WindowSceneDelegate.
• Method names describe setup or encoding actions: initWithMtkView, dealloc, device, drawInMTKView, drawableSizeWillChange, setRotationSpeed, setTranslation.
• Shader entry points use stage/operation names: fragmentShader, meshShaderObjectStageFunction, meshShaderMeshStageFunctionPoints, meshShaderMeshStageFunctionLines, meshShaderMeshStageFunction.
• 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; AAPLRendererAdapter is the owner of metal-cpp renderer through an Objective-C++ adapter.
• Treat object and mesh shader stages as a separate execution/compilation boundary with explicit resource and data-layout contracts.
• The verified ownership edge is AAPLRendererAdapter → _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