Preview: Ragdoll Editor

[KayNine]

Hi All

Since putting together the RobotRagdoll demo (http://www.ogre3d.org/phpBB2/viewtopic.php?t=3711), I've been working on a more generic way of implementing ragdoll physics for Ogre mesh/skeletons. The result is the RagdollEditor. This editor loads a mesh/skeleton, does a first pass at assigning Tokamak rigid bodies to the bones (using OgreTok), allows you to do some testing, and then saves to a .ragdoll format. Then to use the ragdoll in your game, use the reader class to load the .ragdoll file.

Following is a screenie of the main interface. You can see the robot outline (transparent), with the OgreTok objects representing the bones. Note the top left leg is a diff colour, meaning that bone is selected for editing. You can change the bone shape (sphere, cube, capsule), join type, size etc. (Note the instruction box at the top left of each screen).


Once your set your ragdoll up, the first test ensures the physics of the model is stable. If the ragdoll flys off the screen, two bones are too close together. The model should just slowly drift in space if it's stable.


Once it's stable, the next test can be run. This test pins the ragdoll in space by it's head, and you fire balls at it to see how it moves. (ignore the OgreTok hemispheres which are a bug).


There is a demo available in the editor which throws the ragdoll down a set of stairs.


I'm working on another demo where the robot is in it's base stance (with the ragdoll setup as a set of breakable bone), you fire the ball at it and it crumples to the ground. This involves detecting the breakage, clearing the breakable bones, then setting up the bones as dynamic object. It's pretty damn cool, but I'm getting Tokamak GP errors. I have a small concern that Tokamak may not be stable enough for me to implement some of the stuff that will really make this useful (ie. flipping to and from ragdoll physics to animation), but I'll keep going until I hit a showstopper (and them maybe look at ODE?).

If anyone is madly interested in this, I can post the code, however there is still a fair bit of work to do to really get it running properly, which will take a couple more weeks.

[Svapne]

Absolutely amazing work KayNine... Looks incredible..

-Scott

[Stampson]

The robot in RagdollEditor3.jpg just *knows* how SEXY he is...he is posing up a storm!

That looks great, the result is eagerly anticipated =)

-Stampson

[bad_camel]

Cool work, looks very nice...

May I see the route you took to make the robot transparent?

[KayNine]

Yep, but it's ugly....

Code: Select all

void Application::setMeshTransparency(bool transparent)
{
	for (unsigned short i = 0; i < mMyMesh->getNumSubMeshes(); i++)
	{
		SubMesh* s = mMyMesh->getSubMesh(i);
		String name = s->getMaterialName();
		Material* m = (Material*)MaterialManager::getSingleton().getByName(name);
		if (transparent)
			m->setSceneBlending(SBF_ONE_MINUS_SOURCE_COLOUR, SBF_ONE_MINUS_SOURCE_COLOUR);
		else 
			m->setSceneBlending(SBF_ONE, SBF_ZERO);
	}
}

You can play around with different SBF values in the first call to setSceneBlend to get different effects.

[bad_camel]

Thanks, I'm at work now, so I can't really take look at ogre( not sposed to even be posting ), but that code shoud/would make all meshes using that material become transparent?

[KayNine]

Well I am totally stoked. I've got the system working really well and completed the demo where the robot stands in it's base pose, then you shoot it and it crumples to the ground. Why it is standing, there is a static ragdoll representing the underlying bones for collision detection, so when the ball hits the robot, it knows which bone was hit. Then on a collision, the static ragdoll is replaced by a dynamic one, and the hit bone is propelled away from the thing that hit it.

Robot in it's base stance....


And just after it has been hit by the ball - falling to the ground (ignore the OgreTok object poking thru the robot mesh).


And finally dead!


Some pretty spectacular falls could be achieved by shotting the robot while it's standing on a bunch of blocks.

The next step is to implement a static ragdoll collision detection system moving under an animated mesh!

[sinbad]

This is so cool.

@KayNine: Are you using latest CVS? I'm just wondering if the changes I made to add SkeletonInstance were making your life easier.

I'm guessing that .ragdoll is generic enough to be used with any physics system which supports the joint types required?

[KayNine]

sinbad, no I'm not using the latest cvs yet. I probably should, but I've deliberately been using the latest release, which has always proved to be extremely robust. Your recommendation?

