PVS isn't that expensive to compute. Especially nowadays. I assume this is actually referring to the binary space partitioning techniques used in DOOM and improved in Quake, Half-Life, etc in the late 90s, early 2000s.
The BSP tree was also extremely useful for optimizing netcode for games like Quake 3 Arena and games within that family and time period I believe.
PVS requires some hierarchical scene representation with no seams between walls. I know no other way to build such representation other than BSP. But BSP works fine only with pretty low-detail map geometry consisting of brushes. No large detail meshes or terrains can be used with it. If a game has a lot of open spaces or semi-open spaces it's nearly to impossible to build a BSP for it.
Lots of old racing games used a PVS. The way it was calculated was by flying a camera around the track and calculating what was visible every few meters using occlusion culling, then at runtime you just see what section of track you're on and only draw the objects that you know are visible. Recalculating the PVS for that is definitely a slow operation!
Backface culling has been common since the late 1990s when we started using face normals to determine lighting rather than per-vertex lighting. Pretty much every 3D game engine since about 2004 has included and enabled it by default. How is it that you made a game that doesn't use it?
Occlusion culling is really tough in systems where users can add content to the world. Especially if there's translucency. As with windows (not Windows), or layered clothing.
You're in a room without windows. Everything outside the room is culled. Frame rate is very high. Then you open the door and go outside into a large city. Some buildings have big windows showing the interior, so you can't cull the building interior. You're on a long street and can look off into the distance. Now keep the frame rate from dropping while not losing distant objects.
Games with fixed objects can design the world to avoid these situations. Few games have many windows you can look into. Long sightlines are often avoided in level design. If you don't have those options, you have to accept that distant objects will be displayed, and level of detail handling becomes more important than occlusion. Impostors. Lots of impostors.
Occlusion culling itself has a compute cost. I've seen the cost of culling big scenes exceed the cost of drawing the culled content.
This is one of those hard problems metaverses have, and which, despite the amount of money thrown at the problem, were not solved during the metaverse boom. Meta does not seem to have contributed much to graphics technology.
Back in the 90s I made a 3d engine (software renderer) and used frustum culling. But computing the frustum intersection every time was too slow. So one technique I did was add a count to each polygon. If the polygon was outside the view frustum, i added a count of N frames. Each frame if the count for a polygon was 0 it would check against the frustum, otherwise it would reduce the count and skip the polygon rendering entirely.
This worked very well but of course if the camera turned quickly, you would see pop-in. Not a modern technique, but an oldschool one.
I really appreciate this post. It reminds me of a video I watched a couple years ago that does an excellent job of demonstrating how culling works with actual code and visuals
I've always wondered to what extent these culling techniques still work with raytracing?
A reflective surface can bring a bunch of otherwise-offscreen things into the scene. Its what makes screen-space reflections look so bad sometimes, they can't reflect whats not on-screen.
- if you were making a 3d tactical shooter (third person) in c++ from scratch without unreal, godot and unity, would you say that rendering is the hardest task?
- do we have libraries in c++ that can handle this for us?
17 comments
[ 3.6 ms ] story [ 42.7 ms ] threadThe BSP tree was also extremely useful for optimizing netcode for games like Quake 3 Arena and games within that family and time period I believe.
https://slitherworld.com
You're in a room without windows. Everything outside the room is culled. Frame rate is very high. Then you open the door and go outside into a large city. Some buildings have big windows showing the interior, so you can't cull the building interior. You're on a long street and can look off into the distance. Now keep the frame rate from dropping while not losing distant objects.
Games with fixed objects can design the world to avoid these situations. Few games have many windows you can look into. Long sightlines are often avoided in level design. If you don't have those options, you have to accept that distant objects will be displayed, and level of detail handling becomes more important than occlusion. Impostors. Lots of impostors.
Occlusion culling itself has a compute cost. I've seen the cost of culling big scenes exceed the cost of drawing the culled content.
This is one of those hard problems metaverses have, and which, despite the amount of money thrown at the problem, were not solved during the metaverse boom. Meta does not seem to have contributed much to graphics technology.
This is much of why Second Life is slow.
It was used extensively in outdoor games like Jak and Daxter.
This worked very well but of course if the camera turned quickly, you would see pop-in. Not a modern technique, but an oldschool one.
https://www.youtube.com/watch?v=CHYxjpYep_M
- do we have libraries in c++ that can handle this for us?