yes, sorry, I'm not sure where to place the "what should I get" in the example (on screen, in the --help?).
The yellow quad is what is expected. A few things you could try: If you run with --image, you should (without modifying the example) get a washed-out yellow quad with a smaller yellow quad inside. This is the same effect as in osgprerender: a render target is read back as an image and the middle is modified. If you search for "tex_to_get", you can select which of the 4 targets is read back and changed, this will change to colour of the center smaller quad. Without --hdr what basically happens is: RT0 = vec4(1,0,0,1) RT1 = vec4(0,1,0,1) RT2 = vec4(0,0,1,1) RT3 = vec4(0,0,1,1) output quad = RT0 + RT1 + RT2 -0.5*RT3 therefore the washed-out yellow result. With --hdr the values are made very small (too small to fit into FLOAT16) and then combined in the same way (RT0 is also made negative). This is a basic test for MRT with FLOAT32. If you search for shaderSource in the example, you'll see the simple shaders. Reading them would prob explain it better than I can. regards jp Robert Osfield wrote: > Hi J.P, > > I've just done a quick merge of your changes (and committed the typo > fixes) and have run the osgmultiplerendertergets example but don't > know whether its working as all I get is yellow quad. I have a 7800GT > on this machine. > > What should I expect? > > Robert. > > On Wed, Apr 2, 2008 at 10:09 AM, J.P. Delport <[EMAIL PROTECTED]> wrote: >> Hi Robert, >> >> following the discussion yesterday on osg-users, I have decided to submit >> the original patch as is. >> >> MRT is enabled by an explicit call on osg::Camera (setDrawBuffers), just >> like readback of textures/images is enabled by osg::Camera->attach. >> >> To me, the camera seems the natural place for these things at the moment. >> If it would make sense as a StateAttribute (either for Camera or FBO), the >> implementation is left as a possible future enhancement. >> >> regards >> jp >> >> old message >> >> ----8<---- >> Attached are the changes to OSG's Camera and RenderStage. >> >> Camera got a new method called setDrawBuffers (instead of the normal >> setDrawBuffer), which mirrors the OpenGL extension glDrawBuffers. >> >> setDrawBuffers takes a vector of BufferComponents and this vector is then >> translated in RenderStage to a vector of GLenums that is passed to >> glDrawBuffers. >> >> The new calls are orthogonal to current use cases, so hopefully no other >> code/examples would be affected. >> >> The attached example shows sample usage. The example is very contrived, but >> I hope it explains the concept. I have some other examples that I can >> contribute later. >> ----8<---- >> >> -- >> 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 >> >> > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > -- 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
