Realistic Movements and Inverse Kinematics
Author
Hi everybody,
I''ve been gathering up information on the web, a lot of it here at GameDev.net and/or linked from GameDev.net. So, I thought I''d ask a question that has been nagging me for a long time. Is there any plausible way to create realistic movement (humans or characters, etc.) without having to pay a studio to do MoCap technology for you? I can only imagine how costly that''d be. One way I was thinking of that I''ve read a little about, though I haven''t found many good sources, is inverse kinematics. How possible do you think that would be? Are there any other algorithims? Can any of them do the details of movement such as flippancy of the hands, etc? Are home-brewed skeletal models good enough, or is inverse kinematics or some other implementation required? I hope to get a discussion going here, because I''d love to see what knowledge everybody else has about this subject. Please respond with any insight, references, articles, or anything related remotely to the subject. Thanks!
-iamunknown73
I actually just started on my character animation yesterday, and am using inverse kinematics. Right now my "first draft" at it isn''t that great, but I think it''s going to be good when I get around to do all the stuff I planned.
I''m using a particle-spring system to model my characters, and IK can be just about plugged in to the code. The results are not exact, but the mimimalistic stretching and compression is not visible. For me it seems like a great option, as I am not skilled in 3d-modeling / animation, and even creating an ugly walk-cycle is a pain for me.
Clicky for screenshot
I know he''s not pretty, or even relatively sober, but still looks better than a static stick figure
.
I''m using a particle-spring system to model my characters, and IK can be just about plugged in to the code. The results are not exact, but the mimimalistic stretching and compression is not visible. For me it seems like a great option, as I am not skilled in 3d-modeling / animation, and even creating an ugly walk-cycle is a pain for me.
Clicky for screenshot
I know he''s not pretty, or even relatively sober, but still looks better than a static stick figure
.
The particle system mentioned above is relatively easy to implement and gives good results, but may not be suitable for all applications. (Does anyone have a link to the Jacobi (sp?) paper?)
IK is pretty hard to implement, in general. I believe there''s a good overview in the Watts and Policarpo book ''3D Games'', and I think Eberly also discusses it in his book ''3D Game Engine Design''. Eberly also has a new game physics book coming out soon, but I don''t know if it''ll cover IK.
I have read (but have no direct experience myself) that as cool as it is, IK does not necessarily produce the most ''natural'' results animation-wise, which is why mocap, keyframe etc. are still more popular.
If you do want to give IK a try, you can try the mathematical approach (which involves formulating the Jacobian matrix and is fairly complex), or an easier algorithm such as cyclic coordinate descent. I think most practical IK systems use a combination of the above.
That probably doesn''t help much, but you asked for anything remotely related, so there you go :-)
IK is pretty hard to implement, in general. I believe there''s a good overview in the Watts and Policarpo book ''3D Games'', and I think Eberly also discusses it in his book ''3D Game Engine Design''. Eberly also has a new game physics book coming out soon, but I don''t know if it''ll cover IK.
I have read (but have no direct experience myself) that as cool as it is, IK does not necessarily produce the most ''natural'' results animation-wise, which is why mocap, keyframe etc. are still more popular.
If you do want to give IK a try, you can try the mathematical approach (which involves formulating the Jacobian matrix and is fairly complex), or an easier algorithm such as cyclic coordinate descent. I think most practical IK systems use a combination of the above.
That probably doesn''t help much, but you asked for anything remotely related, so there you go :-)
"Are home-brewed skeletal models good enough, or is inverse kinematics or some other implementation required?"
First off, IK is an algorithm. It is independant of the bone representation you use or where you got your bone info from. Home-brewed or not, you need a skeleton if you want to do IK, but you don't necesserily need IK to animate a skeleton.
That said, what IK is particularly good for is reacting to the constraints of the character's environment. For example - suppose your character needs to go up a staircase. If you happen to have an animation suitable for that staircase (motion captured or otherwise), consider yourself lucky. But what if your animation is for a different staircase angle? Your character's fit will eihter land on air or go into the stairs. Not good. And what if you don't have an animation at all? That's where IK comes in. It allows you to say to your animation system "the foot should go *here*", and the IK solver will do the rest.
An IK solver, particularly an itterative one, can give very nice results when coupled with artist-made animations, or even with motion-captured animations. For example, Yann used a combination of motion-capture and itterative IK in his engine, and reports very good results. See here (he also gives a link to a combined analytic/iterative IK solver).
On its own, a smiple IK will probably give you mediocre results (I cannot verify this at the moment, as I haven't done any work with IK just yet..). A more advanced system should give you better results, but still not fully realistic. It is also harder to implement. To get fully realistic results, you need to take additional physical factors into account (mostly the weights of individual body-parts), which are generally ignored by IK. AFAIK, this is currently too computationally expensive for realtime (again, I cannot confirm if this is true).
Michael K.,
Co-designer and Graphics Programmer of "The Keepers"
We come in peace... surrender or die!
[edited by - technobot on November 20, 2003 1:00:32 PM]
First off, IK is an algorithm. It is independant of the bone representation you use or where you got your bone info from. Home-brewed or not, you need a skeleton if you want to do IK, but you don't necesserily need IK to animate a skeleton.
That said, what IK is particularly good for is reacting to the constraints of the character's environment. For example - suppose your character needs to go up a staircase. If you happen to have an animation suitable for that staircase (motion captured or otherwise), consider yourself lucky. But what if your animation is for a different staircase angle? Your character's fit will eihter land on air or go into the stairs. Not good. And what if you don't have an animation at all? That's where IK comes in. It allows you to say to your animation system "the foot should go *here*", and the IK solver will do the rest.
An IK solver, particularly an itterative one, can give very nice results when coupled with artist-made animations, or even with motion-captured animations. For example, Yann used a combination of motion-capture and itterative IK in his engine, and reports very good results. See here (he also gives a link to a combined analytic/iterative IK solver).
On its own, a smiple IK will probably give you mediocre results (I cannot verify this at the moment, as I haven't done any work with IK just yet..). A more advanced system should give you better results, but still not fully realistic. It is also harder to implement. To get fully realistic results, you need to take additional physical factors into account (mostly the weights of individual body-parts), which are generally ignored by IK. AFAIK, this is currently too computationally expensive for realtime (again, I cannot confirm if this is true).
Michael K.,
Co-designer and Graphics Programmer of "The Keepers"
We come in peace... surrender or die!
[edited by - technobot on November 20, 2003 1:00:32 PM]
Author
Thanks for all your insight, suggestions, and links!
I think I''ll look into the particle-spring system more; it''s seems like it could be promising. But juusco, I couldn''t even recognize what that 3d model was! lol However, I''m in the same boat as you; I''m a horrible 3D modeler and animator, so it would definitely help me. I''m even more interested in IK now, especially with technobot''s comments on it. But what does keyframe like? That''s the one thing I didn''t get.
Well, again, thanks a ton and please reply again!
-iamunknown73
I think I''ll look into the particle-spring system more; it''s seems like it could be promising. But juusco, I couldn''t even recognize what that 3d model was! lol However, I''m in the same boat as you; I''m a horrible 3D modeler and animator, so it would definitely help me. I''m even more interested in IK now, especially with technobot''s comments on it. But what does keyframe like? That''s the one thing I didn''t get.
Well, again, thanks a ton and please reply again!
-iamunknown73
Keyframing is the standard way of doing animation. It usually refers to animations without bones, but bone animations actually use keyframes as well. The positions of the vertices are sampled the at particular times (which the artist decides upon), and then interpolated for the times in between. If you use bones, then instead of sampling and interpolating the vertex positions, you do the same for the joints, and then find the vertex positions based on the bones. This also happens with motion capture - the mo-cap equipment simply generates a series of keyframes for a predefined skeleton.
Michael K.,
Co-designer and Graphics Programmer of "The Keepers"
We come in peace... surrender or die!
Michael K.,
Co-designer and Graphics Programmer of "The Keepers"
We come in peace... surrender or die!
Author
Okay, thanks a ton technobot, you''ve really helped! Now I''ll know what to look into. Thanks again!
-iamunknown73
-iamunknown73
A question spawned from this thread...
hows does "rag-doll" physics, like in doom3 and such work? (sliding down stair cases, flopping over hand rails etc).
Thanks.
hows does "rag-doll" physics, like in doom3 and such work? (sliding down stair cases, flopping over hand rails etc).
Thanks.
I''m not very familiar with how ragdoll physics work, but I imagine it is little more than rigid body dynamics applied to a skeletal structure.. the basic principles should be the same as what would be used for simulating a chain. I haven''t found much info on the subject, except this thread in the math and physics forum (includes a couple of links).
Michael K.,
Co-designer and Graphics Programmer of "The Keepers"
We come in peace... surrender or die!
Michael K.,
Co-designer and Graphics Programmer of "The Keepers"
We come in peace... surrender or die!
I think either you guys are confusing inverse kinematics with forward kinematics or I am confusing the two. Anyway this is how I understand it:
Inverse kinematics: The animator specifies joint angles and the model forms to those angles using some type of hierarchical scheme. For example to get the location of a hand in the world it is subjected to the rotations and translations of the wrist, elbow, and shoulder. The fore arm is subjected to the rotations and translations of the elbow and shoulder. While the bicep is subjected to just the shoulder.
Forward Kinematics: The animator specifies the final location of the finger tip and complex calculations determine the angle of the wrist elbow and shoulder. I failed to memorize these calculations and have no intention of coding them in the near future. Inverse kinematics are still used to do the final rendering but the animator dose not need to specify the rotation angle for every key frame.
Anyway I find key frames and inverse kinematics work well enough for what I want to do and will probably be enough for you to. The OpenGL push and pop matrix functions seem to be made for doing forward kinematics so here is a little pseudo code to get your started.
//inverse kinematics for drawing an arm
glPushMatrix(); // entire arm
glTranslate( ); // move arm to final location
glRotate( ); // rotate entire arm by shoulder angle
DrawBicep( ); // your draw function here for just the
// bicep part of the arm
glPushMatrix(); // just the forearm and hand
glTranslate( ); // move the forearm to the end of the
// bicep
glRotate( ); // rotate forearm and hand by the
// elbow''s angle
DrawForearm(); // your draw function here
glPushMatrix(); // just the hand
glTranslate(); // move the hand to the end of the
// forearm
glRotate(); // rotate hand by wrist''s angle
DrawHand(); // your draw function here
glPopMatrix(); // pop the hand matrix
glPopMatrix(); // pop the elbow and hand matrix
glPopMatrix(); // pop the entire arm matrix
If you don''t already know this OpenGl likes to do it''s translation and rotation functions in seemingly upside down order. It makes more sense if you think of putting instructions onto a stack and only running them as they are popped off
Also your draw functions should render the hand, forearm, and bicep with its parent joint at the origin. That is, the hand should be rendered with the wrist at (0,0,0).
One final thing when I say move the hand to the end of the forearm I mean the forearm as you render it, not its current place in the world (that is what Open Gl and reverse kinematics are suppose to do for you). So if you render your Bicep with the shoulder at (0,0,0) and the elbow at (0,0,-3) then the forearm translate should look like this:
glTranslate3f(0.0,0.0,-3.0);
Thanks for listening to my ramblings I hope they helped.
A sample of what I did with Inverse Kinematics can be found at:
http://www.soe.ucsc.edu/classes/cmps161/Winter03/projects/saunders/charge.gif
Death Hamster
Inverse kinematics: The animator specifies joint angles and the model forms to those angles using some type of hierarchical scheme. For example to get the location of a hand in the world it is subjected to the rotations and translations of the wrist, elbow, and shoulder. The fore arm is subjected to the rotations and translations of the elbow and shoulder. While the bicep is subjected to just the shoulder.
Forward Kinematics: The animator specifies the final location of the finger tip and complex calculations determine the angle of the wrist elbow and shoulder. I failed to memorize these calculations and have no intention of coding them in the near future. Inverse kinematics are still used to do the final rendering but the animator dose not need to specify the rotation angle for every key frame.
Anyway I find key frames and inverse kinematics work well enough for what I want to do and will probably be enough for you to. The OpenGL push and pop matrix functions seem to be made for doing forward kinematics so here is a little pseudo code to get your started.
//inverse kinematics for drawing an arm
glPushMatrix(); // entire arm
glTranslate( ); // move arm to final location
glRotate( ); // rotate entire arm by shoulder angle
DrawBicep( ); // your draw function here for just the
// bicep part of the arm
glPushMatrix(); // just the forearm and hand
glTranslate( ); // move the forearm to the end of the
// bicep
glRotate( ); // rotate forearm and hand by the
// elbow''s angle
DrawForearm(); // your draw function here
glPushMatrix(); // just the hand
glTranslate(); // move the hand to the end of the
// forearm
glRotate(); // rotate hand by wrist''s angle
DrawHand(); // your draw function here
glPopMatrix(); // pop the hand matrix
glPopMatrix(); // pop the elbow and hand matrix
glPopMatrix(); // pop the entire arm matrix
If you don''t already know this OpenGl likes to do it''s translation and rotation functions in seemingly upside down order. It makes more sense if you think of putting instructions onto a stack and only running them as they are popped off
Also your draw functions should render the hand, forearm, and bicep with its parent joint at the origin. That is, the hand should be rendered with the wrist at (0,0,0).
One final thing when I say move the hand to the end of the forearm I mean the forearm as you render it, not its current place in the world (that is what Open Gl and reverse kinematics are suppose to do for you). So if you render your Bicep with the shoulder at (0,0,0) and the elbow at (0,0,-3) then the forearm translate should look like this:
glTranslate3f(0.0,0.0,-3.0);
Thanks for listening to my ramblings I hope they helped.
A sample of what I did with Inverse Kinematics can be found at:
http://www.soe.ucsc.edu/classes/cmps161/Winter03/projects/saunders/charge.gif
Death Hamster
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
