Page MenuHome

Fix T87173: wrong Auto-Snap in animation editors
ClosedPublic

Authored by Germano Cavalcante (mano-wii) on Aug 17 2021, 12:03 PM.

Details

Summary

This was partially broken with rBde9ea94fc6f8: Transform: Deduplicate time snap code.

The Frame Step and Second Step snapping options were working as if
they were Nearest Frame and Nearest Second respectively in the
Dope Sheet and NLA editors.

In the Graph Editor the problem was more serious:
"Second Step: ... The keyframe itself moves along as though in snapping
were active at all, while its handles 'stay behind' until it reaches
the next second boundary, at which point the teleport handles to
'catch up'".

Also, for the Graphic Editor, snap inversion (by pressing Ctrl) would
trigger incremental snapping (which should not be supported).

The snapping code for these modes was spread across the transform
mode code and recalcData of each data type. Therefore, create a
unified snapping code for these options so that all issues are fixed in
one place.

Diff Detail

Repository
rB Blender
Branch
tmp (branched from master)
Build Status
Buildable 16486
Build 16486: arc lint + arc unit

Event Timeline

Philipp Oeser (lichtwerk) requested review of this revision.Aug 17 2021, 12:03 PM
Philipp Oeser (lichtwerk) created this revision.

The idea behind rBde9ea94fc6f8, is to join all snap types in the doAnimEdit_SnapFrame function.
This would be ideal as this function is called for different modes.
Isolating SACTSNAP_TSTEP and SACTSNAP_STEP in a specific mode only seems to work around the problem.
Could the problem be inside snapFrameTransform?

The idea behind rBde9ea94fc6f8, is to join all snap types in the doAnimEdit_SnapFrame function.
This would be ideal as this function is called for different modes.
Isolating SACTSNAP_TSTEP and SACTSNAP_STEP in a specific mode only seems to work around the problem.
Could the problem be inside snapFrameTransform?

I know this is somewhat going against the idea behind the refactor.
The whole thing would need to be refactored further (if we want this all in one place), because (and this is the main thing):

  • for stepping, you do the rounding prior to adding it anywhere, for snapping you add then round.
  • calculate delta value in snapping

Second Step (dopesheet) is now snapping to full seconds again.
(Graph Editor is another story -- this needs more refactor since it is doing the rounding in flushTransGraphData which is too late, it needs to round the delta while transforming before adding)

  • Fix snapping of second step

The solution was to deduplicate the code and merge all the logic into the transform_snap_anim_flush_data and transform_convert_flush_handle2D functions

  • functionality now seems to work correctly, thx!
  • one exception is the Graph Editor were holding Ctrl gets you in this weirs state of snapping to 5 frames step interval [this was the case prior to this patch as well, but might be a good occasion to have a look at]
  • you might want to update the Diff description (since this was quite a big refactor, an outline of the required changes would be nice)?
Germano Cavalcante (mano-wii) retitled this revision from Fix wrong Anim Auto-Snap (Frame Step / Second Step) to Fix T87173: Incorrect snap in animation editors.Aug 18 2021, 3:51 PM
Germano Cavalcante (mano-wii) edited the summary of this revision. (Show Details)

Also, for NLA and Graph Editor the snap invert (Ctrl pressing) was not working.

this was already fixed by rB0246128b7f9c: Fix wrong Anim Auto-Snap Ctrl toggle, can be removed from the description, no?

  • Cleanup/Refactor Action conversion
  • Fix incremental snap used in Graph Editor
  • Workaround: Edit the Graph Editor header in transform translate mode
Germano Cavalcante (mano-wii) retitled this revision from Fix T87173: Incorrect snap in animation editors to Fix T87173: wrong Auto-Snap in animation editors.Aug 18 2021, 6:43 PM

Quoting this from T87173 (but I dont think this should be holding this back and I asked to report this separately):

Nearest Marker: interestingly, moving an action with this snapping option enabled changes the action's length. If you drag it between two markers, it'll be stretched so it starts at one marker and ends at the other. If you drag it past the first or last marker, its length becomes a tenth of a frame.

In the NLA, this is actually true for all of the auto-snapping options (not just Nearest Marker).
This is the one thing that is still not solved with D12241: Fix T87173: wrong Auto-Snap in animation editors and I think at this point it would be good to report this separately (I assume this will involve some design decision, it has always taken into account the underlying keyframes [instead of only one strip border as one might expect] -- this might be interesting for @Wayde Moss (GuiltyGhost) or @Sybren A. Stüvel (sybren) )

I tested functionality and all LGTM.
You were mentioning this in chat: not sure if this should have separate commits? (I dont really think it would neccessarily have to be split, only thing I was wondering is if this could somehow make its way back into 2.93 LTS (not sure if is too risky)?)
So green light from me (codewise I could not spot a smoking gun, but have to pretty much trust you on this).

This revision is now accepted and ready to land.Aug 19 2021, 9:29 AM

Resolved by committing {b0d9e6797fb8}