Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualHodgman

Posted 28 October 2013 - 08:23 PM

Even if all the nodes are visible, you can decide to LOD some of them and use the parent instead of the leaf nodes.
If you're not going to do any stuff that exploits the hierarchical nature of the tree (including what mhagain said above), then you've basically just got a 3D grid, not a 3D tree tongue.png
 
The simplest pre-generated PVS system can be extremely simple though. In one game demo that I made, I simply manually created bounding volumes for different sectors, and then manually wrote into a text file lists of which sectors could be seen from which other sectors laugh.png
 
As well as pre-generated PVS, there's lots of runtime approaches that use the CPU rather than the GPU --

  • Lots of games have used sector/portal systems.
  • I know of one proprietary AAA engine that just had the level designers place 3D rectangles throughout the world as occluders (e.g. in the walls of buildings). The engine would then find the ~6 largest of these rectangles that passed the frustum test, and then use them to create frustums, and then brute-force cull any object that was inside of those occluder-frustums.
  • Fallout 3 used a combination of both of the above.
  • Here's another example of occluder frustums: http://www.gamasutra.com/view/feature/131388/rendering_the_great_outdoors_fast_.php?print=1
  • Lots of modern games have implemented software rasterizers, where they render occlusion geometry on the CPU to create a float Z-buffer in main ram, which you can then test object bounding boxes against.
  • Personally, I'm using this solution, where you implement a software rasterizer, but only allocate one bit per pixel (1=written to, 0=not yet written to). A clever implementation can then write to (up to) 128 pixels per instruction using SIMD. Occludee and occluder triangles are then sorted from front to back and rasterized. Occluder triangles write 1's, occludee triangles test for 0's (and early exit if a zero is found).

On the GPU side, there's also other options than occlusion queries. e.g. Splinter cell conviction re implemented the HZB idea, doing culling in a pixel shader, allowing them to do 10's of thousands of queries in a fraction of a millisecond, on a GPU from 2006 (much, much faster than HW occluson queries, but slightly less accurate).
 

Stack trace comes from GL driver which is basically useless

So as long as your usage of the functions is perfectly compliant with the GL spec, then that means you can legitimately blame the driver and/or report a driver bug wink.png


#7Hodgman

Posted 28 October 2013 - 08:21 PM

Even if all the nodes are visible, you can decide to LOD some of them and use the parent instead of the leaf nodes.

If you're not going to do any stuff that exploits the hierarchical nature of the tree (including what mhagain said above), then you've basically just got a 3D grid, not a 3D tree tongue.png

 

The simplest pre-generated PVS system can be extremely simple though. In one game demo that I made, I simply manually created bounding volumes for different sectors, and then manually wrote into a text file lists of which sectors could be seen from which other sectors laugh.png

 

As well as pre-generated PVS, there's lots of runtime approaches that use the CPU rather than the GPU --

  • Lots of games have used sector/portal systems.
  • I know of one proprietary AAA engine that just had the level designers place 3D rectangles throughout the world as occluders (e.g. in the walls of buildings). The engine would then find the ~6 largest of these rectangles that passed the frustum test, and then use them to create frustums, and then brute-force cull any object that was inside of those occluder-frustums.
  • Fallout 3 used a combination of both of the above.
  • Here's another example of occluder frustums: http://www.gamasutra.com/view/feature/131388/rendering_the_great_outdoors_fast_.php?print=1
  • Lots of modern games have implemented software rasterizers, where they render occlusion geometry on the CPU to create a float Z-buffer in main ram, which you can then test object bounding boxes against.
  • Personally, I'm using this solution, where you implement a software rasterizer, but only allocate one bit per pixel (1=written to, 0=not yet written to). A clever implementation can then write to (up to) 128 pixels per instruction using SIMD. Occludee and occluder triangles are then sorted from front to back and rasterized. Occluder triangles write 1's, occludee triangles test for 0's (and early exit if a zero is found).

On the GPU side, there's also other options than occlusion queries. e.g. Splinter cell conviction re implemented the HZB idea, doing culling in a pixel shader, allowing them to do 10's of thousands of queries in a fraction of a millisecond, on a GPU from 2006 (much, much faster than HW occluson queries, but slightly less accurate).


#6Hodgman

Posted 28 October 2013 - 08:19 PM

Even if all the nodes are visible, you can decide to LOD some of them and use the parent instead of the leaf nodes.

If you're not going to do any stuff that exploits the hierarchical nature of the tree (including what mhagain said above), then you've basically just got a 3D grid, not a 3D tree tongue.png

 

The simplest pre-generated PVS system can be extremely simple though. In one game demo that I made, I simply manually created bounding volumes for different sectors, and then manually wrote into a text file lists of which sectors could be seen from which other sectors laugh.png

 

As well as pre-generated PVS, there's lots of runtime approaches that use the CPU rather than the GPU --

  • Lots of games have used sector/portal systems.
  • I know of one proprietary AAA engine that just had the level designers place 3D rectangles throughout the world as occluders. The engine would then find the ~6 largest of these rectangles that passed the frustum test, and then use them to create frustums, and then brute-force cull any object that was inside of those occluder-frustums.
  • Fallout 3 used a combination of both of the above.
  • Here's another example of occluder frustums: http://www.gamasutra.com/view/feature/131388/rendering_the_great_outdoors_fast_.php?print=1
  • Lots of modern games have implemented software rasterizers, and they render occlusion geometry on the CPU to create a Z-buffer in main ram, which you can then test object bounding boxes against.
  • Personally, I'm using this solution, where you implement a software rasterizer, but only allocate one bit per pixel (1=written to, 0=not yet written to). A clever implementation can then write to (up to) 128 pixels per instruction using SIMD. Occludee and occluder triangles are then sorted from front to back and rasterized. Occluder triangles write 1's, occludee triangles test for 0's (and early exit if a zero is found).

