when disabling IK mode, visually keyed bones move to incorrect position until timeline is moved away and back to current frame #107242

New Issue

Julieta Riley · 2023-04-22T15:04:58+02:00

Julieta Riley commented

2023-04-22 15:04:58 +02:00

System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 526.98

Blender Version
Broken: version: 3.5.1 Release Candidate, branch: blender-v3.5-release, commit date: 2023-04-05 07:29, hash: 8f3faae18bb8
Worked: (newest version of Blender that worked as expected)

Short description of error
when disabling IK mode viewport moves bones to incorrect position until timeline is moved away and back to current frame

Exact steps for others to reproduce the error
Open below blend file and then repeat steps shown in attached video.

**System Information** Operating system: Windows-10-10.0.19044-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 526.98 **Blender Version** Broken: version: 3.5.1 Release Candidate, branch: blender-v3.5-release, commit date: 2023-04-05 07:29, hash: `8f3faae18bb8` Worked: (newest version of Blender that worked as expected) **Short description of error** when disabling IK mode viewport moves bones to incorrect position until timeline is moved away and back to current frame **Exact steps for others to reproduce the error** Open below blend file and then repeat steps shown in attached video.

2023-04-22 13-59-07.mp4

6.8 MiB

visual location and rotation need to be keyframed twice to take effect.blend

865 KiB

Julieta Riley added the

labels 2023-04-22 15:04:59 +02:00

Julieta Riley commented

2023-04-22 15:14:57 +02:00

In the above video it worked first time, but sometimes I've also noticed that even when moving the timeline back a frame and then to the current frame once again, the fk is still not in the correct visually keyed position. In this case it's necessary to re-enable the ik constraint, do the visual keyframe again on the chained bones, then disable IK again (keyframe it), and then go back a frame and once more to the current frame. For some reason, the second time it will then work.

Julieta Riley changed title from ~~when disabling IK mode viewport moves bones to incorrect position until timeline is moved away and back to current frame~~ to when disabling IK mode, visually keyed bones move to incorrect position until timeline is moved away and back to current frame

2023-04-22 15:33:41 +02:00

Wayde Moss commented

2023-04-22 18:12:21 +02:00

I think you figured out that Insert Keyframe Visual Loc/Rot/Scale actually works:

So, in general, inserting a key doesn't re-evaluated the frame- and it shouldn't. You don't want to lose unkeyed poses when you key some other bone. For Insert Keyframe Visual Loc/Rot/Scale, it's the same thing. That's why you don't see the expected results until after you disable IK and refresh the frame. If we were to fix this such that the visual keyed bones do get updated, then we'd also have to properly order key insertion by bone dependency (think of a chain of bones with ChildOf constraints to eachother and you visual key all of them). Or, simpler, just directly write to the local channels after all key insertion is done. For now, I think Apply Visual Pose then Keyframe Insert Loc/Rot/Scale is a good workaround.

Though, I'm not sure why it would ever work the 2nd time but not the first. If you can reliably reproduce that part, it'd be helpful.

I think you figured out that **Insert Keyframe Visual Loc/Rot/Scale** actually works: So, in general, inserting a key doesn't re-evaluated the frame- and it shouldn't. You don't want to lose unkeyed poses when you key some other bone. For **Insert Keyframe Visual Loc/Rot/Scale**, it's the same thing. That's why you don't see the expected results until after you disable IK and refresh the frame. If we were to fix this such that the visual keyed bones do get updated, then we'd also have to properly order key insertion by bone dependency (think of a chain of bones with ChildOf constraints to eachother and you visual key all of them). Or, simpler, just directly write to the local channels after all key insertion is done. For now, I think **Apply Visual Pose** then **Keyframe Insert Loc/Rot/Scale** is a good workaround. Though, I'm not sure why it would ever work the 2nd time but not the first. If you can reliably reproduce that part, it'd be helpful.

Julieta Riley commented

2023-04-22 18:56:33 +02:00

Hi, no it's not actually working in the previous scenario from the other bug report still (the one that stops it working unless the last bone in the chain has a parent), that one only works if applying first and then doing a standard keyframe insertion for loc/rot

Julieta Riley commented

2023-04-22 19:14:36 +02:00

