Hi Wojtek, Comments interspersed below.
On Tue, Aug 4, 2009 at 11:47 PM, Wojciech Lewandowski<[email protected]> wrote: > > (1) We agreed that we may now remove the code forcing attachment of > color/depth buffers to FBO when user had not attached such buffer. To relax > FBO requirements its neeccessary to refactor DrawBuffer/ReadBuffer > management. Specifically, we need to allow for explicit setting of GL_NONE > for DrawBuffer & ReadBuffer. Current implementation does use GL_NONE flag > but interprets it more like "INHERIT BUFFER SETTING FROM PARENT" value. In > practice glDrawBuffer( GL_NONE ) and glReadBuffer( GL_NONE ) is not called > by OSG. > > (2) We also agreed that it would be nice if we could add > setDrawBuffer/setReadBuffer methods to State and change buffers in 'lazy > update' manner. > > I promised I would try to come up with solution and post a submission > implementing above proposals. I considered couple options and decided that > best approach to implementing (1) would be adding DRAW_BUFFER / READ_BUFFER > to CullSettings::VariablesMask flags. As we are going to allow for GL_NONE > buffers in their verbatim meaning, we need to specifcally define methods to > allow cameras inherit or override buffer settings from their parents. I > think it will be appropriate to handle this in similar way > Camera::_clearColor is handled. CullSettings::CLEAR_COLOR mask defines > whether ClearColor is inherited or overriden. CullSettings::DRAW_BUFFER and > CullSettings::READ_BUFFER could be introduced and interpreted in the same > way with Camera::_drawBuffer, Camera::_readBuffer variables. > > Do you approve such a plan of extending CullSettings masks for use with > DrawBuffer and ReadBuffer ? I think this would be appropriate - i.e. to extend CullSettings to default to inheriting the _readBuffer and _drawBuffer values, and on setting change this inheritance mask to allow the variable to be used. Other members of CullSettings work this way so look at these for a template. > I also have a decision problem with feature (2): I wanted to add following > osg::State methods and variables > > State::_drawBuffer > void State::setDrawBuffer( GLuint ) > GLuint State::getDrawBuffer( void ) > > State::_readBuffer > void State::setReadBuffer( GLuint ) > GLuint State::getReadBuffer( void ) > > Difficulty here is related to proper setting of default values of > State::_readBuffer and State::_drawBuffer. OpenGL spec says that defaults > depend on context. They are set to GL_BACK for double buffered contexts and > set to GL_FRONT for single buffered contexts. When State is created its not > yet known with which context it would be used. > > I came up with 2 possible solutions: > > (A) Changing State::_drawBuffer/_readBuffer defaults after associating State > with GraphicsContext. This is usually done in GraphicsWindow(or its > subclass)::init virtual method. This method would have to call > state->setDrawBuffer/setReadBuffer to initialize defaults properly. > Drawbacks: > - many classes deriving from GraphicsWindow - many changes need to be done. > - not sure what defaults should be applied for SharedContexts and external > contexts for windows created by the users. > - I am hesitant to modify all GraphicsWindow subclasses::init because I am > mainly Windows progrmammer. I'am afraid I may break something in Linux or > MacOS. > > (B) Read buffer defaults ( glGet(GL_DRAW_BUFFER) ) set in GL Context when > State sees context for the first time. Good place for this would be > State::initializeExtensionProcs method. > Drawbacks: > - initializeExtensionProcs is mainly used for setting OpenGL context / State > capability variables like number of texture stages etc. Setting > DrawBuffer/ReadBuffer defaults would be (dangerous?) precedence of > StateAttributes/StateModes like initialization. > > Which option do You prefer here ? I don't prefer either.... I wonder if a has been applied flags could be used in osg::State to accompany the _drawBuffer and _readBuffer member variables, and if the variables haven't yet been applied to OpenGL the previous value is ignored and the gl calls are made regardless of whether previous value held in osg::State. This way the default effectively doesn't existing and the calling code will always set it. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
