framebuffer object, and glReadPixels quirk?
"Matt Franklin" <[email protected]> Sun, 12 Mar 2006 12:39:24 -0800
| Newsgroups | gmane.games.devel.opengl |
|---|---|
| Organization | Fat City Network Services, San Diego, California |
| Message-ID | <[email protected]> |
Hi, I'm rather perplexed by what appears to be a bug with nVidia drivers, framebuffer objects, and glReadPixels. However, maybe I'm just ignorant of some framebuffer object constraints. If anyone on this list has been using FBOs for a while, perhaps you have some insight? (Note: I haven't been on this list for long. I checked the archives for relevant information, and didn't see any, but they didn't seem totally up to date. If this is redundant, my apologies.) I'm using framebuffer objects to render to textures, as part of a Maya plugin for our artists. Because of hardware constraints, I'm forced to render to two different texture formats (16 bit floats at one point; 32 bit floats at another). One constraint of framebuffer objects is that all attached textures must be of the same format, so I can't simply attach one as GL_COLOR_ATTACHMENT0_EXT, and another as GL_COLOR_ATTACHMENT1_EXT, and be on my way. That's fine, because I'm not using them in the same call. So, theoretically, I should be able to attach one to GL_COLOR_ATTACHMENT0_EXT, do what I need, then attach the other one to GL_COLOR_ATTACHMENT0_EXT, and do what I need. So: glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, my16bitTex, 0); (do some rendering) glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, my32bitTex, 0); (do some rendering) So far so good-- everything appears to work just fine. If I use glGetTexImage to check up on the contents of those textures, they contain the correct values. If I render to the screen, they look good. Now, here's where the problem arises. I need to use glReadPixels for speed reasons (unless there's a preferable alternative?). When I do that, the values come out horribly botched: every non-0 pixel is -2.0000000. The kicker is that I don't even have to do any rendering to the 16 bit texture to get this to happen. Here's a case that will break: glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, my16bitTex, 0); glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, my32bitTex, 0); (do some rendering) glReadPixels Here's a case that will not break: glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, my32bitTex, 0); (do some rendering) glReadPixels So, the only change required to break glReadPixels functionality is the attachment of a different format texture, even if it's not used. I've attempted to clear out that attachment before attaching the next one, and it still breaks. Am I missing something in the FBO spec? Or is this an issue with nVidia's implementation? I've been unable to test on an ATI card so far, but I'm going to attempt that tomorrow. ----- FAQ and OpenGL Resources at: http://www.geocities.com/SiliconValley/Hills/9956/OpenGL -- Author: Matt Franklin INET: [email protected] Fat City Hosting, San Diego, California -- http://www.fatcity.com --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [email protected] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).