Depth Biasing
Hi,
Recognizing the arguable usefulness of z-biasing, I''m stilled interested in the following:
DX9 documentation defines a depth offset as:
Offset = m * D3DRS_SLOPESCALEDEPTHBIAS + D3DRS_DEPTHBIAS
where m is the maximum depth slope of the triangle being rendered
For Z-Buffers...
1) Is this offset "added" to the computed z value after w divide, or is it in the range of the zbuffer?
2) What is the valid range of this offset (e.g. -1.0 to 1.0 or 0.0 to 1.0, etc.)? I.e. can I move a polygon towards me or only away?
3) Is this Offset applicable anytime a ZBuffer is ENABLED or only if D3DRS_ZWRITEENABLE is set to TRUE?
Thanks for all thoughts,
Brad
On this page, it says:
"The offset is added to the fragment''s interpolated depth value to produce the final depth value that is used for depth testing and optionally is written into the depth buffer. "
So:
1) It''s in the zbuffer range, given that it''s written into the depth buffer (if ZWrite is enabled)
2) It''d make sense that you move triangles towards you only (i.e. a positive value)
3) Obviously if z-writes are disabled, the biased depth won''t get written.
Muhammad Haggag
"The offset is added to the fragment''s interpolated depth value to produce the final depth value that is used for depth testing and optionally is written into the depth buffer. "
So:
1) It''s in the zbuffer range, given that it''s written into the depth buffer (if ZWrite is enabled)
2) It''d make sense that you move triangles towards you only (i.e. a positive value)
3) Obviously if z-writes are disabled, the biased depth won''t get written.
Muhammad Haggag
Forgot to say something important:
A lot of drivers/hardware don''t support the new depth-biasing, so you''ll have to resort to hacking the projection matrix for such hardware. Given that the hack works anyway, you might as well use it for all the hardware out there, instead of adding a codepath.
Muhammad Haggag
A lot of drivers/hardware don''t support the new depth-biasing, so you''ll have to resort to hacking the projection matrix for such hardware. Given that the hack works anyway, you might as well use it for all the hardware out there, instead of adding a codepath.
Muhammad Haggag
Muhammad,
Many thanks for the quick response. This is educational for me, so I appreciate your help. If I understand you correctly, if I set a negative value for D3DRS_DEPTHBIAS (for example, with D3DRS_SLOPESCALEDEPTHBIAS=0), it will be clamped to zero. Correct? ...or does produce "unpredictable" results?
Also, I was curious about the D3DRS_ZWRITEENABLE implications in that I was trying to confirm that the "Offset" would be applied for depth testing even if z writing was disabled. (I had tried this is my application and, based on what I was seeing, it wasn''t clear that the Offset was being applied while D3DRS_ZWRITEENABLE was disabled.)
And finally, I had seen the references to tweaking the proj matrix in other threads earlier today; tried it; and it works great! My questions we''re ultimately geared towards a better understanding of how the DepthBias stuff "works".
Thanks,
Brad
Many thanks for the quick response. This is educational for me, so I appreciate your help. If I understand you correctly, if I set a negative value for D3DRS_DEPTHBIAS (for example, with D3DRS_SLOPESCALEDEPTHBIAS=0), it will be clamped to zero. Correct? ...or does produce "unpredictable" results?
Also, I was curious about the D3DRS_ZWRITEENABLE implications in that I was trying to confirm that the "Offset" would be applied for depth testing even if z writing was disabled. (I had tried this is my application and, based on what I was seeing, it wasn''t clear that the Offset was being applied while D3DRS_ZWRITEENABLE was disabled.)
And finally, I had seen the references to tweaking the proj matrix in other threads earlier today; tried it; and it works great! My questions we''re ultimately geared towards a better understanding of how the DepthBias stuff "works".
Thanks,
Brad
quote:Original post by Brad Sweet
If I understand you correctly, if I set a negative value for D3DRS_DEPTHBIAS (for example, with D3DRS_SLOPESCALEDEPTHBIAS=0), it will be clamped to zero. Correct? ...or does produce "unpredictable" results?
Sorry for not phrasing myself clearly. I *think* it''d make sense to be >= 0. The 2 scenarios you decribe are possible, when setting negative values.
As a quick test, try to set it to a negative value and observe the debug output (if it''s illegal, you''ll get an error/warning).
Muhammad Haggag
As long as D3DRS_ZENABLE is set to D3DZB_TRUE, the depth offset will be applied prior to the Z test. If the Z test passes and D3DRS_ZWRITEENABLE is TRUE, then the depth value will be written to the depth buffer (standard stuff).
Both positive and negative offset values are valid.
The offset is being added to a Z value that lies within the range of [0.0, 1.0] (i.e. after the division by W). After the addition of the offset, the result is clamped to the range of [0.0, 1.0].
In the simple case, if you want to offset your primitive in a direction closer to the camera by one unit of precision in a 16-bit Z buffer, you''d set D3DRS_DEPTHBIAS to -1.0/65536.0 (leaving D3DRS_SLOPESCALEDEPTHBIAS set to 0.0).
Also, the depth bias doesn''t affect point or line primitives.
Hope that helps.
Both positive and negative offset values are valid.
The offset is being added to a Z value that lies within the range of [0.0, 1.0] (i.e. after the division by W). After the addition of the offset, the result is clamped to the range of [0.0, 1.0].
In the simple case, if you want to offset your primitive in a direction closer to the camera by one unit of precision in a 16-bit Z buffer, you''d set D3DRS_DEPTHBIAS to -1.0/65536.0 (leaving D3DRS_SLOPESCALEDEPTHBIAS set to 0.0).
Also, the depth bias doesn''t affect point or line primitives.
Hope that helps.
Don,
Thanks for your comments. I had posted the same question to ATI dev support yesterday, and they responded back last night with answers that are consistent (though not as detailed) with your info. Curiously, I also received feedback from MS offering views that were not in line with those presented by you and ATI.
Thanks much for the help,
Brad
Thanks for your comments. I had posted the same question to ATI dev support yesterday, and they responded back last night with answers that are consistent (though not as detailed) with your info. Curiously, I also received feedback from MS offering views that were not in line with those presented by you and ATI.
Thanks much for the help,
Brad
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement