Hi Robert, Stephane
sorry a lot of text....
> As replied in previous posts, their is a whole mechanism in
> osg::State
> for managing state, there is no need for a
> "disapply" as this
> automatically comes part of the package.
>
OK, maybe I have to read through the complete osg code again and again. But I
still do not understand, how State could manage to disapply an Attribute if
this attribute do not provide any default mode set when calling apply() on
fresh instance.
For example one can see, that all the StateAttributes do apply some default
values if they haven't initialized before. For example osg::Viewport do call
glViewport(0,0,800,600) per default. Only if you change its width and height
values, then other values are applied.
Now imagine following scene:
Root
/ \
/ \
A B
here we also call A->getStateSet(new osg::Viewport(0,0,400,300));
but nowhere else.
Now if you take a look into any OpenGL debugger, you may notice, that you get
something like this:
glViewport(0,0,800,600);
...
...
glViewport(0,0,400,300);
..
renderA
...
glViewport(0,0,800,600);
..
renderB
..
This happens because State do create a copy of the osg::Viewport instance (not
the copy of the object) on the root node. This is cool, since this is the
mechanism what you describe.
However if you just think differently, what osg is trying to do here, is just
to disapply the viewport attribute by applying an unitialized (or better to say
a "fresh") instance of the viewport.
What we follow now, is that any StateAttribute has to provide some kind of
default behaviour which is meant to reset the applied OpenGL state to the
previous state (in the osg case - the default state).
Hence, what you suggest to do with more complex StateAttributes, which do not
have any proper default value!???
In such a case you need something like glPushAttribute when the corresponding
Attribute is pushed by the State (pushStateAttribute) and a glPopAttribute,
whenever this attribute is popped (popStateAttribute).
osg::State can not track all this and hence in some cases, the lazy attribute
update will just not work!
In the Stephane's example the problem lies maybe in the osg::Program attribute
which is not correctly copied to the root node. Or, jsut to say, that there is
no call of glUseProgram(0) on the root node, if you think on the example on the
top of this message.
This is a main problem, which I have pointed already out. It do work for now,
since OpenGL do not have so much complex attributes to manage. However as
spoken already in the previous mails, for example for the draw buffer settings,
the lazy state update breaks. It do work for now, because GL do store draw
buffer settings per FBO context. But if it would store it per main context,
then we would get a problem.
I hope, I was able to point out my view on this problem.
Best regards,
Art
P.S. I have seen now from Stephane's patch, that he encounters exactly the
problem, which I have stated in this post :)
__________________________________________________________
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org