My experience is admittedly limited here, but I think some of us are
coming from the position that your physics "graph" is an entirely
different thing than the render "graph". The two are often completely
orthogonal.
In one case you may have physics body represented by something simple
like a ball... where as for various implementation reasons your scene
graph may need to be a whole pile of objects. Conversely, sometimes a
whole mess of physics parts/bodies/bones/whatever may decompose into a
single mesh and a custom shader to move the points around.
While there may be parts similar between a physics "node" and a scene
graph "node", I'm not sure they are similar enough to justify being
related in a class hierarchy.
...and maybe you are already taking all of that into consideration and
I've misunderstood the conversation so far. It just sounds like you are
trying to have the physics engine directly "act" on scene graph nodes
versus transferring values transform information from the physics nodes
to the scene graph nodes. I think you will pay dearly for the
"convenience". :)
-Paul
Sukender wrote:
Hi David,
Well, what we intend to do is simply provide a "plug" so that you can do what you want.
Morover, the osgPhysics' aim is to drive nodes in the graph by the way of physics. We don't plan to
make physic objects to be "cullable", or things like that. Changeing the renderer (like
raytracing) would not affect things handled by osgPhysics.
I hope this is a bit clearer! :)
About Adrian, I also discussed a few points with him, and I may contribute to
PAL too. And yes, he's in Australia... Wang Rui (osgPhysics, osgNV) is in
China, and I'm in France... well it may be difficult to be all online for a
chat, but we still can work :)
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
I guess I understand why people do it, but I would rather that OSG kept the
limited scope of being a scene graph, that is with the features just of doing
3d rendering. I think a more limited scope makes it more useful as a drop in
component of a game engine.
physics and audio, while they are necessary in a game or simulation engine,
they are not rendered, and I don't think they belong in a scene graph. In
delta3d, we have, and are more and more trying to separate things such as
drawing, physics, and audio from simulated objects (actors) so that actors can
be composed of these features via componentization and messaging. We would
eventually even like delta3d to have the ability to use different renderers.
As technologies like raytracing become more prevalent, the scene graph may have
change a fair bit, but that shouldn't affect the audio and physics systems.
Originally we had wanted to work with Robert more closely to make delta3d have
game engine features, and osg have the rendering features, but things didn't
evolve that way.
Either way, this is not a discussion for the osgPhysics list. I'm making
dtPhysics, which appears to have nearly exactly the same goals as you have
except that we intend to integrate with delta3d its component system.
I email back and forth with Adrian Boeing a fair bit, and I have commit access
to PAL, as I said before, so we would discuss the features and direction of
PAL, as we see it. Perhaps PAL needs a mailing list, or maybe we need to do
something more like a telecon to discuss things. I don't know where in the
world you are. I'm on the east coast of the US. Adrian is, I think, in
Australia. So, I'm not sure how practical that is.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