here's an example file showing the issue with the visual keyframes only being inserted correctly on the second attempt:

To recreate, go to frame 30, add visual location/rotation to all bones, then turn off the ik mode custom property on the foot bone and keyframe it. then go back a frame and forward a frame to refresh the viewport a few times. You'll notice the position of the visual keyframes is wrong. Now on frame 30 again, re-enable the ik mode on the foot bone, select the shin and upper leg and once again insert a visual rotation and location keyframe, make sure to turn off ik mode again on teh foot and keyframe it. Now go back and foward a frame a few times, you'll notice it now works correctly.

here's an example file showing the issue with the visual keyframes only being inserted correctly on the second attempt: To recreate, go to frame 30, add visual location/rotation to all bones, then turn off the ik mode custom property on the foot bone and keyframe it. then go back a frame and forward a frame to refresh the viewport a few times. You'll notice the position of the visual keyframes is wrong. Now on frame 30 again, re-enable the ik mode on the foot bone, select the shin and upper leg and once again insert a visual rotation and location keyframe, make sure to turn off ik mode again on teh foot and keyframe it. Now go back and foward a frame a few times, you'll notice it now works correctly.

insert keyframe works second time only.blend

1.0 MiB

2023-04-22 18-08-43.mp4

12 MiB

Wayde Moss commented

2023-04-22 20:28:02 +02:00

I couldn't replicate that problem. In the video, I duplicate the leg bones just to have the original pose to compare to. After following the steps, the visual key seemed to match the original pose exactly.

2023-04-22 (19).mp4

1.6 MiB

Julieta Riley commented

2023-04-22 21:06:09 +02:00

which version of blender are you using, and which os?

Julieta Riley commented

2023-04-22 21:13:55 +02:00

maybe try deleting all keys on frame 30 for all bones, and then move the foot in ik mode, keyframe it, and then insert visual rotation and location without first making a copy (just in case that's oddly having an effect).

Julieta Riley commented

2023-04-22 22:07:04 +02:00

just tried in factory mode, still doing it for me.

Julieta Riley commented

2023-04-22 22:09:16 +02:00

ps, I'm not sure how you managed to duplicate those bones in pose mode.

Wayde Moss commented

2023-04-23 17:55:39 +02:00

3.5.0 (bottom right of Blender)

ps, I'm not sure how you managed to duplicate those bones in pose mode.

It's just a small personal operator I wrote. It's not in Blender vanilla. But I did finally get it to work the way the video shows:

Visual Keying does work because the pose at F30 is preserved when IK is disabled. However, the FK pose and IK enabled pose differ so you get that jump as you toggle IK. As you interpolate from F0 to F30, the IK will interpolate to a different pose. At F30, FK is enabled which causes the jump.
Your solution, which simplifies to Apply Visual Pose twice then Keyframe Insert LocRotScale, appears to work but is actually not preserving the initial pose. However, it does lead to the IK and FK poses being the same at F30. Thus, the interpolation from F0 to F30 is smooth. Workflow wise, this seems fine to me.
The "proper" solution, which I don't recommend unless you can make a script to automate the process, is to:

Apply Visual Pose,
Keyframe Insert LocRotScale on the chain
Disable IK (keyed)
Place the Pole on the pole plane (this is the part where its not worth the manual effort). This is the plane where you can freely move the pole and the chain's pose is not affected.

The last step changes the IK pose so its the same as the FK pose which matches the initial pose. If you're doing this by hand and not using a script, it's probably not worth your time when just doing (2) gets you pretty close anyways.

If you're wondering why Apply Visual Pose (once) leads to the FK pose and IK pose differing, despite the IK target and Pole not having been moved at all... I don't know exactly and I don't like any of my guesses. I just know that Apply Visual Pose (twice) makes the last step of (3) redundant, the pole is already on the plane.

3.5.0 (bottom right of Blender) >ps, I'm not sure how you managed to duplicate those bones in pose mode. It's just a small personal operator I wrote. It's not in Blender vanilla. But I did finally get it to work the way the video shows: 1) Visual Keying does work because the pose at F30 is preserved when IK is disabled. However, the FK pose and IK enabled pose differ so you get that jump as you toggle IK. As you interpolate from F0 to F30, the IK will interpolate to a different pose. At F30, FK is enabled which causes the jump. 2) Your solution, which simplifies to Apply Visual Pose twice then Keyframe Insert LocRotScale, appears to work but is actually not preserving the initial pose. However, it does lead to the IK and FK poses being the same at F30. Thus, the interpolation from F0 to F30 is smooth. Workflow wise, this seems fine to me. 3) The "proper" solution, which I don't recommend unless you can make a script to automate the process, is to: - Apply Visual Pose, - Keyframe Insert LocRotScale on the chain - Disable IK (keyed) - Place the Pole on the pole plane (this is the part where its not worth the manual effort). This is the plane where you can freely move the pole and the chain's pose is not affected. The last step changes the IK pose so its the same as the FK pose which matches the initial pose. If you're doing this by hand and not using a script, it's probably not worth your time when just doing (2) gets you pretty close anyways. If you're wondering why Apply Visual Pose (once) leads to the FK pose and IK pose differing, despite the IK target and Pole not having been moved at all... I don't know exactly and I don't like any of my guesses. I just know that Apply Visual Pose (twice) makes the last step of (3) redundant, the pole is already on the plane.

Wayde Moss commented

2023-04-23 19:05:36 +02:00

For the Duplicate bone is pose mode thing, here's the addon. The new bone's rest pose will match the original bone. I use it to speed up adhoc rigging.

posebone_duplicate_world.py

3.6 KiB

Julieta Riley commented

2023-04-23 19:16:53 +02:00

Thanks. I'm wondering if perhaps you have other addons that are hiding the other issue I mentioned (having to insert visual keyframe twice for it to take effect). Perhaps you can try in factory mode.

If you're wondering why Apply Visual Pose (once) leads to the FK pose and IK pose differing, despite the IK target and Pole not having been moved at all... I don't know exactly and I don't like any of my guesses. I just know that Apply Visual Pose (twice) makes the last step of (3) redundant, the pole is already on the plane.

The issue is happening when going from IK to FK, so the pole shouldn't matter, as the visual keyframe is capturing IK so that FK stays in that position (which doesn't use the pole)

