Skip to content

Latest commit

 

History

History
163 lines (131 loc) · 6.68 KB

File metadata and controls

163 lines (131 loc) · 6.68 KB

Architecture

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.

Repository layout

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.

Components

Studio application

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/ contains IRenderBackend, RasterBackend, RayTracingBackend, MultiviewRasterPass, and RayTracingPass.
  • 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.

Shared runtime

src/runtime/ contains data and algorithms used by both backends.

  • assets/ defines the canonical Gaussian scene and SceneHandle.
  • 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, .dlmap structures, 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.

Raster backend

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.

Ray Tracing backend

src/renderers/raytrace/ provides:

  • the CUDA and OptiX forward-rendering path;
  • D3D12 shared-texture output;
  • Standard, Optical Reuse, and Viewpoint Reuse scheduling;
  • .dlmap consumption;
  • 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.

Python package

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.

Runtime data flow

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.

Rendering modes

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.

Display output

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.