GL_depth_clamp

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.

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.

depth_clamp_separate, I like it. :wink: The question is whether hardware supports it.

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

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 ?

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.

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. [/QUOTE]
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. :slight_smile:

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.

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;

Ah, ok. Thanks.