FBO and multitexturing

I’m using a FBO for offscreen rendering in order to process the data within a fragment program in a first pass and then do normal rendering to the framebuffer in a second pass. I pass the data to the fragment program by rendering a textured quad to a texture in the FBO (RTT actually).
Everything works fine as long as I use a floating point texture (RGB32F_ARB) as input for both my input texture and the target (FBO) texture.
The output of my computation are always 3 floats and therefore the FBO texture remains the same (RGB32F_ARB). However the input data should now come from two different textures with different formats: One should contain 4 unsigned chars, so I chose RGBA8, and the other should contain 1 unsigned char, therefore I selected ALPHA8.
Now the problems:

  1. The content of the first texture (RGBA8 on texture unit GL_TEXTURE0) is being clamped to be within [0,1], and I can’t understand why.
  2. The content of the second texture (ALPHA8 on texture unit GL_TEXTURE1) is empty (all 0) when I read it back with glReadPixels.

And finally my questions :wink:
Can anyone explain the clamping behaviour? I’m getting around it by scaling the values back in the fragment program, which seems to work, but I’d like to understand why this is happening at all.
I’m quite sure that the fragment program won’t do any clamping unless I explicitely write it on it…
And second and probably more important, has anyone experienced problems with multitexturing while rendering to a FBO using GLSL? It seems to me that the second texture unit (GL_TEXTURE1) is being ignored, even though I pass the right values (0 and 1 respectively) to the fragment program as uniforms for accessing the correct texture with texture2D. Do I have to do anything else? Actually what I need is to pass a flag with three possible values (0,1,2) for each fragment. Is there any better option for this?

Thanks for your help and sorry if the question is a bit off-topic, but I’m not sure if this is a problem of GLSL, FBO or OpenGL…

Cheers, :wink:
Schaaade

1.) Content of fixed point color data is always in the range of 0.0 to 1.0. See OpenGL 2.0 spec table 2.9 for the component conversions.
You say that the final result written into the RGB32F data is clamped when you use fixed point input data?
According to the float buffers extensions clamping should only occur on fixed sized color buffers per default.

2.) Table 3.21 contains the component assignment from texture data to color data. An alpha texture has only data != 0 in the alpha component.
Wrt. glReadPixels, you’re using an RGB32F (no alpha!) RTT target. From where do you readback alpha with glReadPixels?
Normally if there is no alpha channel in the pixelformat, all alpha data should be read back as 1.0.

Thanks for your reply Relic!

Originally posted by Relic:
1.) Content of fixed point color data is always in the range of 0.0 to 1.0. See OpenGL 2.0 spec table 2.9 for the component conversions.

OK, thank you for the reference. I knew that would be the case if I were writing to the framebuffer, since it’s a fixed point color buffer. But since I’m actually rendering/writing to a floating point color buffer (actually a texture binded to the FBO) I thought I could read the unclamped values within the fragment program. Well, it looks like I was wrong :wink:

You say that the final result written into the RGB32F data is clamped when you use fixed point input data?
According to the float buffers extensions clamping should only occur on fixed sized color buffers per default.

No, the final result written to the RGB32F data is not being clamped, just the texture data I’m using as input. Whatever I write with the fragment program remains unclamped, just as it should.


2.) Table 3.21 contains the component assignment from texture data to color data. An alpha texture has only data != 0 in the alpha component.
Wrt. glReadPixels, you’re using an RGB32F (no alpha!) RTT target. From where do you readback alpha with glReadPixels?
Normally if there is no alpha channel in the pixelformat, all alpha data should be read back as 1.0.

Sure, you’re right! However, since my card (GeForce 6600 GT) internally stores any RGB32F as a RGBA32F, I still can read an alpha component with glReadPixels. Anyway, I don’t need any alpha component in the resulting color, I just used it to debug what is happening in my fragment program. And the problem is that whatever is in the second texture unit (GL_TEXTURE1) is read as all 0 in the fragment program (it’s just the same with the RGBA8 texture if I exchange the texture units and use GL_TEXTURE1 for it to be uploaded). So it certainly seems to be a problem with multitexturing… I’m binding the corresponding texture unit with glActiveTexture just before uploading the texture data (glTexImage2D) and specify the texture coords with glMultiTexCoord for both GL_TEXTURE0 and GL_TEXTURE1 just before each vertex of the quad. Any suggestions of what am I doing wrong?

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.