Jump to content
  • Advertisement
Sign in to follow this  

Polygon Offset in shader

This topic is 3058 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

Hi! I'm trying to emulate GL_NV_depth_clamp behavior via GLSL when it's not supported. My problem is that if all 3 of the triangle's vertices fall outside of the near / far clipping region, the triangle is discarded. So I won't have a chance to clamp the Z values in the fragment shader. What I came up with is to save the Z and W values to varyings in the vertex shader and substitute the Z value in the gl_Position with a fake one that's not going to be clipped. Then in the fragment shader I do the perspective division and offset with the saved (and interpolated) Z and W varyings. So I can get back the correct position and do the clamp if needed. The problem is I lose the GL_POLYGON_OFFSET_FILL functionality this way. Because that happens after the vertex shader but before the fragment shader. So it looks I'll have to implement the Polygon Offset functionality in the fragment shader. Can anyone help me with that? I already found out that:
offset = m * factor + r * units
where 'factor' and 'units' are user-given parameters,
dx = dFdx (depth);
dy = dFdy (depth);
'm' = sqrt (dx*dx + dy*dy)
'r' = "The smallest value guaranteed to produce a resolvable difference in window coordinate depth values. The value r is an implementation-specific constant."
Is there a way to retrieve or calculate 'r'? Is 'depth' (the value used for derivation) the Z before or after the perspective division? Anyone knows any code example on Polygon Offset implementation in shaders? Or is there a way to disable clipping with the far plane? Thank you!

Share this post

Link to post
Share on other sites

I have found GL_CLIP_VOLUME_CLIPPING_HINT_EXT to disable view frustum culling but it seems it's not supported on today's cards. (And also might be ignored anyway by definition.) So it seems it's not the way to go.

The 'depth' in dx = dFdx (depth); is likely to be the Z after the perspective division or so it seems to me.

But I can not find out 'r'...
I know it should be calculated somehow from the Z buffer precision bit count, but I have no idea how.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!