Caveman and I have started talking about ragdolls over e-mail, and I’m moving the discussion here so everyone can pitch in.
First off, what’s currently in com.jmex.physics.ragdoll is complete rubbish (I wrote it so I’m not offending anyone here :D) and will thus be removed.
A while ago there was a thread discussing this, and here’s what came out of it:
It'll be hard to break joints in a ragdoll.
It's best to load the necessary data from a model format, such as md5.
Caveman has suggested the Cal3D format, which might be a good idea. My knowledge of Cal3D is limited though, so am I right in saying that Cal3D is a modelformat which contains both a mesh file for the graphics, and a bone file for the physics/animation?
Another candidate is md5, which chaosdeathfish has already done an importer for. This is a big benefit I think; it will probably give you (caveman) a big jumpstart.
Besides the format/importer questions, there needs to be some thought done on how to best implement this in jme-physics. What do you think about doing something like this?:
Each limb of the ragdoll is a DynamicPhysicsObject, linked together via joints, forming a PhysicsGroup (new class, got a better name?) which acts as a container so that you can treat your ragdoll as one entity.
The PhysicsGroup has got:
one main DynamicPhysicsObject which position and rotation will represent the whole group
setPosition and setRotation methods that will move/rotate all objects in the group
Chaosdeathfish has shown interest in ragdolls in the past, so maybe you guys can work together on this?
What about just using the .jme format? Just check that it contains a jointmesh (of course this can be enhanced as needed). By supporting .jme you automatically support any formats that contain joints and can be loaded into jME. Now, there's no guarantee that .jme will have everything you need from the outset, but I'm sure it can be added.
There's a thought. As I see it, the problem is that none of the .jme convertable formats contains enough physics attributes for us have enough to work with (mass's, jointlimits). MD5 does, but is loaded through chaosdeathfish's own system.
If md5 or x or cal3D would be available as .jme, this would probably be the way to go. Maybe this is the place to put down the effort? Yes…
yes, if there was an MD5 converter to .jme this would require that the necessary features are added to the .jme spec giving you what you need for physics.
Oh, by the way, regarding that PhysicsGroup class I was proposing, I also ment it to be the foundation of vehicles (or actually any group of objects, linked together via joints, that you want to treat as one).
What about just using the .jme format? Just check that it contains a jointmesh (of course this can be enhanced as needed). By supporting .jme you automatically support any formats that contain joints and can be loaded into jME. Now, there's no guarantee that .jme will have everything you need from the outset, but I'm sure it can be added.
Anyway, currently the jME binary format loader wouldn't support this kind of setup as it can only read in Node objects, not my new Model class. I'd need to either create a separate reader for loading Models in (possibly .jmem, for jME Model?) or modify the JME binary format and reader/writer, which would be a bit presumptuous of me considering how new I am to the project
this is a statement chaos himself
see http://www.jmonkeyengine.com/jmeforum/index.php?topic=1395.0
This initial contribution solves a few problems but I’d like some input on what would be ideal. I think the general purpose of this is to generally have a standard object that represents a group of objects that make up a model (or simply a group a DPOs)? What do you think about having a DynamicPhysicsGroup created that extends DynamicPhysicsObject that wraps a Node? I think this makes logical sense so we can maintain access to the graphical components similarly as with the DPO to Spatial. The models can define specific mass for each element of the model, but that is not really necessary to be addressed initially. For now we can apply a defaultMass when the DPG is being created and that gets assigned to all of the underlying DPOs.
I would like some thoughts on all this as I’m still very new to this arena of development and still have a lot to learn.
Just curious (I know you guys are busy)… were any further decisions made on how to implement ragdoll support? In particular, I'm interested to see how it will integrate with the .jme format.
–K
PS: Great work on the physics system, in general. It looks like an incredibly valuable package.
Well, I guess it's more in a waiting state for the .jme format to come around a bit. We have been discussing re-working a lot of the aspects of the jME-Physics project in general. When I get a few hours without anything better to do I plan to do a quick run-through on my proposal of the new jME-Physics abstract API and hopefully get it adopted directly into jME and then we can do an implementation using ODE. That's my plan, but others on the project may have other ideas, so short answer…nothing much more has been done. :-p
).