I’m rendering to two depth textures using two FBOs. The texture images look OK. Texturing with either texture image looks as expected (one is coarser than the other). However, if I try to texture using both images, using texture2DProj() using two varyings for texture coordinates, and two texture units, then only the first texture seems to work right.
Is this another NVIDIA driver bug, or am I crazy? With GL, there’s no PIX for Windows, and no REF driver, so it’s harder to tell than under Direct3D.
Here’s my vertex shader and fragment shader. Not particularly advanced…
Btw: the problem also happens if I use texture2D().
I have a hard time believing it’s my code, as it works as expected when I comment out either the first or the second texture2D() line. Finally, the binding code for the texture is as follows:
“v” is the index of the uniform, and I get indices 0 and 1 when I’m using two textures, for the respective targets.
void RenderTarget::BindTexture(bool depth)
{
if (depth)
{
if (!depthTexture_)
throw std::exception("Attempt to bind a render target that is not a texture, as a texture");
glBindTexture(GL_TEXTURE_2D, depth_);
if (dirtyDepth_)
{
dirtyDepth_ = false;
}
}
And, finally, screen shots to show the problem:
the problem with the second map can be seen on the yonmost tile (a big black blob)
the coarser shadow map that reaches that far is rendered alone (without the first finer shadow map)
You’re not confusing uniform location with sampler index, are you?
You have to assign samplers to texture units yourself with glUniform1i(), otherwise both lightDepthTexture0 and lightDepthTexture1 will point to image unit 0 by default.
There were more basic problems, like I was using texture2DProj instead of shadow2DProj, and sampler2D instead of sampler2DShadow. Sadly, the NVIDIA compiler or runtime didn’t even warn about that – according to the spec, binding a depth compare texture to a regular texture sampler results in “undefined” behavior, so they’re in their right, but I’d prefer to get at least a warning for that…
The use of sampler2D was not a problem in you fragment shader since you used texture2DProj. The nature of the texture you bound to this sampler is up to your application not the shader, that’s why IMHO the compiler did not flinched.