Sign in to follow this  

Depth and Z buffer

Recommended Posts

brekehan    101
The next thing I am pondering is the order in which to render things and how to solve my Zbuffer issues. The SDK docs say to render from front to back for performance. But when you have differant perspective matrices for differant components who knows what is front and back anymore? For instance: My app will draw a skybox (should be very back), 3d Geometry (should be middle), billboarded effects such as lasers that can be emitted anywhere (who knows?), and finally a 2D UI that lays on top of everything. So I am confused as to what order to render things and when to enable or disable the z buffer so things occlude properly. Most pages I read on the net say to replace your clear function with the rendering of the sky box and disable the z buffer for that, which makes sense, but does not follow the SDKs advice. Next, if I follow the SDKs advice, I render the UI followed by the 3d geometry that makes up the rest of the scene, but how do I enure that the 3D geometry does not appear on top of my UI? How can I force the UI to write the z values that correspond to the near clip plane? How can I verify that it did? How can I provide for differant layers of my UI? For instance: a button on top of an image. etc. I read through all the z buffer docs and researched online, but as far as I can tell, I can only tell Direct3D to render the next calls no matter what and ignore the z buffer, or render it back to front and turn off the z buffer, or (what I really don't understand) do not render the next thing because I am telling the z buffer test to always fail! Mix matching these options I don't see how to guarantee proper order. I could just use the Z values if everything was done with the same perspective matrix, but it isn't and I'd hate to have to work a 3 page trig problem for everything I want to render. Please help me understand this problem.

Share this post

Link to post
Share on other sites
Evil Steve    2017
Rendering from front to back doesn't have to be exact, you only do that roughly to minimise overdraw. If you render from back to front, then some pixels get overdrawn by nearer objects, so the graphics card has to do more filling.
If you're rendering translucent objects (With SRCALPHA / INVSRCALPHA usually), you need to render them from back to front, to get hte see through effect working properly.

There's no point in clearing the backbuffer if you're rendering a skybox, because the skybox will fill the screen anyway. I'm not sure about using the skybox to clear the Z-buffer though, since the skybox is supposed to be at infinite distance, so you'd have to give it very high Z values, and then make sure that it doesn't intersect the far clip plane.

I'd draw your skybox first, then sort your game objects in rough front-to-back order (Don't do any excessive calculations to order it), and make sure that the translucent objects are ordered last, in back-to-front order, then draw all those game objects, then draw your UI. I'd draw the UI last, because it's likely that it'll be translucent, and you might want to disable the Z buffer for rendering it, just to make sure it's on top of everything.

Share this post

Link to post
Share on other sites
ET3D    810
With regards to the skybox, it's no problem to start with a clear, then remove it later, and see if it makes a difference to performance. My general recommendation is to not optimise too much while developing. When the screen is cleared it's much easier to find some errors than when it's not.

Also, don't trust all the advice you read. Some things might have been true once but no longer are. For example, as far as I know current cards do a very efficient clear, which doesn't involve writing data to the entire buffer.

Regarding separating your UI from your rendering, as Steve suggested, if your UI is 2D and on top, then rendering it last with Z disabled is a simple way of assuring that nothing obscures it.

If your UI includes 3D elements which need to be rendered, you can either do it to a render target, or use the MinZ and MaxZ fields of the viewport structure to separate your rendering into distinct Z ranges.

Original post by brekehan
But when you have differant perspective matrices for differant components who knows what is front and back anymore?

What is front and what is back is well defined. After you tranform your vertices, they are always in the same space, no matter where they started from. I'd suggest that you read more about transforms to understand this better.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this