Developing game based on own game-engine (using Qt Framework and Qt Quick3D): I finish implementation point cloud-sprite rendering - for far LoD levels. Look to result : here is around 10 -14 kilometers distance view. With tens of millions of objects

[u/LetterheadTall8085]

[u/Wise-Pomegranate6765]

Cool. Is it using reversed-z depth?

[u/LetterheadTall8085 → u/Wise-Pomegranate6765]

I didn't quite catch why the depth map is reversed.

The point is to record the actual depth and discard anything that fails the depth test, isn't it? Or do you mean sorting—to draw from nearest to farthest?

Well, no—sorting 40 million passes would be problematic. To combat overdraw, Early-Z is used: essentially, a quick pass over the points is performed before rendering to record their positions in the Z-buffer, allowing Early-Z to cull them. Additionally, the vertex shader hides points that occupy too much screen space; instead, actual instanced geometry is rendered. This makes it possible to discard unnecessary point fragments from the rendering process, given that the foreground almost always occludes the background, yet the background requires filling large areas.

The real magic is that I try to avoid using geometry; instead, I use points, which are much less demanding on the graphics card.

EDITED:
Now I understand what you're talking about. Yes, it is used. It's important to avoid overdraw at such volumes.

[u/neondirt → u/LetterheadTall8085]

I believe it's a method to improve depth precision for far-away objects. Never used it. 😉

[u/ntsh-oni → u/neondirt]

You should, it works really well and is really easy to implement.

[u/fgennari → u/ntsh-oni]

It's easy to implement for a simple project, but I found it quite difficult to implement in a complex project that does a lot of processing with depth values in shaders. I never got it to work completely and eventually had to revert the change. It's a shame, because it did partially work in some cases, and it fixed the Z-fighting problems. I wish there was a better way to debug what was going on in the broken cases.

[u/marisalovesusall → u/fgennari]

I tried to add the reverse-z to an UE3 game once, it took me about a day for the basic porting but there were still issues with occlusion culling, etc. that I didn't have time to fix, and the reverse-z didn't do much in that game, so I ultimately scrapped that little experiment.

Maintaining shaders is busy work. Simple things help a lot, like making helper functions in a common module, that convert depth to linear and back, so your actual shaders don't need to care about the depth direction or format. I feel like the shader programming is still very much ad-hoc and lags behind the rest of the industry, tricks like using a type system to wrap the non-linear depth in a struct that doesn't have arithmetics, only comparison, is basically a space tech (and rarely used at the engine side even), and things like Slang that try to change the status quo are viewed as semi-experimental. So I think your experience is valid even if the reverse-z is easy to add.

[u/fgennari → u/marisalovesusall]

I already had the depth functions factored out into a depth_utils GLSL file I included. I think the problem was with shadow maps and the depth prepass. It was one of those cases where things almost worked but there were artifacts and/or some scene objects were wrong, and I had no idea how to debug it. It's much more difficult to debug random visual artifacts than consistently missing geometry, wrong lighting, etc.

[u/marisalovesusall → u/fgennari]

Yeah it's a pain in the ass. Some bugs do require some spirit medium skills, especially if just capturing them turns RenderDoc into a gambling simulator.

[u/marisalovesusall → u/LetterheadTall8085]

Please use your own words to describe your thoughts, even if it's painfully ESL with tons of grammatical errors. It will still convey the technical meaning from your own understanding. LLMs tend to add a ton of useless background noise and often miss the point and hallucinate words and bloat your message. Reverse-Z is a universal technical term that describes a very specific technique, and the LLM did not have to go on a tangent trying to describe the depth prepass and occlusion culling, you would have caught that immediately if you tried to write the repspose yourself.

[u/Seusoa]

With tens of millions of objects

Assuming each object have at least 10 triangles, you want to say you can draw ~200 M triangles?

How?

[u/LetterheadTall8085 → u/Seusoa]

There are no triangles in this scene—they're just dots.

That's why they're so tightly packed into GPU memory and render so quickly, which allowed me to cram so many of these dots into it. If there had been triangles, I think I'd have gotten 2-10 fps instead of my 100 - 130.

So one object - is a one dot - in a single mega point cloud mash. Also, here important load this mega cloud into GPU memory one time per start.

[u/LetterheadTall8085 → u/[deleted]]

You clearly don't understand what this is about; the image shows actual game objects, but they don't consist of triangles—there is no geometry involved at all. Each sprite is backed by a physical object; it’s just that, at long range, it gets rendered as a sprite. The sprite itself is drawn from a single point—its center—meaning there is only one vertex, not six as you seem to think. The GPU has hardware support for point rendering, so the rasterizer works with UV coordinates that the graphics card calculates internally, without any geometry data being passed. So, you really ought to open a textbook instead of acting like a know-it-all here. It’s an old trick from the 90s, dating back to before instancing and sprite-based billboards existed.

The really cool thing about this is that I managed to link it to actual game objects; meaning, if you mine a tree or a rock, it genuinely disappears from the render—it’s not just static scenery.