PDA

View Full Version : z-buffer accuracy

genghis
08-09-2003, 11:39 AM
i've begun reading the opengl programming guide and came to a point where the book mentioned that values closer to the near clipping plane have greater depth accuracy than those nearer the far clipping plane (with perpspective projections). the reasoning behind this was because during the perspective divide the z values were scaled non-linearly. i looked online a little further into the subject, and what i figured is that the z-values are scaled in such a way because that's the only matrix transformation that will produce the desired change of the perspective canonical view volume to parallel canonical view volume (i don't know any linear algebra except how to multiply matrices so i might be wrong). my question is then, why must we HAVE to use a matrix tranformation. why can't we just alter the x, y (w?) values and leave the z value unaltered?

Rob The Bloke
08-10-2003, 09:48 AM
because the perspective projection uses a division in it's matrix.

This is what gives you non-linearity. You can look up w-buffering extensions offered by some vendors if this offends you too much, however having a non-linear depth buffer is more useful IMO; I'd rather have more accuracy where it's needed and less in the far distance....

> my question is then, why must we HAVE to use a matrix tranformation.

Matrices can be multiplied to form 1 output matrix. This means each vertex & normal you draw have a single matrix transform to undergo to output them onto the screen, irrelevant of how many rotations / scales / translations / projections you need to do.

There is no easier way of doing it......

[This message has been edited by Rob The Bloke (edited 08-10-2003).]

genghis
08-10-2003, 03:54 PM
i understand the modelview matrix, and the projection matrix can still remain a projection matrix in hardware. all one would have to change is simply tell the system to lock the z values so they can't be changed even by the perspective transformation. this way, the x and y values are changed and the z values are still scaled linearly. there is no loss of generality if you offered a lock/unlock switch. BUT, i think they also use this particular transformation to preserve lines and planes after the transform, which would mean that the lock idea wouldn't work. but i'm just guessing, i'm hoping someone knows the precise reason.

dbugger
08-10-2003, 10:09 PM
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009680.html