[osg-submissions] Multiple Render Targets

[J.P. Delport]

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 <jpdelport at csir.co.za> 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
>>  osg-submissions at lists.openscenegraph.org
>>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>>
>>
> _______________________________________________
> osg-submissions mailing list
> osg-submissions at lists.openscenegraph.org
> 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.