Cannot key bone relations (specifically, inherit location, rotation scale) on a per action basis #46203

New Issue

Thibaud de Souza · 2015-09-22T07:51:23+02:00

Thibaud de Souza commented

2015-09-22 07:51:23 +02:00

System Information
Windows 8.1 (system details irrelevant to reported issue)

Blender Version
Broken: 2.76 release candidate

Short description of error
When keying inherit rotation, location, scale, my expectation is that created key-frames should be action-specific. However it appears that created key-frames are global to the scene. This is a problem with uses cases where the animator want a bone to inherit rotation or other property only for some actions but not others.

Exact steps for others to reproduce the error

Create an armature with two connected bones A-B
Select child bone (B) and insert keyframe for 'inherit location' by hovering over checkbox and pressing "i".
Open Graph Editor and verify that a keyframe has been created.
Duplicate action in action editor.
Uncheck inherit rotation and replace key-frame.
In Graph Editor verify that keyframe has been corrected applied.
Go back to original action and verify that only one set of key-frames is used for all actions.

Expected result: bone relation keyframes should be created on a per-action basis.
Actual result: bone relation keyframes are created on a per-scene basis.

Note: you may want to animate the parent bone to verify that transform property inheritance is not key-framed on a per action basis.

**System Information** Windows 8.1 (system details irrelevant to reported issue) **Blender Version** Broken: 2.76 release candidate **Short description of error** When keying inherit rotation, location, scale, my expectation is that created key-frames should be action-specific. However it appears that created key-frames are global to the scene. This is a problem with uses cases where the animator want a bone to inherit rotation or other property only for some actions but not others. **Exact steps for others to reproduce the error** 1. Create an armature with two connected bones A-B 2. Select child bone (B) and insert keyframe for 'inherit location' by hovering over checkbox and pressing "i". 3. Open Graph Editor and verify that a keyframe has been created. 4. Duplicate action in action editor. 5. Uncheck inherit rotation and replace key-frame. 6. In Graph Editor verify that keyframe has been corrected applied. 7. Go back to original action and verify that only one set of key-frames is used for all actions. Expected result: bone relation keyframes should be created on a per-action basis. Actual result: bone relation keyframes are created on a per-scene basis. Note: you may want to animate the parent bone to verify that transform property inheritance is not key-framed on a per action basis.

Thibaud de Souza commented

2015-09-22 07:51:23 +02:00

Changed status to: 'Open'

Thibaud de Souza commented

2015-09-22 07:51:23 +02:00

Added subscriber: @eelstork

Bastien Montagne commented

2015-09-22 09:05:38 +02:00

Added subscribers: @JoshuaLeung, @mont29

Bastien Montagne commented

2015-09-22 09:05:38 +02:00

@JoshuaLeung is it expected that those settings do not get added to actions? and why? In fact, are they supposed to be animatable at all?

Joshua Leung commented

2015-09-22 12:04:59 +02:00

Changed status from 'Open' to: 'Archived'

Joshua Leung closed this issue

2015-09-22 12:04:59 +02:00

Joshua Leung self-assigned this 2015-09-22 12:04:59 +02:00

Joshua Leung commented

2015-09-22 12:04:59 +02:00

There's no bug here.

Those particular properties are actually on the armature/obdata level instead of ob/pose level.
The "Action Editor" context (not to be confused with the Dope Sheet) only operates on object level. Animations on any other entities (nodes, materials, lamps, etc.) are not able to be viewed/assigned/edited from there.
I'm not sure what action you're duplicating in step 4 - based on the steps provided, there shouldn't even be an action active/visible in the Action Editor at that point (see 1, due to 2)

@mont29 While we probably don't want to animate these, these still need to be tagged as animateable so that the drivers can work on them.

There's no bug here. 1) Those particular properties are actually on the armature/obdata level instead of ob/pose level. 2) The "Action Editor" context (not to be confused with the Dope Sheet) only operates on object level. Animations on any other entities (nodes, materials, lamps, etc.) are not able to be viewed/assigned/edited from there. 3) I'm not sure what action you're duplicating in step 4 - based on the steps provided, there shouldn't even be an action active/visible in the Action Editor at that point (see 1, due to 2) @mont29 While we probably don't want to animate these, these still need to be tagged as animateable so that the drivers can work on them.

Thibaud de Souza commented

2015-09-22 12:47:48 +02:00

The fact that said properties are on armature/obdata level, that IS the bug. The separation that you refer to (obdata vs pose) would be alphabet soup to me if I didn't have a programming background. "Bug": software doesn't behave as the user expect. User expectations often diverge from the designer's.

Currently I have animations that require setting relations one way, other animations require setting the flag another way. The only viable workaround for me is to work in a different file (I cannot duplicate the armature since this would confuse my pipeline).

I don't know how to align my expectations to yours. "Almost everything" in Blender is animatable. So, property X defined as substate of an object is animatable. How are we to know, or decide, whether X should be obdata or pose? Even more baffling when X is a bone property.

I understand that provided steps may not create an action since the keying happens at another level and sorry for the confusion here.

I will ask on the Q&A site to see if I can find a better workaround. Am I to understand that I should formulate a feature request based on my use case?

Sorry but if you invalidate this based on your understanding of blender internals you leave the impression that the user (me!) is a blunt tool used to detect bugs.

The fact that said properties are on armature/obdata level, that IS the bug. The separation that you refer to (obdata vs pose) would be alphabet soup to me if I didn't have a programming background. "Bug": software doesn't behave as the user expect. User expectations often diverge from the designer's. Currently I have animations that require setting relations one way, other animations require setting the flag another way. The only viable workaround for me is to work in a different file (I cannot duplicate the armature since this would confuse my pipeline). I don't know how to align my expectations to yours. "Almost everything" in Blender is animatable. So, property X defined as substate of an object is animatable. How are we to know, or decide, whether X should be obdata or pose? Even more baffling when X is a bone property. I understand that provided steps may not create an action since the keying happens at another level and sorry for the confusion here. I will ask on the Q&A site to see if I can find a better workaround. Am I to understand that I should formulate a feature request based on my use case? Sorry but if you invalidate this based on your understanding of blender internals you leave the impression that the user (me!) is a blunt tool used to detect bugs.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cannot key bone relations (specifically, inherit location, rotation scale) on a per action basis #46203