I have encountered problems with animations appearing one way in the editor, while being represented in another way during runtime.
This is often the case with IK.
I have found two issues that I am trying to figure out how to problem solve.
1. Often when I create an animation using IK, I finish the animation with proper poses. Bake and save. Then return to the animation to find the IK calculation to have changed, completely posing the rig incorrectly. (This issue not shown in the pictures)
2. The animation I've made is correctly displayed and runs in the editor. Running the animation at runtime calculates the positions differently. (shown below)


This particular rig was trying to prevent incorrect calculations of the limb by using a Point To knee helper, and a Set Position helper for the foot. But even that is not providing expected results.
Hi!
Thank you for the really detailed post.
Thanks to your article, we were able to review this issue.
We did some tests.
Based on the results, we would like to explain the production method we recommend.
Before explaining, let's talk about what caused this issue and what our intentions were to develop it.
We also used IK in 3Ds Max before.
As you said, in a complex coordinate system like 3D, it is more intuitive to use the Helper than to set IK using angles.
Conversely, however, we found it much more intuitive to use angles in a 2D coordinate system.
In 2D, an angle property is one-dimensional, so unlike angles in 3D, there is no ambiguity.
So, we made IK work by actively utilizing the Angle Constraint rather than the complicated method in 3D.
So, the situation where there are two or more IK Controllers in one IK Chain is excluded from development.
In other words, it is more accurate to say that this issue is an out-of-spec specification rather than a bug.
Also, the results in the editor and runtime look different due to "continuity of IK", which will be explained below.
We tested it like this:
We created a "Helper Knee" that orients the knee due to IK.
And we connected the "Helper Knee" by setting the "Position" type IK Controller on the bone of the Calf (not the Thigh).
In the same way, we created a "Helper Ankle" that corresponds to the position of the foot, set an IK Controller of type "Position" for the foot, and connected it to the helper.
It's probably the same as your setup.
We created an animation where the knee bends once forward and once backward.
When we bake the character and play it back, it seems to play mostly the same.
Of course, if you look closely, the character's knees are slightly less curved in the back.
This is due to the "continuity of IK".
AnyPortrait's IK Controller utilizes previous results to calculate IK while an animation is running.
So, if the character's bones move violently in the opposite direction of the previous result, the result of IK changes somewhat smoothly.
Without this "smoothing" process, IK results will sometimes have "spikes".
So, back to the first topic, let's check if this only happens at runtime.
We modified the animation to make the leg bend back and forth more violently.
First of all, IK seems to work without much problem in the editor.
(1) Move the animation's time slider forward a little and play the animation.
(2) when the second keyframe is reached,
(3) the result of the IK is not what was intended.
The leg was not bent backward!
The more continuous the animation is, the more IK will refer to previous results.
So, smoothing tends to work more strongly when playing back in the editor than when editing, and at runtime than in the editor.
In fact, you can see similar results at runtime.
Therefore, it would be more accurate to say "the results differ according to the IK tendency" rather than "the results in the editor and the runtime are different".
You might be wondering what it's like to get rid of IK's smoothing.
Then you'll see horrendous results, such as glitches in the game (e.g. a game character's corpse's limbs trembling).
It was not our intention to add a helper in the middle, so it causes the above problem.
We want to show you how our recommended "Angle Constraint" works.
Disconnect from "Helper Knee" in the settings above.
And set the Angle Constraint on the thigh and calf bones.
The thigh moves back and forth, so we set the range to "-70 to 70".
"Preferred" was set to -50 so that it bends forward as far as possible first.
The main thing is the calf, which only folds in one direction.
So we set the range to 0-90. (Max can be set to 90 or more, but it is recommended that Min converges to 0.)
Since the value of "Preferred" is set to 30, the calf will bend backward if possible as a result of the IK.
Let's move the leg using only "Helper Ankle".
The leg moves normally without bending in strange directions.
You can see that it works naturally without needing to add a helper.
You can see that IK behaves almost exactly the same at runtime.
The way you said isn't wrong, but unfortunately, it's just not supported by AnyPortrait.
We've focused on simplifying the IK setup process so that users don't have too much trouble.
The result is "angle-oriented" behavior and settings.
As a result, the existing techniques using multiple helpers are difficult to utilize.
Please think of this as the trade-off we have chosen.
When we developed the IK Controller, we wanted our users to create animations the way FK (as opposed to IK) and use IK additionally.
This is because, in general, IK has a quite expensive operation and is not stable compared to FK, even if it is not just for AnyPortrait.
So, we expected IK to be used as much as it was used in "Pirate Game", one of AnyPortrait's demos.
(This comes from our experience that simple characters that require complex calculations are not suitable for optimizing performance in games.)
Of course, this is our past development intention.
If you give us ideas for several techniques, including IK, we actively review them and are ready to add them!
If the features we provide are not enough, feel free to let us know!
As always, we will improve AnyPortrait based on user feedback.
Thank you.