Update issue with visual keyframing #38301

New Issue

Bastien Montagne · 2014-01-21T09:42:11+01:00

Bastien Montagne commented

2014-01-21 09:42:11 +01:00

System Information
Operating system and graphics card
Irrelevant

Blender Version
Broken: current master, 2.69 release
Worked: ???

Short description of error
Keyed values are not updated when visual-keyframing, you have e.g. to change current frame to get correct ones.

Exact steps for others to reproduce the error

With default scene, add e.g. a Copy Rotation constraint to the cube with camera as target.
Keyframe visual rotation of the cube (I → Visual Rotation).
Note how rotation value of the cube (in Properties) are now yellow (i.e. keyed), but are still showing zero rotation values.
Note how the cube goes back to its default rotation when setting constraint's influence to zero.
Now, change current frame, and everything is fixed.

Dev notes: I do not understand what happens here, end of ANIM_apply_keyingset() (in keyingsets.c) seems to be doing the needed updates (DAG tag, WM notifiers…)???

**System Information** Operating system and graphics card Irrelevant **Blender Version** Broken: current master, 2.69 release Worked: ??? **Short description of error** Keyed values are not updated when visual-keyframing, you have e.g. to change current frame to get correct ones. **Exact steps for others to reproduce the error** * With default scene, add e.g. a Copy Rotation constraint to the cube with camera as target. * Keyframe visual rotation of the cube (I → Visual Rotation). * Note how rotation value of the cube (in Properties) are now yellow (i.e. keyed), but are still showing zero rotation values. * Note how the cube goes back to its default rotation when setting constraint's influence to zero. * Now, change current frame, and everything is fixed. Dev notes: I do not understand what happens here, end of ANIM_apply_keyingset() (in keyingsets.c) seems to be doing the needed updates (DAG tag, WM notifiers…)???

Bastien Montagne commented

2014-01-21 09:42:11 +01:00

Changed status to: 'Open'

Bastien Montagne commented

2014-01-21 09:42:11 +01:00

Added subscriber: @mont29

blender-admin commented

2014-01-21 09:42:11 +01:00

#38484 was marked as duplicate of this issue

Joshua Leung commented

2014-01-21 10:44:38 +01:00

Added subscriber: @JoshuaLeung

Joshua Leung commented

2014-01-21 10:44:38 +01:00

There is one thing that ANIM_apply_keyingset() doesn't do here: it doesn't actually change the frame or tag the animdata on the object(s) affected as needing their animation recalculated (ADT_RECALC_ANIM). This is what would be needed to ensure that the updated values get flushed from the anim channels onto the properties. However, doing so, you risk destroying any unkeyed properties (yes this can happen, even when using a keyingset - e.g. if separate keyingsets need to be used).

Bastien Montagne commented

2014-01-21 10:50:23 +01:00

We could do that at least when kflag2 has the INSERTKEY_MATRIX flag set? Not ideal either, but better than doing it systematically… I don’t think non-visual keyframing can ever generate new values (different from current ones of keyed props)?

We could do that at least when `kflag2` has the `INSERTKEY_MATRIX` flag set? Not ideal either, but better than doing it systematically… I don’t think non-visual keyframing can ever generate new values (different from current ones of keyed props)?

Bastien Montagne commented

2014-02-04 18:46:28 +01:00

Added subscriber: @GaiaClary

Bastien Montagne commented

2014-02-04 18:46:28 +01:00

◀ Merged tasks: #38484.

Joshua Leung was assigned by Sergey Sharybin

2014-02-17 10:53:31 +01:00

Sergey Sharybin commented

2014-02-17 10:53:31 +01:00

Added subscriber: @Sergey

Sergey Sharybin commented

2014-02-17 10:53:31 +01:00

@JoshuaLeung, mind looking into the report?

Joshua Leung commented

2014-03-10 03:44:14 +01:00

@mont29: After pondering this a bit more, I think we'll still end up having some problems with situations where users are still manually applying different keying sets to keyframe various bones within the same armature. Some of these they'll keyframe normally, but a few of these will be done using visual keying.

The problem will occur since if they keyframe those bones in the wrong order (i.e. the visual keying ones first), the visual keyingsets will fire off the update, which will force the animation to be written over the unkeyed values on the other channels.

I'd expect this to be pretty rare (and if any animator is really dealing with such a tricky mix, they should've turned to setting up a custom keying set which does this for them automatically long ago), but past experience suggests that it's likely that at least 1-2 cases will eventually pop up by the time we put out a release/test build with this.

@mont29: After pondering this a bit more, I think we'll still end up having some problems with situations where users are still manually applying different keying sets to keyframe various bones within the same armature. Some of these they'll keyframe normally, but a few of these will be done using visual keying. The problem will occur since if they keyframe those bones in the wrong order (i.e. the visual keying ones first), the visual keyingsets will fire off the update, which will force the animation to be written over the unkeyed values on the other channels. I'd expect this to be pretty rare (and if any animator is really dealing with such a tricky mix, they should've turned to setting up a custom keying set which does this for them automatically long ago), but past experience suggests that it's likely that at least 1-2 cases will eventually pop up by the time we put out a release/test build with this.

Bastien Montagne commented

2014-03-10 22:58:48 +01:00

Well… looks like a "trade of" case, then?

Agree it’s probably worse to have unwanted update here, than missing update, even if later case is more frequent than former one. Guess we can call it a "known limitation"…

Well… looks like a "trade of" case, then? Agree it’s probably worse to have unwanted update here, than missing update, even if later case is more frequent than former one. Guess we can call it a "known limitation"…

Bastien Montagne commented

2014-08-20 15:45:47 +02:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2014-08-20 15:45:47 +02:00

Bastien Montagne commented

2014-08-20 15:45:47 +02:00

Time to close this as known limitation/TODO I think… ;)

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

Update issue with visual keyframing #38301