"Whole Character" keying set not working properly with autokey enabled #91941

New Issue

Corrado Piscitelli · 2021-10-04T11:47:18+02:00

2021-10-04 11:47:18 +02:00

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

Open attached file or create a new armature with more than one bone, add a few bone properties to each bone.
Enable autokey and set "Whole Character" as the keying set.
Move one bone and you can see that only the transform values are keyed.
If you enable "Only active keying set" in the autokey options and move the bone, a keyframe for the custom properties of the selected bones, at least, will be created, but other bones and properties will be unaffected.
bugreport.blend

**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** - Open attached file or create a new armature with more than one bone, add a few bone properties to each bone. - Enable autokey and set "Whole Character" as the keying set. - Move one bone and you can see that only the transform values are keyed. - If you enable "Only active keying set" in the autokey options and move the bone, a keyframe for the custom properties of the selected bones, at least, will be created, but other bones and properties will be unaffected. [bugreport.blend](https://archive.blender.org/developer/F10761095/bugreport.blend)

Corrado Piscitelli commented

2021-10-04 11:47:18 +02:00

Added subscriber: @CorradoPiscitelli

Corrado Piscitelli commented

2021-10-04 11:48:08 +02:00

Added subscriber: @icappiello

Corrado Piscitelli commented

2021-10-04 12:52:33 +02:00

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.

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.

Pratik Borhade commented

2021-10-04 18:03:40 +02:00

Added subscriber: @PratikPB2123

Ivan Cappiello commented

2021-10-05 13:10:08 +02:00

Added subscriber: @LucianoMunoz

Ivan Cappiello commented

2021-10-05 13:10:08 +02:00

@LucianoMunoz what's your opinion on this issue?

Germano Cavalcante commented

2021-10-06 17:56:17 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2021-10-06 17:56:17 +02:00

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:

If you enable "Only active keying set" in the autokey options, a keyframe for the custom properties of the selected bones, at least, will be created, but other bones and properties will be unaffected

I have enabled Only active keying set, but no keyframe is created.
Did I get something wrong?

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: > If you enable "Only active keying set" in the autokey options, a keyframe for the custom properties of the selected bones, at least, will be created, but other bones and properties will be unaffected I have enabled `Only active keying set`, but no keyframe is created. Did I get something wrong?

Corrado Piscitelli commented

2021-10-06 18:06:44 +02:00

In #91941#1231568, @mano-wii wrote:
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:

If you enable "Only active keying set" in the autokey options, a keyframe for the custom properties of the selected bones, at least, will be created, but other bones and properties will be unaffected

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".

> In #91941#1231568, @mano-wii wrote: > 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: >> If you enable "Only active keying set" in the autokey options, a keyframe for the custom properties of the selected bones, at least, will be created, but other bones and properties will be unaffected > 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".

Luciano Muñoz Sessarego commented

2021-10-07 04:29:23 +02:00

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.

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.

Ivan Cappiello commented

2021-10-07 15:04:28 +02:00

In #91941#1231688, @LucianoMunoz wrote:
Like i dont use whole character, but I "whole character (only selected bones)" because its the only one that makes sense at all.

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

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.

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.

> In #91941#1231688, @LucianoMunoz wrote: > Like i dont use whole character, but I "whole character (only selected bones)" because its the only one that makes sense at all. > 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 > 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. 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.

Germano Cavalcante commented

2021-10-07 17:06:33 +02:00

This appears to be a bug in the transform operator.
But I'm still not sure what the expected behavior should be after moving.

This appears to be a bug in the transform operator. But I'm still not sure what the expected behavior should be after moving.

Corrado Piscitelli commented

2021-10-07 18:18:46 +02:00

In #91941#1232026, @mano-wii wrote:
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.

> In #91941#1232026, @mano-wii wrote: > 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.

Germano Cavalcante commented

2021-10-07 21:46:19 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Germano Cavalcante commented

2021-10-07 21:46:19 +02:00

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.

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.

Ivan Cappiello commented

2021-10-08 11:18:31 +02:00

In #91941#1232155, @mano-wii wrote:
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:

let's say you have a cube and have a keyframe inserted manually on location (no key on roations)
enable auto key with "rotation" as keying set + only active keying set
move the cube around

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 #91941#1232155, @mano-wii wrote: > 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: 1) let's say you have a cube and have a keyframe inserted manually on location (no key on roations) 2) enable auto key with "rotation" as keying set + only active keying set 3) move the cube around 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

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

"Whole Character" keying set not working properly with autokey enabled #91941