[osg-users] Multiple Render Targets - Request forComments/Testing
Robert Osfield
robert.osfield at gmail.com
Tue Apr 1 08:40:14 PDT 2008
Hi Art,
I wouldn't be too discouraged from the ideal of having an
osg::DrawBuffers StateAttribute, it wouldn't be something you'd
integrated into osg::State though any more than you'd do it with other
OpenGL state.
Whether it should be a StateAttribute is really down to how useful it
will be outside the context of osg::Camera, it is, and it looks to be
the case for you then it makes sense. However, there if its only you
who needs it because you don't use osg::Camera's RTT support then
there is nothing stopping you from implementing yourself as you own
custom StateAttribute.
Robert.
On Tue, Apr 1, 2008 at 3:49 PM, Art Tevs <stud_info2 at yahoo.de> wrote:
> Hi Robert, J.P.,
>
> Of course the camera is a good place for it. However I
> would also prefer to have it somewhere else, because I
> am not always using cameras to make render to texture.
> Ok, maybe I am the one who is using the FBOs and RTT
> functionality out of the camera ;-)
>
> Hmm, maybe I was to fast in the conclusion that MRT
> support as StateAttribute would be a good idea. What I
> thought was to have it somewhere in the State, so
> that one can enable or disable draw buffers
> independently of the camera.
>
> The State do already contain such specific stuff like
> Multitexturing or Matricies (projection and view
> matrix). Hence additional methods to manage the draw
> buffers, may be helpful in the future.
>
>
> Best regards,
> Art
>
>
> --- Robert Osfield <robert.osfield at gmail.com> schrieb:
>
>
>
> > Hi Art & J.P,
> >
> > I'm curious about the going for a custom
> > StateAttribute for
> > DrawBuffers. In terms of encapsulation osg::Camera
> > isn't a bad place
> > for it, as there is already lots of RTT support
> > there already. If
> > there are cases when you want to enable/disable
> > different combinations
> > of DrawBuffers within on RTT subgraph then the
> > StateAttribute is
> > certainly the way to go.
> >
> > I haven't yet player with MRT yet though so can't
> > really give too much
> > insight based on experience so am all ears.
> >
> > Robert.
> >
> > On Tue, Apr 1, 2008 at 1:08 PM, Art Tevs
> > <stud_info2 at yahoo.de> wrote:
> > > Hi J.P.
> > >
> > > I am also using MRT, however completely without
> > > osg::Camera.
> > >
> > > However since I am working with FBOs directly I
> > would
> > > prefer to have something like an extra
> > StateAttribute
> > > or something which should setup the MRT. Or maybe
> > the
> > > setDrawBuffers as an extra method in the FBO
> > code.
> > >
> > > I think having the MRT (enable/disable) as a
> > > StateAttribute would be the more general way.
> > However
> > > this would probably require some extra changing
> > in the
> > > RenderStage or wherever to detect that extra
> > > StateAttribute.
> > >
> > > What do you think, guys?
> > >
> > >
> > > Cheers,
> > > Art
> > >
> > >
> > >
> > > --- "J.P. Delport" <jpdelport at csir.co.za>
> > schrieb:
> > >
> > >
> > >
> > > > Hi Wojtek,
> > > >
> > > > Wojciech Lewandowski wrote:
> > > > > I tried to compile it and link on Windows
> > with
> > > > latest SVN. Compiled and
> > > > > linked fine.I ran osg prerender and shadow
> > exmples
> > > > with fbo. Again no
> > > > > problems. But frankly haven't tested MRT
> > > > functionality at all.
> > > >
> > > > thanks for the testing, I'm glad other fbo code
> > is
> > > > still fine.
> > > >
> > > > We are using MRT for two projects here and it
> > works
> > > > on Windows and
> > > > Linux, so 'it works for me (TM)'. I'll submit
> > it.
> > > >
> > > > thanks
> > > > jp
> > > >
> > > > >
> > > > > Cheers,
> > > > > Wojtek
> > > > >
> > > > >
> > > >
> > > > --
> > > > This message is subject to the CSIR's copyright
> > > > terms and conditions, e-mail legal notice, and
> > > > implemented Open Document Format (ODF)
> > standard.
> > > > The full disclaimer details can be found at
> > > > http://www.csir.co.za/disclaimer.html.
> > > >
> > > > This message has been scanned for viruses and
> > > > dangerous content by MailScanner,
> > > > and is believed to be clean. MailScanner
> > thanks
> > > > Transtec Computers for their support.
> > > >
> > > > _______________________________________________
> > > > osg-users mailing list
> > > > osg-users at lists.openscenegraph.org
> > > >
> > >
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > > >
> > >
> > >
> > >
> > > Lesen Sie Ihre E-Mails auf dem Handy.
> > > www.yahoo.de/go
> > >
> > >
> > > _______________________________________________
> > > osg-users mailing list
> > > osg-users at lists.openscenegraph.org
> > >
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > >
> > _______________________________________________
> > osg-users mailing list
> > osg-users at lists.openscenegraph.org
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
>
>
>
> Lesen Sie Ihre E-Mails auf dem Handy.
> www.yahoo.de/go
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
More information about the osg-users
mailing list