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.

The need for GF3 is to do the occluding in hardware.

_______________

Jester, studient programmer
The Jester Home in French

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.

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.