I think reading your response is precisely why I think they did not go this route. It goes against the point of having DXR, you may as well let every vendor have their own RT extension and just bolt that onto DirectX if that is the case. The idea of having a single call, with the drivers doing the work for you, is the point of all of DXR, and the costs in performance are compromises to enabling developers to making a code once and deploy on multiple cards.
That's why the whole thing would be
optional.
The driver still can manage all BVH for you, and if you don't need to look under the blackbox, you won't.
I assume only very few engines would go the route of custom BVH management. But they would have an advantage over the competition, so with time, utilizing the feature would become more widespread.
And in times of most games made using U engines, it's actually enough if only few engines tackle it, sadly.
It's not great, but keep in mind: It's the only way to make traceable LOD. Otherwise we are stuck at discrete LOD till the end of time. Discrete LOD is no solution, and after Nanite it's already outdated.
The situation is now much worse than it would have been if they included specifications or standards at launch. But that's their fault. They messed it up, now they have to clean it up.
The whole idea to generate BVH ingame is silly. I'd excuse they didn't think about LOD, but there should have been options to stream BVH from the start. RT is expensive enough - why do expensive BVH builds if they can be precomputed? Such streaming could have kept blackboxed, and then we would already have a base format the driver converts to the HW, which would be a start towards dynamic BVH.
If the blackbox isn't lifted, the only option becomes a standardized LOD solution, which IHVs have to support by driver software. E.g. 'Nanite' free to use for everybody.
But we don't have such standard. Nanite can only do LOD
per model, so it requires to split some large terrain into thousands of unique models. This would cause cracks across the models, and it would take too much storage and memory anyway. That's why UE5 games still use lofi hightmaps, decorated with some rock models on top of it. Nanite is great, but no general solution yet.
To work out solutions which work for us, it's required that APIs actually allow to do so.
So you see, it sucks, but there is no alternative. The only alternatives are to accept stagnation on the LOD problem, or to simply not use RT, or to accept inaccuracy and redundant costs like Epic does.
Texture Compression formats is actually a good example. It started with many specific formats, but MS enforced standards (iirc) and licensing issues were resolved.
Technical complexity isn't worse for a BVH struct. And i do not even request a standard. I would be happy to know the individual formats IHVs use. I can't be more modest than that.
Developers are having challenges with DX12 today, and that's considered low level, I can't imagine developers having to manage the acceleration structure for a variety of GPUS in a single family
I have to do all this anyway for my own BVH anyway, so i have experience and can imagine what's the effort.
We can compare this to two things, regarding the increase of complexity:
Moving from rasterization (point lights, fake falloff, phong shading -> PBS, TAA) to raytracing (monte carlo integration, importance sampling, PBS, still fake falloff, restir, denoising).
Moving from discrete LOD to Nanite.
The effort is much smaller than either of these. Devs can do it.
Anyone who thinks BVH is black magic and requires rocket science skills is wrong. It's just a tree with a bounding volume for each node. A blackbox does not mean there must be a can of worms under it.
I would also say that mastering low level gfx APIs as a whole is much harder and covers much more details as well.
LOD will be handled the DX method it will be a single code, multi deploy
I could elaborate on why general LOD is impossible to solve.
If we try to enforce a standard, it will be bad and short sighted.
)