Jump to content
  • Advertisement
Sign in to follow this  
kRogue

HOM, is it worth the trouble to implement?

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

Hi all, Nowadays, most of the 3D accelerators out there (for nVidia Gefore3 or better, for ATI, not too sure) have Z-occulsion built into them... thus if you render front to back, then the card will do the Z-culling (or much of it) automatically for you... so IF you write for PC, is it worth the trouble of implementing Heirarical Occulsuion culling (ala Zhang thesis)? it appears that mostly what it does is jsut Z-culling anyways (and is an image precssing method) thus wouldn't the Z-culling of the video card better (in terms of the fact to do Heierchal occulusion, on needs to render to a few textures) .... what do people conisder good culling methods (besieds the obnvious view-frustrum)? I am having an eye on methods which do not require pre-computing (like BSP stlye PVS)...I've seen hints of "per-pixel" Occlusion Culling, but my first though on that was fishy (namely shoot a ray from the viewer to each picsl on the screen)... and started to just think that the Z-culling of a video card would be better than that.... one mehtod that looks attractive to me is at: Portals and Occulusion query any thought, input much appreciated. Best Regards

Share this post


Link to post
Share on other sites
Advertisement
From what i'm aware of image space methods are the best as of this moment and unless something else has come up, the current state of the art in occlusion culling is incremental occlusion maps (IOM) an incremental variant of HOMs plus some other techniques thrown in, handles dynamic scenes and from what i remember requires no precomputed info. Spatial data structure used is an axis-aligned BSP tree (probably a kd-tree variant where the position of the splitting plane is not fixed making it adaptive to the configuration of objects).

From what i've read the system is overly complex and the original implementation was something like 10,000 lines of code, as far as i know only the dPVS library implement it.

Share this post


Link to post
Share on other sites
The sort of Z-culling that you automatically get with current video cards is on the fragment level. So if you have a model with 5000 triangles that's getting culled, you're still sending all those triangles to the card, which eats bandwidth and vertex processing power.

It's possible to use the occlusion query extensions to improve this a bit by getting the video card to check against a bounding box of the object first, checking the result and then only drawing the object if its bounding box would have appeared. This is a pretty high-latency thing to do and tends to cause stalls in the GPU pipeline, so in practice what often is done is using the visibility result from the *last* frame to determine if something is occluded in the current frame. This approach works, but you're still using a decent amount of fillrate checking the bounding boxes.

In the end, it still might be a win to do a low resolution HOM on the CPU. With the current trend towards multi-core processors, running the HOM calculations in a separate thread might be a good solution, especially if performance is limited by bandwidth to the GPU, GPU vertex processing rate, or fillrate.

j

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!