[osg-submissions] Bug in MRT and FBO

[Art Tevs]

Hi Robert, J.P.


Ok, Robert, I think you ahve to remove the ambiguosity of using GLenum then form the source code. In my application I now just do write something like this:

                    fbo->setAttachment(osg::Camera::BufferComponent(osg::Camera::COLOR_BUFFER0 + i), ...)

which do the work. I am not a friend of non-clean c-code, however I can live with that solution. (I see that it is also often used in osg sources, hence who cares ;) )

I have attached the patche FrameBufferObject files, to remove the ambiguosity of using GLenum. now user have no possibility to use GLenums anymore. Check it out.


Best regards,
Art

--- Robert Osfield <robert.osfield at gmail.com> schrieb am Di, 15.7.2008:

> Von: Robert Osfield <robert.osfield at gmail.com>
> Betreff: Re: [osg-submissions] Bug in MRT and FBO
> An: stud_info2 at yahoo.de
> Datum: Dienstag, 15. Juli 2008, 13:37
> Hi Art,
> 
> On Tue, Jul 15, 2008 at 12:15 PM, Art Tevs
> <stud_info2 at yahoo.de> wrote:
> > for (int i=0; i < 4; i++)
> >   fbo->setAttachment(GL_COLOR_BUFFER0_EXT + i,
> ...);
> > , which is correct in respect to OpenGL
> specificatiosn, since GL_COLOR_BUFFERn_EXT =
> GL_COLOR_BUFFER0_EXT + n.
> >
> >
> > If you remove the GLenum then one has to write
> something like this:
> >
> > for (int i=0; i < 4; i++)
> >  
> fbo->setAttachment(Camera::BufferAttachment(int(Camera::COLOR_BUFFER0)
> + i), ...);
> >
> > which ends up in a lot of casts, which is not so nice
> code style (one can not add integer value to an enum
> value).
> 
> Perhaps allow ints, but no GLenum would allow you to avoid
> the
> casting.   Another perspective is that it wouldn't
> expect most users
> ever to directly use FBO's so this isn't a big
> issue to for most
> users.
> 
> > Hence I would propose to let the GLenum in there or to
> work out a new API interface to solve that problem.
> 
> More API isn't really solving a problem, its just
> creating more
> potential problems in usage/maintenance and understanding. 
> I would
> like to simplify things and avoid gotcha's like
> you've come across.
> 
> 
> > P.S. Sorry, I do not remember the discussion about the
> using of COLOR_BUFFER!=COLOR_BUFFER0. I can not see any
> issue which might be introduced by setting
> COLOR_BUFFER=COLOR_BUFFER0. Could you explain me in few
> words why?
> 
> The discussion will be in the archives.  The upshot is that
> with MRT
> you really need to explicitly select it, rather than
> implicitly
> setting it as was done previously.  The rule now is the if
> you want to
> use MRT you have to use COLOR_BUFFER0 rather than
> COLOR_BUFFER, as
> COLOR_BUFFER is the non MRT FBO path.  This clears up any
> ambiguity of
> whether you need to enable MRT or not.  The problem case
> before was
> when you had only have COLOR_BUFFER and FBO would then not
> know
> whether to enable MRT or not, this caused bugs.
> 
> Robert.
> 
> Robert.


      __________________________________________________________
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FrameBufferObject
Type: application/octet-stream
Size: 18276 bytes
Desc: not available
URL: <http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/attachments/20080715/086ba60f/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FrameBufferObject.cpp
Type: text/x-c++src
Size: 26114 bytes
Desc: not available
URL: <http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/attachments/20080715/086ba60f/attachment-0001.cpp>