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