.ragdoll is pretty much generic. It stores....

• int ParentRagollBoneNumber (translates to Skeleton bone number)
  Enum mJointType (0 = BALLSOCKET, 1 = HINGE);
  Enum mBodyType (0 = CAPSULE, 1 = BOX, 2 = SPHERE);
  Real mCurrentWidth;
  Real mCurrentDepth;
  Real mCurrentLength;
  Quaternion mJointRotation;
  bool mUseTwistLimit;
  Real mTwistLimit;
  bool mUseLimit;
  Real mLowerLimit;
  Real mUpperLimit;
  bool mEnabled;
  Real mMass;

I'd be happy to modify/change the format so it is applicable to ODE. Given how much work I've spent on this, the thought of porting the whole thing to ODE isn't appealing right now - maybe an ODE expert can take that on!

[SpannerMan]

Wow, this tool looks fantastic, KayNine, very impressive.

I see you mentioned adding support for ODE ragdoll physics...I'd be even more interested in that
Is this something on your todo list?

Anyway, nice work man, keep it up!

[bad_camel]

Using that .ragdoll for ODE should be not too much hassle....here are a few pointers:

1) capsule is a ccylinder in ode ( not a biggie )
2) sphere proxy in ODE takes a radius param, but perhaps you are doubling the usage of one of height, depth or length to apply to sphere
3) Mass in ode is a bit more complex than the "real mMass"....you need to define (unless you manually set ineria values) the mass as a box, sphere etc along with a size. ODE then allows you to set the mass as a density for the primitive or as a total mass

[KayNine]

Mmmmm, a ODE version would be quite some time away - I've got a string of things to look at before then. Maybe once I release the source, an ODE expert could take a look at doing a version for it.

On the plus side, I've almost got the "firing a bullet at the walking robot" working. Stay tuned.....

[:wumpus:]

3) Mass in ode is a bit more complex than the "real mMass"....you need to define (unless you manually set ineria values) the mass as a box, sphere etc along with a size. ODE then allows you to set the mass as a density for the primitive or as a total mass

Yup, this is the ODE mass representation:

Code: Select all

typedef struct dMass {
  dReal mass;   // total mass of the rigid body
  dVector4 c;   // center of gravity position in body frame (x,y,z)
  dMatrix3 I;   // 3x3 inertia tensor in body frame, about POR
} dMass;

As I've understood inertia is about the mass distribution of the object, the other two things are quite clear.

Edit: possibly this data format could be more generalised to a physics representation of an object? As non-ragdolls could be represented by just one bone (=one collision geom, and one mass).

[staringmonkey]

Wow! I picked a hell of a week to go on vacation! Nice work on this KayNine! The hemisphere bug as well as the others you reported are on my immediate todo list, was stupid on my part to make that change without thinking through the design implications. (The change from cylinders to capsules, visually.) Can't wait for a "playable" version!

Wishing OgreTok lived up to projects this sweet ,
staringmonkey

[KayNine]

Been away for a few days.....

The Ragdoll Editor is ready for testing. It's still missing a bunch of stuff (like changing limits, etc), however the basics are there, and best of all, the tech to flip from animation to ragdolls and back again is working, so you can shoot the walking robot from the platform. Very nice.

Staringmonkey, the RagdollEditor requires those bug fixes to OgreTok, so once they are ready, I'll post the code so people can have a play.

I have also tried to implement Tokamak sensors, but everytime I call AddSensor, null is returned!

Anyway, another teaser....

Robot walks along the platform (there is actually a skeleton under this mesh built from Tokamak animated objects for collision detection):


The ball is fired at the robot, and at the instant shown a collision has been detected between the ball and the underlying ragdoll.


The underlying static ragdoll is replaced by a dynamic ragdoll, and the mesh skeleton is now tied to that ragdoll instead of the walking animation. A force is applied to the limb that the ball hit to get things moving!


The robot falls to the ground and comes to rest.
[/img][/list]

[Kencho]

Coooooool, Kaynine!

[T.T.H.]

*reviving old thread*

Hi

Just to repeat what's happening:

