Tessera Engine

The boundaries are enforced by folders as well as interfaces. Platform alone talks to SDL3; only RHI/D3D12/ includes Direct3D headers. Render decides what to draw without recording GPU commands. ECS, Jobs and Scene include neither Render/ nor RHI/; Assets and Project also remain independent of rendering.

Import libraries and compression belong exclusively to Tools/TesseraCooker. The runtime consumes cooked data without carrying authoring dependencies. Include scans check these rules, but compilation provides a stronger check: Tessera.NoD3D12.sln builds the engine and editor with a null backend and an SDL_Renderer interface. A leaked D3D12 type breaks that solution; its builds produce zero Dx*.obj objects.

Each worker owns a Chase-Lev deque: it pushes and pops without a lock while idle workers steal from the other end. A worker waiting for a job executes other work on its current stack. The single-worker test checks that dependencies still progress. Threads outside the pool wait passively; allowing them to help would create two producers for a single-producer deque.

Jobs have AnyWorker, LongRunning or MainThread affinity. Separate counters track frame work and long-running work, so shader compilation cannot extend the frame wait. In the recorded comparison, the slowest frame during recompilation dropped from 803 ms to 18.75 ms. Per-worker FrameArena storage supports temporary allocation; ParallelFor over 1,048,576 elements produced the serial result with zero heap allocations.

Three concurrency defects surfaced during development, including one that only appeared with the editor window visible. A watchdog naming the stalled frame stage helped isolate it. Replacing batch stealing with element-by-element stealing moved that cost to the idle thread. A broad graph of real work measured 94.7% worker occupancy.

The cooker uses the same system: compressing one 2048² texture took 311.8 s with one thread and 9.7 s with 24. Tracy and an editor timeline expose CPU/GPU activity and work per worker. These are specific project measurements, not general throughput guarantees.

Mesh shaders are not implemented in the renderer. The existing pipeline deliberately leaves the path open: canonical root-signature slots are visible to all stages, pipeline creation uses the pipeline state stream, DXC recognizes ms and as at Shader Model 6.5 or later, and capability detection queries GPU support.

A test successfully created a mesh-shader pipeline against the canonical root signature. That checks compatibility, not a shipping rendering path. meshoptimizer is selected but not integrated. The plan is for the cooker to generate meshlets into a new .tmesh chunk; older files will retain the traditional vertex path when that chunk is absent. The container and pipeline contracts are what make that extension possible.

A pass declares resource reads and writes, access types and GPU stages. The graph sees the whole frame and derives ordering and barriers from those declarations. It never records commands. The D3D12 executor reads the execution order and per-pass barriers, then records the corresponding work.

Compilation builds dependencies against the preceding last writer, rejects cycles with an empty plan, removes unused producers, selects queues, computes transient lifetimes and generates barriers where resource roles change. Exported resources and declared side effects preserve required work; simply importing a resource does not protect its producer from removal.

Use order and lifetime are distinct with optional compute: positions in the plan do not describe overlapping execution. The graph provides lifetime intervals; the heap owner chooses aliasing and requests aliasing barriers. My allocator packs by lifetime, the requirement that led me to reject the evaluated size-based D3D12 Memory Allocator approach. Eight deliberately staggered resources used 2,688 KB instead of 10,752 KB, a 4.00× reduction and the minimum for that test.

The supplied forward graph was exported from Sample.tscn on October 6, 2026. In that recorded configuration, 20 passes produce 15 barriers. Six disabled occlusion/ray-tracing passes only open empty scopes: a pass with no writes is not an unused producer and is not automatically removed. The highlighted SceneColor transition before ToneMapPass is inferred from its change from render target to shader read. Counts vary with the shading path and enabled effects.

Reset() clears frame data while retaining vector capacity; graph resource handles expire with it. Graphviz export and the editor panel expose the plan, while --rendergraph-self-test runs 242 checks without a GPU.

Dear ImGui docking keeps the editor in C++, in the engine process. The Lobby opens a project without launching another application. The Content Browser has rendered thumbnails, a self-invalidating disk cache and background imports. Mesh/prefab windows provide GPU previews; the texture editor isolates channels and packs ORM. Asset properties expose the binary chunks directly.

Hierarchy, Inspector, ImGuizmo transforms, undo/redo, prefabs, tags and asset colours support scene work. The Material Graph is a read-only view derived from .tmat; its wiring is not editable. The graph widgets come from ImGuizmo’s GraphEditor.

Play, Pause, Stop and Simulate share the snapshot mechanism: Stop restores the captured world and verifies that its hash is identical. Authoring scenes use JSON for readable Git diffs and are cooked to binary for runtime. Profiling, Render Graph, ECS Diagnostics and Console make the running systems inspectable from the editor.

I returned to Sharpmake after CMake so one generator defines both IDE and command-line builds. Sharpmake and vcpkg produce two solutions in Debug, Development, Profile and Shipping: eight local builds, all treating warnings as errors. Post-build checks verify runtime DLLs and mirrored shader trees.

Headless subsystem tests include 4,883 ECS checks, 242 render-graph checks and 837 cooker checks. Command-line probes exercise individual features; a benchmark harness compares timings and counters against a baseline. Image diffs against the preceding version require zero different scene pixels for the refactor acceptance checks described here.

Those numbers come from the project records used for this case study. They document the validation method and measured scenarios, not a fresh execution of the private repository by this website. Together, the alternate build, replay audits and image comparisons check different failure modes that a successful normal build alone would miss.