Define precise. Lumen s/w is using SDF representation for those which are considerably less precise than proxy meshes used for Lumen h/w.
If you want 1:1 mapping then Nanite must be done in a different way - but is it really needed?
Yes, it is needed. But your comparison of Lumen SDF for GI is not suited, as for GI geometric or material precision is neither needed nor good.
Shadows is the best example. Say we want area light shadows of a tree. This means soft shadows on the ground and sharp self shadows on the tree. Shadow maps can't do this well, but RT can.
Though, if we use proxy geometry for the tree different from the visual mesh, we get self shadows and peter panning, so exactly the problems RT promises to finally solve.
Thus, shadow maps will remain the only robust solution for Nanite models. RT can be used only for GI or reflections (to some degree), where error is acceptable.
(That's my personal conclusions and assumptions, maybe somebody can confirm or correct me.)
Now you may ask if shadows are that important, and if accelerating GI and reflections isn't much more benefit.
But for me HW RT can not accelerate my GI, nor can it make it more accurate.
Thus, all i get from HW RT would be imperfect reflections, which isn't worth the extra cost of maintaining proxy geometry and runtime BVH building just for that.
Much more likely i'm better off with compute tracing my surfel hierarchy to get imperfect reflections. A bit blurrier, but probably faster on average, and much less memory for sure.
RT doesn't prevent any progress with LOD, what it does is prevent using said progress inside the results of RT itself. These are two completely different issues.
No, LOD is the independent problem here. Triangle meshes work for both raster and RT.
But current RT does not work for resolution adaptive triangle meshes, which are the only option to achieve fine grained LOD using triangles.
Thus, current RT APIs do prevent any progress to achieve such fine grained LOD for RT. Period, and no further discussion required. That's the true situation.
The only option for LOD for RT is discrete LOD. But that's no solution to the problem. It does not work for large models. You need to split them into multiple pieces, which causes overlapping BVH like kitbashing, increased workload on generating TLAS, visual glitches, and increased content production costs.
Which one? Just don't say Avatar again, which won't require RT. So which game will be the first with RT on minimal specs? (just out of interest)
It can "beat" h/w by being considerably less precise and glitchy while running at the same or lower performance.
Not sure. Less precision can actually halp for GI, as a prefiltered sample gives a good average otherwise requiring many point samples for the same result.
But i won't argue. If you say Lumen sucks, that's two of us. Portal RTX looks way better. ; )
But these even if used during content creation aren't present in the shipping code as is anywhere for the same reasons why they are introducing issues in UE5 - they are bad for actual rendering, with or without TR.
Misunderstanding? The first UE5 demo (Land of Nanite?) used heavy kitbashing. They mentioned up to 20 layers of models, like onion skin. This can't be optimized away for a shipping game, because all those 20 models are somewhere visible.
If they are not visible but deep below the visible surface (will happen few times), raster will cull them, and RT will find the closer intersection before traversing them, for the most cases. It should not degrade perf. too much.
But lets close this for now and see if shipping games indeed use such insane detail levels at all.
There is, it's using the same proxy mesh as Nanite is using anyway. Proxy meshes there are not for RT.
Ahrg. You can't deal with your shiny god having some fails too, no?
You can generate proxy meshes using Nanite, but that's not it's distinctive feature.
Nanites function is (visually) continuous detail, which only is possible if you edit a static mesh locally. The entire mesh becomes 'dynamic', even if it's meant to look static.
To support this for HW RT, the only current option would be to rebuild the BVH from scratch every frame, for each instance of every model in the whole scene. This is not possible in real time.
You surely understand this, so stop pretending you wouldn't, please.
No further corrections from my side about this.
We can safely say that this is not the case as otherwise we'd already see the h/w being used this way if not in Vulkan IHV EXTs then on PS5 at least.
No. Because PC holds back consoles just as much as consoles hold back PC. It isn't worth to make specific solutions just for one platform.
And there are no VK extensions to expose BVH data structures.
Let's see if the platform lives long enough to require this.