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

Reply via email to