[osg-submissions] osg-submissions Digest, Vol 4, Issue 2

[J.P. Delport]

Hi,

John Donovan wrote:
>> Hi Guys,
>>
>> I tried the below but still get errors.  I'm afraid I don't have time
>> to go debugging what is effectively a half backed submission.
>>
>> Could you all review the submission and get it working.  Without
>> errors when running standard examples like:
>>
>>   osgviewer cow.osg --3d-sd
>>   osgviewer cow.osg --panoramic-sd
>>   osgprerender cow.osg
>>
>> Right now I'm revert all changes related to this submission and
>> sticking to the standard SVN version of these code.
>>
>>
>> Robert.
>>
> 
> Doh! OK Robert, I'll have a poke around. I'm a shade busy at the mo, so I'll
> hold off until after 2.2. The new BufferComponent enum will save a bit of hackery!
> 
> -J
> 
I also think this should prob go in after 2.2. I've quickly looked at 
Don's code yesterday and was thinking that maybe we should completely 
split the drawbuffer vs drawbuffers operation. That is, we add a 
setDrawBuffers call to camera.

It has the following advantages from my point of view:
- OSG will mirror OpenGL.  This in line with keeping OSG a thin layer 
above OpenGL.
- OSG does not have to guess about user intention (inferring 
drawbuffer/s calls from buffer attachments)
- The user must explicitly request MRT with the setDrawBuffers call. All 
current code that uses setDrawBuffer would therefore not be influenced 
by the addition.

Camera would therefore need the same vector Don added to store the 
requested drawbuffers (set explicitly). Renderstage could copy this when 
setting up. We could either use the vector size to indicate the camera 
is using MRT or have an explicit flag.

An MRT example to show the new functionality is also needed.

What do you guys think?

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.