IKFK Switch vs IKFK Blend

Rigging
#1

Hi! I’m considering whether there’s any reason to go with IK Blend for my rigs instead of IK Switch.

The difference is that IK Switch is an enum where you only have 2 options with no blending, but it’s possible to create automatic snap when you switch with no external tools required. It also eliminates the need of creating 2 keyframes next to each other when you need to make a switch.

IK Blending has an option of slowly blending between IK and FK but makes the setup somewhat harder and possibly with more overhead, as you need to use blending nodes instead of, for example, choice node. It’s still possible to create the auto snap with built in tools, but may complicate node network further.

As an animator myself I rarely find it useful to use blend between IK and FK, most of the time switch needs to be instant in one frame.

So far all points to the fact that it’s in fact easier both for riggers and animators to use switching instead of blending. But in majority of rigs I see (with few exceptions) riggers implement IK FK blending instead of switching. What is the reasoning behind that? Is it really necessary?

Curious to know both riggers’ and animators’ points of view.

EDIT: Forgot to also mention that in a lot of cases IK-FK blend is linear, especially with stretchy IK, resulting in weird deformation which basically make IK-FK blend simply unusable in real situations.

#2

Almost every animator I have ever worked with just wanted a switch and not a blend. It’s a little less mental overhead to have to worry about and typically the swap between IK and FK or vice versa happens on one frame anyways.

1 Like
#3

Correct me if I’m wrong but the IKFK Switch and IKFK Blend can be achieved in one set-up.
Basically, if an animator wants only IKFK Switch, then use integer values. 0 and 1. If he wants to blend, then use decimal values 0.2, 0.5, 0.7 etc.

I think this kind of set-up is also implemented in the Advance Skeleton Rigs.

#4

Sort of, AS uses 0-10 values though. And I did mention that yeah, it’s possible to make a separate attribute that can only go 0-1 (same enum for example), that just drives the IK-FK blend and sets it to 0 or 1.

The problem I see with this is that under the hood you are still using blend nodes and more complicated node networks. More overhead - slower working rig and more points of failure.

It just sounds like both wasted work and wasted CPU cycles if actual IK-FK blend is never used.

And there is one more downside I did not originally mention in my post, it’s that a lot of the time IK-FK blending is linear and does not behave the way you’d want in animation, resulting in odd movements and poses on any values other than 0 or 1.

#5

depending on your setup if you use just rotations and scales for blending the blending does not move in a linear way

most animators i worked with want the option to switch and keep the joints in place(this is achieved through callback, marking menu or hotkey), but also want the option to blend from on value to another, you can add some information nodes in the scene that pop up while the blend is not completely set.

ideally the setup works with values 0-1, the 0-10 range seems to be frustrating.

the blend nodes might seem to be more overhead, but i don’t think this is all that much of a problem, specially now with bifrost you can even put it in a single node connection. otherwise blending is just 2 blendcolor nodes for rotate and scale. with a switch node you will always have to make a script that sets the correct position otherwise there will be popping in animation, thats seems to be more overhead to me.

1 Like
#6

depending on your setup if you use just rotations and scales for blending the blending does not move in a linear way

Yes, but then you need to have additional layer in the rig to make sure that deformation joints are not scaled, as it results in wrong deformation and is bad for game engines.

ideally the setup works with values 0-1, the 0-10 range seems to be frustrating.

Yeah, that was surprising to me as well.

That’s the same with blend node in most cases when you need a one-frame switch. You still need a script to perform matching.

Apart from it breaking backwards compatibility, does it create standard nodes under the hood or operates on it’s own plugin level?

EDIT: Checked out bifrost. Well, it does have potential, but at least now using native Maya nodes is a lot faster. It does calculations completely separately from maya, so on one hand they may be able to improve it’s performance, but on the other hand it may be impossible to reduce the overhead of it interacting with maya to a point where it will be faster than maya’s core nodes.

Feel free to correct me if I’m wrong

#7

from what i noticed is that as long as you make sure that you don’t have too much inputs going into and out of the Bifrost node it is faster. it compiles in the background of each node connection using LLVM to make sure its as fast as it can be, possible even faster then c++ nodes.

if you are making a rig for games then my advice would be to separate the rig structure from the skeleton anyway, yes this adds a layer of overhead and can make the rig a bit slower but not by much in todays standards, that way you can choose to blend with rotate and shale and only connect the skeleton using parentConstraints, removing all possible scale from the rig to the skeleton.

as for a one frame switch, yes you will need to have the 2 keyframes to make this possible, but with a blend node you can also let the animator choose to blend from FK to IK over a few set of frames, thus removing the pop.

i always add as much possible features to my rigs as possible, specially since i work with too many different animators with different needs, sure the rig gets a bit slower, but there is always solutions for that. and yeah there is a lot of overhead but for that i use python :stuck_out_tongue:

#8

I always try to make my tools backwards compatible for at least a few Maya versions, so until Bifrost is well established I don’t really wanna use it in my auto rigger. Even though with subscription model people tend to update Maya more frequently a lot still use older versions. Studios often lock versions for projects.

And now got curious, does bifrost have any API or any way to control it from Python?

As for blending and scaling and constraints I kind of liked Jarred Love’s approach here: https://www.youtube.com/watch?v=ZnWGTrsHq8M

Using matrices instead of constraints does make hierarchy look a lot cleaner and evaluates faster.

In any case I’m trying to write my autorigger as modular as possible on all levels, so swapping things or adding new modules with different rigging approaches or adjusting existing ones should not be a problem.

#9

bifrost has Mel commands so it should be python scriptable as well. all nodes you create leave their command messages in the script editor. but i believe the nodes can be exported as json as well (don’t pin me on this as i haven’t tested this myself)

#10

I personally prefer blend over switch.
Enums don’t work in additive animation layers. They are always set to override.
Another advantage of blends is that an animator doesn’t always have to maintain the 2 keyframes around the switch but can blend over a few frames (when it makes sense) and therefore tweaks don’t break the animation as much as switches do.

Bifrost btw does NOT support animation caching. The bifrost node are unsupported and therefore you lose the great fps optimizations of Maya2019.

And I agree that when working with rotation channels for blending you get good results in comparison to translation and rotation.

In the end the animators decide what they want to work with.

2 Likes
#11

bifrost may not support animation caching but it is evaluated in parallel.

we tried animation caching but it proved to more of a hassle then a blessing (cached playback has too many bugs).

our pipeline now makes full use of parallel evaluation and rigs hit a stable 60fps while animating and in playback. my preference goes out to c++ nodes anyway but that’s more easy to maintain within a company.

#12

Yeah, I don’t want to have animators install plugins or anything extra to work with my rigs, that’s complication that’s not justified enough.

Hm, good point about layers. But if you need to animate IK and FK on layers you’re probably doing something wrong IMO. I can’t really think of a situation where I’d want to animation IK FK blending on different layers and not want to override. Sometimes you may not notice that your IK-FK is not set to 1 or 0 and animate part of the animation this way and then find out that oh my, that’s all broken. Usually solved by showing both IK and FK controls if it’s non at 0 or 1, but still possible.

And still out of all the rigs I worked with only a handful have IKFK blending work in an actually useful way.

Well, I guess I’ll have to code it in as an option.