The free cross-platform open-source Godot game-making engine has been around for over ten years now. Created by Argentinian developers Juan Linietsky and Ariel Manzur, it has been used so far by indie developers in games like Deponia, The Case of the Golden Idol, Cassette Beasts, Brotato, and the upcoming Slay the Spire 2. Perhaps the highest-profile game made with Godot was Sonic Colors: Ultimate, developed by Blind Squirrel Games.
As with all active engines, Godot is continuously updated by its makers. Last year, they added support for AMD FidelityFX Super Resolution 2.2 and several shader improvements. What’s next, though? Well, yesterday, creator Juan Linietsky wrote a lengthy thread on Twitter/X outlining the team’s goal for a cinematic renderer: they’d rather go with full path tracing than with a hybrid solution like Unreal Engine 5’s Lumen.
The first thing to understand is that this type of technology is more in the realm of cinematic renderers. It requires more modern, dedicated GPUs as a baseline. Most Godot users currently do not need or aim for this with their games; hence, it is not a priority. Instead, most of the work the past year was to first modernize the rendering base code and solve all the existing problems. This was needed before any work on a cinematic renderer.
But okay, let’s say everything is ready to do a cinematic renderer. The first thing to understand is that Godot is not Epic. The project does not have 150 veteran graphics engineers who can maintain an insanely huge renderer. […] First of all, it should be ray/path-tracing only (with base raster pass). This saves incredible amounts of work, as shadows, GI, reflections, etc. would all be ray traced. Hybrids like Unreal or Unity HDRP are far too much complexity, and hardware is getting there anyway.
It’s an interesting take, even though path tracing games can still be counted on one hand. Lumen does have a hardware-accelerated ray tracing option, by the way, but again, most developers just skip it in favor of the baseline software solution.
Godot’s Juan Linietsky also dived into why he’d rather not follow Epic’s approach to virtualized geometry (Nanite):
As for Nanite. The problem with it is that it is also just too complex; it works as a hierarchical meshless LOD, plus it’s not that friendly with raytracing, which is our main goal. Instead, a much simpler approach can be using more traditional auto-LODs with meshlets, all GPU-driven. This works great with raytracing (just stream LOD levels together). Has a bit more overdraw? Sure, but remember, we don’t have shadow maps, so we don’t care. Downsides? Probably slower for insanely complex, huge geometry if it spans hundreds of meters. Just divide it up (which most, if not all, games, do anyway), but for anything else, you still get great performance and detail. Also likely will use meshlet LRU less efficiently, but to be honest, unless you are an AAA studio, you don’t care about these things; you have something close that solves a similar problem, and on the Godot side, something way simpler to do and maintain.
Linietsky did not provide any timeline as to when the path-traced cinematic rendered might be implemented in Godot, but we’ll be certain to keep an eye out on the engine’s updates.
