This commit simplifies the logic for finding the control curves for NLA strips,
thus eliminating a whole bunch of weird errors that were happening here. It should
also fix a number of other related issues here.
- Add blentranslation `BLT_*` module.
- moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`).
- moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
There were some reported data race conditions in the python interpreter which
seems to be rather valid.
Surely this is not very pretty solution, but it might solve some annoying bugs
related on threading.
Logically, it makes sense that this parameter only gets used to describe the action
that the F-Curve actually belongs to (if it belongs to one). Otherwise, it should not
be set at all.
So far, we had an operator to 'bake' keyframe curves into samples, but no
way to make the fcurve editable again (i.e. to convert it back into a keyframes one).
Needed to fix mocap addon (see T43259).
Also, fixed a glitch in `fcurve_store_samples()`, since given end frame is included in range,
it is valid to give same start and end frame (in case you want a single point in samples,
not much practical cases, but...).
Own fault in rBb154aa8c060a60d to fix T42447... Reverted that commit, and added
kind of not-so-nice hack instead.
Note root of the issue comes from the special case we are doing here re 'Local'
space of parent-less objects. In that case, local space should be the same as
world one, but instead we apply the object rotation to it... This is inconsistent
with all other cases and could very well lead to other issues as T42447, but afraid
fixing that properly would be rather hairy - not to mention it would likely break
all existing riggings etc. :(
Should be safe for a 2.73a, shall we need it.
Small optimisation (which shouldn't have much of an effect) where we skip
complex handle calculations if all the handles/verts for a Bezier curve
segment are all flat.
Patch by Campbell (T40372 -> F91346)
When the active action is a NLA strip, the keyframe indicator colors for buttons
and the 3D view indicator (i.e. the current frame indicator changes color) didn't
work correctly. This was because they were still checking for keyframes in
"global" time space, whereas they needed to be applying NLA corrections to
"look inside" the remapped action.
This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still
not work in those cases... Better that than nothing, though.
Thanks to Campbell for review.
The "Show All" and "Show Selected" operators in the Graph Editor was taking into
account all handles on keyframes, even when some of those would be invalid and/or
set to nonsense values (e.g. for any interpolation mode other than "Bezier")
!!! ANIMATORS/RIGGERS PLEASE TEST !!!
I've reduced the size of the threshold for the keyframe lookup here. This threshold
determines the minimum time in frames between keyframes (i.e. "how close" to each
other they can get). Making this too small causes problems like T39207, but it seems
that the threshold we've been using makes it impossible to get accurate behaviour on
driver curves with keyframes, when the driver target only moves 2cm (i.e. 0.02 BU).
So far, all of the test cases from T39207 seem to work fine, as well as Caminandes 2
files, and Kenny the Caterpillar. The Kiribati rigs/shots (thanks jpbouza for helping
to check on these!) also seem to be fine.
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.
