Thread by @reduzio

Since this seems to have sparked some interesting discussion, here is my take of why I would _not_ implement something like Nanite in Godot and instead go for something else. Some complex technical points in thread, but make sure to fully unroll and read them first (thread) 🧵👇

The first thing to understand is that this type of technology is more 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 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 (thanks to large part amazing work from @RandomPedroJ, @dariosamo and @matiasgoldberg). This was needed before any work on a cinematic renderer...

But okay, lets say everything 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 that can maintain an insanely huge renderer..

Instead, to achieve similar goals, we have to be smart and plan properly to get the best possible results with the minimum amount of code that we can write and maintain.

So, how would a cinematic renderer work?

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..

As for Nanite. The problem with it is that Its also just too complex, it works as a hierarchical meshlet LOD, plus its 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 TBH 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.