Hi Robert, J.P., Guy, sorry, I haven't followed the discussion about the MRT patch completely, hence just my comments on it.
> > Art's comments of yesterday still has me wondering > whether the vector of > render targets should be kept in RenderStage or > whether they could go > into fbo. If MRT is only used with fbo, maybe > RenderStage can then query > it for the targets (or maybe even make fbo call > glDrawBuffers itself). > I was speaking about fbo's because MRT is usualy used with fbos. I have no idea if one do use MRT also with pbuffers or something different, but as far as I know the common way (or maybe the only one way) is to use FBOs to do multiple targets. Hence for me it was more normal to include that code into FBO class. However there will be a question: if it is possible to attach different FBOs to different MRTs? Hmm, I would suggest to use the patch you have already provided. If one need some changes, we can do it later, I think. To the MRTs as StateAttribute, or per node choose; Yes, Guy, you are right. Maybe there are some nodes which do have a shader using multiple rendering targets. However there will be still a question where the result is written to. If you render the scene through a camera, which do have only one normal rendering target and a shader of a specific node do write multiple outputs, then this is of course bad. There is some kind of MRTVisitor or another concept required, which checks how much MRT buffers to enable before rendering the subgraph of the camera object. And for that some kind of StateAttribute is required. I would suggest to use the current patch as it is and provide the proper per subgraph MRT visitors (which will work inside of a camera or the fbo) later. Because this two concept seems to be pretty orthogonal to each other. Best regards, Art > rgds > jp > > > -- > 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-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > __________________________________________________________ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
