Z-buffer / decal derivation and Starbourne
Well, I've been rather busy. As my 3D career progresses, things are starting to become clearer in my head. I'm gaining a more firm grasp on the mathematics and the code. I've noticed that a lot of the times, developing code is just sweat - work that needs to be done. You have to put in the time to get the results.
I found an error in the derivation of Eric Lengyel's excellent book. In Mathematics for 3d Game Programming & Computer Graphics, Second edition, P. 276, there is an estimate of the epsilon given in order to help calculate a z-buffer offset for decal application:
|epsilon| >= (1 / 2^m-1) * (f-n)/(f+n)
Where f = far plane, n = near plane, and m = number of bits of precision in the z-buffer. According to Eric, "The minimum epsilon equation was derived by considering that the offset shown in Equation (9.4) is a constant epsilon * (f+n)/(f-n) at all depths. In an m-bit depth buffer, the distance between discrete z values is 1/(2^m-1), so we just set the offset equal to this value and solve for epsilon. As already mentioned, this value is just a theoretical lower bound. Its exact value isn't meant to be used, but instead the calculation is meant to give you an idea of what general size your offsets need to be."
However, as confirmed via e-mail, this reasoning only works if the range of the normalized z-buffer was between 0 and 1. But since that offset was found a perspective z equation that is supposed to normalize z-values from -1 to 1, the discrete z values map from -1 to 1, hence the distance between the discrete z-values actually twice as much - 2 / (2^m - 1). I have confirmed with Eric that the correct epsilon equation is:
|epsilon| >= (2 / 2^m-1) * (f-n)/(f+n)
I would like to reiterate that this value is considered by the industry professionals as essentially a theoritical low-bound for the actual epsilon values. Hence, you need to use an experimental value in conjuction with the theoritical value to truely eliminate z-fighting when implementing a decal functionality.
In other news, I've started developing Starbourne, the space game, in my free time. The details of this title are shrouded in mystery (as any indie game should be), except I will admit it is based on the excellent Irrlicht game engine.
I found an error in the derivation of Eric Lengyel's excellent book. In Mathematics for 3d Game Programming & Computer Graphics, Second edition, P. 276, there is an estimate of the epsilon given in order to help calculate a z-buffer offset for decal application:
|epsilon| >= (1 / 2^m-1) * (f-n)/(f+n)
Where f = far plane, n = near plane, and m = number of bits of precision in the z-buffer. According to Eric, "The minimum epsilon equation was derived by considering that the offset shown in Equation (9.4) is a constant epsilon * (f+n)/(f-n) at all depths. In an m-bit depth buffer, the distance between discrete z values is 1/(2^m-1), so we just set the offset equal to this value and solve for epsilon. As already mentioned, this value is just a theoretical lower bound. Its exact value isn't meant to be used, but instead the calculation is meant to give you an idea of what general size your offsets need to be."
However, as confirmed via e-mail, this reasoning only works if the range of the normalized z-buffer was between 0 and 1. But since that offset was found a perspective z equation that is supposed to normalize z-values from -1 to 1, the discrete z values map from -1 to 1, hence the distance between the discrete z-values actually twice as much - 2 / (2^m - 1). I have confirmed with Eric that the correct epsilon equation is:
|epsilon| >= (2 / 2^m-1) * (f-n)/(f+n)
I would like to reiterate that this value is considered by the industry professionals as essentially a theoritical low-bound for the actual epsilon values. Hence, you need to use an experimental value in conjuction with the theoritical value to truely eliminate z-fighting when implementing a decal functionality.
In other news, I've started developing Starbourne, the space game, in my free time. The details of this title are shrouded in mystery (as any indie game should be), except I will admit it is based on the excellent Irrlicht game engine.
posted by Wizards1stRule at
9:45 AM
0 Comments:
Post a Comment
<< Home