Hi, Guy wrote: > 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. There are no more manual settings in Camera in the latest version.
> 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. Attaching COLOR_BUFFER0 or greater now enables MRT, so no other setting that can get out of sync is needed anymore. If user does not want MRT, attach COLOR_BUFFER only. Matching shaders to attachments is still the user's responsibility. jp > > 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 >> [email protected] >> > 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 [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
