For once, it’s for legs. And on the other note, animation needs to be made easier, not more complex. What you guys talking about is adding unnecessary complexity.
The OP and others seem to have a sketchy concept of the reason for IK and FK. They aren’t meant to be interchangeable methods of solving a bone chain’s motions – the names say it all. Forward Kinematics results in the motion being propagated from a specific joint forward to the end of the chain, resulting in arcs. Inverse Kinematics uses the end of the chain - the IK Target - to determine the rotation of all joints within the chain, “inverting” the hierarchy. IK was developed because it allows the goal of a chain’s motion to determine the chain’s joint actions - for example, the hand reaches for something, a goal. The hand’s motion in this case is pretty much strictly linear, and trying to keyframe that linearity via FK arcs is a nightmare. So IK solves for the goal’s linear motion and transfers the solution to the IK chain’s joints.
Conversely, using IK to move the hand in a substantial arc contradicts IK’s basic intent, which is based on the goal in linear motion. So in that case, use FK, where arcs are a natural consequence of the bone chain solution.
This is what IK/FK switching is all about, and should be used in all but the most trivial cases. A trivial case is where the arc is so short it can be defined by only a handful of linear IK keys, one for every frame of the arc. There aren’t many trivial cases of using FK where IK is best suited – using arcs to define even a limited linear motion at the end of a multi-jointed bone system is really, really way too much work!
Nice long write up. Can you now re-word it in plain English please? And I am not being sarcastic.
For all I know, IK is used where you need to plant end of the chain (foot, hand) firmly or affix it to an object and have chain following object. FK is used for free motion where nothing is affixed to anything. All joints in the human body move on arcs. There is no linear motion.
So what you are essentially saying is that after IK foot is about to take off the ground, I should switch to FK and continue animating using FK until foot gets back to the ground?
Doing that with feet would be difficult unless your rig has IK/FK snapping controls. I guess using auto-IK on FK limbs in Blender would work too. I’ve never tried this I like IK always on all limbs unless character doing tumbling spinning jumps or swinging types of action.
Many character animators like using IK on both legs and arms with the pose-to-pose method of animating. The trick is to animate in passes when using IK. Blocking in the movements first then refining the arcs in later passes. Refine as much as possible before ever touching curves for the last precise refinement and to perfectly smooth everything out.
FK is better for the straight-ahead method of animating. In pose-to-pose method FK controls can result in a different time eating issue. If you change a character’s placement or just a spine or shoulder later in the process you often have to re-key all the joints in the limbs.
Many use a hybrid method of pose-to-pose and straight-ahead using both IK/FK. I guess some like to use FK arms always. Maybe some do always FK feet too. Both can be very tedious in 3D animation*. The choice of when to use either depends on preference and also time available to refine an animation. There are also other reasons for pose to pose or straight ahead… many say that some action shots turn out better if animated straight-ahead instead of pose-to-pose. But straight-ahead you have to guess where things will end up at the end of an action.
Some folks like to jump into curves early on too. Others say that is too tedious and easy to make a mess of things (I agree).
All this tedium is why video reference, thumbnails, and sketch animating is used. These planning methods are used to get all the action and timing mostly figured out before you ever set the first key in the 3D app.
Nothing about this stuff is easy until you get your methods worked out and do it enough to be fast.
I love talking about this stuff it’s fascinating. An amazing craft.
-Larry
- Edit: Everything chipmasque said applies. Pick your poison.
@LarryPhillips: Question - what is “straight-ahead”? I only ever used pose-to-pose with tweaking in-between frames.
While I don’t really see any issue animating exaggerated characters, my current project requires to have more of a natural motion (ideally closer to anime side) of human characters. And that’s a royal pita 
I am thinking maybe I should figure out a way to do mocap instead of animating (for walk/jog/run anims only) ? Although I’ve been told all these new cheap mocap methods have no stabilization algorithms and it will be a lot more work to smooth / clean up the output of mocap.
As for IK/FK snapping, I watch a tutorial from Blender Cookies and the guy had snapping via buttons on the tool panel. I don’t recall ever seeing that add-on in the public 
This is called IKFK matching (or snapping) and Rigify apparently allows for it (my source). I really think it could be made through constraints and drivers alone, but how exactly, I don’t have time to research as of now… I suggest you look into Rigify and adapt the generated script to your rig.
Oh, I see my source mr LarryPhillips is present in this very thread. Well, then… 
As for the method I was suggesting :
First thing, you’re welcome. Then, it’s for legs, you say ? I don’t see a problem - just place your parent bone at the hip, and rotating it will affect its child - the foot ! It’s very simple, you can always hide the specific controller if you only need it once in your animation.
That’s not a natural way of animating! o.O Foot doesn’t just move on an arc, it’s a complex path.
I mean, if you animate that way - good for you. I can’t even fathom the pain of doing animation this way.
Pardon me, but you really sound like you don’t know what you want, concurrently pretending you know perfectly what’s best. Remember how your initial question was how to move IK bones on an arc ?
Now will you settle for an IKFK switch ? If you feel like you need a “match position” tool, which I admit is very handy, my advice would still be to look into how Rigify handles it.
Hadrien
I do - I want to animate without thinking about all this junk. That’s what I did in 3DS MAX using CAT and it worked wonders. I didn’t have to think about IK, FK, all these technical hacks just to get the job done. Your method introduces yet another level of complexity.
I do want to try FK/IK switch on legs, using IK only for contact poses. But I need that instant IK to FK snapping add-on, and hopefully have it on tool panel with instant access to it.
Yeah, I will dig Rigify, thanks (I’ve never used it, so I didn’t even know it’s the instant snap).
Your English comprehension level isn’t my problem, though refusal to consider any but your own viewpoint seems to be one of yours. Your “For all I know” comment indicates you have a lot to learn.
Obviously feet do not in any way move in FK-directed arcs in normal walk/run motions, their movements are primarliy linear in nature, with close-approximations of arcs only in certain segments of the overall movement. The foot-plant capability is as much a function of IK as goal-directed as reaching for an object – the plant point is a goal that is maintained for a certain number of frames while the foot is on the ground. After that the goal lifts up and moves to the next stationary goal.
Keep in mind that the joints being manipulated by an IK constraint are still moving radially (in arcs, if you will) – it is the sum total of the joint movements that determine where the end of the chain (like a foot or a hand) ends up. FK provides one solution using these radial joint motions, and IK provides another. That is why they are not interchangeable.
I also mentioned that IK is more successful at dealing with arc-like motion than FK is at dealing with linear motion, but maybe your comprehension slipped a bit there?
I’ve fallen behind here while typing so bear with me…
Straight-ahead is where you start from the beginning of an action and keyframe as you go instead of setting key poses first then doing the inbetweens.
There’s a ton of info on the net about this. Remember these techniques come from hand-drawn animation but still applies to 3D animation. Some differences like keeping size, volume, and proportion during straight-ahead animation doesn’t apply if you’re posing a CG puppet. You’ll also see people saying that pose-to-pose is good in CG because the computer does all the inbetweens for you. Wrong! As you’ve already found out the computer seldom does it correctly.
As mentioned above, many use a hybrid technique. Pose-to-pose overall but straight ahead for some things like swinging limbs in an arc where the computer does in fact create perfect inbetweens for you. That’s where the IK/FK switching comes in. Tricks like switching IK to FK at the camera cuts is used. If you want to switch in the middle of a shot then you really need IK/FK bone snapping*. Rigify has auto snapping ability (I need to figure out that code so I can put it in my own rigs),
Methods described for hand-drawn animation here:
Here’s a great explanation in 3DCG if you don’t mind the short ad in the beginning.
http://blip.tv/cg-brains/3d-animation-pose-to-pose-vs-straight-ahead-part-1-5654236
I learned much from various free stuff on the net but most from The Animator’s Survival Kit - Richard Williams book and especially the DVD set for that. Most of my hands-on learning was through Jason Ryann’s training series and other one-off tutorials I bought there. He has a few free prep videos to give you a taste of the sketch pose to pose animation solve using Flipbook. Flipbook is just easier to use than doing this in Blender but it is possible to do it in Blender.
Unfortunately there’s no free vids where he takes this into Maya. What he does is paste the sketch animation onto a plane in Maya to use as reference for posing and timing the 3D character there.
http://www.jasonryananimation.com/
http://vimeo.com/ianimateworkshops/videos/page:20/sort:date
Mirrors and video is also used by animators. Then thumbnails with timing symbols like oldschool animators used, or sketch animation like Jason does. Some animators just use mirrors and/or video then straight into the 3D app. The prep is all about figuring out the action and the timing ahead of time. Solving your animation before you actually animate the final product is what it’s all about.
Hey motosep sorry about this wall of text. There’s nothing simple about good animation. Good as in smooth flowing pleasing to watch. All this technical junk is easy to comprehend after you get over the initial learning hump. You also have to learn animation principles too like anticipation, followthrough and overlap, etc. Easy to do with much practice. The hardest part of character animation is yet to come… it’s called acting.
This is why animators get the big bucks compared to modelers, texture artists, lighters, etc.
Sheesh I’ve typed a book here it seems. All this ain’t just for you motorsep. I always post for the lurkers / database too.
I’m done here I hope. Good luck in your animation endeavors.
-LP
- Edit: Keyframing methods can be used instead. See post #36 below.
Wall of text that is easy to comprehend is totally awesome! Btw, I have that book too Just n o DVDs. Yeah, I figured it’s just like with anything else - practice and practice and practice again.
I animate for a video game, not for FMV. So I need that instant snap between IK/FK.
Thanks for the tips, Larry.
The biggest difference between movies and games is you have to animate for any view angle not just for a single camera. Otherwise it’s basically all the same except for technical issues like having to use armature rigs that the game engine can use. You may not have the luxury of snapping in a game engine rig. I don’t know I’ve never done anything for games. More research for you to do no doubt.
OK I’m really done now.
-LP
My experience with the Unreal Engine and a little in Unity is that game rigs don’t operate on exactly the same kind of data that animation app rigs can, which is why most use some kind of filter/exporter to create data files for the games using input from apps like Blender or Maya. IK usually makes it through the pipeline OK, and FK always, so some sort of IK/FK switching should be workable. But certain kinds of constraints don’t always translate as well, and usually require a test.
For our engine it all works, because all data is baked into keyframes on export. And then engine has it’s own IK solution on top of that.
Just need to test if IK/FK instant snap bakes correctly.
Before there were more automated methods of “IK snapping” I did it with a couple of manual steps and single-frame transitions, so I usually use that method still. It also allows for gradual transitions as well as snaps, useful in some situations. But there’s no special means involved, just clever keyframing, so it should also work for game engines without hassles.
How would you get IK chain bones to be exactly at the same position as FK chain bones without fancy script?
By manually positioning them and keying the appropriate channels. The switch doesn’t really take much time to keyframe, it’s the residual motions after switching that can take lots of keying on the ones.
An example: The Clean & Jerk
Up until the figure grasps the bar, the arms are all FK. The switch is at the first frame of the grasp, so the hands stay pinned there. As long as the hands grip the barbells, they are under IK control, but there’s another switch when he releases the weights.
This is a case that’s exactly as you mention, the hands need to “stick” to the bar – the bar is actually what is keyframed for the lift, dragging the hands along. Keyframing on the wrists (often on the ones) is what sort of “disguises” the fact that the bar is lifting the arms, not vice-versa.
The IK pinning of the hand actually occurs at the bases of the hand bones, i.e., the wrists, so there tends to be a lot of “drift” in the hands on the bar during the lift-- the Location is nailed but the Rotation is not, so there’s a lot of compensatory keyframing to keep the hands looking right, particularly given how the hands change orientation during such a lift. But trying to match the motion of the bar by keying FK moves on the arms would be right near impossible, so IK is the better solution.
PS: Had this been a one-handed lift, IK would not have served as well – in that case using a constraint to tie the grasped object to the hand is better, and then use FK for the arm motions. The grasped object will need some keys for its own motion (if any), but otherwise it’s very straightforward. This is how the bucket my Showreel character carries was handled. The arms move in sweeping arcs (perfect for FK), so the bucket has a constraint to follow the action.
PPS: Scripts are great for automating, but they only rarely do things that cannot be done manually, with a little more effort.