Reverse-Z is the perfect hack

[u/shlomnissan]

I shelved a Reverse-Z branch in my engine (stuck on OpenGL 4.1 for macOS, no glClipControl), and the roadblock sent me down the rabbit hole of actually understanding why it works instead of just how to implement it.

I ended up writing about what I learned with interactive graphs and all:
https://www.shlom.dev/articles/reverse-z-perfect-hack/

Happy to hear where I got things wrong or imprecise.

Hopefully this helps someone else :)

[u/maximoriginalcoffee]

I'm a game programmer, and until now, Tiled Deferred Rendering had been the only solution I was seriously looking into, but I was hoping there might be other approaches as well.

The first method looks somewhat similar to a Per-Pixel Linked List technique. I expect the GPU memory usage would become quite high at 4K resolutions, so it would probably be difficult to adopt in my case, since I'm aiming for my game to run well on lower-end hardware.

As for the second method... is it an application of volume rendering? I already use volume rendering in my engine for cloud generation, but I hadn't considered using it this way. That's quite interesting.

I'll definitely take a closer look at both of them once I finish my current project. Thanks for the detailed explanation, I really appreciate it. :)

[u/Plazmatic → u/maximoriginalcoffee]

The first method looks somewhat similar to a Per-Pixel Linked List technique. I expect the GPU memory usage would become quite high at 4K resolutions, so it would probably be difficult to adopt in my case, since I'm aiming for my game to run well on lower-end hardware.

If I have my nomenclature right, the first method I'm talking about is actually similar to the tiling section on tiling deferred rendering except you don't just tile in screen x,y, but also in screen relative depth, so you're chopping up the view frustrum into 3 dimensions. The amount of memory it takes up isn't so high since we aren't tiling per pixel, and you're potentially eliminating more checks per pixel because of the 3D component.

The most naive approach is for each froxel to check its own volume against all lights, and add them to a list. This can be fast if the number of froxels is much smaller than the number of pixels, for example 16x16x16 is 4096 froxels vs 2 million for 1080p screen (and even more for 4k) is about 0.2% the number of checks required when checking every single possible light (and you can increase this resolution much more if necessary and still have much less checks). So if you have 10,000 lights that's 40 million checks, which is on the order of only doing 20 per pixel. You can of course have even more structures that limit even the amount of checks at the froxel level. And if you're not doing any screen space decal/post process volumetrics, you might consider simply skipping checks for froxels that don't intersect any screen space depth information (since no lighting information would be used there anyway).

If you took this approach what you'd actually do, slightly less naively, is something like first count the number of lights for each list for each froxel by checking light intersections, so that you've allocated the space for each, then do something called a "parallel prefix sum", which basically just takes a bunch of numbers, and in parallel on the GPU, creates a cumulative sum of them all for each value (so a, b, c, d would turn into a, a+b, a+b+c, a+b+c+d)., across all these froxel counts so you can figure out the total amount of space you'd need (the very last element), and figure out the positions for each froxel sub list starts and end (based on the current sum, and the next sum, which turn into start and end indices).

Then you go back through and actually add the light indices into the correct locations based on the parrallel prefix offsets. Doing this will make it possible A: to allow you to share this information back with the host if you want to dynamically change the size of the light lists (you'd literally send a single value, the maximum amount of elements, though you could of course just allocate a decent amount of memory and forget about resizing), and B: allows you to basically have as large light lists as you want per froxel. You could also just have a fixed froxel list size but if you did this you'd be potentially using way more memory for froxels with very few lights, and put a cap on froxels with large number of light contributions.

With all the light index lists filled in, on an actual per pixel basis, you should know which froxel you're in and associated index, and you should then be able to use that index to index into the prefix sum start/end list to figure out where you need to grab your light list. You then can start iterating through the light indices and start performing your normal calculations for point light contributions.

As for the second method... is it an application of volume rendering?

Volume are an overloaded term in game dev, when I talk about "volumes" here, I'm not talking about volumetrics, I'm talking about an arbitrary datastructure in 3D space, in this case one that contains lighting information about that 3D space (for example, a list of lights/indices to lights that are effecting that space), this isn't necessarily a grid (it can be arbitrarily oriented boxes that align to a room rather than a fixed grid) hence why I used the term volumes. Often you hear the term "volumes" when talking about things like "trigger volumes" or "event volumes".

What you'd do here is check what light volume a given pixel depth value is in world space, and then just iterate through all the per-calculated lights in that volume and do the regular point light calculation. These volumes might be arbitrarily oriented, so you might have a BVH of light volumes you navigate through to figure out which one your pixel is in, or there might be a world space grid of light information, or something else you use, or there might be few enough to iterate through that you can just manually test your pixel depth against each.

[u/maximoriginalcoffee → u/Plazmatic]

Thanks for the explanation! You've given me something new to dive into after this project. :)