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.
(From personal stash of bugs - since early 2.5 versions)
F-Curve colors get applied only on Graph Editor "refresh()". In some cases, undo
was reverting back to a state where the colors had not yet been set. In these
cases, there would be no refresh() after that undo (until expanding a channel or
some other similar action), resulting in "black F-Curves" appearing. So, now we
force such an update after undo to ensure that the curves never display black.
(Noticed while investigating another bug for Mango related to
CLIP_OT_constraint_to_fcurve not sending notifiers required when new F-Curves
are added)
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).
- Make sure functions are named in way BKE_<object>_<action> (same way as RNA callbacks)
- Make functions which are used by mball.c only static and remove their prototypes
from public header file.
Further cleanup is coming.
--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.
Graph Editor
Under User Preferences -> Editing, there's a new setting "F-Curve Visibility"
which controls the how much F-Curves blend in with the background colour.
Increasing this value makes F-Curves stand out more, at the expense of making it
less obvious which F-Curve is active.
