Different results when keyframing visual transforms and applying transforms manually on IK constraint #76791
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#76791
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Blender Version
Broken: v2.82a and blender-2.90-f9d0f59bed4d-windows64
Working: never, tested with 2.75a and that even shows this issue.
Short description of error
There is a difference between using the insert keyframe menu to insert Visual LocRot compared to if you Apply Visual Transform to Pose and then use normal keyframe LocRot.
Exact steps for others to reproduce the error
keyframe-visual-root.blend
Using Keyframe Menu (broken):
2020-05-15 11-24-58.mkv
Iterating Keyframe Insertion (Semi-working):
2020-05-15 12-02-32.mkv
Manually applying transforms to Pose (working):
2020-05-15 11-29-47.mkv
Added subscriber: @sok0
#81302 was marked as duplicate of this issue
Added subscriber: @mano-wii
Changed status from 'Needs Triage' to: 'Needs User Info'
Could you provide a simple .blend file demonstrating the problem?
Also videos should be used to quickly describe the problem and not as steps to reproduce the problem.
A guideline for making a good bug report can be found at https://wiki.blender.org/wiki/Process/Bug_Reports
IK_constraint_keyframe.blend
Armature was keyframed with Visual LocRot
Armature.001 was keyframed after using Apply Visual Transform to Pose
Expected result should be the same. Instead the Visual LocRot does not properly keyframe the pose position of the IK constraint.
Changed status from 'Needs User Info' to: 'Needs Triage'
Added subscriber: @dr.sybren
@sok0 Please test with older versions of Blender to see which version of Blender still worked properly. This will help developers in finding the root cause of the issue.
For videos, please use h.264 in an MP4 container, so that they can be directly played back in the browser. Re-encoding them after the recording will make them much smaller (I have them stored at a 1/35th the file size on my machine after locally re-encoding them).
Changed status from 'Needs Triage' to: 'Confirmed'
I tested with few older versions. As you go back in the versions it never seemed to work and at some point the Apply Visual Transform to Pose operation stops working as well so it's not possible to test further.
2.79b not working, same behavior
2.77a not working, same behavior
2.60 not working, apply pose as rest pose doesn't work either
Blender 2.5 doesn't work and apply pose as rest pose doesn't work either
got it
@sok0 thanks for testing. I did some digging, and it's due to the way visual keying is implemented in Blender (
visualkey_can_use()inkeyframing.c). It will fall back to regular keying when there is no parent bone and no constraint on the bone either. This "no constraint" check does not consider IK-chains on child bones, which is why the root bone of the chain isn't keyed correctly. This has been pretty much been the situation since the code was ported to Blender 2.50 (6343d4e233) 11 years ago.This can be resolved by simply always performing visual keying when a user chooses that from the keying set menu, regardless of whether there are any constraints. This would be a bigger change than is currently possible for Blender 2.83, though. First and foremost, this change in behaviour should be discussed with more animators, which I'll do.
@sok0 Is visual keying part of your day-to-day workflow? Or is it just something you're trying out?
@dr.sybren I came across the bug on a side project to write my own IK solver algorithm and wanted to compare my results to what Blender produced. I was creating an animation for a robot arm and wanted to see what the difference would be between joint interpolated motion and Cartesian interpolated motion of the end effector. Joint interpolated motion required visual keying of the start and ending frame rotations of each joint while Cartesian interpolation used the IK constraint and only keyed the IK target then letting the IK solver calculate new joint rotations on every frame. When I was not getting the expected results for the joint interpolated motion I realized there might be a bug and traced it back to visual keying. Hopefully that answers the question, let me know if there is any other way I can help.
Added subscribers: @wbmoss_dev, @Hjalti, @BassamKurdali
The people I have talked with (@BassamKurdali , @Hjalti, @wbmoss_dev) have all expressed that they perceive Visual Keying as buggy, and that this is why they don't use it in their day-to-day workflow. It seems that Visual Keying, even though the idea looks nice, needs a redesign to become usable in practice.
As such, I'll mark this down as a known issue. In time we can create a design task and make this work properly.
Added subscribers: @netricsa, @iss
Added subscriber: @0xb
was there a design task created for this? Just wondering how it's going.
@dr.sybren you mentioned above that the people you spoke with don't use visual keying. I'm wondering, what's the alternative if you're wanting to transition from IK to FK?
I'm using visual keying to key the position of the bones post IK constraints, so that when I disable the IK constraint the FK bones will remain in the same location. Really interested to know which alternative method is possible.
actually, I think I realise now they must be applying visual transform to pose and then inserting a standard keyframe (not visual), as I now understand that all 'apply visual transform to pose' does, is move the selected bones to the constrained position they're in, so that when you insert standard location rotation (not visual) keyrframes, the keyframes are created in the visual location. Very odd how keyframing this way works, but inserting a visual location rotation keyframe doesn't.
Perhaps instead of a full redesign (which appears to not be happening based on the 3 year elapsed time), just make inserting a visual location/rotation keyframe do the following:
apply visual transform to pose
insert standard location rotation keyframe.
Wow this has been around a while, and I am in agreement at least that I am not clear at all now on why/what visual keying is doing if it isn't applying the visual transform and keying that.
I think now is a good time to see if a small change can make this intuitive to use and we can update the documentation as well.
With what I said in my earlier comment in mind, this might be fairly doable to address for Blender 4.0.
A few notes while I'm investigating this:
Diving into history
The behaviour (of not visual keying when requested) can be traced back to the behaviour of the
visualkey_can_usefunction (as I described above). I did some digging to figure out more about the underlying design choices..876cfc837e("Visual Keying refactor") back in 2007 refactored the visual keying system. The author writes:Note that Ipo-curves where the precursor to F-curves.
Designed workflow
So it would seem that the design goal was to support a workflow where animators always have visual keying preference enabled, which would then automatically decide when and where to use visual keys. This matches the current (4.0-alpha) description of the preference ("Use Visual keying automatically for constrained objects").
This workflow can still be supported, and I suspect that it will be enough to extend the
visualkey_can_usefunction to also detect constraints that influence the current bone but are defined on children (i.e. IK constraints).That workflow vs. explicitly asking for visual keys
I do see a difference between the above workflow, and a workflow where you press
Iand explicitly choose "Visual Rotation", "VisualLocation", etc. In that case I feel that Blender should just do what you asked it to, and use visual keying regardless of whether there's a constraint or not.
More possible confusion
Finally there is another source of possible confusion. Inserting a visual key only does that: it stores a set of keys in the Action. What it does not do, is re-evaluate the animation data. The result is that after visually keying the rotation, the bone's actual rotation properties are still set to their previous value. In the example blend file, this means it's set to the quaternion (1, 0, 0, 0). Changing the scene frame will do this, and you'll see that the rotation properties are then set to the visually kceyed values.
If Blender would re-evaluate after setting a visual key, it means that you can no longer change the rotation of two bones, and visually key them one after the other -- the first would be keyed, but it would trigger a re-evaluation and the second bone would pop back to its previous orientation. Of course we could try to limit this to the keyed properties, but that would mean that drivers, constraints, etc. that depend on those properties are themselves not re-evaluated, which would IMO be even more confusing to work with.
In the end I think Blender's current behaviour is acceptable, even though it can cause some confusion at first. At least it is not a destructive operation, in that it doesn't discard any unkeyed changes until you actually change the scene frame.