# D3D12_Research is a Windows toy renderer for DirectX 12 experiments > D3D12_Research is a personal C++ renderer that exists to try out rendering ideas: GPU driven rendering with mesh shaders, a visibility buffer with two phase occlusion culling, DDGI, tiled and clustered light culling, a render graph and a path tracing mode. It needs Visual Studio 2022 and a DirectX 12 capable GPU, and it has never been released as a version. **simco50/D3D12_Research** — Personal hobby project to experiment with various rendering techniques. - Repository: https://github.com/simco50/D3D12_Research - Stars: 814 · Forks: 37 - Language: C++ - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/simco50-d3d12-research ## A playground, not an engine The README is direct about what this is: a personal toy renderer meant as a playground for experimenting with ideas and rendering techniques. The repository description says the same thing, a personal hobby project to experiment with various rendering techniques. That framing explains the repository layout better than a feature list would. At the root there is a Source directory, a Resources directory, a ThirdParty directory for vendored dependencies, an Images directory holding the result screenshots, a clang-format configuration, and the Premake files that drive the build. There is also a D3D12.args.json, named for the arguments handed to the program when it is launched from the IDE. The substance is in the techniques, and the README lists them: GPU driven rendering, two phase occlusion culling, a render graph, deferred texturing, a path tracing mode, tiled light culling in the Forward+ style, clustered light culling in the Clustered Forward+ style, cascaded shadow maps, volumetric lighting, bindless resources with no input layouts, compute particles, dynamic eye adaptation, screen space reflections, raytraced reflections, screen space ambient occlusion, raytraced ambient occlusion, temporal anti-aliasing, a microfacet BRDF and shader hot-reloading. Three of those are marked as work in progress in the list, screen space reflections, raytraced reflections and raytraced ambient occlusion, which is an unusual amount of honesty for a repository of this kind and a useful signal about the state of the code. The code is C++, the licence is MIT, and the project is explicitly aimed at people who want to try rendering ideas rather than ship a game. ## Premake generates the Visual Studio projects There is no committed Visual Studio solution, because the solution is generated. The repository ships premake5.exe and premake5.lua at the root, and the README gives the two steps: Run scripts/Generate_VS2022_Windows.bat to generate the Visual Studio project files, then open D3D12.sln and compile and run. ```bash scripts/Generate_VS2022_Windows.bat ``` That means the IDE project files are not checked in but generated, which is why the repository can target one toolchain without carrying generated projects in version control. It also explains why the build is Windows-only in practice rather than by policy: the generator produces Visual Studio projects. There is a .clang-format file, so the C++ is formatted with a checked-in style rather than by personal preference, and a .gitignore to keep generated output out of the tree. The Resources directory presumably holds the assets the sample scenes load, and the Images directory holds the screenshots that the README embeds. One practical note for anyone trying this on a fresh machine: the batch file is the entry point, and it needs the Visual Studio toolchain and the Windows SDK it references, so the order of installation matters. The requirements list is short enough to state in full, which is unusually helpful for a hobby repository. ## The hardware floor is a Tier 3 resource heap GPU The requirements section tells you exactly what this renderer expects, and it is not a modest list. Visual Studio 2022 is required. The Windows SDK version is pinned to 10.0.19041.0. And the GPU has to be DirectX Raytracing compatible with Resource Heap Tier 3 support. Resource Heap Tier 3 is the constraint that shapes the code. Tier 3 is the feature level that makes bindless resources and large descriptor heaps possible, and the README lists bindless resources with no input layouts as one of the notable features. Those two facts are connected: without Tier 3 there is no large enough heap for the bindless design, so the renderer simply will not run on hardware that predates it. The DXR requirement is separate and comes from the ray tracing work in the feature list, from raytraced reflections and raytraced ambient occlusion through to the path tracing mode and the reference path tracer section of the images. For an engineer evaluating the repository this is the first thing to check, because it rules out a lot of machines. A laptop GPU from a few years ago, or a virtual machine without a DXR capable adapter, will not run this. There is also no software rasteriser fallback mentioned anywhere in the documentation. The pinned SDK version is worth noting separately. Pinning 10.0.19041.0 means the code was written against a specific SDK surface, and a newer SDK may require adjustments even when the GPU is capable enough. ## GPU driven rendering into a visibility buffer The centrepiece of the repository is the visibility buffer path, and the README describes it in one sentence: GPU driven rendering with mesh shaders using the two phase occlusion algorithm to a visibility, or ID, buffer. Each of those terms is a design commitment. GPU driven rendering means the GPU decides what to draw rather than the CPU issuing draw calls per object, and mesh shaders are the DirectX 12 feature that makes that practical, because the GPU can amplify a small set of mesh shader invocations into many primitives. Two phase occlusion culling is the visibility decision: a coarse phase that rejects whole objects, and a finer phase that rejects individual triangles, before anything is rasterised into the visibility buffer. Deferred texturing then means the buffer is not a final colour target but a record of which triangle each pixel came from, with materials resolved later. The images section pairs a two phase occlusion culling screenshot with the visibility buffer deferred texturing screenshot, which is a good way to read the code: the buffer image is the intermediate the technique produces, and the culling image shows the input to it. Bindless resources with no input layouts are the companion change. Instead of binding per-object vertex buffers and input layouts, the geometry sits in one large heap and the shaders index it. That is what Tier 3 resource heaps are for. A separate section covers the concurrent binary tree, described in the README as GPU driven runtime subdivision, so the alternative subdivision strategy is visible in the same codebase as the mesh shader path. ## Many lighting techniques live in one codebase The images section is effectively an index of experiments, and the lighting work is the most extensive part of it. Dynamic diffuse global illumination appears as a set of comparison images: DDGI on, DDGI disabled, and a path traced reference. That triple is the interesting part, because it means the renderer can show the same scene three ways, which is the only way to judge whether a real-time approximation is behaving. Light culling is present in both common forms. Tiled light culling in the Forward+ style divides the screen into tiles, and clustered light culling in the Clustered Forward+ style divides it into clusters, with the images showing the view alongside the tiled and clustered bucket assignments. Cascaded shadow maps appear with a colour coded view of the cascades, which is again a debugging aid rather than a marketing shot. Volumetric fog, volumetric clouds, auto exposure and dynamic eye adaptation are each shown as enabled and disabled pairs. A reference path tracer sits alongside the real-time modes as the ground truth. The pattern across all of these is comparison. Every technique in this repository is presented next to the state without it, and several are presented next to a path traced result, which makes the repository unusually useful as a reference even if it is not usable as a product. The microfacet BRDF entry and the temporal anti-aliasing entry place the work in a physically based shading context, and the compute particles entry shows that the compute side of DirectX 12 is being used as well. ## The engineering scaffolding: render graph, profiler, hot reload A technique showcase is only useful if you can see what it is doing, and that is where the tooling sections come in. The render graph section shows a resource re-use view and a graph visualisation, which tells you the renderer tracks dependencies between passes and reuses resources across them. If a graph visualisation exists, you can inspect the pass structure of a frame rather than guess at it from the code. There is a CPU/GPU profiler section with a screenshot of its output. A renderer that claims GPU driven rendering, clustered lighting and a path tracing mode without a profiler is hard to evaluate, since every claim becomes an assertion. Shader hot-reloading is in the notable features list, and for an experiment-driven repository this is a development tool rather than a rendering technique. The point of a playground is the edit and rerun loop, and hot reloading shortens that loop from a rebuild to a recompile of one shader. The D3D12.args.json file at the root is the other piece of that tooling story, carrying the launch and debugging arguments Visual Studio uses when the sample runs. Taken together, the render graph, the profiler and the hot reloading are the infrastructure that makes the technique list maintainable by one person, which is the actual constraint this repository operates under. ## Where this renderer is the wrong tool The limitations are severe and they are the kind that follow from the project being a personal playground on Windows. It is Windows only. The build path is a batch file that generates Visual Studio projects, the requirements name Visual Studio 2022 and a pinned Windows SDK, and there is no Linux or macOS path described. For a renderer study you might reasonably want to run on Linux, that is disqualifying. It is not a framework. There is no documented API for adding your own passes, no plugin interface, no scene format, no asset pipeline and no documentation of the internal structure beyond a README with a feature list and screenshots. The premake5.lua is the only description of the module layout that exists, and reading a Lua build file to understand a renderer's architecture is not a substitute for documentation. It has never been released. The repository has no GitHub releases, so there is no tagged version to pin, and the default branch is master. Anyone building on this code is tracking a moving branch. The maintenance state deserves to be stated precisely. The repository is not archived, and the last push was on 2026-04-19, which is a little over six months ago. That is recent enough to show the work was alive and old enough that you should not assume anything about the current state of master. Three features are marked work in progress, and the Images directory is a set of stills rather than a test suite, so there is no way to tell from the repository whether a given technique still behaves as its screenshot suggests. The licence is MIT, which means you may reuse the code freely, including in commercial work, with the notice requirement, which is the friendliest part of the whole arrangement. ## Conclusion Graphics engineers who want to read working code for GPU driven rendering, deferred texturing, two phase occlusion culling, DDGI and clustered light culling should study this repository, because the techniques are implemented side by side with the images that show what each one changes. It is the wrong starting point for production work, since it is a hobby project with no releases, no documentation beyond a feature list, and a hardware floor of a DirectX 12 Resource Heap Tier 3 GPU on Windows. Before you build on any of it, generate the Visual Studio projects with scripts/Generate_VS2022_Windows.bat and confirm the technique you care about actually runs on your GPU, and note that the last push was on 2026-04-19. ## FAQ ### What are the hardware requirements for the D3D12 toy renderer? Visual Studio 2022, the Windows SDK 10.0.19041.0, and a DirectX Raytracing compatible GPU with Resource Heap Tier 3 support. Tier 3 is what makes the bindless resource design possible, and there is no software fallback described. ### How do I build the D3D12_Research project? Run scripts/Generate_VS2022_Windows.bat to generate the Visual Studio project files from the Premake configuration, then open D3D12.sln and compile and run. The repository ships premake5.exe and premake5.lua at the root rather than a checked-in solution. ### Which rendering techniques does this repository implement? The README lists GPU driven rendering, two phase occlusion culling, a render graph, deferred texturing, a path tracing mode, tiled and clustered light culling, cascaded shadow maps, volumetric lighting, bindless resources without input layouts, compute particles, dynamic eye adaptation, screen space reflections, raytraced reflections, screen space ambient occlusion, raytraced ambient occlusion, temporal anti-aliasing, a microfacet BRDF and shader hot-reloading. ### Is D3D12_Research suitable for production use? No. The README describes it as a personal toy renderer and a playground for experimenting with ideas, it has no GitHub releases, and the documentation is a feature list with screenshots rather than an API description. The licence is MIT if you want to reuse the code. ## Sources - [Issues](https://github.com/simco50/D3D12_Research/issues) - [License: MIT](https://github.com/simco50/D3D12_Research/blob/master/LICENSE) - [README](https://github.com/simco50/D3D12_Research/blob/master/README.md) - [simco50/D3D12_Research on GitHub](https://github.com/simco50/D3D12_Research) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/simco50-d3d12-research