right, but not a "disapply" so much as a pop of state to a baseline, and the problem is that baseline is currently undefined. So it seems the answer is to provide that missing baseline state in osg::State "above the root", so that state popping properly restores.
I wish I could create and submit the change, but I'm really pressed for time atm -- mew On Fri, May 23, 2008 at 9:57 AM, Art Tevs <[EMAIL PROTECTED]> wrote: > 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 > -- Mike Weiblen -- Austin Texas USA -- http://mew.cx/ _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
