JoeJ said:
Well, they achieve a lot of things i work on for years, and i think their tools are much faster. I have heavy preprocessing costs and could not claim to import high poly model and display immideastely.

They didn't show Unreal Engine 5 tools yet. I personally didn't like Unreal Engine 4 tools at all (they just seem too heavy and too slow) - others may disagree, as this is a personal opinion. My hope is that they make it a lot more lightweight.

JoeJ said:
Such high detail is a problem. Inconsistent amount of details expected. Can they have this on everything? The character certainly is not detailed enough for the environment. And what if no Quixel model is available for your game?

Using Quixel is “double edged sword" - you get photo realistic geometry on the objects, with very high quality geometry and textures. But you will most likely not get every model you need, those may stand out and ruin the immersion (and in the demo, as pointed out, character does stand out). Authoring content may be a problem (while photogrammetry gets a bit more standard these days, it is not suited for all the scenes and definitely not suited for some graphics styles - yet this would get us into different discussion, where everyone will have a different opinion due to different taste in art).

RT can support really large and complex models - yet the acceleration structure will grow accordingly. I haven't touched DXR much yet, but from my experience “tens of millions of triangles” when static are not really that big problem for RT (… once you have your acceleration structure built of course). Truth to be told - RT could possibly outperform their scene with multiple “tens of millions triangles” statue in room with instancing and multi-level acceleration structures.

JoeJ said:
But we can always come up with some doubts. They achieved a big leap, and it really shakes things up.

No doubts about that, their tech does look nice in the end (which is the goal) - if they pack right tools with it (which they will), they will find a market for their engine. I intentionally mentioned that it doesn't seem to me as a big breakthrough mainly due to lower use of RT than I expected (although I'm the person who pushes RT everywhere where he can, so take my opinion with a grain of salt).

Vilem Otte said:
Authoring content may be a problem

I think it will make game production only more expensive than it already is. But that's expected.

I see new options for procedural content. E.g. simulating materials and matter with fluid simulation, and using vector fields on geometry to guide procedural placement and growth.
Perlin noise and other building blocks we still use in Substance tools are no longer enough.

Vilem Otte said:
I haven't touched DXR much yet

Do you know, is it possible to stream BVH models, or must the driver build it at runtime?
I know RT suffers less form triangle counts, but details, huge scene and depth complexity like a forest will hurt it regardless, both with memory and performance. So i'd like the option of discrete LOD chunks at least.
Guess could solve the gaps with vector displacement map that gradually projects hitpoints to the bound of lesser detailed LOD near transitions to avoid artifacts from discrete LODs.
Having texture space shading in mind (no longer sure after UE5), i'd like to get rid of SM and use RT for cached high frequency direct lighting. RT should beat SM here also with performance due to caching and stochastic updates.

JoeJ said:
Do you know, is it possible to stream BVH models, or must the driver build it at runtime?

I will get a bit off topic here (as usual), but it is still related to RT (I will not be talking about DXR, I don't know deep details of its implementation - but I do know deep details of my own library - OpenTracer (subject name to change) - The library is an OpenCL based GPU ray tracing library).

Now, as my library supports different acceleration structures, realistically speaking for game scenes only two can be reasonably used those are (with limitation for first one):

OpenTracer::Aggregate::AGGREGATE_BVH and OpenTracer::Aggregate::AGGREGATE_MULTILEVEL

The first one (as others like KD-Tree) requires full acceleration structure rebuild each time you change anything in scene. So the limitation here is to use HLBVH builder (which is fast enough for more complex dynamic scenes).

The second one is actually multi-level BVH implementation. You have a top-level BVH (scene BVH) which contains other BVHs in its leafs, along with transformation matrix. Those BVHs (bottom-level) are BVHs for specific geometries in scene (of course this allows naturally for very fast instancing). Now comes the tricky part, both, top-level and bottom-level have certain configuration that defines what build algorithm is used (SAH, Split-SAH, HLBVH, etc.).

Clearly top-level BVHs need to be rebuilt every time something moves in the scene. Using standard binning-SAH is fast enough for real time use.

Bottom-level BVHs are a different thing. They are built once (ideally using Split-SAH as that gives out the best results), and never re-built again (Note. This is not entirely true though, you have a flag that BVH has to be rebuilt before rendering - such case is for deform-able geometry - like skinned characters, for those Split-SAH is a no-go, you have to use binning-SAH or HLBVH). This being said, it clearly is possible that static geometry can have acceleration structure stored on hard drive.

Let me show you the following (and yes, this is from a project when I went full nuts and used path tracing only - which is often called “ultimate solution”):

This is the BVH view in OpenTracer (you can clearly see the nodes around the dynamic nodes (characters), and that their interior is rebuilt. The nodes holding scene (visible on center element of the scene) are never rebuilt. Also, later in the video you can see how top-level BVH gets rebuilt too.

So, to answer your question - yes, it is possible to store and load BVHs on hard drive. Dynamically streaming it with adding entities into scene is also possible - although engine must allow for that. This also saves you some time when you would have LODs and swap between them (as you can have precomputed BVH for all of those).

The main problem is really dynamic geometry - if you would have N keyframes of animation, you can theoretically precompute BVHs for all of those (but when you start interpolating between any keyframes, you are out of luck, same goes for animation blending - which is a standard these days). For subtle animations (like grass/trees), a BVH re-fit approach might work, but I personally didn't like it - as it is too situational and heavily decreases the quality of tree once your movement is ‘a bit more subtle’ (so as of now I simply mark such geometry as dynamic and do full rebuild).

I personally would like to make at least some full featured scene on that library (with exterior and interior environment, animated character and physics). Maybe I'll get to it this year, depends on the situation though.

Vilem Otte said:
a BVH re-fit approach might work, but I personally didn't like it

But it's the best option? I do like it! : ) I guess it could make sense to build it in a rest pose with all limb joints in their most relaxed position, so 90 degree at knees and elbows, spine rolled in a bit, head looking halfway down etc. But not tried this yet.

A second idea is to play back all animation, and extend bounding spheres to the maximum required to bound the mesh in any situation. After that, make the (now huge) bounding boxes you need from the spheres and hierarchical refitting at runtime is no longer necessary. Just transform the tree each frame (with skinning).
Works for me but for classic RT it might decrease tracing perf too much i guess. But could be worth a try.

---

The issue with DXR is that BVH is vendor specific, so we would need an option to generate BVH on client machine and save to disk, similar to pipeline cache in Vulkan. During first game launch, level load etc.
But AFAIK this is not possible yet. Not sure, though.