If you have a 24-bit Z buffer, and reasonable near plane distance, then you shouldn''t really be seeing problems.

Z buffers have linear resolution in framebuffer space. That means that, if you count the DEPTH of a pixel as well as the width, a pixel in the framebuffer that''s near the plane may be 1 cm x 1 cm of screen real estate, and 2 cm of depth (for example). That same pixel, if it''s representing something far away, might be 1 m x 1 m, and then it would represent 2 m of depth interval.

W buffers represent the same distance of depth no matter what the pixel represents. Thus, if the pixel is up close, it''ll have 30 cm resolution. If it''s really far away, you''ll still have 30 cm resolution. The problem with this is that you lose WAY too much precision up close, and you get precision way far out that you don''t need. Z is much better, because it scales just like pixel size with distance.

What would actually happen if someone used three matrices, one with a relatively close near plane for objects that are extremely close, another with a more modest near plane for 90% of the geometry and then a third matrix with its planes extremely far away for rendering objects in the distant background with better precision. So long as all the matrices share the same FOVs would this technique work seemlessly or would there be some serious noticable flaws?

"I find it immoral to have a battle of wits with an unarmed man"
~Vendayan


[edited by - Vendayan on January 8, 2004 1:57:55 AM]

quote:Original post by Vendayan
What would actually happen if someone used three matrices, one with a relatively close near plane for objects that are extremely close, another with a more modest near plane for 90% of the geometry and then a third matrix with its planes extremely far away for rendering objects in the distant background with better precision. So long as all the matrices share the same FOVs would this technique work seemlessly or would there be some serious noticable flaws?

As long as you clear your Z-Buffer between passes it will work. However, you need to draw the far things first, which can reduce the benefits of doing so. For example, if you used a 2 pass approach (1 for the world, 1 for the GUI) and draw the GUI last, then many things that would have been occluded by the GUI will be rendered anyway in the first pass. Visually it will be fine, but it is a performance hit.


Stay Casual,

Ken
Drunken Hyena

Hmm... I see, that is a bit of a performance hit having to refill the entire scene potentially for scenes that are densely occluded

Yet is this still how many games accomplish this?

"I find it immoral to have a battle of wits with an unarmed man"
~Vendayan

First things that come to mind, some of these have already been mentioned:

Use a W-Buffer instead of a Z-Buffer.

Change your clipping planes-if you are rendering other objects behind your windows, render them first, then reset your z-buffer with your clipping planes.

Use ZBias - Research SetRenderState & D3DRENDERSTATE_ZBIAS


-----------
VenDrake

"My stupid jar is full. I can''''t talk to you anymore."

NOTE: I''ve never tried this so I don''t know how well it will work. It just occurred to me.

-Clear your scene
-With Z enabled, turn off your colour channels
-Render your windows quickly (no text, no detail, just base shape), this primes your Z-Buffer
-Turn colour channels back on
-Render your scene, Z-Buffer will still reject anything that would be occluded
-Clear Z
-Set clipping planes to give disgusting precision only up to 100 units (the farthest your UI is rendered)
-Render GUI

Still not ideal, but should help some of the performance issues and give you extreme precision for your GUI.

Though if your GUI blocks large segments of your scene, you may want to do some sort of occlusion culling which would speed things up even more and require less fiddling.


Stay Casual,

Ken
Drunken Hyena