Primitive optimization
Author
What if we do the following:
DISABLE COLORBUFFER
RENDER EVERYTHING to ZBUFFER
ENABLE COLORBUFFER
RENDER EVERYTHING to COLORBUFFER
Is anyone using this technique? Or is this technique unuseful because of other methods of "invisible" surfaces elimination (like portals etc.)?
It's very common when you are doing a lot of passes and/or have expensive pixel shaders that you're using. Also, the newer cards can render Z-only at double speed compared to what they do if color is enabled. Generally it's not that helpful unless you have a lot of passes or shaders though -- the idea is to leverage your early Z cull in those cases.
I always thought doing something like that would cause mad z-fighting! In fact, that's one of the things I never understood or saw explained about multipass rendering.
Quote:Original post by captainmikey
I always thought doing something like that would cause mad z-fighting! In fact, that's one of the things I never understood or saw explained about multipass rendering.
No, providing the geometry is exactly the same, because then all the calculations throughout the whole CPU/GPU/whatever will be identical so all of the Z values will be the same in each pixel. There's a section in the OpenGL spec about this because GL doesn't define much about numerical accuracy of results, but does require a good amount of self-consistency, so for instance if vertex transformation was done part-CPU and part-GPU then a GL implementation would have to ensure both sets of results were the same.
Cool! Somehow I was under the impression that even changing the render state could mess up that consistency. What kind of things would break it? Like if you rendered a triangle strip, then did multipass on a subset of that geometry using triangle lists (with the exact same vertex coords as the triangles they're overdrawing) would it still work?
sure, as long as the triangles shared the same vertex's. why not? it being a list, or a strip doesn't change the rendering aspect, this only saves space and makes things a little faster, z values are obtainted by interpolation across the 3 vertices, so if those vertices are the same, then the result is the same.
Yeah, for some reason I remember reading somewhere that it was like non-deterministic on most video cards ... somehow. That never really made sense to me :P Anyways, thanks!
Quote:Original post by Generic Guest
What if we do the following:
DISABLE COLORBUFFER
RENDER EVERYTHING to ZBUFFER
ENABLE COLORBUFFER
RENDER EVERYTHING to COLORBUFFER
It's used a lot. It's called a "Z-fill" pass, or "laying down depth". Since recent cards do early Z-testing, you can get a LOT out of this technique if you use heavy pixel shaders and/or have a lot of overdraw. Moreover, on NVIDIA cards, there's a way to get very high performance during this pass; you can find a description of how to do it here. Remember that after the Z-fill pass, you should set your depth test function to EQUAL, and disable depth-write.
There is an appendix in the Red Book called "OpenGL Invariance".
"OpenGL can guarantee that images rendered into different color buffers, either simultaneously or separately using the same command sequence, are pixel-identical. This holds for all the color buffers in the framebuffer or all the color buffers in the off-screen buffer, but isn't guaranteed between the framebuffer and the off-screen buffer"
Doesn't say much about the depth buffer, but I presume this is also the case.
"OpenGL can guarantee that images rendered into different color buffers, either simultaneously or separately using the same command sequence, are pixel-identical. This holds for all the color buffers in the framebuffer or all the color buffers in the off-screen buffer, but isn't guaranteed between the framebuffer and the off-screen buffer"
Doesn't say much about the depth buffer, but I presume this is also the case.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
