the plug-in can use the high res. LOD of a model or the low res. it can use a bb.
There is no "cheat" and "correct" implementations, this is game development, not scientific research and visualization, we favor look and feel over physically correct behavior or result
It's time you don't have the time so you cutt corners.
But please tell people what it dosn't do. Or they belive otherwise.
Feeling and look has with performance to do in the end if you saturate the system.
Well if you just have one pass one material and two objects on the screen you won't have any problem. Look and feel is OK.
But if you want to use DX9 Sm3.0 features and do some heavy scenes you need to save your computers energy and put it where it counts.
What I mean with cheap trick is rendering too an off screen texture usually smaller then screen size. Which results in a depth buffer in the RTT that can't be used for early z out because it's not the same size.
This means you need two extra passes of your scene one for hw occlusion query one for depth whoich is even more expensive...
And if you use the same size on the RTT and the backbuffer you use up too much memory.
I also mean that any solutions that only use bb has tio high fill rate cost.
And finally that the implementations are not general. Everything can't be occluders occludes automatically. It's just for the scene manager nodes or it's just for the portals. And if you want to use hardware occlusion query on something else in the scene as well you are done for.
The plug-in does the depth pass and hardware occlusion test in one pass on the backbuffer using the hole Ogres rendering system.
You don't need to set a special pass for every technique for every material in your application.
It's more generic and it's exactness is only depending on how you use it.
So you see, it's very different from those one of solutions for particular demos or applications that visualize an empty city, structure thing.
It's more geared for giving feed back to a game engine via an API on what’s really visible on a really detail level using callback interface.
Using boxes... well that’s fine to start learning hardware occlusion or doing a little specialist thing. It's not what the manual suggests.
There might be applications out they’re stopping and waiting for a query to be ready. Next you will claim that’s OK too? Having the CPU sitting idle doing nothing is one of the seven sins.
Bad accuracy is when a bb is visible but the object in it isn't.
And the BB takes up more fill rate than the object.
When I did the plug-in Ogres rendering options was not as advanced as they are today. Still you can get a way with alot.
I am so sorry if I am unjust in my feers that fast implementations may lead people to belive it's general solutions.,
Another "cheat" is thoose apps that use hw occlusion query but they render the frames with Ogres low level API only. They don't support Ogres renderques or rendering at all which this plug-in does. It supports basic Ogre rendering pipeline.
So hopefully you now understand what I mean by "cheats", they are plenty the ones you read about and think thats sound general and fine but they are not.
One cheat for early z out is to sort on materials but make an exeception for the a couple of big objects in the front (good occluders) and render them first and the rest of the scene sorted on materials.
There are just so many cheats...
Being a good game programmer means knowing them and using them
where they fits.
Middleware developers however needs the general solutions that works with the hole system, because different customers want's to use it for different applications with different needs. Thats why our plug-in is general
and as complete as possible.
Ph.D. student in game development