[osg-users] Dynamic datavariance clarification

[Eric Pouliquen]

Hi,

sorry to ask questions about such a classic topic but I've read lot of things about Datavariance and would like to be sure about some points :

I've read in osg guides that the datavariance of a Drawable (and all subclasses) and a StateSet must be set the DYNAMIC if we plan to modify its data during object's life. This is clear.
But I also read in the QuickStart Guide in the Cow example (page 96) that the coder set the datavariance of a MatrixTranform to DYNAMIC because he will modify the matrix values in a callback...

So : do we need to set the datavariance to DYNAMIC for any osg Node that we want to act on in a callback ? That point is not clear for me.

If yes, for example do we need to set a DYNAMIC datavariance for a switch node as soon as we are going to modify its children enable states in a callback ???

Thanks a lot for your clarifications

Thank you!

Cheers,
Eric

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=45471#45471

_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Paul Martz]

This has been discussed before, but I'm not sure what you'd search for to find
it in the archives.

In the most general and conservative sense, you should set dynamic data variance
on anything you need to change.

But in reality, you only need to do this for objects that are referenced by the
draw list / render graph. Unfortunately, there is no (header file doxygen)
documentation that tells you what goes in the render graph and what doesn't. So
you can either take the conservative approach, or you can dig into the source to
determine whether you can get away with not marking something dynamic, even
though you know you're going to modify it.

For me, this boils down to a 5 second code change (to mark it dynamic) versus
possibly hours of digging into the code. So I usually take the conservative
approach.

Specifically regarding MatrixTransform, marking it as dynamic (as I did in the
Quick Start Guide) isn't necessary, as OSG's render graph is composed of copies
/ concatenations of the matrix itself, and doesn't hold references to the
MatrixTransform node per se.

Note also that data variance is used by the osgUtil::Optimizer. Other code in
OSG might also reference data variance for various purposes.
-Paul

[Eric Pouliquen]

Thanks Paul for your answer.

You're right, the conservative approch is a good way to think, as it seems to be very critical (seeing from stability of the app).

I was wondering effectively what is or not in the render graph, just because it seems it can affect a lot the global perf of the app...

Just a little question: Is right to tell that this Dynamic datavariance has no effect in "SingleTreaded" mode ?

I'm digging my code because I have instabilities and it always crashes on the "frame()" function of the viewer...

Last but not least, in the same way of thinking, I wonder since a long time of what NEED to be in an updateCallback... for example, when you change a switch state, or a stateset value .. ? Maybe you will answer the same way... the conservative approch is to put every modification in an updatecallback, but I just wonder. If on of these chages is not correctly coded in such a callback, can it causes crash or only a "one frame" update latency ?

Thanks again

Eric

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=45603#45603

[Paul Martz]

For contents of the render graph, the following might have some information:

http://www.bricoworks.com/articles/stateset/stateset.html
http://www.bricoworks.com/articles/stategraph/stategraph.html

SingleThreaded means that frame() doesn't return until the draw threads have
completed. At that time, you are free to make any changes you want. In other
threading models, the draw threads might still be active after frame() returns,
but you are guaranteed that objects with dynamic data variance have been
processed (only static or unspecified data variance is left for the draw threads
to work on).

The update NodeVisitor is for convenience only and isn't required for any
modifications.

If your instability (crash?) goes away in SingleThreaded mode, then the issue is
either improper use of data variance, or you have a thread safety issue in one
of your callbacks.
-Paul

[Eric Pouliquen]

Thanks for these clarifications Paul.

Currently my application still crashes even I've put Dynamic datavariance on every modified node... and this crash appears also in SingleThreaded mode. It always crashes on the frame() viewer's function which I use in a custom thread in Qt. My main problem is that when it crashes, it seems impossible to know which node is the problem because I can't see any thing clearly in my Visual Studio debugger. The stack is only talking about UpdateTraversal.

So when you say UpdateTraversal is only for convenience, it means you can update a position or a stateset from anywhere in your code without any crash even in multi threaded modes ?

Regards

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=45707#45707

[Martin Scheffler]

Hi Eric,

I think it is not enough to mark every changed node as dynamic, you also have to mark all their child subgraph nodes as dynamic!

Cheers,
Martin

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=45711#45711

[Glenn Waldron]

You should only update a stateset, drawable, or the scene graph structure from the update traversal, update callback, or update operation. Are you modifying anything at runtime?

Outside of the Optimizer, DataVariance has no effect in SingleThreaded mode. It also has no effect on Nodes (only Drawables and StateSets). So it's more likely that you are trying to modify the scene graph from another thread without proper synchronization.

Glenn Waldron / @glennwaldron

[Robert Osfield]

Hi Eric,

If you are seeing a crash when running single threaded then
DataVariance won't be an issue, you'll need to look elsewhere.
Unfortunately there is too information about the exact problem you are
seeing on your system to be able to guess at what the problem might
be.

A general note about DataVariance, in the OSG there are internal Nodes
of the scene graph - such as Group, Transform, Geode etc, setting
DataVariance on these is only a hint to code that might optimize the
scene graph about what is safe to replace and change and what isn't,
unless you are calling the osgUtil::Optimizer is pretty likely that
setting DataVariance on Node in the scene graph will have no effect on
the end result - as the update, cull and draw traversals all ignore
the Node's DataVariance settings.

The only time that DataVariance is used is when the viewer is run
multi-threaded with the DrawThreadPerContext or
CullThreadPerCameraDrawThreadPerContext threading models, and where
it's only the draw traversal that uses the DataVariance, and the since
the draw traversal has only references to Drawable and StateSet leaves
on the scene graph it's only the DataVariance on these that is
checked. This means the nodes and any sate attributes attached to
StateSet are ignored.

Robert.