Thanks. I'm wondering if perhaps you have other addons that are hiding the other issue I mentioned (having to insert visual keyframe twice for it to take effect). Perhaps you can try in factory mode. > If you're wondering why Apply Visual Pose (once) leads to the FK pose and IK pose differing, despite the IK target and Pole not having been moved at all... I don't know exactly and I don't like any of my guesses. I just know that Apply Visual Pose (twice) makes the last step of (3) redundant, the pole is already on the plane. The issue is happening when going from IK to FK, so the pole shouldn't matter, as the visual keyframe is capturing IK so that FK stays in that position (which doesn't use the pole)

Wayde Moss commented

2023-04-24 01:07:11 +02:00

Here's a video (has audio) explanation based on your video showing that things work properly. Let me know if I misunderstood anything.

a slight term mistake in the video. I said at 1:10: "IK and FK pose are slightly different... the IK chain is going to interpolate to a different [frame]".. i meant "pose" instead of "frame"

Here's a video (has audio) explanation based on your video showing that things work properly. Let me know if I misunderstood anything. a slight term mistake in the video. I said at 1:10: "IK and FK pose are slightly different... the IK chain is going to interpolate to a different [frame]".. i meant "pose" instead of "frame"

2023-04-23 (11).mp4

7.3 MiB

Julieta Riley commented

2023-04-24 12:51:15 +02:00

Why would the FK pose and IK pose be slightly different if the FK pose is visually keyed from the IK pose? And why would IK be going to a different frame than FK on the same frame (it shouldn't matter where it's going, only where it is when visually keyed no?). You've lost me a bit here.

I could understand a slight difference when going from FK to IK, because the pole target would need aligning so the bones in IK match the FK precisely, but when visually keying frame 30 from IK, then turning off the IK should result in the bones remaining precisely where they are (after going back and forward a frame to refresh the viewport), as there's no other influences other than the visually keyed location and rotation.

Why would the FK pose and IK pose be slightly different if the FK pose is visually keyed from the IK pose? And why would IK be going to a different frame than FK on the same frame (it shouldn't matter where it's going, only where it is when visually keyed no?). You've lost me a bit here. I could understand a slight difference when going from FK to IK, because the pole target would need aligning so the bones in IK match the FK precisely, but when visually keying frame 30 from IK, then turning off the IK should result in the bones remaining precisely where they are (after going back and forward a frame to refresh the viewport), as there's no other influences other than the visually keyed location and rotation.

