Hi Václav,
2008/10/26 Václav Šmilauer <[EMAIL PROTECTED]>:
> First question is whether such flat graph (one linear sequence of
> bodies, one linear sequence of interactions) is ok for osg -- if it will
> not pretty much kill all the advatages that graph-oriented approach has.
A flat graph is certainly possible, but the cull traversal won't be as
efficient as it could be with a quad/oct tree layout.
If one really wanted a flat tree, but gain the advantage in
performance of a qaud/tree you could possible have a custom Group node
that manages an internal KdTree of culling and have this KdTree
updated dynamically. I haven't personally tried this but it's
certainly doable.
> Second question is whether nodes of the scene graph can be taught to ask
> simulation elements for their data: think of Transform object, which
> holds position and orientation of a particle (its leaf). It would be
> best if it could query
> bodies[id]->physicalParameters->se3.{position,orientation} as needed
> (when the scene graph is traversed) instead of copying those
> periodically from the simulation into the Transform object.
You could subclass from osg::Transform yourself and provide a custom
connection directly to your objects.
> Third question is how ref_ptr play with boost::shared_ptr? We use
> shared_ptr's extensively, but as long as the code is well separate,
> these two will hopefully never be mixed?
In the SVN version of the OSG we have a couple of helper methods that
allow boost::intrusive_ptr<> to be used with osg::Referenced obejcts
(bascially all the scene graph and callbacks have osg::Referenced at
the top of the class inheritance). This allows you to use
intrusive_ptr<> and ref_ptr<> side by side robustly.
> Fourth question: is there support for selection of an element in the 3d
> scene with mouse?
You can certainly get interesections with objects in the scene, and
then decorate these objects to show that they are selected, but the
OSG at the scene graph level doesn't have the concept of selection -
it's up to your app how you manage the scene graph to do selection.
Have a look at the osgpick example to see how to do this.
> Fifth question: honestly, I read that opensg is more suited for CAM etc
> apps, would it be better for me?
I'm not aware of any features that OpenSG has that OSG lacks that
would make OpenSG more suitable for CAM.
What I can say is that the OSG is has a community size of over 2000
while OpenSG's is just 300, so for the vast majority of scene graph
users the OSG looks to be more useful for a wider range of users and
usage models. The OSG has more contributors (340 at last count) than
OpenSG has users, so it's almost certainly influenced far more widely
by the needs of end users.
> Or some other suggestion, like VTK? Our
> objective is not to have the highest possible framerate, but it shold
> certainly run at a dozen fps with 1e4 bodies (spheres, boxes,
> triangulation elements etc) on regular hardware.
VTK is quite a different beast to OpenSG or OSG, its strength lies in
data processing and visualization pipelines. You could you use it to
do what you want, but it probably isn't as nature fit as a scene
graph.
Robert.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
