Animation In Editor vs Runtime (With IK)

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.

Alright, so I've done further testing to reproduce this in an isolated environment. Currently, if you do not have a bone constraint on an IK segment, the animations will not calculate the same each time. Such as here.

The IK will not attempt to recreate the bone position desired (Right) but produce (Left). It is heavily dependent on the frames leading up to the position. Also, if you scrub the timeline backwards, you'll get different bone positions than if you scrub the timeline forward. As such, my first instinct is to set up 'helpers' such as this 3D example.

The helper assists the IK segment so it knows where the intended forward facing direction is always.

Attempted to recreate this in AP editor, I come to this following setup.

The Red Helper is where the Thigh Leg is set to Point Towards. Which ensures that I get the same IK calculations every time I return to AP animator. This works as expected within the AP editor. This set up breaks down at Runtime with the following results.

It seems that the Leg bone isn't gathering the correct point towards information during runtime. I've tested this with various settings and weights with the Look and Set Position helpers, to no better effect. Granted, all of this was without the use of Bone Constraints. Which I wanted to get intended results without their usage in case I needed to break said constraints. I think I was trying to use the helper bone incorrectly, Should the Set Position helper bone not be used to control an IK chain for the purposes of animations? And only use it for dynamic interactions such as foot to ground/hand to reach/Aiming etc? Especially if you are trying to animate without constraints. Still, I am curious why my attempt at the Pointer + Set Position worked in AP editor, but not Run Time. My final bit of testing, If you use only the IK chain with the Target Bone as the only bone that has keyframes on the timeline. You can place the Target Bone in the same X,Y cords while maintaining the direction of the Knee, either left or right and reliably swap the knee point direction to either side. It maintains value in editor and at runtime. But, If you only use Set Position constraint, with that as the only bone on the timeline, you are unable to set the Knee point direction left or right reliably. I have resolved my current issue I had through further testing and can get results I expect and desire. Although, I feel like the AP Editor providing the correct calculated animations with the Set Position Helper and Point Direction Helper, while Runtime does not, might be a sort of odd bug in this particular use case. Thanks!

Hi!

Because "IK calculation" are not baked and are always calculated, the results in the editor and the results at runtime are not perfectly identical. And it's slightly different every time, not just in two cases.

This is a common characteristic of IK itself.

However, there is something a little strange about it.

AnyPortrait's IK operates by considering "the result of the previous frame".

Therefore, it is common for in-game results to be more accurate and natural than results in the editor.

(The editor does not play animations in consecutive frames, so the error in IK is rather large.)

But in your case the opposite is the case, and we are a little puzzled.

Looks like we'll have to re-examine the IK code as a whole.

Anyway, it is difficult for us to know exactly what the situation is in the first case that you described without images, so we will only write about the situation that you informed us with images.

You added an IK Helper to the character's knee, we recommend the "Angle Constraint" more than that.

AnyPortrait's IK was developed to be more consistently calculated when "Angle Constraint" is enabled.

This property not only limits the range of angles, but also causes IK to behave based on the "Preferred" angle.

Specifically, "Angle Constraint" solves your case, where your character's leg joints are completely inverted.

For a detailed explanation of "Angle Constraint", see the page below.

https://rainyrizzle.github.io/en/AdvancedManual/AD_BoneIK.html

Incidentally, connecting multiple Effectors (or Helpers) to one IK Chain is not our intended production method.

Since we don't know exactly how you set up your IK Controller, we're only giving you a rough outline.

Please try using "Angle Constraint" and if the problem is not solved, please leave a comment again.

And if you tell us how you set up IK, we can fix this issue faster.

Thank you.