Julieta Riley commented

2023-04-24 13:07:30 +02:00

are we saying that the process of visually keying the bones in IK mode changes the position of the bones on the IK frame, because the new location/rotation is added to the original position? But if that were the case, wouldn't the same happen when visually keying the second time too? Confusing :)

Julieta Riley commented

2023-04-24 13:09:01 +02:00

perhaps the code could be modified to do the visual key twice if that's the only way to get the correct results?

Wayde Moss commented

2023-04-24 18:02:57 +02:00

when visually keying frame 30 from IK, then turning off the IK should result in the bones remaining precisely where they are

This is what's happening. That's why I added a reference circle in the video, to show the bones remained precisely where they were.

To clarify, there are 3 poses:
IK_INITIAL: IK-enabled deformer pose, before any visual keying occurs
FK_POST_VKEY: FK-enabled deformer pose, after visual keying occurs
IK_POST_VKEY: IK-enabled deformer pose, after visual keying occurs

Why would the FK pose and IK pose be slightly different if the FK pose is visually keyed from the IK pose?

IK_INITIAL and FK_POST_VKEY are the same
IK_POST_VKEY and FK_POST_VKEY differ
You have IK enabled from frames F0 to F29 so the IK-enabled rig will interpolate to IK_POST_VKEY. At F30, IK is disabled and you see FK_POST_VKEY. These two poses differ so you get that jump/jitter.

are we saying that the process of visually keying the bones in IK mode changes the position of the bones

Without getting caught up in the details, yes. Visual keying modifies the deformer bones which generally (not always) modifies the IK pose, resulting in IK_POST_VKEY.

But if that were the case, wouldn't the same happen when visually keying the second time too? Confusing :)

