"Whole Character" keying set not working properly with autokey enabled #91941
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
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
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
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
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
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
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
8 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#91941
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
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?
System Information
Operating system: macOS-11.5.2-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 575X OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.6.20
Blender Version
Broken: version: 2.93.4, branch: master, commit date: 2021-08-31 09:23, hash:
b7205031ce
Worked: (newest version of Blender that worked as expected)
Short description of error
Using the keying set "Whole character" with autokey enabled creates a keyframe only for the selected bone and not for all bones and properties.
Exact steps for others to reproduce the error
bugreport.blend
Added subscriber: @CorradoPiscitelli
Added subscriber: @icappiello
to further clarify the issue, there is a "Whole character (selected bones only)" keying set that works, with autokey enabled, exactly like the "Whole character" one.
The expected behaviour should be to create a keyframe automatically exactly like pressing the "i" key. Right now this doesn't happen for the "Whole character" set.
I have checked some previous versions up to blender 2.79b and this seems to be a consistent problem, so probably it's a choice by design or something nobody noticed until now.
Added subscriber: @PratikPB2123
Added subscriber: @LucianoMunoz
@LucianoMunoz what's your opinion on this issue?
Added subscriber: @mano-wii
The behavior when inserting keys should correspond to typing {key i}.
If that's not the behavior, then I'd say it's a bug.
I'm having a hard time understanding this point:
I have enabled
Only active keying set
, but no keyframe is created.Did I get something wrong?
I explained that poorly.
What I meant is "if you move around the bone with 'only active keying set' enabled, it will insert a key frame only to that bone but at least it will include the bone's custom properties if present".
Oh i have some opinions.
Like i dont use whole character, but I "whole character (only selected bones)" because its the only one that makes sense at all.
but to me "i" or insert key should obey keying set
but autokey should always obey just the "available channels", not the specified keying set.
So, since there's a separate option for that you should agree that if "whole character" is kept as keying set should act different than "selected bones only". I mean that if there's a difference between the two there should be for some reason
Here we have an option (and always been as far as I can remember) to force the auto key to use specified keying set, my question is not if such option should exist, but what should be the expected behavior for auto-key with keying set restriction.
I know a couple of animation directors that like to have key poses on all controls (in a 2D like way, where a key is a complete drawing). So could agree with you in a general sense of what could be better to do, but I'd not restrict animator's choices on a single method.
That said, even in favor of it, i have some concerns about having the auto-key obey to "whole character" keying set since it could potentially affect performance on complex characters with lots of keyable properties since each move should reflect in inserting thousands of keys each time.
Anyway can't see a specific reason for having that keying set available in auto-key and not using it.
This appears to be a bug in the transform operator.
But I'm still not sure what the expected behavior should be after moving.
Since all other keying sets are meant to be used only on selected bones, "Whole character" is the only one that should work differently, as the name implies.
Basically, moving the bone around should be like using the "i" Key, since that's what happens with other keying sets.
Changed status from 'Needs Triage' to: 'Confirmed'
I'm not familiar with this area, but one thing that needs to be analyzed is whether it's really necessary to add keyframes to custom properties since only the transform parameters have changed.
Perhaps the error is in the selected objects and not the others.
@mano-wii The problem is quite more easy to inspect and approach.
By design, when using auto key + a specified keying set + Only active keying set option all keys are added according to specified keying set.
let's take this example:
result:
the auto key insert a keyframe on rotation but NOT on location (even if location was keyed)
This demonstrates that the only active keying set option overrides the standard keying behavior forcing the auto key to do what is explicitly set in the keying set.
Now the "whole Character" keying set is made explicitly to keyframe all the keyable values and properties on every bone in the character. That's what is made for. So if the auto key should respect the keying set, should keyframe all bones and properties. This is the only consistent and expectable behavior from an user pov.
We could debate if "whole character" should be an option or not for auto key, but as long as it's there should act consistently with all other keying sets
In Blender 3.3.0 we have the same behaviour. I have setup my character with keyframes on only the channels I will be animating. The option to only insert available is turned on in preferences and it behaves as expected.
Keying Set is "Whole Character" and Auto-Record is set to "Only Active Keying Set". If I move a controller the auto-record does as expected and inserts KF's on only the available channels (for the selected controller only) - but in order for the Whole Character to be keyframed I have to press "i" shortcut, which makes the auto record function pretty useless, having to press i on each new frame makes auto recording redundant.
I need this functionality during the blocking stage of the animation, where I make the various poses in the timeline in a Constant interpolation - for each frame, having the ability to KF all the active channels automatically makes it so that when we later switch to Bezier interpolation there won't be weird sliding of the limbs since they have all been keyframed at once.
TL;DR - Auto Record should respect the keying set on top of everything else - right now it doesn't matter if you check the Only Active Keying set, as it doesn't do anything new, it just inserts on the available channels and not on "Whole Character"
Of course I can just press "i" on each new pose, but that defeats the purpose of auto-recording.
It does seem bizarre that the whole character doesn't get keyed on auto-key with the
Whole Character
keying set. Particularly given the existence of theWhole Character (Selected Bones Only)
keying set.I think it would make a lot more sense for auto-keying to always key the same things that would be keyed with the
i
hotkey (aside from the influence of auto-key-specific options likeOnly Insert Available
). That presents a simple predictable mental model for users, and also gives more workflow flexibility. People who want the current behavior can simply useWhole Character (Selected Bones Only)
, and people who want to auto-key the whole character can useWhole Character
.Having said that, the current behavior does allow for a "use
i
to key the whole character, and manipulate to only key selected" workflow. Not sure if anyone finds that meaningfully useful, though. Seems pretty niche to me...?But if we do need to accommodate that, we could reshuffle the current auto-key options to be more like a set of available auto-key modes. Maybe something like, "Key Transforms", "Key Keying Set", "Key Keying Set (Selected Items Only)". (But with better names, ha ha.) Then
Whole Character (Selected Bones Only)
would become redundant, and could be removed.I also have a gut feeling that we just need to revisit how users specify keying and auto-keying behavior in general. The current set of options feel simultaneously too complex/confusing and not flexible enough.
There's a lot of issues with the autokeying system. I've grouped them together at https://wiki.blender.org/wiki/Modules/Animation-Rigging/Weak_Areas#Auto-keying