Hi, Using MRT with one target at gl_Data[0] really makes a problem. I still don't think it is required to set manually the Camera for using MRT unless it's a patch until the MRTVisitor is implemented. When the visitor is implemented, if a node is using MRT it's probably because the user attached a shader that uses gl_Data[], and then it will set on the flag whether it has one or many COLOR BUFFER attachments, or maybe the attribute will be something like (MRT, State::ON) and this will turn on the flags. For the cameras, if there are more than one COLORBUFFER attachments, it should turn the flag on whether the StateAttribute is ON or OFF, but if there is only one attachment (or less), and the user didn't set the StateAttribute to ON, the drawBuffers extension shouldn't be applied.
Guy. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Wednesday, April 02, 2008 2:11 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Multiple Render Targets - Request forComments/Testing Hi, Robert Osfield wrote: > Hi J.P, > >> >> I'm sure you will see that there is no magic to my current >> >> implementation. The difficult part is to figure out when to enable it. >> > >> > Can we not just do it when COLOR_BUFFER1 upwards are enabled? >> >> Problem is that enabling MRT with just COLOR_BUFFER0 and then using >> glFragData[0] in a shader is also a valid use of glDrawBuffers. I know >> this is a special case (MRT with one buffer), but it's useful when e.g. >> automatically generating code. > > OK. I see the issue now. > >> If we ban or don't expect this type of use, then enabling MRT when >> COLOR_BUFFER1 upwards are enabled should be fine. > > Rather than ban this type of usage perhaps we could come up with > another scheme. Would making COLOR_BUFFER0 be separate from > COLOR_BUFFER be a way around this, i.e. if the use wants MRT then they > COLOR_BUFFER0+i, if they just want standard then just use > COLOR_BUFFER. This sounds good to me, it makes the distinction between single buffer MRT vs non-MRT clear. > > The other possibility would be to explictly enable MRT support via an > option in osg::Camera. The special option would have the same problems as my setDrawBuffers at the moment. One could get the option and attachments out of sync. > > My concern about having both Camera::setDrawBuffers and the > BufferComponent attachments is that its more code and open for people > making mistakes in the implementation i.e. they two are set without > being properly matched. Yes, I agree with this. I think your suggestion to separate COLOR_BUFFER and COLOR_BUFFER0 is the best. In RenderStage the check to enable MRT would then be as Guy suggested. See if the _drawBuffers GLenum vec has something in it. The vec is populated from the camera attachments. > > Robert. jp > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g > -- 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
