JoeJ said:
So that's really a bad argument i think.

the total polygon surface of 1000 x 1meter boxes 1000 meters away will be likely 98-99% smaller than one 1m box in front of you, depending on how you position them and how wide your camera view is, therefore at this point this is:

if poster really want something that remotely makes sense, thats called geometric lod (instancing) instead

Geri said:
the total polygon surface of 1000 x 1meter boxes 1000 meters away will be likely 98-99% smaller than one 1m box in front of you, depending on how you position them and how wide your camera view is, therefore at this point this is:

Not sure how i have to imagine the example, but my point is:
1000 boxes means 1000x more draw calls, 1000x more vertices to transform, 1000x more matrices to upload to GPU, etc., than the single box in front.

Now let's assume those 1000 boxes are arranged in a circle around the player.
You propose to cull only the boxes which are behind the camera, so we'll draw 500 boxes.
I propose to cull based on the shape of the camera frustum. The test is fast and simple. If our fov is 90 degrees, we'll draw 250 boxes. Many games have just 60, that's 167 boxes.

I don't think there is any point to argue what's the better option here in the general case.
But feel free to make examples of cases where a back side test has outperformed a frustum test for you.
Whatever this is, my counter example then is a top down open world game, where a back side test would cull nothing, and you have to render the whole world every frame although the player sees only 0.01% of it.

if poster really want something that remotely makes sense, thats called geometric lod (instancing) instead

What has LOD to do with instancing?

JoeJ said:
instancing

They go hand in hand and i have noticed they are usually used and recommended together, sometimes people refer them under the same umbrella terminology.

Geometric LOD is the most important here.

https://en.wikipedia.org/wiki/Level_of_detail_(computer_graphics)​​

Normal instancing will also be important as drivers will would not like to paint every piece of grass with a separate draw call.

JoeJ said:
But feel free to make examples of cases where a back side test has outperformed a frustum test for you.

I tested it in ~2006-2007 when i had an athlonxp with radeon 9800 and i already used vbo. Some walls were able to cover out specific models (such as high poly characters) - the algo was very simple. The test was about having a few rooms with a high poly statue in it (100k or so, which back then was HUGE), and filtering out the model if you were in a room where it was not visible (not doing the draw call for the modell).

The difference was 30 vs 35 fps or so. I was not amused, and scrapped the idea.

Geri said:
They go hand in hand and i have noticed they are usually used and recommended together, sometimes people refer them under the same umbrella terminology.

But it's completely different concepts.
LOD aims to have constant geometry to screen resolution ratio independent of distance. (decreases detail)
Instancing is about the idea to model complex scenes with many copies of the same object. (increases detail)
They neither build upon similar technology, and even their goals differ.
Ofc. you can combine both, e.g. rendering a forest with instances of a tree model having multiple LODs. But they still remain different concepts.

Geri said:
I tested it in ~2006-2007 when i had an athlonxp with radeon 9800 and i already used vbo. Some walls were able to cover out specific models (such as high poly characters) - the algo was very simple. The test was about having a few rooms with a high poly statue in it (100k or so, which back then was HUGE), and filtering out the model if you were in a room where it was not visible (not doing the draw call for the modell). The difference was 30 vs 35 fps or so. I was not amused, and scrapped the idea.

If you cull objects which are in the frustum but occluded by a wall, then we talk about ‘occlusion culling’ (or ‘hidden surface removal’), which opposed to frustum culling is a hard problem and still open.
I worked on this too, at about the same time. I've used a custom quake 3 level, a house with detailed interiors. And i wanted to render a city scene, duplicating the house 16 times. From the street, you could look through windows and see coffee cups on the kitchen table. Back then the frame rate was 20 fps if frustum culling was the only culling method.

My algorithm required to model a low poly version of the house, containing the walls, but still making holes for windows and doors.
Then i made an octree to divide the big model into smaller chunks (i did not use Quake BSP because i wanted support for dynamic scenes). And i put the low poly occluders into the same tree.
Then i process the octree in coarse front to back order.
If there is a occluder polygon, i rasterize it on CPU. But i do not process individual pixels, instead just horizontal spans with a start and end point. Intersections with former spans are needed to guarantee correct depth order, but otherwise it's fast. Only the vertical screen resolution matters for performance.
For any octree node, i test its bounding box against the current depth buffer. This again processes only spans, no pixels. If it's occluded the whole branch of the tree can be skipped, otherwise any chunk of geometry in the node is drawn.

The cost was multiple milliseconds on a single CPU thread, but it saved the GPU so much work i got 60 fps in the end.
The cool thing about the algorithm is that culling reduces work for both GPU and the culling algorithm on CPU itself. I also get frustum culling for free.
The bad thing it's not well suited for multi threading or parallel implementation on GPU. Automated generation of low poly occluders also would be difficult.

Modern games mostly do it with reprojection of the previous frames depth buffer, making a max depth pyramid, and having the whole culling pipeline on GPU. But that's not accurate. UE4 often shows white flashes on failure cases.

People rarely talk about it nowadays, but visibility is still the key problem in computer graphics. Fancy ray tracing for example is just a visibility test. Visibility is the most expensive part in the rendering equation, etc.
Maybe not amusing, but definitively worth to work on it if we want nice things on affordable hardware ; )

JoeJ said:
People rarely talk about it nowadays, but visibility is still the key problem in computer graphics

Yes well they don't talk about it, due to the reason i mentioned: not rendering models behind + lod + instancing gives you enough performance boost, and other methods would be too complicated, and barely giving any extra speed. Imho the topic not worths more research.

Geri said:
Yes well they don't talk about it, due to the reason i mentioned: not rendering models behind + lod + instancing gives you enough performance boost

Using HW as intended but spending zero effort on efficiency just to keep it simple does not give you a ‘boost’, it only gives you the bare minimum, which obviously is good enough for your personal application.
But it's not good enough for me, and it's not for the industry either.

Geri said:
Imho the topic not worths more research.

+1 one for beginning with ‘imho’. You should do this much more often.