DirectLStudio is organized as one native Windows application, two rendering backends, a shared light-field runtime, and a small Python package for generating subpixel-reuse maps. The C++ targets are built together by the root CMake project.
DirectLStudio/
├── .github/
│ └── workflows/
│ └── release.yml
├── configs/
│ ├── display_profiles.json
│ ├── reuse_catalog.json
│ ├── scene_presets.json
│ └── studio.json
├── docs/
│ ├── assets/
│ │ └── teaser.gif
│ ├── ARCHITECTURE.md
│ ├── BENCHMARKS.md
│ ├── GETTING_STARTED.md
│ ├── PARAMETERS.md
│ └── SUBPIXEL_REUSE.md
├── src/
│ ├── python/
│ │ └── directl_subpixel/
│ ├── renderers/
│ │ ├── raster/
│ │ │ ├── cmake/
│ │ │ ├── include/
│ │ │ ├── shaders/
│ │ │ ├── src/
│ │ │ └── third_party/
│ │ └── raytrace/
│ │ ├── cmake/
│ │ ├── cuda/
│ │ ├── src/
│ │ └── third_party/
│ ├── runtime/
│ │ ├── assets/
│ │ ├── display/
│ │ ├── include/directl/
│ │ └── interlace/
│ ├── studio/
│ │ ├── app/
│ │ ├── metrics/
│ │ ├── platform/
│ │ ├── render/
│ │ ├── scene/
│ │ └── ui/
│ └── tests/
│ ├── data/
│ └── python/
├── tools/
│ ├── benchmark.py
│ ├── build.ps1
│ ├── download_assets.py
│ ├── package.ps1
│ └── verify_release.py
├── .gitattributes
├── .gitignore
├── CMakeLists.txt
├── LICENSE
├── pyproject.toml
├── README.md
└── THIRD_PARTY_NOTICES.md
Shared C++ headers live in src/runtime/include/directl/, next to the runtime that owns their contracts. There is no root-level include/ directory because v1.0 exposes an application and Python package rather than a C++ backend plug-in SDK.
src/studio/ builds DirectLStudio.exe.
app/owns startup, command-line parsing, the main loop, camera state, screenshots, and user settings.platform/provides the Win32 window, monitor enumeration, Per-Monitor V2 DPI handling, and the D3D12 swap chain.ui/implements the Core, Parameters, Scene, Device, and Camera panels together with the compact status HUD.scene/manages scene selection, drag-and-drop import, and camera presets.render/containsIRenderBackend,RasterBackend,RayTracingBackend,MultiviewRasterPass, andRayTracingPass.metrics/records structured frame and mode information for command-line runs.
IRenderBackend gives the application a common interface for binding a scene, applying camera state, rendering a request, exposing the GPU result, querying status, and releasing cached resources.
src/runtime/ contains data and algorithms used by both backends.
assets/defines the canonical Gaussian scene andSceneHandle.display/loads display profiles and describes the selected physical monitor surface.interlace/implements light-field camera generation, physical subpixel view selection, and GPU interlacing.include/directl/contains the scene ABI,.dlmapstructures, display types, and reuse catalog interfaces shared across build targets.
Physical subpixel coordinates begin at the top-left of the display: (x, y, k) = (0, 0, 0), where k = 0, 1, 2 denotes the RGB subpixel.
src/renderers/raster/ provides:
- PLY, SOG, SPZ, and SPZ4 scene loading;
- D3D12 Gaussian packing, culling, sorting, and rasterization;
- OneSweep GPU radix sort;
- multiview rendering and compute-shader interlacing;
- the shaders and third-party components used by those paths.
The backend renders a set of light-field views and interlaces them directly on the GPU.
src/renderers/raytrace/ provides:
- the CUDA and OptiX forward-rendering path;
- D3D12 shared-texture output;
- Standard, Optical Reuse, and Viewpoint Reuse scheduling;
.dlmapconsumption;- the OptiX device programs and supporting math code.
The backend is built as DirectLRayTracingBackend.dll, with OptiX programs staged as DirectLRayTracing.ptx. This boundary keeps CUDA and OptiX resource lifetimes separate from the D3D12 application while sharing the same scene and camera contracts.
src/python/directl_subpixel/ is installed as directl-subpixel and imported as directl_subpixel. It generates Optical and Viewpoint .dlmap files from display calibration values and can convert a local Looking Glass visual.json into DirectL parameters.
PLY / SOG / SPZ / SPZ4
│
▼
Canonical GaussianScene
│
├───────────────┐
▼ ▼
Raster GPU cache Ray Tracing GPU cache
│ │
└───────┬───────┘
▼
Native interlaced texture
│
▼
Profile-sized D3D12 backbuffer
The scene loader parses an asset once and creates a SceneHandle. Each backend builds its own GPU representation when first selected. One CameraController supplies the pose, projection, clip planes, focus distance, and light-field array parameters to every mode.
Multiview Raster produces multiple rasterized views followed by GPU compute interlacing. Ray Tracing and both reuse modes write to a D3D12 shared texture through CUDA and OptiX. Rendering, interlacing, and presentation remain GPU-resident.
| Key | Display name | Backend | Reuse map |
|---|---|---|---|
1 |
Multiview Raster |
Raster | — |
2 |
Ray Tracing |
Ray Tracing | — |
3 |
Optical Reuse |
Ray Tracing | Optical .dlmap |
4 |
Viewpoint Reuse |
Ray Tracing | Viewpoint .dlmap |
Mode changes preserve the window, swap chain, SceneHandle, display profile, and camera. GPU caches remain available according to the configured residency policy, while only the active reuse map occupies its mapping allocation.
Fullscreen mode uses the selected monitor's physical rectangle and the active profile's native dimensions. Windows DPI scaling affects interface sizing but not the light-field render target. Windowed mode uses the same native light-field surface inside the application window.