Occlusion queries rock and DirectQ has been set up to be able to read back the results without stalling the pipeline. The tradeoff is that there is a frame or two of latency in the results, but in practice that's not a problem, especially if you set things up to be reasonably conservative to begin with.
Previously I've used them on MDLs only, but now I've extended them to also include brushmodels. Furthermore, all MDLs and brushmodels in the scene are also potential occluding objects, as well as potential occludees. A slight difficulty with this is that objects may now potentially occlude themselves, but I was able to resolve that by expanding the bounding box slightly. This should also help with cases where a model is just barely occluded but is about to come into view shortly.
Is it fast? You bet! The "difficult" ne_tower scene that I frequently mention has now jumped by about 20 FPS. I think that's a good result.
There is now also potential to run them on the world; possibly at node or leaf level. It's all in the name of lopping off as much overdraw as possible so that things can run ultra-smooth in even the most complex scenes.
There is some small overhead from running occlusion queries in that they need to draw a bounding box (with colour and depth writing disabled) in order to test if the object is going to appear in the final scene, but overall this balances against the performance gain from not drawing objects that don't appear.
They can also bring in some good performance levelling. It's no use running simple scenes at 47 billion FPS if complex (or even modelately complex) ones drag you down to less than 20. It's worthwhile to sacrifice some of that 47 billion in order to bring up the speeds of the slower scenes, don't you think?
Anyway, off to try them out on the world; I'll let you know how that goes shortly. And before you ask, no, that's actually not the other thing I have planned for further accelerating world rendering; there's potentially still more to come.
Update:
Unfortunately that one frame of latency is proving to be a killer when crossing a water line. The current option seems to be to not include water surfaces as potential occluders. Let's see how it goes...
Update 2:
Yup, that did it.
Saturday, June 26, 2010
More Occlusion Queries
Posted by
mhquake
at
3:50 PM
Subscribe to:
Post Comments (Atom)
2 comments:
..Good deal! Sounds greaT.
xaGe
Sounds like you're very close to a r_showbboxes cvar...
Post a Comment