Thanks Art, changes now merged and submitted to SVN.
On Tue, Jul 15, 2008 at 1:34 PM, Art Tevs <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]> schrieb am Di, 15.7.2008: > >> Von: Robert Osfield <[EMAIL PROTECTED]> >> Betreff: Re: [osg-submissions] Bug in MRT and FBO >> An: [EMAIL PROTECTED] >> Datum: Dienstag, 15. Juli 2008, 13:37 >> Hi Art, >> >> On Tue, Jul 15, 2008 at 12:15 PM, Art Tevs >> <[EMAIL PROTECTED]> 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 > _______________________________________________ > 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
