PDA

View Full Version : GL_depth_clamp



remdul
11-05-2009, 08:48 AM
If GL_NV_depth_clamp will be added to the core, wouldn't it be useful to enabled/disable the clamp mode for the near and far plane individually?


glEnable(GL_DEPTH_CLAMP_NEAR);
glEnable(GL_DEPTH_CLAMP_FAR);
I currently use depth_clamp for shadow mapping to avoid near plane clipping of shadow casters, and keep the depth range focused on where it is needed most. However, I don't want stuff clamped to the far plane. If distant geometry were clipped by the far plane and not rasterized at all (as normally) it could save a tiny bit of performance. And I'm sure there are other uses as well.

Dark Photon
11-06-2009, 07:37 AM
If GL_NV_depth_clamp will be added to the core, wouldn't it be useful to enabled/disable the clamp mode for the near and far plane individually? ... I currently use depth_clamp for shadow mapping to avoid near plane clipping of shadow casters, and keep the depth range focused on where it is needed most. However, I don't want stuff clamped to the far plane.
That's a good point.

I agree with the utility of this, especially with shadow mapping for directional lights (parallel projection light frustums) where there's no Z=0 singularity.

You'd certainly want the "closer to the light" casters to be smashed onto the near clip plane of the shadow map, but smashing the beyond-far caster fragments back into the frustum (against rays of light) is a waste.

Now admittedly, we all should be frustum culling what gets rendered into the shadow map, so we should only be talking about fragments of objects that straddle far-clip that are smashed back onto the far clip (not bunches of objects beyond far clip). But still, a good point for saving shadow map fill.

So if it's all the same to the vendors, I agree, separate clamps would be desirable.

Eosie
11-06-2009, 11:34 AM
depth_clamp_separate, I like it. ;) The question is whether hardware supports it.

FYI, ARB_depth_clamp (based on NV_depth_clamp) is already part of GL3.2.

Rob Barris
11-12-2009, 01:37 PM
So, assuming values were not being clamped to the far plane, what value would you like written to the Z buffer for those cases ?

Restated, what's wrong with just setting a high clamp value, one that results in the maximum possible depth value ? The outcome with and without the far camp would then be the same I think ?

Edit, OK I see, you might want them to just fall outside of the clip volume and be lost ?

Dark Photon
11-12-2009, 06:21 PM
Edit, OK I see, you might want them to just fall outside of the clip volume and be lost ?
Exactly. The operative issue being the potential fill savings. If an engine is only doing course frustum culling (or isn't culling), or has objects with lots of tris/fill, it could really mount up.

remdul
11-16-2009, 03:04 PM
Edit, OK I see, you might want them to just fall outside of the clip volume and be lost ?
Exactly. The operative issue being the potential fill savings. If an engine is only doing course frustum culling (or isn't culling), or has objects with lots of tris/fill, it could really mount up.
Ditto.

Actually our engine does pretty accurate frustum culling for the shadow pass (anything beyond the far-plane is culled, anything in front of and behind the near-plane is rendered), but I still don't want the portion of the geometry beyond the far plane rasterized if the hardware can clip it just as easy. :)

Xmas
11-18-2009, 03:11 AM
As a stop-gap solution you could manually clip against the far plane in the vertex shader.

Dark Photon
11-18-2009, 06:07 AM
As a stop-gap solution you could manually clip against the far plane in the vertex shader.
Maybe I need more caffeine this morning, but how would that work? Suppose two verts in and one vert out.

Xmas
11-19-2009, 07:32 AM
By writing a clip distance in the vertex shader (or using client-defined clip planes in earlier versions of GL).

In the API:

glEnable(GL_CLIP_DISTANCE0);
In the vertex shader:

gl_ClipDistance[0] = gl_Position.w - gl_Position.z;

Dark Photon
11-19-2009, 11:41 AM
Ah, ok. Thanks.