Jump to content
  • Advertisement


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


how to choose occluder in ABT

This topic is 5618 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

I plan to add occlusion culling (using software HOM) to my simple ABT/frustum culling system, but I don't know how to choose the best ABT node as the occluder. (in my implementation, each ABT node contains ~500 triangles, so I think I cannot afford software rasterizing more than one node) I know it's more or less based on distance or screen-space projected area. But I don't know the detailed math here. Can anybody describe more in details? [edited by - gamelife on June 3, 2003 7:20:49 AM]

Share this post

Link to post
Share on other sites
I have implemented a software rasterizer for that purpose, but i''ve encountered some problem, the algorithm works and works well, but it doesn''t turn out to get a speed acceptable ( at least for me ), basically , i do a second rendered using cached surfaces i store in a list when i traverse a bsp tree with inorder walk, the inorder walk gives me front to back ordering, i trace the widest surfaces stored in a sorted array during building time, then i check for the node bounding boxes against a software depth map optimized with hand-assembly, *but* , sometimes the heuristic for choosing the best occlduers fails , because smaller occluders are rejected when they might occlude wider area fusing toghether, stopping with a maximum of surfaces didn''t help because a lot of visible map was still showing, then i''v moved the traingle rasterizer to be a polygon rasterizer but this gave all kind of nasty clipping problems, anyway, if you want to research, you should
extract your viewing matrix
compute the viewing coordinates of your occluders
cache the shared vertices to avoid recomputation
project the vertices , clipping to the near plane
rasterize the occluder
test for bounding box occlusion when you are about
to draw the next node in your tree, if the test gives false,
pop ( or jump ) form the current recursion
good luck

Share this post

Link to post
Share on other sites
Hmm. First of all, you need to decide if you want to use the ''real'' mesh geometry stored in each node to represent the occlusion, or use a special occlusion geometry placeholder. The former case is going to be much more CPU intensive. As you said, you can''t SW render more than one node, and one node is far from enough in practice. To get the full benefit of occluder fusion, and deep occlusion (culling at greater distances), you''ll have to render quite a few nodes.

I would personally suggest using dedicated occlusion skins, or virtual occluders. In the end, it all depends on the kind of geometry you want to display, but generally occluder skins aren''t too hard to create, and are well worth it. For the same performance used to render a single node using the full mesh, you could render 20+ nodes when using occlusion skins.

Now, about the selection, that''s anything from extremely easy to extremely complex. Actually, you can make it as complex as you want, but the basic system is very easy. It''s upon you, if you are satisfied with the basic results, or if you prefer to investigate into something more complex. Basically, you can start by using the minimum camera-node distance. Take your node''s bounding box, create a plane that is parallel to the camera plane, position it at the nearest possible point of the box, and compute the distance to the camera. If you do that in eye-space, it''s extremely easy: transform your 8 box points into eye-space, and take the nearest z-value. There you have your distance. Even more otimized algorithms also exist.

Next thing is, as you guessed, the screenspace projection size. For that to work, you''ll have to (manually) project your bounding boxes to the screen. But you''ll have to do that anyway for the HOM test later on, so you will probably already have the code. Then, get the bounding rectangle of the projected box on the screen, and compute the area. There you go, your second factor.

Several more criteria exist, expecially when dealing with temporal coherency - things like: was that node occluded during the last frame ? Was it a good occluder ? Was it partially visible, and does it have the chance to be totally occluded this frame ? Etc... As I said, you can make it arbitrarily complex But your mileage will vary, a heuristic that is good for my engine might not be good for yours, and vice-versa.

I''d suggest implementing a couple of heuristics, and trying them out. Fiddle around with weighting factors, combine several of them, etc. It''s much trial and error involved, you''ll eventually find an optimal combination.

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!