Render policy & frame graph
Authored scene intent, compiled shader availability, and real device capabilities determine the selected rendering paths. Explicit attachment and sampled-resource declarations guide each backend.
03 / Features & capabilities
Same intent.
Different workloads.
The goal is a coherent authored world. Each device gets a rendering workload that its selected paths can support.
Materials & visibility
Unlit and physically based material families, reflected instances, masked coverage, CPU visibility and projected-error LOD. Additional indexed or GPU-compacted paths are capability- and workload-dependent.
Atmosphere & lighting
Shared environment inputs, atmosphere lookup tables, scene lights, shadow maps, baked surface lighting, and independently budgeted volumetric work. Simpler quality paths remain deliberate choices.
Water & world presentation
Spectral ocean and water-surface work, optical inputs, terrain LOD, and vegetation presentation. Effect selection and resource budgets differ by backend and target profile.
Networked worlds
Authoritative input validation, snapshots, adaptive client interpolation, and native/RTC transport adapters. Protocol capacity bounds are not equivalent to tested concurrent-player capacity.
XR, UI & native media
Vulkan OpenXR integration, input routing, renderer-neutral UI, and optional capture/recording services. Device features, permission, build options, and tested implementation determine availability.
Native paths
A shared boundary.
Platform-owned execution.
| Backend | Documented routes | Scope |
|---|---|---|
| Vulkan | Windows, Linux, Android, OpenXR | Native raster implementation; XR presentation follows the runtime. |
| Metal | Apple Silicon macOS, iPhone & iPad | Native implementation; quality profiles cover different GPU capabilities. |
| Direct3D 12 | Windows, Xbox Series S Dev Mode | Native implementation; consumer Dev Mode is separate from retail-console shipping. |
| WebGPU | Compatible browsers | Browser implementation with WebRTC transport; a successful render does not establish native feature or performance parity. |
Implementation is not blanket acceptance.
These routes are source-backed implementations and platform contracts. Visual correctness, feature coverage, performance, and packaging remain separate checks on a particular device and commit. Software Vulkan is functional evidence rather than hardware GPU performance evidence. Intel Macs and Android-tablet acceptance are outside the current documented scope.
Advanced techniques earn their place.
A device advertising a capability does not mean an engine path for it exists, or that it improves a given workload. Indexed resources, compute visibility, and other advanced paths need shader support, native implementation, explicit fallback, and evidence. Future hardware ray tracing and mesh-shader ideas are not advertised here as delivered features.
A moving projectDevelopment checkpoints ↗