1. robot walks over plain area: there is a "static" ragdoll and it's bones are moved by the animation
2. ball hits robot: collision is detected, "static" ragdoll is replaced by "dynamic" ragdoll
3. robot falls down: bones are moved by physic engine (weights, joints, gravity, ball contact,...)

Question 1: how does the robot get up on his feet again and continue walking?

Question 2: the ball might have different weight or speed (= momentum) and so different effects on the robot. A big ball might bring the robot completely to fall just as described above. But on the other side a small ball hitting maybe his upper torso might just bring him out of balance but he would continue his walk. How would you accomplish that?!?

Thanks & Bye,
T.T.H.

[KayNine]

1) To get the robot to walk again, you can simply call a function in the ragdoll manager to swap from ragdoll movement back to animation movement - however the robot will instantly go from the ground back to walking. Better would be to have an animation for getting the robot from it's random "dead" position into a know walk stance position - which could be tricky. I would suggest writing something that creates an animation from the dead pos into a know prone position, then have an animation in the skeleton file for getting from the prone position into the walk stance, then continue walking. Have I understood your question correctly?

Anyway, when I shoot them, they don't get up

2) From memory, when a collision is detected between the ball and the robot, I think I put a fixed force into the limb that was hit from the direction the ball is travelling - would need to check the code to confirm. The force could be modified depending on the weight and speed of the ball, however, once the ragdoll is controlling the robot, it WILL fall. I read about Unreal 3, where they can control just part of the skeleton with the ragdoll, so if a small force hits the arm, the arm is "ragdolled", and flops around (and breaks????), but the rest is animation controlled. I think that is sort of what you are after, and would require some heavy changes the to ragdoll system - but in theory IS possible. Simulating a small blow to the chest will be very difficult, since skeleton is still under animation control.

Another option could be to achieve this outside the ragdoll system, by mixing a "move the chest a bit" animation channel with the "walk" animation channel.

Even better would be to have some system of muscles, so that the mesh/skeleton stands on it's own, until it is pushed over a certain limit, when it will then fall - simulating a real human. I did quite a bit of research on this 12 months ago, and even wrote some bad code, but never got too far. There were some research papers on it - but the maths was killer.

So, a very long answer to 2 small questions....

[bad_camel]

for (2) if i understand you correctly the limitation is more from skeletal animation, cause even if you just make the part hit dynamically controlled, in the next frame the skeletal animation will reposition the bone to where it is sposed to be?

Would there be a way to remove that bone from the animaton but keep it attached?

[KayNine]

Bad Camel, that's a question for someone with far greater knowledge than I to answer. But off the top of my head.....

You could change the bone weights, so that the hit limb vertices no longer belonged to the animated skeleton bone. But then how would you control the vertices? Would need another bone to be created. Maybe there is a better way to do the ragdoll stuff than I have done - where the mesh has 2 skeletons instead of 1, a ragdoll skeleton, and an animated skeleton, then point the vertex weights to the appropriate skeleton and bone depending if it is animated or ragdoll controlled.

...or...

Once the animation has been applied to the skeleton, re-adjust the ragdoll controlled bone prior to rendering. I vaguely remembered that the animation and rendering all happens in one hit in Ogre, and it's tricky to get access to the animated mesh once prior to it being displayed.

But I am way out of my depth here, and pretty rusty on Ogre....

[T.T.H.]

Answers like those give me back hope that the internet isn't just full of spammers...

KayNine, you got me absolutely correct. Your solution comes very near what I had in mind: when lying on floor get back in "known" position (e.x. prone), than do a animation to get in "normal" position (e.x. get up again).

In my opinion "hitting" isn't an assault gun bullet stray all the time. It could be an arrow hitting a limb. Or maybe even the wooden shield attached to an adventurers arm. That doesn't kill the guy but may bring him to fall - or at least out of balance.

