Archived

This topic is now archived and is closed to further replies.

Z-buffer limitations???

This topic is 6561 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

If you were to design a program which uses hardware z-buffering is there a limit to the size of the maps you can create? eg. there are a limited number (16-bit, or more recently 24-bit) of z-values to use for depth. I noticed that the map size in the Dagoth Moor tech demo (GeForce) is huge and I was wondering if anybody knows whether it uses hardware z-buffering or if it does all of this in software (eg. Z-sort from far to near etc..)???? Paulcoz.

Share this post


Link to post
Share on other sites
Well, I have no idea about them demo becuase I have never seen it, but you are pretty much right about the z-buffer.

As with pretty much anything with computers, there''s always an upper limit, but there are techniques to help us deal with them. One obvious way is just removing objects once they are a certain distance away. Then you can use fog to help hide the sudden removal of objects.

This kind of trade if is just part of game programming. No single technique is perfect or we would all be using it. I wish I had seen that demo so I could give you a more specific answer.

Share this post


Link to post
Share on other sites
Uh, the answer is the Z-buffer is logarithmically interpolated over the distance between your near and far clipping planes. A W-buffer is linearly interpolated. Therefore a Z-buffer provides good accuracy up close but crappy when far away and W buffers provide decent accuracy all the way through.

Obviously 16 bit Z/W buffers are less accurate (and
visually appealing) then their 32 bit versions.

And btw I am sure the demo you talk about probably Z sort their objects first to minimize Z/W buffer overwrites.

Share this post


Link to post
Share on other sites