A build graph is not a frame graph: tracing Arcglass Engine

A game-engine repository can contain a renderer, physics, animation, networking and ray-tracing code without putting all of them into one rendered frame. To understand what Arcglass Engine demonstrates today, I start with its CMake target graph and then follow the smaller paths that actually reach an application.

Arcglass is a Windows C++20 engine prototype. It has a Win32 platform layer, a Direct3D 12 rendering interface, shared world and asset modules, a custom editor, a separate runtime sample, and native tests. The graph below describes build dependencies; it is not a claim that every module runs together in the current game loop.

Follow the shared layers into two applications

The dependency structure starts with Core utilities such as logging, allocators, jobs and profiling. The Win32 layer owns the window and input path; the Direct3D 12 RHI wraps the device, command queue, descriptor heaps, swap chain and resource objects. Renderer utilities build above that interface. The entity/component world and the asset virtual file system form separate shared branches used by both the editor and the standalone runtime.

That separation gives the code a place for systems to live and be built independently. It does not prove that the editor, runtime and every subsystem form a complete authoring pipeline. The architecture notes make that distinction explicitly, so I keep it in the article too.

The visible editor is a focused rendering preview

The editor is the most concrete way to inspect the project. It opens a scene, lets you select and transform objects, saves the small .arcscene format, and includes a file browser that copies selected files into the project’s asset tree. That browser does not validate, import or cook the files, and the editor is still a custom full-screen HLSL canvas rather than a mature docking workspace.

Its viewport is also intentionally scoped. The current preview ray-casts a procedural height field, shades it from a directional-light marker and approximates object shadows with bounding-sphere checks. The sky and clouds are shader effects. They make the scene useful for exploring lighting and presentation, but they are not the engine’s mesh-based render-graph passes or a general terrain, shadow or atmosphere system.

The standalone runtime is a separate graphics and input sample. Keeping it separate makes the rendering path inspectable, while the asset workflow and scene hand-off between editor and playable game remain unfinished.

Keep experiments out of the runtime claim

The source tree contains broader rendering experiments: meshlet and HZB work, ray tracing, neural radiance cache, volumetric effects and virtual texturing. The README says these are not demonstrated as a complete integrated frame pipeline in the runtime. The DirectStorage manager is another useful boundary example: it simulates a queue lifecycle on the CPU; it does not read files, decompress data or transfer bytes into VRAM.

I treat those modules as experiments to inspect, not features a player can currently use. That distinction matters in an engine project: a class or shader can compile while still being disconnected from the frame that the runtime presents.

Separate a successful build from a test result

The latest Windows Actions run I reviewed, on 14 October 2026, configured the windows-msvc-release preset and completed the build. The test step then failed before CTest could run: the preset writes to build/arcglass-msvc-release, but the workflow asks CTest to open build/windows-msvc-release. That run therefore provides build evidence, not a fresh test pass. The README records an earlier local Windows build and one CTest target passing on 6 October; that historical result is separate from the later CI run and does not show that the current workflow is green.

This difference is small in the workflow and important in the evidence. A compiled Engine_Tests.exe is not the same as tests being executed. The project currently registers one CTest target containing multiple internal checks, so that target’s coverage also should not be mistaken for a complete game-engine validation suite.

The next integration step

The most useful next milestone is a narrow path that crosses the current boundaries: load one supported asset through the editor’s asset workflow, save a scene, open that same scene in the runtime, and verify the rendered result in a repeatable test. Alongside that, the CTest directory should be derived from the selected CMake preset so CI runs the target it just built.

That would turn the current set of credible building blocks into stronger end-to-end evidence. Until then, I describe Arcglass as a C++20 and Direct3D 12 engine prototype with a verified Windows build path, a focused editor preview and several subsystems still under development.

For a related look at source-derived boundaries, read how Sentinel-DB keeps unsupported migration SQL in manual review and how I trace a client prediction correction through a Unity prototype.

← All notes