On the GPU side, there's also other options than occlusion queries. e.g. Splinter cell conviction re implemented the HZB idea, doing culling in a pixel shader, allowing them to do 10's of thousands of queries much, much faster than you can with HW occluson queries.


#5Hodgman

Posted 28 October 2013 - 08:13 PM

Even if all the nodes are visible, you can decide to LOD some of them and use the parent instead of the leaf nodes.

If you're not going to do any stuff that exploits the hierarchical nature of the tree (including what mhagain said above), then you've basically just got a 3D grid, not a 3D tree tongue.png

 

As well as pre-generated PVS, there's lots of runtime approaches that use the CPU rather than the GPU --

  • Lots of games have used sector/portal systems.
  • I know of one proprietary AAA engine that just had the level designers place 3D rectangles throughout the world as occluders. The engine would then find the ~6 largest of these rectangles that passed the frustum test, and then use them to create frustums, and then brute-force cull any object that was inside of those occluder-frustums.
  • Fallout 3 used a combination of both of the above.
  • Here's another example of occluder frustums: http://www.gamasutra.com/view/feature/131388/rendering_the_great_outdoors_fast_.php?print=1
  • Lots of modern games have implemented software rasterizers, and they render occlusion geometry on the CPU to create a Z-buffer in main ram, which you can then test object bounding boxes against.
  • Personally, I'm using this solution, where you implement a software rasterizer, but only allocate one bit per pixel (1=written to, 0=not yet written to). A clever implementation can then write to (up to) 128 pixels per instruction using SIMD. Occludee and occluder triangles are then sorted from front to back and rasterized. Occluder triangles write 1's, occludee triangles test for 0's (and early exit if a zero is found).

On the GPU side, there's also other options than occlusion queries. e.g. Splinter cell conviction re implemented the HZB idea, doing culling in a pixel shader, allowing them to do 10's of thousands of queries much, much faster than you can with HW occluson queries.


#4Hodgman

Posted 28 October 2013 - 08:12 PM

Even if all the nodes are visible, you can decide to LOD some of them and use the parent instead of the leaf nodes.

If you're not going to do stuff like that, then you've basically just got a 3D grid, not a 3D tree tongue.png

 

As well as pre-generated PVS, there's lots of runtime approaches that use the CPU rather than the GPU --

  • Lots of games have used sector/portal systems.
  • I know of one proprietary AAA engine that just had the level designers place 3D rectangles throughout the world as occluders. The engine would then find the ~6 largest of these rectangles that passed the frustum test, and then use them to create frustums, and then brute-force cull any object that was inside of those occluder-frustums.
  • Fallout 3 used a combination of both of the above.
  • Here's another example of occluder frustums: http://www.gamasutra.com/view/feature/131388/rendering_the_great_outdoors_fast_.php?print=1
  • Lots of modern games have implemented software rasterizers, and they render occlusion geometry on the CPU to create a Z-buffer in main ram, which you can then test object bounding boxes against.
  • Personally, I'm using this solution, where you implement a software rasterizer, but only allocate one bit per pixel (1=written to, 0=not yet written to). A clever implementation can then write to (up to) 128 pixels per instruction using SIMD. Occludee and occluder triangles are then sorted from front to back and rasterized. Occluder triangles write 1's, occludee triangles test for 0's (and early exit if a zero is found).

On the GPU side, there's also other options than occlusion queries. e.g. Splinter cell conviction re implemented the HZB idea, doing culling in a pixel shader, allowing them to do 10's of thousands of queries much, much faster than you can with HW occluson queries.


#3Hodgman

Posted 28 October 2013 - 08:09 PM

Even if all the nodes are visible, you can decide to LOD some of them and use the parent instead of the leaf nodes.

If you're not going to do stuff like that, then you've basically just got a 3D grid, not a 3D tree tongue.png

 

As well as pre-generated PVS, there's lots of runtime approaches that use the CPU rather than the GPU.

 

Lots of games have used sector/portal systems.

 

I know of one proprietary AAA engine that just had the level designers place 3D rectangles throughout the world as occluders. The engine would then find the ~6 largest of these rectangles that passed the frustum test, and then use them to create frustums, and then brute-force cull any object that was inside of those occluder-frustums.

 

Fallout 3 used a combination of both of the above.

 

Here's another example of occluder frustums: http://www.gamasutra.com/view/feature/131388/rendering_the_great_outdoors_fast_.php?print=1

 

Lots of modern games have implemented software rasterizers, and they render occlusion geometry on the CPU to create a Z-buffer in main ram, which you can then test object bounding boxes against.

 

Personally, I'm using this solution, where you implement a software rasterizer, but only allocate one bit per pixel (1=written to, 0=not yet written to). A clever implementation can then write to (up to) 128 pixels per instruction using SIMD. Occludee and occluder triangles are then sorted from front to back and rasterized. Occluder triangles write 1's, occludee triangles test for 0's (and early exit if a zero is found).

 

On the GPU side, there's also other options than occlusion queries. e.g. Splinter cell conviction re implemented the HZB idea, doing culling in a pixel shader, allowing them to do 10's of thousands of queries much, much faster than you can with HW occluson queries.


PARTNERS