tags:

views:

469

answers:

2

I generate a texture like this:

GLuint id;

glGenTextures(1, &id);

glBindTexture(GL_TEXTURE_2D, id);

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

glTexImage2D(
 GL_TEXTURE_2D, 0,
 GL_RGBA16,
 //GL_RGBA16F_ARB, //< Won't work
 256, 256, 0, GL_RGBA, GL_FLOAT, NULL
);

glBindTexture(GL_TEXTURE_2D, 0);

I attach it to a framebuffer object (FBO) for rendering to. All of this works like a charm when I set the internal format to GL_RGBA16. However, I need a higher dynamic range and was thinking that GL_RGBA16F_ARB might do the trick.

Unfortunately, if I replace GL_RGBA16 with GL_RGBA16F_ARB in the code given above, the texture seems to stop working. Nothing I try to render to the FBO/texture sticks, and when I use the texture it contains random garbage. (A lot of purple, as it turns out) This would not be so frustrating if I had gotten an error message hinting at what might be wrong, but I can't seem to find one. In other words, glGetError() returns 0 after the glTexImage2D-call, and glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT) returns GL_FRAMEBUFFER_COMPLETE_EXT when I have attached the texture

I haven't messed with glClampColorARB(...) ... yet :)

  1. Have I forgotten to check for errors in a place/way that I haven't thought of?
  2. Do GL_RGBA16F_ARB-textures require any special treatment that I haven't given?
  3. Is there anything else that might be wrong?

I'm stumped, since everything works smoothly with GL_RGBA16... :(

EDIT: When using GL_RGBA16F_ARB, the first frame I try to render to screen doesn't make it. Seems to me that I should be getting an error message somewhere..?

EDIT: By inspecting ShadowIce's working code example I figured out that the problems disappeared if I changed the depth buffer on my FBO, and give glRenderBufferStorageEXT(...) GL_DEPTH_COMPONENT24 as its second parameter, rather than GL_DEPTH_COMPONENT16. I have no idea why this works, but apparently it does work.

Also, ShadowIce's code breaks like mine if I do the opposite substitution there.

+2  A: 

There shouldn't be anything special to do for setting up a framebuffer with float textures. Some things I would check:

  1. Is the FBO bound and the draw/read buffer set correctly before you call glCheckFramebufferStatusEXT? Also try testing it right before you draw to it.
  2. Does the texture look ok after a simple glClear with a specific clear color? If yes, there might be something wrong with your shaders (if you use any) or the way you draw to the FBO.
  3. Are your drivers up to date? And does the problem still exist on a PC with different hardware?
  4. How about GL_RGBA32F_ARB?

Edit:

  1. Check the id of your framebuffer and texture, also check if the texture id matches the one attached to your fbo (with glGetFramebufferAttachmentParameteriv). Normally I would guess that everything is ok with that if it works with a RGBA texture but random data (especially purple) is a good sign that nothing was written to the texture or it wasn't cleared properly.

I have written a small example application that should work, maybe that helps. I have only tested it on windows, so for linux you might need to change it a bit: link

Maurice Gilden
1. Yes. Verified by testing right before drawing, 2. No, it does not look OK, 3. I get my drivers from the Ubuntu-repository. Should be reasonably up to date (nvidia). I get the same problem om a different machine, 4. I get the same result sometimes, but now it has apparently locked completely!
Magnus Hoff
(4. continued:) When breaking it in a debugger the stack I get to see is only one deep with "libGL" as the only element. The program is completely locked, and uses 100% CPU :O
Magnus Hoff
Also: Thanks! If you have any more ideas, I'm all ears :)
Magnus Hoff
The example you made worked nicely. Now to isolate the differences...
Magnus Hoff
I ought to create sockpuppet-accounts so I could thank you properly ;)
Magnus Hoff
Hehe, thanks. ;)
Maurice Gilden
+1  A: 

GL_HALF_FLOAT_ARB might work as the type instead of GL_FLOAT.

SPWorley
Thanks. Unfortunately this gives the same result; It still works with GL_RGBA16, but fails with GL_RGBA*F_ARB :(
Magnus Hoff