
Godot Ray Tracing: The NVIDIA RTX Fork
NVIDIA released a path tracing fork of Godot at GDC 2026. It is a fork, not a mainline feature. Do not assume that the fork and a stock Godot release have the same rendering features or hardware requirements.
Godot is also building native ray tracing support separately. Godot 4.7 dev 1 landed initial Vulkan RT plumbing by Antonio Caggiano. These are two parallel tracks that may converge.
Most indie devs will not use this today, and that is fine. The trajectory matters more than the current state. Godot now has credible RT work happening from both NVIDIA and the core team.
A fork, not a feature
At GDC 2026, NVIDIA released a path tracing fork of the Godot engine . This is not a plugin you drop into your project. It is a modified version of Godot itself , hosted under NVIDIA’s GitHub organization and released under the MIT license.
The fork required low-level rendering changes that could not be done as an addon within Godot’s current architecture. NVIDIA modified the rendering pipeline to replace rasterization with full path tracing, which means every pixel in the scene is computed by simulating actual light bounces rather than using screen-space approximations.
80.lv covered the launch , and the Godot community response on the forums has been a mix of excitement and realistic caution.
Before trying the fork, check its own build instructions, supported hardware and known limitations. Vulkan capability alone is not enough to establish that a GPU will work with a particular branch and denoiser.
https://github.com/NVIDIA-RTX/godot/tree/nvidia-pt-dlss
How this actually works
Traditional game rendering uses rasterization: project every triangle onto the screen, then fake lighting with a stack of tricks (shadow maps, screen-space reflections, ambient occlusion probes). It is fast and looks good enough for most games. Every Godot game you have played uses this approach.
Path tracing flips the model. Instead of projecting geometry to pixels, you shoot rays from the camera into the scene and simulate how light actually bounces between surfaces. Reflections are physically accurate. Soft shadows happen automatically. Global illumination is a natural result, not a separate system you have to tune.
The tradeoff is brutal on performance. A single path-traced frame might need thousands of rays per pixel to converge to a clean image. Real-time path tracing is only possible because modern GPUs have dedicated RT cores that accelerate ray-scene intersection tests, and because AI-based denoisers can reconstruct a clean image from a noisy one rendered with far fewer samples.
Most shipped games that advertise “ray tracing” actually use a hybrid approach: rasterize most of the scene, then use RT for specific effects like reflections or shadows. The NVIDIA Godot fork goes further with full path tracing, where the entire image is ray-traced. This is the same approach used in NVIDIA’s RTX Remix for classic game mods .
NVIDIA’s fork and Godot’s native RT work
Here is what makes the current situation interesting: there are two separate efforts to bring ray tracing to Godot, and they are happening in parallel.
NVIDIA’s fork is a separate code branch. Its existence does not establish that the same features are available in a stock Godot release. Check the branch itself for its current state.
https://github.com/NVIDIA-RTX/godot/tree/nvidia-pt-dlss
Godot’s native work has a separate milestone. The Godot 4.7 dev 1 announcement credits Antonio Caggiano’s GH-99119 with Vulkan ray-tracing groundwork and links to a GDScript demonstration. The 4.7 beta 1 announcement also describes this groundwork. These announcements should not be read as confirmation that NVIDIA’s fork has merged or that Godot has gained a finished built-in path tracer.
https://godotengine.org/article/dev-snapshot-godot-4-7-dev-1/
https://godotengine.org/article/dev-snapshot-godot-4-7-beta-1/
The demonstration linked by the project is here:
https://github.com/Fahien/godot-raytracing-gdscript-demo
The best outcome is convergence: NVIDIA’s path tracer gets refined, the Godot core team reviews and adapts the rendering changes, and some version of RT support lands in mainline Godot. Whether that happens as a merged PR or an official GDExtension addon remains to be seen.
Honestly? Not much yet.
If you are building a 2D platformer, a roguelike, or even a stylized 3D game, this changes nothing about your workflow today. And that is okay.
Path tracing is a AAA rendering technique. It demands a high-end GPU from your players, it limits your audience to desktop, and it solves a problem (photorealistic lighting) that most indie games do not have. The games driving Godot’s growth on Steam, which doubled yearly to 2,864 titles in the 2025-26 period , are almost entirely games that look great with rasterization.
But the trajectory matters more than the current state. Here is why:
Credibility. When studios evaluate Godot for 3D projects, “does it support ray tracing?” is a checkbox question. The answer used to be a flat no. Now it is “NVIDIA built a working implementation, and native support is in development.” That shifts conversations.
Check requirements on the branch you plan to use
Do not choose hardware from a generic Vulkan ray-tracing support list. Check the exact branch, driver requirements, denoiser and known limitations first. Test a copy of your project before treating an experimental renderer as part of your shipping plan.
https://github.com/NVIDIA-RTX/godot/tree/nvidia-pt-dlss
Unreal has had this for years
Let’s be direct: Unreal Engine has supported ray tracing since version 4.22 in 2019 . Lumen, Unreal 5’s global illumination system, uses a hybrid approach with software and hardware ray tracing. Fortnite runs Lumen on consoles. This is production-proven technology.
Godot is not competing with Unreal on photorealistic rendering, and it should not try. If your project needs Lumen-quality global illumination, Nanite-level geometry, and MetaHuman character fidelity, Unreal is the right engine.
What the NVIDIA fork demonstrates is that Godot’s Vulkan renderer is flexible enough to support path tracing at all. For an open-source engine that was primarily 2D-focused five years ago, that is significant. Godot 4.6 already brought Jolt Physics as the default and overhauled screen-space reflections , and the 3D pipeline keeps improving with each release.
The gap with Unreal on high-end rendering is still wide. But it is narrowing, and the NVIDIA fork proves the architecture can support it.
The signal is bigger than the feature
Even if 95% of Godot developers never touch path tracing, this fork matters for three reasons:
NVIDIA is investing engineering resources in Godot. This is not a weekend hack. Building a path tracer that integrates with Godot’s rendering pipeline, scene system, and material model is serious work. NVIDIA choosing to do this signals that they see Godot as a platform worth supporting.
It validates Godot’s architecture. The fact that NVIDIA could build this as a fork (rather than requiring a ground-up rewrite) suggests that Godot’s Vulkan renderer is well-structured enough to support advanced rendering techniques. That bodes well for future graphics features.
It gives the Godot rendering team a reference implementation. Even if the NVIDIA fork never merges directly, the core team can study the approach, identify which architectural changes are needed, and incorporate lessons into the native RT work happening in 4.7.
For most developers reading this, the practical advice is simple: keep building your game with Godot’s current renderer. It is good, it is getting better, and it handles everything from 2D pixel art to stylized 3D well. Do not plan a release around a future ray-tracing feature or merge date.
The fact that it exists at all is the real story.