The performance target thing worries me A TON though. 1080p 30 with Hardware RT Lumen on Next Gen consoles. That's not acceptable, even with their new upsampler.
...Just why? I thought hardware-RT is faster than software RT at the same quality settings? Why not combine Medium Lumen + Hardware RT to get crazy good performance? It looks more than good enough. Or is triangle based Raytracing really that inefficient and their software solution is simply faster?
Did not watch the video, but summing up the points already made before eventually explaining why software can be faster:
1. UE5 tends to have lots of overlapping models / instances. With HW RT this means overlapping BLAS, and each one has to be processed to find all ray hits. Only after that we know which object was hit first, the other traversal and intersection work is for nothing.
With SDF tracing, distance to closest hit is already known on ray entry to the per object SDF. So we can reject all objects but the closest one early, and only trace the single object which will give us the closest hit. That's a really interesting advantage of SDF over BVH.
To fix the problem, we they could avoid overlapping multiple BLAS by merging all geometry into a single BLAS (or fewer of them). But this would not reduce the number of (mostly hidden) triangles, so it's still not optimal, but we loose the option to save lots of memory by using instances of BLAS per object.
A better compromise might be to remove hidden triangles below the surface, which would be possible on the client using SDF blocks. It would break some easy streaming, so that's some work and will take time. Downside is: With full RT solution, having SDF blocks just for that purpose is storage and memory waste. So it would be better to mark hidden triangles per instance offline and use that smaller data over SDF blocks.
2. Current DXR does not allow continuous LOD like Nanite, so from the above we can only expect lower poly proxies, which still need discrete LODs at least to keep things scalable.
Epic may try to request RT API improvements so they can work on a proper solution instead hacks, which will take even more time.
So, maybe disappointing RT perf. at the moment is a good thing helping to improve RT APIs, which were designed without LOD in mind.To me, the cause and failure clearly lies on the API side and isn't Epics fault.