Geri said:
I tried to warn you. Scrap it before you waste another month of your life on this technology. And do not try to clone technologies just because some obsolote jokeware engine which was designed 20 years ago relies on it.

I practically gave it about 2 evenings (I have quite a list to implement, and getting to specific things takes time).

I'm quite curious how it will behave in real world scenario and not Sponza. Truth is - it might be more than possible that frustum culling + LOD (I mostly have only static LODs - with exception for terrain - ray tracing and dynamic LOD just doesn't like each other that much) will beat it.

You must also count the long thinking process in your mind and the research you have spent on it, not just the actual time to type in and debug the required code lines.

By the way this is might useful for you, i forget to mention it last time: according to reverse engineers, nvidia gpus - depending on the content, the texture, the shader, the blend, the position of the stars on the sky, the shape of the sacraficed chicken guts, etc, will internally switch to a partially deferred tiled rendering algorithm internally. You might want to take this into consideration when observing your results.

Vilem Otte said:
I'm quite curious how it will behave in real world scenario and not Sponza. Truth is - it might be more than possible that frustum culling + LOD (I mostly have only static LODs - with exception for terrain - ray tracing and dynamic LOD just doesn't like each other that much) will beat it.

It's highly likely that the Sponza scene just isn't complicated enough to showcase the advantages of the technique. As I mentioned in my earlier post, we see wins in scenes with tens or hundreds of thousands of meshes being rendered (which is all we care about in practice).

It's entirely possible that simple frustum+LOD culling will outperform Hi-Z (and other occlusion-based techniques) for simpler scenes because of the fixed overhead (generating depth pyramid, etc.), but as is often the case in gamedev the answer is “it depends” and it's always worth measuring before making assumptions - or just let users have a checkbox to turn the technique on and off.

Valakor said:
tens or hundreds of thousands of meshes

Yikes! surely that's with lots of instancing. I had thought about 10k draw calls was the max you could realistically do. Have the times changed with Vulkan and newer APIs? I imagine even the rest of the game (aside from graphics) would get pretty slow with 100k objects.

Aressera said:
Yikes! surely that's with lots of instancing.

Yes, very heavy usage of instancing. IIRC the max number of draw calls I remember seeing in our engine recently was around 3300, with closer to 1500 being typical.

Aressera said:
I had thought about 10k draw calls was the max you could realistically do.

classic opengl 1.0 nowadays can do 50k-100k draw calls at 60 fps at most on a modern pc with modern drivers, when drawing a few polygons, as i have recently benchmarked it https://www.gamedev.net/forums/topic/713344-opengl-draw-call-test/​

dont forget this is a syntethic test as a non-real-world scenario, also this is without switching texture or anything meaningful in the state descriptors, so divide the speed by 2-3 for real world result.

i have my doubts if older versions of directx scaled like this, those probably still damn slow.

i have no idea about dx12 and vulkan tho. but i wouldnt assume it can do much more. even opengl, when i used vbos, was fell in the speed significantly, compared to classic opengl 1.0 calllist magic.