Re: framebuffer object, and glReadPixels quirk?

I do a lot of research (prototyping and tinkering) using glReadPixels to get
back data for CPU processing.  With NVidia's recent drivers, I haven't had
any problems with it.  I would suggest making sure you have glReadBuffer set
to something valid.  I call glReadBuffer with glDrawBuffer right after
creating the framebuffer object while it's still bound, since this is
framebuffer dependent state.

- Kevin B

On 3/12/06, Matt Franklin <[email protected]> wrote:
>
> 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).
>