   Occlusion Culling and Terrains.
  I've two questions regarding occlusion culling.1. Supposing I'm using a kd-tree for occlusion culling, and I have a terrain system which optimizes using geomipmapping and other techniques such that at each render frame, the view cone is used to generate a polygon list for the terrain to be rendered, how do I use this info in conjugation with the kd-tree. Do I simply mark the set of polygons as potential occluders and draw them on the map??2. Given that terrain vegetation can act as good occluders, what kind of coarse skin can I use for trees. Because they have leaves which may use alpha channels to achieve detail and because the skin will never use this channel to render at least if I am using a sw approach, or do I use that channel somehow??(I posted this in the Game Programming section too...)-thanks for any help :)   
Quote:Original post by obhiGiven that terrain vegetation can act as good occluders, what kind of coarse skin can I use for trees.Vegetation generally makes very poor occluders - you will only achieve 100% coverage with masses of dense foliage. A better approach might be to render the scene from front-to-back, and let the early z-reject take care of terrain fragments.Quote:Because they have leaves which may use alpha channels to achieve detail and because the skin will never use this channel to render at least if I am using a sw approach, or do I use that channel somehow??Are you implementing a software renderer, or using OpenGL/D3D? I could see this type of occlusion culling helping a software renderer, but on modern graphics cards, I have doubts that you will see much of a performance benefit from this approach.Quote:(I posted this in the Game Programming section too...)Please don't cross post - it just makes for confused replies [wink]   ;  for terrain it often makes sense to precalculate occlusion. you just save a tightly compresses (with runlenght) bit pattern at every sector for the visibility of the other sectors. that probably wont change during gameplay.this culling is really cheap to test, and you could even use your KD-tree to store that bit at every node, which would cull a big amount of terrain with one bit-test.that's for sure not as accurate as real occlusion culling, but doing accurate occlusion-culling on terrain isn't cheap either.   ;Quote:Original post by swiftcoderAre you implementing a software renderer, or using OpenGL/D3D? I could see this type of occlusion culling helping a software renderer, but on modern graphics cards, I have doubts that you will see much of a performance benefit from this approach.I'm using D3D (basically an abstract driver with a working d3d9c implementation), but I am considering a software rasterizer for the occluding geometry to get rendered on the occlusion buffer.Quote:(I posted this in the Game Programming section too...)Oh well! I actually deleted that the instance I posted it here.Quote:Original post by Ktypt0nfor terrain it often makes sense to precalculate occlusion. you just save a tightly compresses (with runlenght) bit pattern at every sector for the visibility of the other sectors. that probably wont change during gameplay.Do you mean a view independent bit pattern. I cannot figure out a way to or method for generating such a bit pattern, the compression wont be an issue though.What should be the search text for articles on this type of occlusion culling. Pointers are welcomed.Thanks for your reply's.   ;Quote:Original post by swiftcoderVegetation generally makes very poor occluders - you will only achieve 100% coverage with masses of dense foliage. A better approach might be to render the scene from front-to-back, and let the early z-reject take care of terrain fragments.Yeah, but I was hoping for a way to avoid pushing those polygons to the graphics card. In fact I found a previous post quite similar to mine where people considered using low poly conservative skins for trees. Of course grass and ground foliage(like shrubs) might not really need an occlusion query, it would rather be costly on the CPU. I was rather thinking about trees, a dense forest may occlude a building far down the view distance and I am really considering large view distance here.;Quote:Original post by obhiQuote:Original post by swiftcoderVegetation generally makes very poor occluders - you will only achieve 100% coverage with masses of dense foliage. A better approach might be to render the scene from front-to-back, and let the early z-reject take care of terrain fragments.Yeah, but I was hoping for a way to avoid pushing those polygons to the graphics card. In fact I found a previous post quite similar to mine where people considered using low poly conservative skins for trees. Of course grass and ground foliage(like shrubs) might not really need an occlusion query, it would rather be costly on the CPU. I was rather thinking about trees, a dense forest may occlude a building far down the view distance and I am really considering large view distance here.If your terrain and vegetation are mostly static, then Ktypt0n's suggestion of pre-calculated visibility is probably the best option from a performance standpoint. Basically, you put together an offline tool that calculates from each chunk the visibility of every other chunk.I don't think your software occlusion rasteriser will really help that much - but I haven't actually tried it.   ;  Actually, this is a basic implementation, I'll go forward with the occlusion query feature most graphics cards have these days. But I'll really be interested in learning how this offline processing is done, any pointers.   ;  it took me really a lot of efforts to make an software occlusion rasterizer that was fast enough to save something. especially with those amount of triangles you usually have for terrain, cause the tri-setup, even with funky halfspace or homogenous space rasterization, takes you several cycles, while the GPU setups one tri/s.so, to get some advantage, you have to have a really high ration of occluded:visible terrain segments.occlusion culling on gpu, in general, suffers from the fact, that you still need to draw something. to get best results, you can setup the Vertexshader to be as simple as possible, with no pixel shader, no framebuffer, just z-tests. But that wont save you that much cpu-setup time for drawing (and drawcalls are usually a bottleneck) and you still have to push the vertices on the gpu (some lower LOD might help).if you want to search for the precalculated stuff (precomputed visibility set), your keywords are: terrain+pvs;  Correct me if I'm wrong but if implementing on the hardware, can't we use the FVF by drawing the low poly skin to the depth buffer only (disabling the color buffer). We can surely use the occlusion query feature in direct3d (opengl supports this too), to just check if any pixels were drawn. If not, we can avoid drawing the object altogether.In the software, no doubt the rasterizer will need thorough optimizations. SIMD will help.   