[osg-submissions] Move MRT into FBO patch

[Art Tevs]

Hi Robert, J.P.

> What should happen with is that the subgraph with
> the FBO should have
> the FBO applied/enabled for it, and on first apply
> this FBO will be
> cloned (the type rather than whole object and
> settings) using the
> default constructor to provide a FBO to apply to
> reset the state back
> to non FBO pathway, and this cloned object will be
> automatically
> applied to other subgraphs that don't define their
> own FBO.   So... it
> shouldn't be neccessary to apply your own FBO, if it
> is then it
> suggest the that the default constructed FBO isn't
> disabling things
> correctly.
> 

Ok, this is the only way how to reset the state of the
OpenGL's pipeline without having some kind of
"disapply" or "resetback" method in the
StateAttribute,
when popping a stateset out of the stack.
Am I correct?


However, I have now studied this specification:
http://www.opengl.org/registry/specs/EXT/framebuffer_object.txt

and as one can read in the Issues part (56), the
glDrawBuffers and glDrawBuffer seems to be different.
Per specification they decided to store the value of
glDrawBuffers (hence MRT) in the frame buffer object
context rather than in the main rendering context.

That means that changing the glDrawBuffers() value
after the call to glBindFramebufferEXT does not change
the value of the glDrawBuffer() call in the main
context (or in our case in RenderStage).

Indeed I have encountered this by extensively
debugging of OpenGL calls in an example application.
It seems that something like this:

glBindFramebuffer(1);
glDrawBuffers(some array);
render A
glBindFramebuffer(0);
render B

still do render only B on the screen and A in the FBO,
even if the value of glDrawBuffers() isn't changed
after the second glBindFramebuffer(0) call.

Hence all my afraids, seems to be gone now, I think.

Thank you guys for the nice discussion. I think if
they do not change the speicification we can live
without any default call of glDrawBuffers() when
applying FBO 0.


Art


> Could you provide a code example that reproduces the
> problem?
> 
> Robert.
> 
> On Wed, Apr 16, 2008 at 11:13 AM, Art Tevs
> <stud_info2 at yahoo.de> wrote:
> > Hi Robert,
> >
> >  I have now found out when this problem with
> >  glDrawBuffers happens, or at least I suppose I
> know
> >  when.
> >
> >  The problem comes when one use FBO as
> StateAttribute.
> >  In my case I do assign the FBO as state attribute
> to
> >  the stateset of a node, allowing nodes to specify
> if
> >  they want to be rendered in a texture or not.
> >
> >  This means, that everytime when the node is
> rendered
> >  there is a glDrawBuffers call, because of the
> FBO.
> >  However afterwards there is no reset to the
> default
> >  draw buffers mode. Even worse, there is no real
> unbind
> >  of the FBO, which mean, I have to add an empty
> FBO to
> >  other nodes, which do not use FBO, so that I get
> >  something like glBindFramebufferEXT(0) called
> when
> >  other nodes are rendered.
> >
> >  I hope I was able to explain you my problem.
> >
> >
> >  I think this is not only a problem with draw
> buffers,
> >  but also with FBOs if one use them as
> StateAttribute
> >  in a StateSet.
> >
> >
> >  Please comment on this. I have already couple of
> ideas
> >  how to solve that issue, however we have to
> discuss.
> >  Maybe I am making mistakes.
> >
> >
> >  Art
> >
> >
> >
> >  --- Robert Osfield <robert.osfield at gmail.com>
> schrieb:
> >
> >
> >
> >  > On Wed, Apr 16, 2008 at 10:41 AM, Art Tevs
> >  > <stud_info2 at yahoo.de> wrote:
> >  > >  good, I am glad to hear that this do its
> job.
> >  > >  Then this feature can now be shipped as
> official
> >  > MRT
> >  > >  support in the upcoming osg version ;-)
> >  >
> >  > Yep, it'll be in 2.4 ;-)
> >  >
> >  > Could you let us know how testing goes at your
> end,
> >  > and whether we do
> >  > need to add the extra fallback glDrawBuffers
> calls
> >  > into
> >  > FrameBufferObject.cpp
> >
> >
> > > _______________________________________________
> >  > osg-submissions mailing list
> >  > osg-submissions at lists.openscenegraph.org
> >  >
> > 
>
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
> >  >
> >
> >
> >
> >      
>
__________________________________________________________
> >  Gesendet von Yahoo! Mail.
> >  Der Lieblings-Mailbox der Welt.
> >  http://de.overview.mail.yahoo.com
> >  _______________________________________________
> >  osg-submissions mailing list
> >  osg-submissions at lists.openscenegraph.org
> > 
>
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
> >
> _______________________________________________
> osg-submissions mailing list
> osg-submissions at lists.openscenegraph.org
>
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
> 



      __________________________________________________________
Gesendet von Yahoo! Mail.
Der Mailbox mit unbegrenztem Speicher.
http://de.overview.mail.yahoo.com