It is confusing and has caused me the same problems too. The 2nd time you visual key, the IK pole bone is on the IK pole plane, defined by the pole_axis and ik_axis (see link for visual). So Blender's IK solver doesn't have to solve or do anything and so IK_POST_VKEY==FK_POST_VKEY==IK_INITIAL. (math: https://blender.stackexchange.com/questions/19754/how-to-set-calculate-pole-angle-of-ik-constraint-so-the-chain-does-not-move/19755#19755 ) I'll look into Blender's IK solver but that link is a pretty good guess and, when I bake IK from FK, has yet to fail or result in not preserving the pose. Contrary to the guess, Blender's IK solver does allow the chain to not exactly point at the pole which is why IK_POST_VKEY is not the same as IK_INITIAL.

perhaps the code could be modified to do the visual key twice if that's the only way to get the correct results?

That would work for IK. It would mess up offset based constraints due to applying a double transform (ChildOf, CopyLoc w/ Offset, etc). It would also mess up IK that uses offset-constraints on any bone on the chain.

But again, "correct results" is to visual key once. But "useful for smooth interpolation across IK/FK changes w/ minimal work" means visual keying twice. (For more general rigs, to account for offset-based constraints, we would have to vkey/bake FK from IK, then IK from FK, then FK from IK again, all to avoid double transforms on offset based constraints)

(If you don't need me to look into Blender's IK Solver for the exact math, let me know. I've been there before and all I remember is being confused)

> when visually keying frame 30 from IK, then turning off the IK should result in the bones remaining precisely where they are This is what's happening. That's why I added a reference circle in the video, to show the bones remained precisely where they were. To clarify, there are 3 poses: IK_INITIAL: IK-enabled deformer pose, before any visual keying occurs FK_POST_VKEY: FK-enabled deformer pose, after visual keying occurs IK_POST_VKEY: IK-enabled deformer pose, after visual keying occurs >Why would the FK pose and IK pose be slightly different if the FK pose is visually keyed from the IK pose? IK_INITIAL and FK_POST_VKEY are the same IK_POST_VKEY and FK_POST_VKEY differ You have IK enabled from frames F0 to F29 so the IK-enabled rig will interpolate to IK_POST_VKEY. At F30, IK is disabled and you see FK_POST_VKEY. These two poses differ so you get that jump/jitter. > are we saying that the process of visually keying the bones in IK mode changes the position of the bones Without getting caught up in the details, yes. Visual keying modifies the deformer bones which generally (not always) modifies the IK pose, resulting in IK_POST_VKEY. > But if that were the case, wouldn't the same happen when visually keying the second time too? Confusing :) It is confusing and has caused me the same problems too. The 2nd time you visual key, the IK pole bone is on the IK pole plane, defined by the pole_axis and ik_axis (see link for visual). So Blender's IK solver doesn't have to solve or do anything and so IK_POST_VKEY==FK_POST_VKEY==IK_INITIAL. (math: https://blender.stackexchange.com/questions/19754/how-to-set-calculate-pole-angle-of-ik-constraint-so-the-chain-does-not-move/19755#19755 ) I'll look into Blender's IK solver but that link is a pretty good guess and, when I bake IK from FK, has yet to fail or result in not preserving the pose. Contrary to the guess, Blender's IK solver does allow the chain to not exactly point at the pole which is why IK_POST_VKEY is not the same as IK_INITIAL. > perhaps the code could be modified to do the visual key twice if that's the only way to get the correct results? That would work for IK. It would mess up offset based constraints due to applying a double transform (ChildOf, CopyLoc w/ Offset, etc). It would also mess up IK that uses offset-constraints on any bone on the chain. But again, "correct results" is to visual key once. But "useful for smooth interpolation across IK/FK changes w/ minimal work" means visual keying twice. (For more general rigs, to account for offset-based constraints, we would have to vkey/bake FK from IK, then IK from FK, then FK from IK again, all to avoid double transforms on offset based constraints) (If you don't need me to look into Blender's IK Solver for the exact math, let me know. I've been there before and all I remember is being confused)

👍 1

Julieta Riley commented

2023-04-24 19:38:56 +02:00

OK, thanks for the detailed explanation. I think I get it....when doing a visual keyframe on IK, the FK is keyed in the IK position, but the IK result then changes, resulting in them no longer being aligned when switching.

👍 1

Julieta Riley commented

2023-04-24 19:45:14 +02:00

Perhaps always forcing the IK solver to point exactly at the pole would be a possible resolution.

Contrary to the guess, Blender's IK solver does allow the chain to not exactly point at the pole which is why IK_POST_VKEY is not the same as IK_INITIAL

Anyway, I won't take any more of your time, it's getting a bit beyond my understanding now. Thanks.

Perhaps always forcing the IK solver to point exactly at the pole would be a possible resolution. >Contrary to the guess, Blender's IK solver does allow the chain to not exactly point at the pole which is why IK_POST_VKEY is not the same as IK_INITIAL Anyway, I won't take any more of your time, it's getting a bit beyond my understanding now. Thanks.

Richard Antalik commented

2023-04-27 01:39:56 +02:00

Not sure I would say, that this works as expected from user perspective, but the behavior is to be expected. I am not too familiar with rigging and to fix this there would have to be system that manages relations and data being set by user (which may also result in different limitations and problems), so current behavior may be actually better.

Long story short, inserting keyframe does not actually set any position (as far as bones in IK chain know, nothing has ever changed apart from bone.003 being moved), so disabling IK constraint would read data it had before keyframe was inserted. This has been said here, so not sure if I simplified the explanation in any way.

Technically and practically, this is not a bug, so I will close this report.

Not sure I would say, that this works as expected from user perspective, but the behavior is to be expected. I am not too familiar with rigging and to fix this there would have to be system that manages relations and data being set by user (which may also result in different limitations and problems), so current behavior may be actually better. Long story short, inserting keyframe does not actually set any position (as far as bones in IK chain know, nothing has ever changed apart from bone.003 being moved), so disabling IK constraint would read data it had before keyframe was inserted. This has been said here, so not sure if I simplified the explanation in any way. Technically and practically, this is not a bug, so I will close this report.

Richard Antalik closed this issue

2023-04-27 01:39:58 +02:00

Blender Bot added

and removed

labels 2023-04-27 01:40:00 +02:00

Julieta Riley commented

2023-04-27 17:04:46 +02:00

OK thanks. I'll make a feature request then so that the viewport always displays the actual position of thing.