Hello, In continue to what I said before, I don't believe it's possible to change the subgraphs MRT definitions, since all the subgraph under the camera renders to the camera attachments. So if the camera is using MRT, then all the subgraph is rendered MRT. The differences in the subgraphs could be the shaders using or not using the MRTs.
That brings the issue that if shaders use MRT and we didn't set the attachments correctly, a problem will occur. So what I think should happen is that whether using StateSet attribute to declare the need for MRT by sub-graphs or by testing the Shaders, the camera should activate some visitor on it's sub-graph, find the draw buffers required, and then setup itself for the maximum need. But then the setting would be the same for the whole sub-graph. Does it makes sense? Thanks, Guy. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, April 01, 2008 3:40 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g > > > > > > Lesen Sie Ihre E-Mails auf dem Handy. > www.yahoo.de/go > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
