It's a simple question but I can't get a definite answer to it. I hope the more experienced OpenGL-users here can: I know that in the OpenGL render pipeline stencil-testing occurs before depth-testing, but can this situation be exploited to speed up rendering by limiting overdraw using the stencil buffer? Keep in mind that the z-buffer can't be disabled in my situation. I'd say it will be slower (as you have to do two per-pixel operations (Stencil and depth) but is this really the case? Vision yourself this situation: You are in a room with a very small window looking outside (the outside is completely occluded except through the tiny window). Rendering the outside world "as it is" wouldn't give problems (the Z-buffer will do it's work, but there will be a massive amount of useless z-test failures) but can this be speed up by using the Stencil buffer (for the "window-area") and only using the Z-buffer for the pixels that passed the Stencil test? I hope I made myself clear enough.

It depends [grin]

Modern hardware performs an early z-cull, which means that fragments are rejected before they even hit the fragment shaders, never mind the rest of the pixel pipeline.

Because of this many games do a z-only pass (or z and ambient colour), which fills the z-buffer with values to prevent overdraw as all fragments which wont be seen will be culled before they hit the pixel shaders.
This is why you should draw in a rought front to back order as well.

There are a couple of situations which disable this feature however.
If you use a shader which modifies the depth value it will switch off this early cull and fall back to the 'normal' method of the pipeline. (It stays off until a depth buffer clear as well afaik)

iirc polygon offset also causes this effect, but I'm not 100% certain if its (a) true and (b) if it effects both NV and ATI or just one of them.

So, with your theortical scene, as long as you arent adjusting the depth value then you just draw your scene front to back and let the zbuffer work its magic.

You could optmise it a bit by working out what objects you wont see before drawing, however this will require CPU time so depending on the complexity of the object to be drawn and your target hardware it might be faster to just let the card reject it and free the CPU for other work.