Page MenuHome

Update issue with visual keyframing
Closed, ArchivedPublic

Description

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…)???

Details

Type
Bug

Event Timeline

Bastien Montagne (mont29) set Type to Bug.
Bastien Montagne (mont29) created this task.
Bastien Montagne (mont29) raised the priority of this task from to Needs Triage by Developer.

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

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)?

Brecht Van Lommel (brecht) triaged this task as Normal priority.Jan 22 2014, 3:36 PM

@Bastien Montagne (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.

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 (mont29) closed this task as Archived.Aug 20 2014, 3:45 PM

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