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
