Rtx mega geometry like for cycles
Currently, when our scenes get REALLY big, with tons of small objects, super-dense forests, ultra-detailed cities, or when we use Geometry Nodes to create worlds full of detail, Blender struggles to keep up. Rendering in Cycles can become very, very slow, sometimes using a lot of memory, and it makes working on these large scenes a bit frustrating. It's as if Blender isn't yet designed to handle astronomical amounts of detail all at once.
The idea:
Imagine if Cycles could handle MUCH more detail than it does today, much more smoothly. The idea would be to integrate a new way of handling geometry (all 3D objects, polygons, etc.) that is made for gigantic scenes.
Rather than processing each small object or group of polygons individually, this new system would organize everything super intelligently behind the scenes. It would allow Cycles to only look at and calculate what's really necessary for each ray of light, even if the scene contains billions of tiny hidden or distant elements.
It's a bit like Blender becoming an expert at juggling a crazy amount of toys at once, without dropping a single one and without wasting time looking at the ones inside the box.
Why would it be great?
Create scenes of incredible scale and richness: We could finally create infinitely dense forests, terrains with crazy micro-surfaces, cities populated with millions of tiny details, without Blender suffocating.
Render large scenes much faster: End (or almost...) the endless waiting times for the most complex renders. The calculations would be much more efficient.
Open new creative doors: This would make Geometry Nodes even more powerful for creating gigantic procedural worlds, or allow for the use of super-heavy 3D assets more easily.
Blender would feel more powerful: The user experience on large projects would be transformed, making Blender even more capable for ambitious productions.
This idea is inspired by new techniques (like what NVIDIA is doing with its "Mega-Geometry"; see the link if you're curious) that are being explored in the industry to manage gigantic virtual worlds in an ultra-efficient way. It would be incredible to have this integrated natively into Cycles!
The advantage of this technique is that it's directly powered by VK and therefore supported on all GPUs and all platforms! Its exactly like Meshlets (mesh shader) except this one is for Ray Tracing/ Path Tracing, so could be better ! And really efficient!
5 Comments
Uhh... this proposal is full of incorrect assumptions. For example:
It is a very confusing, and difficult to understand proposal. I get the higher level desire, but then it gets lost as it assumes stuff is for free. Would rather see that as this is a heavy technical proposal to proof your statements with a prototype. Making these technical proposals including the claims require a lot of knowledge and time in itself. The actual project can take years to finally realize (or technology to be able to actually do this).
You can also have trust to the developers to do the right thing in the right time and moment.
👀
Link ref : github.com/NVIDIA-RTX/RTXMG
That link is about a rasterizer approach, not related to cycles. Seems to be focus on allowing some "modifiers" to run on the GPU. Yes it would change memory with processing allowing more to happen, but seems to be far from what is asked here.
"RTX Mega Geometry (RTXMG) is a DX12 code sample that shows how to use NvAPI to quickly build ray-tracing acceleration structures for subdivision surfaces with structured clusters." Mention that it is a sample, not a library. So far from a feature complete.
Also check the requirements:
A few years back we have a chat about making a good design. An important topic of that for these technical proposals was to have as much of consequences as benefits. If this isn't balanced, than the value of the proposal is also limited. Perhaps revisit this for your next proposal
It’s true that, based on what I’ve read elsewhere online, implementing this is a real challenge because it combines two techniques that were originally considered "incompatible." However, with recent technological advancements and the significant time researchers have dedicated to these breakthroughs, it is now possible to make them work together (despite the fact that they are two distinct pipelines operating side-by-side). I must admit that the implementation of this "thing" is highly complex, but it’s not impossible.
Even though it’s unconventional to mix multiple pipelines, from what I understand, the rendering engine "Octane" does something very similar with its "Meshlets" system a concept I’ve already mentioned to you before! And now, RTX Mega Geometry is following a similar approach.
I also heard that something similar is being considered for "Arnold Render." Yes, it’s quite difficult to set up! But we’re talking about several months of work, not several years! To accelerate workflows, we now have amazing resources and tools that help maintain consistency and performance continuity during complex tasks.
I can understand why many developers might think that building a prototype would be a waste of time, fearing that the performance gains might not be significant enough. However, the current geometry pipeline is completely outdated sooner or later, it will have to evolve. Many studios have already migrated to real-time rendering engines for better scalability, on-demand performance, and improved visual results! It has been demonstrated repeatedly that this technology is reliable, provides real performance gains, and enables extremely high-quality 3D models!
It’s also true that some features are currently exclusive to Nvidia GPUs, which is quite unfortunate on Nvidia’s part. However, we still have "Meshlets"And this one works with all backend and all GPUS (as used in Octane, which looks very promising a solution you should definitely consider, it will make a big impact when it’s released in 2026)! Alternatively, if you're looking for something a bit simpler yet similar, I found this, which is compatible with all GPUs and also offers significant performance improvements (although again, it involves mixing two pipelines):
vcgdata .isti .cnr .it/Publications/2004/CGGMPS04/vbdam_sig04.pdf
Always a pleasure to read you, Jeroen! :)
Many technologies similar to Nanite already existed before Nanite! And many more have emerged since. This is just the beginning! At some point, we’ll have to seriously consider a full implementation, even if it’s complex. A lot of people (myself included) are waiting for true geometry streaming support for Blender / Cycles / Eevee.