Most of the examples I can find of occlusion queries check the occlusion of each object each frame and then act on that the next to prevent stalling the pipeline (I can understand this; if you ask for the number of pixels you have to wait for the number to be generated) but when they are occluded, the object is replaced by its bounding box (with the colour and depth masks preventing rendering) and if any of that is visible the object is rendered.
This, to me, presents a problem; if the object becomes occluded, but its bounding box (by nature, filling more volume) is not, does this not mean that it will become visible and invisible every frame as it is made visible, occluded, invisible, bounding box not occluded, made visible, occluded, invisible, bounding box not occluded, and so on, which would lead to an uneven and unstable framerate?
I see your point. Yes, as far as I see, it can lead to a bit unstable framerate.
How many objects in a scene would go in this ‘unstable’ group? No need to panic if the number is small (5-10%).
So the issue is real and there’s no solution to it? 5-10% IS quite a lot, especially if you don’t have spare fillrate, and it would create a jerk on every second frame that would create the impression of a lower overall framerate.
vsync or bust.
5-10% is not a lot, when users disable vsync. Low-end users are used to spikes between 10 and 80fps, highend users are used to spikes between 80 and 300 fps.
It’s absolutely impossible to make each frame render exactly as quickly as the others, when the camera moves. Camera looks up: 10 objects, camera looks forward: 4000 objects.
Even if you’re coding for a set-in-stone platform (console), you plan the headroom, and via a play-through performance test check whether parts of the scene need to be simplified to meet the vsync.