Hi Wojtek,
Thanks for the investigation. Checking through RenderStage it's clear
that it doesn't just use the _drawBuffer/_readBuffer setting verbatim,
i.e.:
if (!using_multiple_render_targets)
{
if (_drawBuffer != GL_NONE)
{
glDrawBuffer(_drawBuffer);
}
if (_readBuffer != GL_NONE)
{
glReadBuffer(_readBuffer);
}
}
Which suggests to me that the right thing to do would be to refactor
this code so it allowed the setting of the draw and read buffer values
directly even with the value is GL_NONE. As things stand by filtering
out GL_NONE the code is effectively inheriting the state from the
previous Camera.
If we done remove the != GL_NONE and the if
(!using_mulitple_render_targets) then enable the unconditional setting
of glDrawBuffer and glReadBuffer from the osg::Camara settings which
is as first cut looks sensible, but if apps are making assumptions in
their osg::Camera setup about the current inheritance of state when
GL_NONE then we could break existing apps. I do rather prefer
explicit setting of Draw/ReadBuffer value in apps though, as assuming
default will always work for you is dangerous.
The solution that you took of forcing glDrawBuffer & glReadBuffer to
GL_NONE in the case when no colour buffer is applied should probably
wrapped up in the above glDrawBuffer/glReadBuffer code rather than in
it's own block as otherwise the logic will get hard to follow if we
are setting the same state in multiple places.
Robert.
On Mon, Jul 27, 2009 at 9:39 AM, Wojciech
Lewandowski<[email protected]> wrote:
> Hi Robert,
>
> I made a check yesterday. glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT)
> fails if glDrawBuffer & glReadBuffer are not set ot GL_NONE.
> Look at GL_EXT_framebuffer_object extension description
> http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.txt
>
> Usage Example (7):
> (7) Render to depth texture with no color attachments
>
> // Given: depth_tex - TEXTURE_2D depth texture object
> // fb - framebuffer object
>
> // Enable render-to-texture
> glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fb);
>
> // Set up depth_tex for render-to-texture
> glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,
> GL_DEPTH_ATTACHMENT_EXT,
> GL_TEXTURE_2D, depth_tex, 0);
>
> // No color buffer to draw to or read from
> glDrawBuffer(GL_NONE);
> glReadBuffer(GL_NONE);
>
> // Check framebuffer completeness at the end of initialization.
> CHECK_FRAMEBUFFER_STATUS();
>
> <draw something>
>
> // Re-enable rendering to the window
> glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
>
> glBindTexture(GL_TEXTURE_2D, depth_tex);
> <draw to the window, reading from the depth_tex>
> Cheers,
> Wojtek
>
>
> ----- Original Message ----- From: "Wojciech Lewandowski"
> <[email protected]>
> To: "OpenSceneGraph Users" <[email protected]>
> Sent: Friday, July 24, 2009 4:25 PM
> Subject: Re: [osg-users] Frame rates vary dramatically across runs
>
>
>> Hi Robert,
>>
>>> I've just has a look at your changed RenderStage. The changed code is
>>> below. Is there a reason why the #if !FORCE_COLOR_ATTACHMENT which
>>> disables the draw and read buffer is done after the FBO apply? I
>>> looks to me that one could simply have an #ifdef/#else. I do also
>>> wonder whether this is glDrawBuffer( GL_NONE ); etc. is even needed as
>>> well - as wouldn't the Camera provide the appropriate settings via the
>>> Read and DrawBuffer fields.
>>
>> Frankly, this is something that puzzles me as well. I wrote this code only
>> to test if color attachment enforcement could be easily removed. It was
>> never intended as formal submission. It did it a year ago and I do not
>> remember why I have added glDrawBuffer( GL_NONE ); glReadBuffer( GL_NONE )
>> calls. I suppose I did it because original attempt did not work as intended.
>>
>> Ok I think I recall what was my goal. If there was no color attachment I
>> wanted to make sure glDrawBuffer and glReadBuffer are set to NONE because
>> otherwise OpenGL would assume that they are set to colorbuffers of
>> backbuffer/frontbuffer. And I did it after fbo->apply because I thought that
>> fbo->apply may call these functions with other flags.
>>
>> It needs to be verified if I was right and this part was really needed. As
>> I said before this was not intended as submission and I had not make serious
>> study of its implications. I may try to look at this topic again in next
>> week.
>>
>> Wojtek
>>
>> _______________________________________________
>> osg-users mailing list
>> [email protected]
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
