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

Accelerating ray tracing and motion blur using Metal

At a glance

Item Summary
Purpose Generate ray-traced images with motion blur using GPU-based parallel processing.
App architecture Objective-C, Objective-C++ host code with Metal shaders; ViewController hands work to Renderer, which owns motion acceleration structures before ray-tracing compute kernel.
Main patterns Scene/renderer separation, Bounded frames in flight, Host-shader data contract
Scope High-level review of 15 scanned source files and 29 detected declarations; build assets are omitted.

Project structure

Source bundle/
├── Application/
│   ├── ViewController.mm
│   ├── main.m
│   ├── AppDelegate.h
│   └── AppDelegate.m
└── Renderer/
    ├── Shaders.metal
    ├── Renderer.mm
    ├── Scene.mm
    ├── ShaderTypes.h
    └── Scene.h

Structure observations

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

Application/ViewController.mm:60 — feature handoff or setup anchor

    Scene *scene = [Scene newMotionBlurSceneWithDevice:_view.device
                                    usePrimitiveMotion:usePrimitiveMotion];

    _renderer = [[Renderer alloc] initWithDevice:_view.device
                                           scene:scene
                              usePrimitiveMotion:usePrimitiveMotion];

    [_renderer mtkView:_view drawableSizeWillChange:_view.bounds.size];

Interpretation

This is the dominant control/data path: platform code composes Renderer; that object controls motion acceleration structures; GPU-visible work ends in ray-tracing compute kernel. The arrows summarize responsibility transfer, not a claim that every node directly calls the next.

Ownership and state

Ownership evidence

Application/ViewController.mm:63ViewController creates and stores _renderer

@implementation ViewController
// ...
    _renderer = [[Renderer alloc] initWithDevice:_view.device
                                           scene:scene
                              usePrimitiveMotion:usePrimitiveMotion];
// ...
@end
Owner Object or state Relationship Mutation authority
ViewController _renderer / Renderer Creates and stores; the diagram uses composition because construction is source-visible. The declaring scope performs setup and replacement.
Renderer 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
ViewController selects/configures the view and composes the feature objects. NSViewController, UIViewController Application/ViewController.h:18
Renderer owns pipeline/resource setup and per-frame command encoding. NSObject, MTKViewDelegate Renderer/Renderer.h:13
Scene holds scene geometry, instances, camera, or lighting data. NSObject Renderer/Scene.h:145
AppDelegate handles application/window lifecycle callbacks. UIResponder, UIApplicationDelegate, NSObject Application/AppDelegate.h:14
WindowSceneDelegate handles application/window lifecycle callbacks. UIResponder, UIWindowSceneDelegate Application/WindowSceneDelegate.h:11
BoundingBox stores the minimum and maximum corners of an axis-aligned scene bound. concrete Metal/framework collaborators Renderer/Scene.h:25

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
AppDelegate 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/AppDelegate.h:14)
Renderer 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/Renderer.mm:1)
Shaders 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/Shaders.metal:169)

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 ViewControllerApplication/ViewController.h:18 The type’s callbacks and stored state align with this responsibility.
Owns pipeline/resource setup and per-frame command encoding RendererRenderer/Renderer.h:13 The type’s callbacks and stored state align with this responsibility.
Holds scene geometry, instances, camera, or lighting data SceneRenderer/Scene.h:145 The type’s callbacks and stored state align with this responsibility.
Handles application/window lifecycle callbacks AppDelegateApplication/AppDelegate.h:14 The type’s callbacks and stored state align with this responsibility.
Motion acceleration structures Renderer / Application/ViewController.mm:60 Keeps Metal/framework setup and encoding out of entry or lifecycle code.
Ray-tracing compute kernel Renderer/Shaders.metal:169 GPU-parallel code remains in the Metal compilation boundary.

Shader boundary reference

Renderer/Shaders.metal:169 — representative GPU entry/helper

kernel void raytracingKernel(uint2 tid [[thread_position_in_grid]],
                             constant FrameData & frameData,
                             texture2d<unsigned int> randomTex,
                             texture2d<float> prevTex,
                             texture2d<float, access::write> dstTex,
                             device MeshResources *resources,
                             device MTLAccelerationStructureMotionInstanceDescriptor *instances,
                             device AreaLight *areaLights,
                             accelerationStructureType accelerationStructure)
{
    // ...
}

Design patterns

Pattern Source evidence Purpose or tradeoff
Scene/renderer separation Renderer/Renderer.mm:46 Makes the sample’s motion acceleration structures an explicit, reviewable boundary.
Bounded frames in flight Renderer/Renderer.mm:17 A semaphore/ring limits CPU writes from overtaking GPU reads.
Host-shader data contract Renderer/Scene.h:14 Shared indices/structs and matching bindings couple host encoding to shader signatures deliberately.

Naming conventions

  • Role suffixes make ownership visible: ViewController, Renderer, Scene, AppDelegate, WindowSceneDelegate.
  • Method names describe setup or encoding actions: init, initWithDevice, uploadToBuffers, resourcesStride, encodeResourcesToBuffer, markResourcesAsUsedWithEncoder, addCubeWithFaces.
  • Shader entry points use stage/operation names: raytracingKernel, copyVertex, copyFragment.
  • Names favor concrete domain roles and target-local types; no broad public library namespace is introduced.

Architecture takeaways

  • Keep ViewController focused on composition; Renderer is the owner of motion acceleration structures.
  • Treat ray-tracing compute kernel as a separate execution/compilation boundary with explicit resource and data-layout contracts.
  • The verified ownership edge is ViewController_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
Application/ViewController.mm ViewController
Renderer/Shaders.metal KeyframeResources, MeshResources, ray, CopyVertexOut
Application/main.m entry point or feature implementation
Renderer/Renderer.mm Renderer
Renderer/Scene.mm TriangleKeyframeData, MeshVertex, Geometry, GeometryInstance, Scene
Renderer/ShaderTypes.h Camera, AreaLight, FrameData, Sphere
Renderer/Scene.h BoundingBox, TriangleKeyframeData, Geometry, GeometryInstance, Scene
Application/AppDelegate.h AppDelegate, AppDelegate
Application/AppDelegate.m AppDelegate, AppDelegate