When switching to ragdoll means crumbling down then this is bad. It would be too "binary", I imagine something inbetween. Could there be an "interpolation" between animation-based skeleton and ragdoll-physics-based skeleton? Or could you apply some forces to the ragdoll physics which are defined by the animation? Maybe not a full muscle simulation (that's he thing why we humans actually can walk and don't crumble down...) but some "fake" one, based on the "normal" skeleton (e.x. "he should be like this if he would be walking") just to influence the physics simulation. There might be a force in any situation trying to bring every limb angle in the position defined by the animation. Massive ball hits would "override" them (not by threshold, but simly by having far bigger forces in the physics engice's calculations) and bring him to fall - but lighter ones would just cause "balancing it out".

Concerning Enreal 3: probably those are the things they get their bucks for...

Do those research papers have anything in common with game development and game physic engines? If yes I would be interested ( teeteehaa (o) gmx.de ): I don't want to understand all the math but want to learn the correct "terms"/"descriptions" of those things.


Behind the story...

I recently saw a World of Warcraft trailer and was somehow shocked: large groups of characters charge at each other, meet each other, instantly come to halt and then it goes bing - bong - bing - bong - bing - bong - etc. until on of them has zero hitpoints. That fights are so static!!! I mean nothing new since Diablo I. Just a matter of having the bigger sword and the more healing potions. You could make a duct tape stripe on your left mouse button and go for a pee in that time...

Neverwinter Nights has better fights: while being very statically concerning the rules (I don't think it is such a big bonus point to advertise with "based on D & D rules") the moving animations are great: blocking, parrying, dodging, falling down - unfortunately all animations. Nice, but scripted.

I do imagine more dynamically (fantasy) fights, just like in modern ego shooters: players run around, dodge around, going on their knees to have a better aim, getting knocked out by a shot. That I want to see in fantasy games! Let axes shatter their bones, let arrows pierce their armors!

I imagine an adventurer with a shield and a sword charging a club swinging ogre. The ogre hits him first, he blocks with the shield and stays unwounded, nevertheless he's flying away due to the force, stumbling down. Then he gets up again, comes back and hits the leg of the ogre. The ogre's one leg folding (sp?) down, so the guy can have a blow on the ogres head. Ogre gets up again, pushing the adventurer back again with his fist and then swinging his club after him. And so on and so on. I want players to franatically hammer their cursor keys while fighting and moving their mouse in "fluid" movements to swing their weapons (e.x. as in Arena: The Elder Scrolls). And of course I don't want scripted animations but a physic simulation of that fight. So that is possible that the ogre throws a barrel after the guy, knocking him off his feet, giving him a headache, letting burst the barrel.

*sigh*

I started dreaming again...

Well, I think ragdoll physics are the future of game characters and I do want to learn about it.

Thanks & Bye,
T.T.H.

[KayNine]

T.T.H, I like your vision...

1) Check out the pdf files at http://www.ri.cmu.edu/pubs/pub_4410.html and to a lesser extent http://citeseer.ist.psu.edu/536104.html. Some intersting (but techo) stuff there.

2) Modifying a radgoll physics bone with an animation is almost impossible. I tried it and the results were terrible. If a ragdoll bone is at a certain point in space, and the animation indicates it should be a little to the left, if you set the position of the ragdoll bone a little to the left, the physics (Tokamak) engine thinks you just applied an infinite force to the bone and the bone flings about wildly.

3) I agree with you on the WoW stuff. Looking thru a mag reviewing the games expo in the States recently, the hit games coming out in the next 12 months are all pretty ho-hum (the graphics look stunning, but the physics is more of the same). Libraries of animations isn't going to cut it in the future. The movements of the characters will be generated on the fly.

As a related side-issue.....I've been using MotionBuilder to make animations (in bvh format) for Poser, and creating little movies - Matrix-style. (It's awesome to have your character kick someone in the head, then apply dynamic clothing and hair and wind and let the physics engine calculate the dynamics). There is also a lot of bvh motion-cap stuff on the web that can be plugged into MotionBuilder and exported in Poser format (people falling etc). But MotionBuilder doesn't have physics system, so you can't throw your character around, or drop them - it has to be done by hand. However, there is also an application called Endorphin, which effectively has a skeleton rag-doll, which falls, or which you can apply a force to (almost identical to the Ragdoll Editor, but cost $16k US!!!!). Endorphin allows you to apply a force to say the left arm of the skeleton, and it will fall according to the physics of the situation (same as the Ragdoll Editor), however it sames the fall in bvh format, which can then be loaded into MotionBuilder, and exported to your favourite 3d app. But from what I can tell of Endorphin from the limit amount I have seen, you can't specify your own rag-doll dimensions. So I think there is a market for the Ragdoll Editor enhanced, so it can record animation data for whatever ragdoll set-up you want to specify (even quadrapedes). A good prototype would be to modify the ragdoll editor to record the falling animation in Ogre animation format.

