When the dopesheet was open, "keyframe edited" events from the graph editor
(i.e. fired whenever any properties on keyframes or FModifiers are changed)
would trigger the dopesheet to synchronise selection states of anim channels
and ensure that FCurve autocolours are initialised correctly.
This however was undesired when editing properties in the graph editor. Now,
made it so that keyframe adding/removing operators use different notifier flags
to specify that the channels might have changed + need colour syncing, and
adjusted the dopesheet updating logic to fit
Problem was introduced back in 2.70 during Project Pampa when the FCurve Normalisation
feature was introduced. The cause was that the normalised cursor value was always getting
passed to the KeyframeEditData context, even when it wasn't needed.
This commit introduces support for a number of new interpolation types
which are useful for motion-graphics work. These define a number of
"easing equations" (basically, equations which define some preset
ways that one keyframe transitions to another) which reduce the amount
of manual work (inserting and tweaking keyframes) to achieve certain
common effects. For example, snappy movements, and fake-physics such
as bouncing/springing effects.
The additional interpolation types introduced in this commit can be found
in many packages and toolkits (notably Qt and all modern web browsers).
For more info and a few live demos, see [1] and [2].
Credits:
* Dan Eicher (dna) - Original patch
* Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase
* Joshua Leung (aligorith) - Code review and a few polishing tweaks
Additional Resources:
[1] http://easings.net
[2] http://www.robertpenner.com/easing/
This makes a number of operators no longer ask for confirmation, rather it will
show an info message after performing the operation. Ref T37422 for decision. In
particular, these were changed:
* Delete objects, bones, keyframes, masks, mask curves, motion tracks, markers.
* Clear and delete keyframes in the 3D view.
* Align bone to parents.
* Separate bones from armature.
* Group/ungroup metastrips in sequencer.
* Copy/paste objects to/from buffer.
Reviewed By: brecht, dingto
Differential Revision: http://developer.blender.org/D35
Added two options to a header of FCurve editor:
- Normalize which makes it so every individual
curve is fit into -1..1 space.
- Auto-normalize, which probably is to be called
"Lock" which "locks" curve normalization scale.
This is useful to prevent curves from jumping
around when tweaking it.
It's debatable whether it need to be a button to
normalize curves n purpose only, and it's fully
depends on animator's workflow.
Here during Project Pampa we've got Francesco
who get used to auto-renormalization and Hjalti
who prefers locked behavior.
Docs are to be ready soon by Francesco.
Thanks Brecht for the review!
Remove usages of ANIM_unit_mapping_apply_fcurve in favor of
runtime scale factor apply.
There're still calls to ANIM_nla_mapping_apply_fcurve are
hanging around, they're the next t be cleaned up!
when running viewport operations with exec() rather then invoke(), perform the action immediately rather then using smoothview.
makes viewport operations usable from python scripts.
- add missing headers from cmake (own omission)
- quiet rna_test.c unused define warnings.
- minor style edits
- spelling corrections and ignore all uppercase words with spell checking script.
Code could enter in an infinite loop when curve value was an odd multiple of PI (i.e. 180°)...
Current code was also factorized and got rid of fabs calls! ;)
The tooltip seemed to hint that this tool is able to resolve all manner of
gimble-lock situations by untangling the curves (i.e. performing some kind of
equivalent-angles resolution, keeping in mind the nearest situations nearby).
However, this tool currently only performs corrections for the most basic case
when large jump+flip discontinuity artifacts appear in euler rotation curves as
a result of rotation values getting clipped to +/- 180 degrees, which arises
when these rotation curves are the result of baking some physics sim or so.
(Also, fixed an unrelated "replace-all" typo in a comment)
This operator used to be called "Jump to Frame". It basically takes the midpoint
(frame number and/or value) of selected keyframes, and positions the current
frame (or2d-cursor in Graph Editor) at this point.
The hotkey for this is now Ctrl-G (i.e. as it's similar to a "Goto Frame"
feature). It is also now in the Key menu instead of in the relatively obscure
View menu, even though it doesn't actually result in any keyframe edits taking
place.
(Also, fixed a typo/grammer issue with one of Remove Bone Group operator)
property
Changes:
This commit adds a second line to the tooltips (below the generic operator
description) showing the appropriate description for each enum option. This
brings it more into line enum properties in Blender which also show this sort of
information.
Rationale:
Operators such as Snap and Mirror in the Action and Graph Editors use an enum to
control their behaviour (respectively, "how to snap" or "what to use as the
mirror line"). In the menus, these options are displayed using a submenu, but
hovering over each of these items for more information from a tooltip only shows
the (relatively unhelpful) generic operator tooltip/description.
Another area where these descriptions are useful is for Keying Sets, where it's
now possible to see the descriptions for what each Keying Set
does/affects/requires. Again, this is more helpful than just the generic
tooltip, which would be something like "Insert keyframes using a Keying Set".
than one curve is displayed
The range calculation used to use a fixed 0-1 range whenever it couldn't find
any values for a particular F-Curve. However, this was then taken by the
aggregation calculation to be used as just another value, leading to problems if
only vertices of a very high-value curve are selected to be included.
Modified the range calculation to ensure that suitable vertices were found
before trying to take the range values returned.
In response to [#31670], I've reviewed the way that the Paste Keyframes tool for
the DopeSheet and Graph Editors works. Previously, it required you to always
select the F-Curves to paste the keyframes into before allowing you to paste
keyframes. This was because it is quite difficult to infer which ID-block's set
of curves is intended if more than one ID-block has similar curves (e.g. a scene
with two materials, and both have their diffuse color animated). The underlying
assumption and intention of the feature here was that the copy+paste were only
being used by animators to copy animation between similar curves, to transfer
and offset animation across block boundaries.
However, it turns out that many people were by far more familiar with the
simpler copy/paste paradigm from everywhere else (i.e. instead of trying to use
duplicate to copy keyframes around within their respective F-Curves).
Furthermore, in most cases there is only going to be a single character being
animated at a time (vs multiple), which means that most of the time the matching
problem is much simpler.
Hence, the Paste now works as follows:
- If there are selected F-Curves, we limit the paste-matching to only consider
those in the selected F-Curves. This makes it possible to still explicitly
specify where to paste.
- In the more general case (no prior selections), pasting will try to match
anything relevant it finds.
TODO:
- Check on whether the strictest matching level needs adjustments to limit the
number of false positives
- Testing and feedback of the new behaviour needed <--- ANIMATORS! PLEASE TEST
F-Curves
It is possible to get the old behaviour (handles excluded) by bringing up the
Operator Properties (F6) while in the Graph Editor (this doesn't work elsewhere
due to the context requirements of this stuff).
--debug
--debug-ffmpeg
--debug-python
--debug-events
--debug-wm
This makes debug output easier to read - event debug prints would flood output too much before.
For convenience:
--debug-all turns all debug flags on (works as --debug did before).
also removed some redundant whitespace in debug prints and prefix some prints with __func__ to give some context.
In fact, most "UI special cases" are not well translated, currently. :/ This affects especially the "Properties" panels. This commit should address problems in Graph editors, and 3D View (but probably not yet all of them). Yet it already adds more than 100 new messages (and fixes translated drawing of more).
Also done some style edits…
