-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Osfield wrote: > > I have been thinking about physics integration as well, but not > suggested it on this round as there wasn't a contender sitting of the > shelf ready to integrate. > > Longer term I'd like to see physics integration, ideally in a way that > we can plug in different physics engine implementation, be them open > source or commercial. OPAL might the a basis for such an > implementation, or perhaps just inspiration to how to tackle/how not > to tackle it ;-)
Opal looks OK, but it doesn't seem to be actively developed. The most recent version of ODE breaks with it quite horribly. However, some of the design is quite nice. > > I'd suggest member of the community experienced in this area propose > what they see as a workable route forward. Even better get some code > together for it 8-D I have working code for Bullet at the moment, but this has worked the same for Opal too. Basically, it consists of three things: 1) A special node "powering" Bullet engine on every frame, either by means of an update callback or through an overridden accept(). This steps the physical simulation by elapsed real time between frames, calculating collisions and resolving them on the way. Here we can play with real/non-real time, decoupling between rendering and simulation time, etc. 2) Every rigid body has an update callback that when called updates the OSG transform of the node from the corresponding Bullet transform of the rigid body. This ensures that the objects are rendered where Bullet tells them to be and with right orientations. 3) Object loader. This is the tricky beast, because physics engines support objects built up out of several pieces connected by joints (hierarchies). Think of a car or a rag doll. Each piece has a collision proxy mesh and physical properties (mass, position, initial velocity and torque, material parameters ...) At the moment I have only a loader that takes a simple geometry (something osgDB can load) and builds up a collision proxy either automatically using bounding boxes or takes one from a config file, together with the remaining parameters. I do not support joint hierarchies yet, but the code exists in Bullet examples for this. Then the loader has to instantiate all rigid bodies and all geometry, link them together using update callbacks and ideally deliver the whole collection of objects somewhere as a higher level object (e.g. called "car" or "character"). Here one would think that the hierarchy should have a root and you simply keep a reference to that, but it may not actually have one - e.g. a simple "car" could be 4 cylinders (wheels) and a platform, connected by joints - there isn't really an explicit notion of a root transform in the scene graph sense. All pieces are simulated independently in world coordinates, the joints ensuring that the pieces stay together (or not - Bullet supports breakable joints). I have this solved by something called an "object manager" which keeps track of these kind of objects, but I am fairly open to design discussion because I do not like this too much - it is hassle to deal with, e.g. from scripting code. I am willing to contribute this code, however I am not sure whether this is a meaningful design - especially when it comes to possible scalability issues with all those callbacks and the object loading/management. Also, loading of the physics data should be ideally integrated with loading of the geometry itself - e.g. Collada supports export of physical properties of objects. >> That does not make really sense. > > And that doesn't really parse ;-) :-p > Agree with all the above, and this is what I had in mind with my own > introduction of motives. > > One of the reasons to integrate osgLua and/or osgPython with the core > is facilitate all the above usage, but also help consolidate the > effort on making these libraries better supported and maintained. > There libraries will need work to get them fully functional. This is > something I can help mentor, but being stretched for time and skills > will be unlikely to be able contribute too much to the development. Actually, I think that the focus should be on providing a meaningful API to export to these languages. That could even mean a wrapper in order to eliminate/minimize usage of pointers and some C++ functionality that is difficult to translate (templates?). Once you have that, the language bindings could be done very quickly for almost any language, even in an automated way (e.g. using SWIG or something similar). Ideally, the wrappers should be made automatically from the current code. It also neatly sidesteps a problem that some people may not like Python or Lua or whatever for any kind of reason - they are free to build their own bindings, since the API is there already and it would be only a matter of running SWIG or whatever on it. Even something like CORBA binding to OSG would be possible without too much hassle. Think scene/viewer control over a network, without having to code any networking code - I have code for omniORB controlling the camera from external Python application somewhere. This works wonders if one is working in a CAVE or something similar and cannot have a local GUI (it would show up on the CAVE walls :) ) Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHXDgzn11XseNj94gRApuEAJ9ifSmD2sX/8DX0Hof4BMSzCPjlswCg0C4s 580uHlTGHURRZGLLbRkiH70= =p3t2 -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
