Hi Guy, Thanks for jumping in on the discussion, it does remind me of part of the original intent of the osg::Camera BufferComponent is that it'd map to MRT, but... I'm rather cold on the subject having not visited it for over a year. Your suggestion of computing the glDrawBuffers setting from the BufferComponents makes sense, actually it's probably what I was vaguely hoping for in my original code. Alas I never got further than just wiring up standard FBO's though, and haven't had the time to experiment with MRT so have to defer to others that have.
Perhaps on review of J.P's code how the extension is used will make more sense and how to do the above mapping automatically will come to me. Feel free to propose your own code though... Robert. On Wed, Apr 2, 2008 at 8:15 AM, Guy <[EMAIL PROTECTED]> wrote: > Hi, > I think we have discussed this issue before. > I also not familiar with the general framework use of SetState, I myself > implemented solution similar to that of JS with the exception that I > activated the glDrawBuffer extension in the apply method of the FBO. I > also made another difference, I didn't use vector for the draw buffers, > but counted the attachments of different color buffers, and only if > those were greater than one, applied the drawBuffers extension. > > But I thought to myself, is it true to use it ONLY when FBO's are on? > I'm not familiar enough with attachments when not using FBO (like > PBuffer or maybe in the future there will be separate frame buffers for > separate screens) and this returns the location of applying the > extension back to the RanderStage as JS did. (That's why I was quiet > until now :) ) > > Now, suppose I do understand a little about SetStates, this is not > applicable here since if there is more than one color buffer attachment > you must use the extension, and if not, there is no point in using the > extension, so why let the user set the state? > > What I think should be done is instead of adding the > setDrawBuffers(BuffersVec) method, in the RenderStage setUpCamera > function one should count the attachments to different color buffers and > decide whether to use the extension or not, and in the InnerDraw apply > the extension according to the flag found in the setUpCamera. > > Besides that I think JS has done very nice work. Bravo. (or cheers or as > we say in Israel "Kifak-Hey") :) > > Thanks, > Guy. > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of J.P. > Delport > Sent: Tuesday, April 01, 2008 2:57 PM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Multiple Render Targets - Request > forComments/Testing > > Hi Art, > > > Art Tevs wrote: > > Hi J.P. > > > > I am also using MRT, however completely without > > osg::Camera. > > Yes, I've compiled osgPPU and ran the examples; cannot say that I fully > understand the code yet :) > > > > > > 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? > > > > I think having the MRT selection going through FBO-class could be a good > > option. However, I do not know how to add the StateAttribute. We might > need an enable/disable and setDrawbuffers, or can a StateAttribute take > a vector? I do not know how to pass the vector of render targets using > an attribute? > > ----- > > At the moment I have: > > Camera->setDrawBuffers(vec) - this sets the intention to use MRT and > also passes the list of targets. > > RenderStage->runCameraSetup - this queries the camera for the buffers, > and if there are any, creates a vector of GLenums. > > RenderStage->drawInner - The existence of the target vector is used to > determine if MRT is enabled. glDrawBuffers is called using the vector. > > ----- > > I think what you propose is: > > Camera->setDrawBuffers(vec) > > RenderStage->runCameraSetup - since this creates the FBO anyway, it > might as well pass the camera settings regarding MRT to the FBO. Maybe > using _fbo->setDrawBuffers. > > RenderStage->drawInner - instead of checking the member _drawBuffers, > query the FBO to determine if MRT should be enabled and also get the > list of targets from the FBO. > > ----- > > This could work, and I can probably integrate it into the patch, but I'm > > not sure how you get your FBOs into renderstage at present. > > Also, how do you control the reading back of textures/images? At the > moment the readback attachment map is also setup in camera. Would this > also need to be moved? > > > > > > > Cheers, > > 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-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 > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
