In the process, I've removed the old operator (ANIM_OT_channels_visibility_set)
and folded that option in with the hide operator, to make this consistent
with how this is done in the 3D view and other parts of Blender.
Now the hotkeys here work in line with what's done for other parts of Blender
* H = Hide selected
* Shift-H = Hide unselected (i.e. old VKEY behaviour)
* Alt-H = Reveal all
Revised the tools for managing which FCurves are visible in the Graph Editor
curves area. Now, there are the following tools in place:
* V (channels region only) = Hide all curves except those in selected channels [OLD]
* H = Hide all selected curves [NEW]
* Shift-H = Show all previously hidden curves [NEW]
I've removed the old operator to toggle visibility status of selected curves,
as it doesn't seem that useful anymore.
For FCurves where all the keyframes use the "simple" interpolation types
(i.e. Constant, Linear, and Bezier), we now use the old FCurve drawing
code that was used prior to the Easing Equations changes. This should
be generally faster in general.
When the "High Quality Line Drawing" option (View menu) is disabled,
the sampling rate (i.e. the size of timesteps to use when sampling
the FCurve for drawing it in most cases now) is set to be quite low
(i.e. at 0.1 frame increments). This amounts to at most 10 sub-steps.
In one test file (with a wide window), this had the effect of improving
the performance by over 3x. It's still not as good as a sampling-free
approach, but for this functionality is still needed for FModifiers,
so it's better that we can optimise this.
Make the UI API more consistent and reduce confusion with some naming.
mainly:
- API function calls
- enum values
some internal static functions have been left for now
Quick fix, this is actually a demonstration of why we should use modal keymaps!
We can give any event to *start* the op, but then hard-code how to *end* it... tsk.
This uses a different operator than the other time editors (as it needs to support
the setting of the value-cursor too), so the changes here didn't get propagated through.
Editing the y-coordinate of the right handle of a keyframe via the Active Keyframe
panel in the Graph Editor, while both handles are selected and are both of type "aligned"
resulted in weird behaviours such as the x-coordinate of the right handle changing
(and rapidly starting to overshoot) but nothing else. However, this problem
doesn't occur when only a single handle is selected.
It turns out that the "order of computation" logic in calchandleNurb_intern() gets
confused in the case of both handles being selected, and results in a sub-optimal
handling of the right handle being the one that's been changed. We hack around this
here by temporarily making it so that just the right handle is selected when doing
the updates here.
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.
View2D had some inconsistencies making it error prone in some cases.
- Inconstant checking for NULL x/y args.
Disallow NULL args for x/y destination pointers, instead add:
- UI_view2d_region_to_view_x/y
- UI_view2d_view_to_region_x/y
- '_no_clip' suffix wasn't always used for non-clipping conversion,
switch it around and use a '_clip' suffix for all funcs that clip.
- UI_view2d_text_cache_add now clips before adding cache.
- '_clip' funcs return a bool to quickly check if its in the view.
- add conversion for rectangles, since this is a common task:
- UI_view2d_view_to_region_rcti
- UI_view2d_region_to_view_rctf
Inspired by T39315, this commit adds a few more driver "linting" messages used for
providing users with tips on how to use drivers better. This time, we specifically
address 2 cases:
1) Drivers being abused for procedural animation, due to the misconception that
procedurally generating F-Curves using F-Modifiers means that drivers are needed
to wire such procedural motion-sources to properties.
2) Setting up Average/Sum/Min/Max driver types without any input variables - you can't
expect anything to happen (unless of course, your intention was to lock the property
to 0.0)
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/
In order to combat the problem of users frequently trying to use inlined
bpy.data/bpy.context paths for data access in their driver expressions
and then finding/complaining that these don't update correctly, the UI
now flags these as the error conditions that they are (with suggestions
on how to fix this).
Also tweaked the "Add Variable" button to have more descriptive text about
what exactly variables are and why to use these, along with some other
visual tweaks (icons!).
