This option (alongside the Ease In/Out/InOut options already available) aims to make it
easier to get an initial curve that looks closer to the one you were expecting, by
automatically picking whether Ease In or Ease Out should be used based on the type of
interpolation being used for the curve segment in question.
Notes:
* The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in)
* This does break compatability with files saved in previous dev builds, but only
if you were using Bounce/Elastic/Back with "Ease In"
Since this is now pretty much the de-facto "minimum distance between keyframes",
we might as well expose this in this header so that other places which need similar
thresholds can perform similar checks (needed for my next commit)
Evaluation of time-warping modifiers ("Stepped" is one of them) didn't actually
end up distorting the time to look up what values other modifiers in the stack
generate. This meant that when a "stepped" fmodifier was on top of a "generator",
the stepped fmodifier looked like it didn't have any effect.
(This fix requires a bit of testing still, so should be left for 2.71)
Previously, amplitude was more of an "absolute" value in the sense that whatever value
you set it to became a sort of "maximum bounce" height. However, it turns out that this
approach isn't so nice when dealing with large gaps between the values of two keyframes,
as the elastic easing equations expect that "amplitude > |change|" (where change is the
difference in values from key1 to key2).
Now, the "amplitude" value we pass to the easing functions are "|change| + amplitude".
This is easier to control, as now, as soon as you start changing that value, there are
immediately visible effects.
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/
Yet another attempt at fixing the problems here. This time, I've added a new
function/version of the binary search utility so that we can pass in custom
thresholds (Note: This ability is only used for evaluation currently, with
everything else using a wrapper which still uses the old default threshold),
making it ok to start trusting the "exact" parameter.
This commit attempts to fix some of the FCurve evaluation regressions arising from
an earlier commit to speed up the process using binary search. Further tweaks may still
be needed though to get this to an acceptable level of reliability (namely, tuning the
threshold defining which keyframes get considered "close together"). Since we're still
in an early stage of the 2.71 dev cycle, for now it's still worth trying to get this
working instead of simply reverting this (which can still be done later if it proves too
problematic).
Specific fixes:
* The previous code was somewhat dangerous in that it allowed out-of-bounds accessing
of memory when a == 0. It turns out this was more common than originally anticipated
(as the assert I added here ended up failing in the "action_bug.blend" file in the report)
* Tweaked the code used to test for closely-spaced points so that the "Clive.blend" example
for driver curves won't fail. The approach used here has the downside though that
since "exact" uses a might coarser threshold for equality, there may be some precision
loss issues causing backwards compat issues (namely with closely spaced keyframes, or
for certain NLA strips).
For now, I've left in some debug prints that can be enabled by running Blender in debug
mode (i.e. "blender -d"), which can provide some useful tuning info should we need to
look more into our approach here.
This provides a speedup to evaluating long F-Curves in fcurve_eval_keyframes()
by using the pre-existing binarysearch_bezt_index() function (used for keyframe
insertion) to find the relevant BezTriple on the FCurve at the current evaltime.
The current code loops over all BezTriples (sometimes not even breaking from the
loop after cvalue has been evaluated).
Reviewer Notes:
- Unlike in the original patch, we use the old/existing logic instead of
checking that (exact == true). See comments in code and also on the tracker
entry for this patch for more details.
Patch By: Josh Wedlake
Summary:
Crash was happening because of fcurve modifier stack
used modifier's DNA to store temporary data.
Now made it so storage for such a thing is being
allocated locally per object update so multiple objects
which shares the same animation wouldn't run into
threading conflict anymore.
This storage might be a part of EvaluationContext,
but that'd mean passing this context all over in
object_where_is which will clutter API for now without
actual benefit for this.
Optimization notes: storage is only being allocated
if there're Cycles modifier in the stack, so there're
no extra allocations happening in all other cases.
To make code a bit less cluttered with this storage
passing all over the place added extra callbacks to
the FModifier storage which runs evaluation with the
given storage.
Reviewers: brecht, campbellbarton, aligorith
CC: plasmasolutions
Differential Revision: https://developer.blender.org/D147
By default, drivers (used to) automatically map the driver result (i.e.
"evaltime" or the x-coordinates in the driver graphs) to results. This evaltime
=> cvalue mapping is necessary when there are absolutely no keyframes or
modifiers on a driver F-Curve, or else nothing would happen.
However, when there are modifiers on these driver F-Curves, and these modifiers
only work within certain ranges, there would be confusing and unwanted
situations where even if you clamped the modifiers to only generating a curve
within certain frame ranges, the final driver output would still ignore the
results of the curve due to the underlying 1-1 mapping.
This commit introduces a check to ensure that this automatic mapping won't
happen during such invalid ranges.
- when an fcurve had no selected keyframes, a default fallback value was used which caused view-selected to include frame 1, even when no selected frames were there.
- the vertical axis was always reset, ideally we would center vertically too but the way this operator currently works we only know about the frame range,
now don't change the vertical scroll when viewing selected since it would always jump to the top of the screen (view-all still acts this way).
Most of the places which relied on RNA_path_resolve() did so believing that if
it returned true, that it had found a valid property, and that the returned
pointer+property combination would be what the path referred to. However, it
turns out that if the property at the end of the path turns out to be a
"pointer" property (e.g. "data" for Object.data), this would automatically
become the pointer part, while the prop part would be set to null. Hence, if a
user accidentally (or otherwise) specifies a path for the single-property driver
variable type like this, then Blender would crash.
This commit introduces two convenience functions - RNA_path_resolve_property()
and RNA_path_resolve_property_full() - which mirror/wrap the existing
RNA_path_resolve() functions. The only difference though is that these include a
check to ensure that what was found from resolving the path was in fact a
property (they only return true iff this is the case), and make it explicitly
clear in the name that this is what they will do so that there's no further
confusion. It is possible to do without these wrapper functions by doing these
checks inline, but the few cases that had been patched already were pretty
hideous looking specimens. Using these just make it clearer and simpler for all.
I've also beefed up the docs on these a bit, and changed these to using bools.
using the -d flag
This prevents a stream of error messages flooding the console when working with
particular rigs which may have a few broken controls. In general, riggers now
have a better alternative by using the filtering tools in the Graph Editor.
in the UI
This is the second part of the fixes for [#32492], making it easier to identify
which part of a driver (i.e. which of its targets) is causing problems
A number of additional/related changes needed to be made:
* Red-alert status for layouts is now propagated down to child layouts when they
are created. This is needed as otherwise some of the templates used in the Graph
Editor driver settings won't actually get the red-alert status flushed down to
them. Also, note that this status needs to be set before any widgets are added
to the layout, or else the settings aren't applied when the relevant widgets get
created.
* "Single Property" RNA-Paths resulting in out of bounds array access will now
trigger an error status and appropriate warnings
TODO:
* The error tagging doesn't get applied immediately after variables are created,
or their types changed
* There was also some other weirdness involved when a higher-value flag (1<<10)
was used for this setting, which needs further attention
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.
