HI Wojtek, I agree with your analysis that it'd be appropriate to place glDrawBuffers/glReadBuffer support into osg::State and utilize lazy state updating for this.
In terms of the existing RenderStage::_draw/_renderBuffers values, this is currently set by the CullVisitor + SceneView, so rather than being their for lazy state updating it's there as means of passing values for high level set up to the lower level draw traversal so would need to remain. Robert. On Mon, Jul 27, 2009 at 1:17 PM, Wojciech Lewandowski<[email protected]> wrote: > Hi Robert & J-S, > > Sorry if I am bit late with the answers. I have browsed the code to know > what we are talking about ;-) > >> [...] right thing to do would be to refactor >> this code so it allowed the setting of the draw and read buffer values >> directly even with the value is GL_NONE. As things stand by filtering >> out GL_NONE the code is effectively inheriting the state from the >> previous Camera. > >> [...], but if apps are making assumptions in >> their osg::Camera setup about the current inheritance of state when >> GL_NONE then we could break existing apps. I do rather prefer >> explicit setting of Draw/ReadBuffer value in apps though, as assuming >> default will always work for you is dangerous. > > I cannot imagine how such explicit setting of glDrawBuffer/glReadBuffer > could be done without setDrawBuffer / setReadBuffer methods in osg::State > (and/or in osg::Camera) ... If you suggest refactoring, I think the best way > to tackle it would be adding such methods and corresponding variables to > osg::State and allow the State to handle lazy update of buffers when needed. > It seems to me that these complex checks in RenderStage are trying to > accomplish the same as lazy update: change the buffers only when this is > neccessary. > > I think we should remove _drawBuffer / _readBuffer variables and part of > corresponding logic from RenderStage and move it to osg::State. In the same > refactorization let GL_NONE to be set. Then let all OSG code liberally set > buffers with state.setDrawBuffer() and state.setReadBuffer() calls. Lazy > update will control when they really change. > > I also think we shouldn't worry about users who rely on sideffects of > current code. We earlier decided we are going to blow up user comfort of > default ColorAttachments/DepthAttachments. So now its just a consequence. We > should feel free to to the same with DrawBuffers/ReadBuffers. J-S will > simply have more to explain to frustrated users for whom OSG stopped working > ;-) > >> The solution that you took of forcing glDrawBuffer & glReadBuffer to >> GL_NONE in the case when no colour buffer is applied should probably >> wrapped up in the above glDrawBuffer/glReadBuffer code rather than in >> it's own block as otherwise the logic will get hard to follow if we >> are setting the same state in multiple places. > > I agree. But instead of RenderStage::setDrawBuffer( ) & > RenderStage::setReadBuffer( ) I would rather call State::setDrawBuffer() > State::setReadBuffer( ). > > I suppose corresponding getDrawBuffer/getReadBuffer plus similar set of > calls for multiple DrawBuffers should probably be added to State. > > What do you think ? > > Cheers, > Wojtek > > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
