Hi Bill,

The osg::State::pushStateSet()/popStateSet() is really in internal
mechansim used in the draw traversal.  osg::State isn't ued directly
during the cull traversal, instead the StateSet's a used to help build
an osgUtil::StateGraph.

For the cull traversal have a look through include/osgUtil/CullVsitor
and src/osgUtil/CullVisitor.cpp to see how it handles push and pop's
of StateSets.  You can write your own cull callback than can call
these directly during the cull traversal.

Robert.

On 10/17/06, Bill Prendergast <[EMAIL PROTECTED]> wrote:
> so if you want to decoratate a subgraph with a StateSet then
> just attach a StateSet to that subgraph

Understood.  As I indicated in my example, this is the easy part.

> Also if you want to retain reference to StateSet's that you
> adding/removing from the scene graph simply hold a ref_ptr<StateSet>
> in your app to these StateSet's and all memory will automatically be
> managed safely

To reiterate, the issue is one of "decorating and walking away".  The
need is for code to decorate and leave (the object requesting the state
set change may be short-lived).  Other code (let's say a *separate*
scene reset function) has the responsibility of restoring the node's state
sets back to the way they were.

Ideally, this original state would be held at the NODE level, not in some
"common to everyone" pool of saved statesets (e.g., ref_ptr's) where
the reset code would have to compare each node against the saved
nodes to see if it had a pushed (original) stateset.

It appears that osg::State's pushStateSet / popStateSet can manage
"returning to a previous state set" for drawing / culling purposes.

So... to be clear:  Is it true that there is no built-in way to perform a
similar push / restore at the scenegraph node level?



I had hoped that others may have come across similar issues where
they modified a node's stateset and need to return to the as-loaded
configuration (without the burden of a model re-load).

This is one I can indeed solve "outside" of osg;  Again, a std::map
of a node address key and a stateset data would suffice along with
a visitor to walk through and restore state sets along the way.  I was
hoping for something within the scenegraph as opposed to an
external solution.

Bill

_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to