nv_depth_buffer_float breaks shadow mapping

Hi folks!

I render a shadow map to a GL_DEPTH_COMPONENT32F_NV texture. This texture is attached to a FBO without any color attachements.

I render the normal scene to a RGBA8 color Renderbuffer and a GL_DEPTH_COMPONENT32F_NV depth renderbuffer, both attached to a FBO, not the same as the one used for the creation of the depth map.

When the depth range is [0.0, 1.0] everything works (glDepthRangedNV called with (0.0, 1.0))
But as soon as I widen the depth range (with a call such as glDepthRangedNV (0.0, 10.0) for example), the shadow mapping doesn’t work anymore, the vector returned by shadow2DProj is uniform over all the fragment of the scene.

Any idea?
I’ve been searching the spec for 2 days, looking for the notion i’m missing but unsuccessfully!

Thanks!

Details:

glClearDepthdNV (10.0) called.
I called glClearDepthdNV and glDepthRangedNV almost everywhere: before, after FBO binding, every frame…

Both FBOs’ target is GL_RENDERBUFFER_EXT, but I use framebuffer_blit later in the rendering, but when it is called, the scene is already rendered into the 2nd FBO’s color attachment.

FBOs’ completeness is checked.

Depth map texture:
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_COMPARE_MODE, GL_COMPARE_R_TO_TEXTURE);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_COMPARE_FUNC, GL_LEQUAL);

Using GLSL vertex and fragment shaders.
The sampler in the fragment is a sampler2DShadow.

Running on a GeForce 8800 GTS 640mo, ForceWare 158.22, WinXP SP2, all patches applied.

Double-Thanks, you’ve even read the details!

Perhaps it’s the R coordinate that is in the wrong range?

One more thing - texture coordinates can get normalized to 0.0-1.0 range. For example if you have a set of texture coordinates:
{3.0, 3.0}, {3.5, 3.2}, {3.8, 4.5}
You can get:
{0.0, 0.0}, {0.5, 0.2}, {0.8, 1.5}
After such normalization.

I don’t know if R coordinate will behave like this but I guess it can’t hurt if I mention it.

Thats of course no problem if you use shaders and pass texture coordinates from vertex to fragment shader as generic varying variables.

I though about that but:
(quote from ext spec. P1146 in nvOpenGLSpec.pdf)

"If the texture’s internal format indicates a fixed-point depth texture, then D_t and R are clamped to [0, 1], otherwise no clamping is performed. "

Thanks anyway

No, it’s not the clamping I had in mind - it’s the range.
Usually you put 0.0-1.0 value to R, but since now your shadowmap is in range 0.0-10.0 then you can get wrong results if you keep pasing 0.0-1.0.
In other words - there is no clamping of R but you don’t put values greater than 1.0 into it anyway.

I gonna investigate that way.
Thanks for your replies