I have a working animations loading system from FBX files. What I want now is my 3d human model to pick a ball from the ground and throw away. How do I do that?

'Inverse Kinematics'. You would add constraints to the feet to keep their position and set the ball as target for the hand. Then the system solves for joint angles of a pose that satisfies this. An optional objective would be to maintain stable balance (keep the center of mass of the whole character above the support polygon - a convex polygon formed by the feet contact points.)

The problem you describe is already pretty difficult. A IK solver alone does not give you animation that is realistic. To get this, you either can use a physical simulation of the character, and work out a controller that behaves natural (keeping in balance is usually the most important task, reaching a goal becomes secondary), or there are approaches that use machine learning and motion capture data to learn natural behavior, or you do something in between. It's a hard problem that will keep you busy for a very long time eventually.

So what are your goals? Typical for games would be to rely on animation but use IK only to adjust this. E.g. fitting feet to stairs or sloped terrain, aiming a gun to a target, etc. To pick up a ball you would have an animation to kneel down. Then the IK solver can reach for the ball (mainly about lower and upper arm - can be solved analytically without iterations - pretty simple). To throw the ball having animation would be helpfull es well, and you can then cheat about the trajectory of the ball after it leaves the hand.

JoeJ said:
'Inverse Kinematics'.

Oh, sorry. Did not realize you already mentioned this in thread title. I meant it to be helpful as a search keyword.

So here's what i did to handle IK:

I have hard coded solvers but only for parts of the body, which are arms, legs (almost the same but no shoulder), and spine.

For arms and legs i have effectors at hands and feet. Those may try to move to a target position and orientation. IIRC it's like this for arms:

1. Check distance from shoulder to target. If the target is to close or too far, rotate shoulder accordingly to help a bit (the rest of the body may have to do some action to help further).

2. Calculate ellbow joint angle so distance from shoulder to target = distance shoulder to hand. After that calculate all joint rotations and we have the pose for the arm.

But there are two problems:

1. Joint limits: We need to make sure we do not violate them. Worst case is flipping where some joint might flip between + and - 180 degrees (if there were no joint limits) if the target moves only a little bit. If i come close to such a situation i slow down to prevent rapid movements.
2. Swivel angle. Put your hand on the table and rotate your elbow around the line from hand to shoulder. You can do this while still being on target. So this angle is an open variable. Usually we choose an angle that 1. violates all joint limits the least, and 2. reduces muscle power to hold the pose (so we have ellbow downwards if possible.)

So that's pretty simple and does not need a solver. Because pose never changes a lot between two frames, one iteration of this is enough for me.

A full body IK solver would not allow such hardcoded algorithm and it would be more expensive. Personally i don't have a need for it. Instead i have a higher level control that operates on the body as a whole and does things like moving feet effectors upwards if we want to lower height.

The above is about pose but tells nothing about speed.

A natural way of motion for humans or animals is constant acceleration. That's a bit harder than moving at constant velocity, but this looks robotic.

So, if we have a task like ‘reach the apple with hand after one one second’, you can calculate angular acceleration for each joint, the time of negating this so it becomes deacceleration, and then after one second all joints are in target pose and all velocity is zero.

I don't do this super exactly and minimize error with each frame so it works good enough. Notice that positions and velocities change smoothly, but acceleration may be 0,10,-10,0 for example. So it changes abruptly and remains constant for certain periods of time. If your motion is somehow like this, it looks natural. (Edit: Another way to achieve a similar result is to use splines for joint angles like we do for keyframes in animation software.)

Thanks for your answer. I'm trying to create a cricket game. At first it's a simple one, one bowler, batsman etc. After reading your posts, IK seems a tough subject. I have also created a simple physics engine for my game(Rigidbody simulation). Currently, in the game when I want to bowl the ball(w/o a bowler animation), I put it at a certain height with a horizontal velocity and add it into the physics engine. Engine does the rest. Without using IK, how can I mix a bowling animation and the ball? kind of cheating?

isu diss said:
Without using IK, how can I mix a bowling animation and the ball? kind of cheating?

For a sports game there is no real way around IK probably.

After having the animation, you could place the character at the correct spot so he grabs at the the balls location. But then you have the problem to ‘walk’ him to this exact spot which is also IK, and not sure if this strategy works for all other actions as well.

It's also still very common in games to teleport objects. E.g. grab nearby the ball and teleport it into the hand.

But after work on physics you should be prepared for IK. Control problems are pretty different from simulation problems, but doing adjustments to animation is easier than generating all animation procedurally.
Also, having the animations and the general idea what's going on in your game, joint limits will be rarely violated so it's mainly about calculating target rotations and done. No difficult motion planning problem around obstacles i guess.
There seems also little interaction between multiple player bodies in Cricket. This also makes it easier.

There are surely other options than what i've said. E.g. if you have constraints in your engine, you could turn your animation into joint torques to play it back with ragdolls, and add a constraint to the hand so it follows that.

It's also still very common in games to teleport objects. E.g. grab nearby the ball and teleport it into the hand.

Nice idea. I think I can cheat this out. Thanks.