Archived

This topic is now archived and is closed to further replies.

Terrain Occlusion Culling

This topic is 5599 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Most information about terrain rendering and related algorithms usually talk about LOD and frustum culling. The occlusion culling is mostly talked about in context of indoor engines. This seems a little wasteful to me, if there are large mountains the terrain could very well benefit from occlusion culling. I couldn''t find much info on the subject. Could someone point me to some sources and/or give me ideas? Thanks.

Share this post


Link to post
Share on other sites
I haven''t got any source for you (sorry), but I do have a few ideas.

I''m sure a few people have tried this, but you could have a look at using hardware occlusion queries by rendering bounding volumes of oct/quad-tree nodes to check if their contents may be occluded. I haven''t tried this myself, as I don''t have the GF3+ hardware to try it out

Another technique to search for is "horizon mapping"... I recall a guy on these forums (Mirko aka Darkwing?) doing a terrain demo (using a quadtree), and he used a paper on this topic as a basis for experimenting with occlusion culling. Can''t remember the name of the paper (sorry again ).

Also, I believe that lively sheep-shagger Zedzeek implemented a PVS system for his terrain in Gotterdamerung (using an octree), and he said it cut down on rendered geometry a surprising amount (due to having a good number of tall hills and deep valleys I imagine).

Lastly, take a peek at this article at Gamasutra (you may have already seen it though)

Share this post


Link to post
Share on other sites
I don''t see the need for a GF3...
I''d imagine you use an octree for your (heightmapped) terrain - a node is opaque if it''s entirely underground. You can easily determine that by finding the maximum height in the tree.
You can probably also develop a similar approach using quadtrees.

- hillip@xenoage.de''>JQ
Full Speed Games. Period.

Share this post


Link to post
Share on other sites
I developed an occlusion algorithm for my engine, it helped the framerate a LOT, and I have a GF4. I use a quadtree for both frustrum and occlusion culling. Each 3d bounding box around a terrain chunk obviously holds the info of its 8 corners, but for the purposes of my occlusion culling I also define points halfway along each edge, I''ll explain why later. Oh I don''t actually use vector points for these bounding boxes I use integer values since they never change (unless you want destructible terrain), and to save memory.
Now for the good stuff. While I''m doing my frustrum culling I flag whether a chunk is completely within, or partially in the frustrum. The following method applies ONLY to chunks that are completely in the frustrum. I loop through EACH point (including the halfway points) in the bounding box and trace a ray between the players viewpoint and that point. Then I step in a pre-defined increment along that ray and check whether it is under the terrain at that point. If it is, I flag it and go on to the next ray. If it is never under the terrain then the whole chunk has to be drawn because a portion must be visible, so you can stop checking and move on. Now, back in the loop, if EVERY point that I check is under the terrain at some point, then the box cannot be visible, so we don''t have to draw it. This can eliminate tons of terrain behind big mountains. The reason for the point in the middle of each edge of the box is that if you''re looking between two peaks at a chunk it will actually be visible, but all of your corners will be under so it won''t be drawn. This ain''t good, so having the edge point there increases the accuracy tons. Although it''s not a perfect fix, I have NEVER witnessed a visual anomoly in my occlusion with this method, so for all intents and purposes it is perfect. Oh and the reason that we only check chunks that are completely in the frustrum is that it provides a nice balance between offloading geometry to the GPU or culling with the CPU, and my testing showed that it increased framerates. If you want a demo of this, email me y2kiah@hotmail.com, sorry no code can''t give it ALL away. Later.

Share this post


Link to post
Share on other sites
just adding to my last post, I left this out. The pre defined step interval along your rays is important. The larger the step, the less accurate and faster your culling algorithm will be. This value determines how large a step you take over your terrain, so a bigger moountain will be needed to occlude a terrain chunk the larger the value gets. I recommend somewhere between 1 and 1.5 times the length of your highest LOD terrain chunk size. That way, you won''t skip over (many) quads, but you also won''t make repetetive checks. Again, balance between CPU and GPU how you want.

Share this post


Link to post
Share on other sites