Indices of static geometry
quote:
Already looking into occlusion culling techniques.. any good techniques that you know for outdoor environments?
I was about to link to that outdoor occlusion thread, when I realised that it was you who posted it... doh...
What I do in our engine is very simple, yet pretty effective. It''s not so easy to explain. So you have your terrain (mine is not a heightmap, but that''s not important. It will also work with heightmaps). You have small and large features on that terrain, from small little rocks to large mountain-like formations. The small ones don''t create very much occlusion, and we can ignore them. The large ones create lots of occlusion.
What I simply do, is use a heuristic that first recognizes those large features, and isolates their geometry (in your case, that would be the part of the heightmap they occupy). It then creates a volumetric representation of that feature using boxes, that are positioned under the terrain. In such a way, that no box will ever intersect the terrain at any point, but will still fill the maximum possible volume under the large terrain feature.
Those box constructs are then labeled as occulsion geometry. They are static (if your terrain doesn''t change), and can be rendered very efficiently. Before rendering a frame of the game, I render those boxes into an offscreen buffer (no texture or lighting required). I also render the occlusion geometry of other objects (ie. the outlines of large features in a 3D town, eg. walls, large houses, etc). Since it''s an image space method, it will automatically take care of occluder fusion.
Last step is to perform an occlusion test on each part of the terrain before you render it (using it''s bounding box). That can be done in software, or hardware on GF3+.
/ Yann
Author
Ok, i think i got it...correct me if im wrong:
First you render volumes that are inside the objects (such as under the terrain) to an offscreen depth buffer, keeping the nearest points. Then for each bounding box of geometry (border volumes of a solid object) that needs to be rendered, you test against this buffer to see if the bounding box is completely occluded. and if no part of the bounding box is eligible to be rendered, then you dont render the geometry and move on to the next one. hmm...similar to an algorithm i read...but it uses a buffer instead of manually performing occluder fusion.
how does one do the last step in software... i know there is an occlusion test extension by NVidia that does it in hardware..
First you render volumes that are inside the objects (such as under the terrain) to an offscreen depth buffer, keeping the nearest points. Then for each bounding box of geometry (border volumes of a solid object) that needs to be rendered, you test against this buffer to see if the bounding box is completely occluded. and if no part of the bounding box is eligible to be rendered, then you dont render the geometry and move on to the next one. hmm...similar to an algorithm i read...but it uses a buffer instead of manually performing occluder fusion.
how does one do the last step in software... i know there is an occlusion test extension by NVidia that does it in hardware..
In our engine at work i used a software-based occlusion culling technic, since it has to run on any graphic card.
In a preprocessing step, i generate a list of "potentially" good occluders. This step is done by merging neighboor triangles together to form a big occluder, while trying to stick to a convex polygon. Then, i reject occluders that are too small. This results in a small number of occluder polygons for a complete scene (don't remember the numbers exactly, but it's around 1000 occluders for a 250000 triangle scene).
At run-time, i allocate a fixed amount of time (2 milliseconds) to do occlusion culling. I sort the occluders by effectiveness (based on the distance and the occluder area), and then i only process as much occluders as i can in the allocated time. For each occluder, i generate a shadow volume which is tested against the scene octree like in a standard frustum culling method (it's basically the same code). It works because the shadow volume is convex.
On a PIII-500, i was able to test around 50 occluders in these 2 milliseconds, which is enough since it's the 50 "best" occluders for the given frame.
Y.
[edited by - Ysaneya on August 28, 2002 3:33:31 PM]
In a preprocessing step, i generate a list of "potentially" good occluders. This step is done by merging neighboor triangles together to form a big occluder, while trying to stick to a convex polygon. Then, i reject occluders that are too small. This results in a small number of occluder polygons for a complete scene (don't remember the numbers exactly, but it's around 1000 occluders for a 250000 triangle scene).
At run-time, i allocate a fixed amount of time (2 milliseconds) to do occlusion culling. I sort the occluders by effectiveness (based on the distance and the occluder area), and then i only process as much occluders as i can in the allocated time. For each occluder, i generate a shadow volume which is tested against the scene octree like in a standard frustum culling method (it's basically the same code). It works because the shadow volume is convex.
On a PIII-500, i was able to test around 50 occluders in these 2 milliseconds, which is enough since it's the 50 "best" occluders for the given frame.
Y.
[edited by - Ysaneya on August 28, 2002 3:33:31 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
