Hi all,
Basically, ive just mustered enough free time and enough determination to do ragdolls now.
So some ideas about specific implementation:
BoneChain
This is the backbone of the entire ragdoll thing. It initially starts off as 2 ligaments joined by a specific joint. Then you can add a new bone to it via a method and give it a joint to use between the previous bone in the chain and this new limb.
Skeleton
A storage for multiple bone chains. A simple arraylist of bone chains and their positions and whatnot…
Humanoid
Creates the specific bone chains and skeleton class. This extends skeleton and creates everything for you. Things like joint types and whatnot.
The reason behind the BoneChain class is so that you can add/remove bones easily. It also provides extendability. I.e. in the Humanoid class, you can specify how many limbs you want in an arm (2 if you dont want a hand, 3 if you want one…things like that).
What does everyone think of this? Does anyone have any other ideas? Objections?
DP
Ok, first problem.
When removing a joint/bone from the bone chain, should that result in two bone chains that are still a part of the same skeleton? or should that result in two skeletons as they are now detached completely?
DP
I’d say that once a bone/joint is removed, it’s a free entity, with no skeleton - you’d have to add it back into a skeleton to use it.
I think they should be seperated to two skeltetons but also be mergeable again.
What functionality do You intend to offer by leaving them in one skeleton ?
right, but think of it like this. If you removed the shoulder joint, what happens to the arm? Its definetly gonna be a bone chain, but should the bone chain still be part of the skeleton…
I think they should be seperated to two skeltetons but also be mergeable again
Is there any reason for remerging them again? Besides providing functionality that *might* be used one day?
The reason for leaving them as one skeleton...well, there is no reason, its just so that you know where it comes from.
DP
I’m not sure i understand what’s going on then :?
When the skeleton is an arraylist of bone chains what’s the difference of being detached when the detached bones/bone chains remain in the skeleton ?
Actually, thinking of it, bone chain will not be a linear chain of bones (it can be), it can have branches. E.g. spine + shoulders.
Currently, i will not support detachable limbs (because odejava crashes), but i will do in the future.
In the future, when detachable limbs are there, what will happens is that once the bonechain has been broken into two, two new bones chains arise…Say you took the leg off from teh body, the body and the leg will become two seperate bone chains in the simulation. And are referenced individually.
Skeleton will be an abstract class which has an "compile" abstract method. Humanoid and whatnot will extend this and the compile method will be called by the PhysicsWorld when adding to add the joints and bodies to the world.
How does that sound?
DP
Sounds well
… waiting to see it in action 
awsome, it needs some modification to the joint class. Its a one liner, i’l send it to ya via email so you can have a look. 
DP
When you have some working code, let me know and I’ll try to integrate it with my animation stuff…
I just thought of an idea for this…but its risky.
Use the bones in the model! Basically, loop through the bones in the model and connect them together using BallJoints…
Then its up to the developer to add constraints on each joint.
What do you think of that?
That sounds like a good idea to me! Might be worth hearing with the AgentFX guys if they could let us in to any secrets on how they did it…
I don’t know much about modelling and such though, but I guess it’s possible to get the location of where one bone ends and another one begins, no?
This might even be a job for the physics editor as not all of the joints can be ball ones, so may need a little config from the developer.
I always thought that ragdolls was done with pre-rigged models using the exported skeletons 8-O, isn’t that optimal for preserving proper vertex/joint deforms
I think agency does that way dont they :?
what are the risks anyway ?
I’m a little confused, newbie and all
basically, the risks are when it comes to connecting bones in hands. If you walk through it sequentially, you might end up connecting the top part of the first finger with the bottom part of the second finger…
If not hands, take arms. You might end up connecting the top part of the arm to some vertebrae in the back…which isn’t very good.
Thats risk 1. Risk 2 is that you are confined to 2 model formats, ms3d and md5 (md3?). So you see, its not going to be very optimal for us to do this.
Im gonna think about this one and see how it goes.
DP
model formats have come a long way and although I see your point I find it a little hard to believe that people still go through the stress of programatically skinning non-skeletal formats
don’t skeletal formats store their hierachy data somewhere I know .x does and since doom3 death animation are all handled by ragdoll physics and force of collision I assume they would have also, in short it seems bothersome to provide ragdoll abilities to all formats since people have access to modelling & animation software, ms3d is cheap and blender free, for example, my point is focus on the formats that use skeletal animation.
I agree; if we can get hold of all necessary information from these formats, we should simply stick with them. At least for the autogenerating stuff - we could still have a framework underneith that lets developers "hardcode" their ragdolls.
agreed.
However, since the md5 stuff isn’t part of the core model loading stuff. It would be hard. However, im going to push to integrate them together as i think md5 needs to be supported.
Personally I would prefer to finish my model animation stuff, which could replace a lot of the model loading code in place. My code is more suited to models in the world, whereas the existing code would be much better for rooms, environments etc. which don’t change.
I’m probably going to give up on my bumpmapping work for now, and get back into the main model animation code (including importers for other model types).