# TrueTrace: a Unity path tracer that runs on compute shaders and does not need RT cores > TrueTrace is a path tracer for Unity that implements the whole thing in compute shaders and HLSL, so it works on integrated graphics, while still using hardware ray tracing where the card has it. The feature list covers the usual path tracing ground plus a Light BVH, ReSTIR GI, bindless texturing and photon mapping, and the author is candid that the ReSTIR implementation is cursed. **Pjbomb2/TrueTrace-Unity-Pathtracer** — A High Performance Compute Shader Based Mesh Pathtracer in Unity3d without RT Cores - Repository: https://github.com/Pjbomb2/TrueTrace-Unity-Pathtracer - Stars: 1,016 · Forks: 64 - Language: C# - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/pjbomb2-truetrace-unity-pathtracer ## The goal: interactive path tracing regardless of the hardware TrueTrace is a high performance compute shader based path tracer for Unity, and the project's own framing is worth quoting because it sets the expectation. It is a passion project that has been going on for a while, with the goal of bringing at least interactive path tracing to everyone in Unity, regardless of their hardware. That last clause is the whole design brief. A hardware path tracer needs RT cores, which means it needs a discrete card from the last few generations, and everyone else is excluded. TrueTrace implements the same algorithm on compute shaders instead, so the requirement becomes a GPU that can run compute shaders at all, which includes integrated graphics. The feature list leads with exactly that. High performance compute shader based path tracing without RT cores, and a Compressed Wide Bounding Volume Hierarchy for high performance software RT, with no RT cores needed. And then, separately, hardware RT support for modern cards, so the same scene can use the hardware path when it is available and fall back to the software path when it is not. The rest of the list is a complete path tracing feature set, and the order tells you what was hardest. The material model is a full Disney BSDF. Light sampling is Next Event Estimation with Multiple Importance Sampling, backed by a Spherical Gaussian Light Tree or the Light BVH for Next Event Estimation, with support for all default Unity lights using NEE. Environment lighting gets Environment Map Importance Sampling. Global illumination has ReSTIR GI, described in the list as cursed implementation. Denoising is split in two: ASVGF for realtime and OIDN for offline. Beyond the path tracer proper there is a long list of engine integration work. Bloom, depth of field, auto exposure, TAA and tonemapping are supported. Precomputed multiple atmospheric scattering for the sky is included. Object instancing works without RT cores. There is a radiance cache, a material preset system, IES for spotlights, and efficient panorama rendering. True bindless texturing is supported, credited to Alex Bakanov for bringing bindless textures to Unity, and the README gives massive thanks to him for it. The primary language is C#, the licence is MIT, and the recent releases are v2.7.2 in December 2025 described as QoL, v2.7.1 in November 2025 described as hotfix and more, and v2.7 in October 2025. The repository is not archived, with the last push on 2026-08-21. ## Installation is a Unity package, and it needs one restart The repository listing is short and tells you how the project is distributed. There is TrueTrace/ which is the Unity project itself, TrueTrace.unitypackage with its .meta file, TrueTrace.meta, the README and its .meta, the LICENSE with its .meta, the .Images/ directory, and .github/. The .meta files next to everything are the giveaway, since that is Unity's asset tracking format, and the whole project is a Unity package rather than a source repository in the usual sense. So it is installed by importing TrueTrace.unitypackage into a Unity project, and the second point in the feature list is the one that catches everyone out. After you first install TrueTrace, you will need to restart the Unity project this one time, so that the bindless plugin can initialize properly. A project restart in Unity is a heavier operation than it sounds, because it recompiles scripts and reimports assets, and on a large project it can take a while. The reason given is the bindless plugin, and that connects to the feature list entry for true bindless texturing. Bindless means the renderer does not bind individual textures one at a time, it keeps them all resident and indexes into them, and the plugin that sets that up has to be present before the first frame. So the one-time cost of a restart is the price of the texture path. Beyond that, the setup is per scene and per object, and the README is unusually explicit about it because getting it wrong produces a scene that renders incorrectly rather than one that errors. The automatic method starts with adding your gameobjects as a child of the Scene gameobject created by TrueTrace. Then either a global setup, pressing Auto Assign Scripts in the TrueTrace settings menu, or a local setup where you go to Hierarchy Options in the same menu and drag the root gameobject you added into the Selective Auto Assign Scripts section and click Selective Auto Assign. The manual method is the fallback when the automatic one does not do what you want. Each gameobject that contains a mesh needs the script RayTracingObject added to it, which keeps track of per-mesh materials. For non-skinned meshes you then add a ParentObject script either to each gameobject that has a RayTracingObject script, or to the direct parent gameobject of those gameobjects, which groups their meshes together and increases performance. For skinned meshes the ParentObject goes on any parent gameobject of the RayTracingObjects, which groups together all skinned children. And for default Unity lights you just add the RayTracingLight script to each one. The grouping detail is the performance lever. A ParentObject on each mesh gives per-mesh control, and a ParentObject on the parent gives a single group, and the README says grouping increases performance. The cost of that grouping is that adding or removing an object later rebuilds the acceleration structure for the whole group, which the general notes section comes back to. ## The acceleration structure, and what happens when you change the scene The general use notes are where the practical behaviour of a path tracer in an engine becomes clear, and they are more honest than a feature list usually is. The first note is about the acceleration structure. The green and red rectangle shows when the acceleration structure is done building and thus ready to render, red means it is not done, and green means it is done building. A ding will sound when it completes if it takes longer than 15 seconds, and you can turn that on in TrueTrace Settings under Functionality Settings. So there is a visible state, a colour and a sound, for the fact that the BVH has to be built before the scene can be path traced. That is unavoidable in this design, since the compute shader path needs a traversal structure over the scene, and the software path needs a compressed wide BVH rather than the hardware's own traversal. The status indicator is the kind of thing a well-built engine integration would provide, and the fact that the sound is off by default and configurable suggests the author has thought about how irritating it would be on a big scene. The second note is the cost of dynamic scenes. Objects can be added and removed at will simply by toggling the associated GameObject with a ParentObject script on and off in the hierarchy, but they will take time to appear as the acceleration structure needs to be rebuilt for them. The README also warns that clicking on parent objects with complex children will lag, which is the hierarchy view itself becoming slow because of what it is tracking. This is the fundamental trade of a path tracer in a real time engine, and the feature list contains the two halves of the answer. On the rendering side there is runtime transform, add and removal of objects, and runtime modifiable materials. On the performance side there is a Compressed Wide Bounding Volume Hierarchy for high performance software RT, and refitting appears in the topic tags, which is the technique for updating a BVH after a small change rather than rebuilding it. So the workflow is: change something, wait for the structure to rebuild, and the frame is now path traced. That is a perfectly good workflow for an artist tweaking a lighting setup, and a poor one for a game that changes every frame. The project does not pretend otherwise. There is a related constraint with emissive meshes. They need to have a non-zero emissive value when they are built or rebuilt to work with NEE, but after that their emissiveness can be changed at will. The reason is structural rather than a limitation of the material model: Next Event Estimation needs to know the light is emitting when the structure is built, so that it can be sampled directly rather than found by accident. ## The lighting model, the two denoisers and the rest of the engine integration It is worth pulling the feature list apart into the parts that are the path tracer and the parts that are the Unity integration, because the second group is where a lot of the work actually is. The rendering core is the Disney BSDF for materials, Next Event Estimation with Multiple Importance Sampling, and a Spherical Gaussian Light Tree or the Light BVH for sampling the lights. The Light BVH is credited to PBRT 4, and that is the right reference, because a Light BVH is the standard answer to the problem of a scene with many lights, where brute force sampling does not scale. The Spherical Gaussian Light Tree is a more recent approach with a different representation, credited to a GPU Open publication on hierarchical light sampling with accurate spherical Gaussian lighting. The diffuse models are interesting because they are research rather than industry. The list names Lambert or EON diffuse models, with the vMF Diffuse Model and the EON Diffuse Model both credited to papers. The vMF one is described as a unified rough diffuse BRDF from NVIDIA research, and the EON one is a 2024 arXiv paper. So the material system has interchangeable diffuse lobes rather than one fixed one. Then the denoising pair, and this is a design decision rather than a feature. ASVGF is for realtime denoising and OIDN is for offline denoising, so the project offers both a cheap approximate denoiser for interactive use and a proper one for stills and final renders. That is a sensible split, and it is why the README recommends DX12, since OIDN requires it. ReSTIR GI is listed as a cursed implementation, and the parenthetical is unusual enough to be worth repeating verbatim rather than paraphrasing. It means the author has shipped a working but rough implementation of a technique that is difficult to get right, and is telling you so. That is more useful than a claim that it works well. Photon Mapping is there for fast but not realtime caustics, and Full Multiscatter Fog is marked as not realtime, so both are explicitly in the offline category. The Unity integration group is long: object instancing without RT cores, runtime transform add and removal of objects, runtime modifiable materials, animatable material properties, a material preset system, a radiance cache, IES for spotlights, efficient panorama rendering, a Radiance Cache, orthographic camera support, full skinned mesh support, deformable standard meshes, Unity heightmap terrain and heightmap trees, and a simple upscaling ability. Several entries credit other people's work, and the project is careful about it. Convolution Bloom is marked as not mine, with a link to the FFTConvolutionBloom repository. Mesh slicing using SDFs does not modify meshes and is for rendering cuts only, like cross-sections. Vulkan and Metal support comes with the warning that your mileage may vary. The list also includes the render pipeline question, and the answer is that it supports the Built-in, HDRP and URP pipelines, with a separate credit for the URP compatibility script inspiration. For a tool that replaces the rendering path, supporting all three is unusual, and it is probably the single most valuable line in the list for anyone who has a real project. ## The material workflow, where roughness lives in the occlusion slot One configuration note in the README is likely to cost an afternoon if you do not read it, and it is the kind of detail that only appears when a project has been asked to work with an existing asset library rather than its own. To set up PBR with the default BIRP material, all textures go into their proper names, but roughness goes into the occlusion texture. This can be changed in the MaterialPairing menu. The reason is that Unity's standard PBR shader packs occlusion, roughness and metallic into a single texture, the standard metallic roughness map. An occlusion map is normally a separate grayscale texture with the ambient occlusion baked in, but in the packed Unity layout the R channel is occlusion, the G channel is roughness and the B channel is metallic. So there is no separate roughness slot to put the map into, and the tool takes the packed map's roughness channel and treats it as the occlusion slot, with the MaterialPairing menu letting you change which channel it reads. That is an accommodation of Unity's asset convention, and it is a good example of what a path tracer integration has to deal with that a standalone renderer does not. The material model here is a full Disney BSDF with PBR texture support, and the textures still arrive in Unity's layout, so the mapping has to be reconciled somewhere. Putting it in the MaterialPairing menu rather than hardcoding it means a project with a different convention can work. The other item in the same area is blendshapes. If you are using blendshapes to change the geometry of a skinned mesh, you may need to go to the import settings of it in the inspector, turn off Legacy Blendshape Normals, and make sure all normals are imported and not calculated, otherwise the normals will be wrong. That is a Unity import setting rather than a TrueTrace setting, and the reason it matters here is that the path tracer relies on the mesh normals being correct, so a normal recomputed at import time rather than carried through from the source asset will be subtly wrong in the render. The last integration note worth flagging is the camera. The camera you want to render from, you attach the RenderHandler script to it, and if you have a camera tagged MainCamera this is done automatically. And DX12 is recommended, because it enables use of OIDN, bindless texturing, RT cores and higher performance. That last recommendation is the clearest statement of the project's priority order. The software path exists so the tool is not locked to recent hardware, but the preferred configuration is the one where the hardware does the work. ## Conclusion TrueTrace fits a Unity developer who wants path traced rendering in a project and can accept that the tool is a passion project maintained by one person, that quality and performance are hardware dependent, and that the setup involves manually attaching scripts to scene objects. It is the wrong choice if you need a supported, guaranteed API, and the wrong choice if your target hardware cannot run compute shaders at all. Before installing, read the first install note about the required project restart, plan for the fact that the acceleration structure is rebuilt whenever objects change, and check the material pairing rules, because the default PBR workflow expects roughness in the occlusion texture and that is not where you would look for it. ## FAQ ### Does TrueTrace need a GPU with RT cores? No. The path tracing is implemented in compute shaders and HLSL over a Compressed Wide Bounding Volume Hierarchy, so it runs on integrated graphics. Hardware ray tracing is used where the card supports it, and the feature list states no specific GPU vendor is needed and no RTX cores are required. ### What do I have to do after installing TrueTrace in a Unity project? You have to restart the Unity project once so the bindless plugin can initialize properly. Then you add your gameobjects as children of the Scene gameobject TrueTrace creates, and either press Auto Assign Scripts in the settings menu or use Selective Auto Assign for specific hierarchies, or attach the RayTracingObject, ParentObject and RayTracingLight scripts manually. ### How does TrueTrace handle scene changes at runtime? Objects can be added and removed by toggling GameObjects with a ParentObject script, but the acceleration structure has to be rebuilt for them, so they take time to appear. A rectangle in the editor shows the state of the build, green when it is ready to render and red while it is still building, with an optional sound after 15 seconds. ### Why does my roughness texture need to go in the occlusion slot in TrueTrace? With the default PBR material, all textures go into their proper names, but roughness goes into the occlusion texture, because Unity's standard PBR layout packs occlusion, roughness and metallic into one map and there is no separate roughness slot. The MaterialPairing menu lets you change which channel is read. ## Sources - [Issues](https://github.com/Pjbomb2/TrueTrace-Unity-Pathtracer/issues) - [License: MIT](https://github.com/Pjbomb2/TrueTrace-Unity-Pathtracer/blob/main/LICENSE) - [Pjbomb2/TrueTrace-Unity-Pathtracer on GitHub](https://github.com/Pjbomb2/TrueTrace-Unity-Pathtracer) - [README](https://github.com/Pjbomb2/TrueTrace-Unity-Pathtracer/blob/main/README.md) - [Releases](https://github.com/Pjbomb2/TrueTrace-Unity-Pathtracer/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pjbomb2-truetrace-unity-pathtracer