But ultimately, I think game characters will be controlled as tho they are human. Maybe a ragdoll physics system, that applies a "standing" force to make your character stand. To throw the axe, a rotation force is applied to the arms, and the torso is put in a position to balance the rotation, so if the character has just dodged a blow and is low, the axe swing will start low and rise - all dynamic. When the axe hits the other person, the stopping force of the axe is applied back into the axe swinger.

I wrote some code to do this a while back, which was a simple as connecting the head on my ragdoll to a static object at head height. The ragdoll sort of hung there, standing, with feet limply touching the ground. Then to raise an arm, I dynamically connected the hand to another static object in the air, and the arm raised. Very clunky, and didn't simulate the muscle system, but food for thought.

OK, enough rambling from me.

[T.T.H.]

T.T.H, I like your vision...

Hehe, fine

If a ragdoll bone is at a certain point in space, and the animation indicates it should be a little to the left, if you set the position of the ragdoll bone a little to the left, the physics (Tokamak) engine thinks you just applied an infinite force to the bone and the bone flings about wildly.

Why "move" the points around and make the physic engine believe that infinite forces are at work? I think you don't have to take the animation for the truth of state for the skeleton, but only as an ideal state for the skeleton which should be reached but does not have to be reached. Why not just apply (moderate) "forces" as a physic engine would expect it?

Some instant scribbles at work:



Basic idea outline:

• have two seperate skeletons
• ragdoll skeleton is controlled only by physic engine
• animation skeleton is only controlled by animation states
• skeletons are affiliated by springs which do connect the joints of the two skeletons (ellbow to ellbow, knee to knee, head to head, etc.)
• springs do represent additional forces applied to the joints of the ragdoll skeleton within the physics engine
• springs do not have a linear force based on "stretch size"(sp?) but a distance-to-force function customized to the problem (semi-animated, semi-ragdolled bipedal characters)
• intention is to "gently" push the ragdoll skeleton into the state of the animation skeleton, but without neglecting gravity and other forces
• when character is influenced by yet another force (e.x. ball, bullet, barrel, etc.) character tries to "balance" back into animation state (induced by the springs)
• when hitting force is too big and so the ragdoll skeleton differs too much from animation skeleton, the springs "rip" and do not apply any more force on the joint (and so the poor character tumbles down)
• when too much springs rip even all other spings rip and the animation skeleton is disabled
• when character's tumbling comes to a stop a completely different animation skeleton is activated, which gets the ragdoll skeleton (now again unaffacted by other forces like a bullet) back up again - e.x. a "prone animation skeleton" which has an animation over several frames to get up into an "standing animation skeleton" again.

Well, sounds a little bit like Pinocchio the marionette

But as you said: no solution but only brain-food here...

Bye,
T.T.H.

[A55b0t]

I believe if you check the Havok website they have a video of some zombies being shot up. I of course have no idea how they do this but maybe someone else might be able to ween some information about how they do this from watching it?

Edit: http://havok.com/products/Zombie.avi
Edit v2: Just a thought from watching that vid again. It looks like the one zombie didn't resume it's animation again until it recovered back to it's keyframe. I guess if you were to implement something like this an option to do it like that or to make them keep animating animating would be useful.

[litobyte]

For my little experience on ragdolls I'd say:

° just one skeleton
° 2 states



Zoom in:

One skeleton is enough for all the mansions, animation and ragdoll, the physic system objects (no matter what system you use ODE, tokamak, newton, havok) will be only SOME of the "joints", particularly in a very detailed skeleton (with fingers and all), if you'd use the whole skeleton's joints as physic object, your ragdoll will be super-realistic, but your game will run poorly low fps.

So I say one skeleton only, but with 2 (or more) engine states,

- one for when the skeleton is managed by animation data.
- two for when the skeleton is "ragdolling"

Of course we could have had much more states eg:
one for manual joints manipulation, one for mixed modes, and one where we could also "mix" ragdoll and animation states, with a certain % for each and interpolating them (just like the Half Life2 SDK MeshViewer does when you combine more animations and ragdoll if you know what I mean).

This will achieve almost infinite combinations and a super-scalability for the game engine you are working on.