| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Noisy change, but safe, and better do it sooner than later if we are to
rework copying code. Also, previous commit shows this *is* useful to
catch some mistakes.
|
|
|
|
Thus it is according to the Manual
https://docs.blender.org/manual/en/dev/animation/drivers/drivers_panel.html#driver-variables
|
|
Things like `BLI_uniquename` had nothing, but really nothing to do in
BLI_path_util files!
Also, got rid of length limitation in `BLI_uniquename_cb`, we can use
alloca here to avoid overhead of malloc while keeping free size (within
reasonable limits of course).
|
|
Drivers can use this to refer to the data which the driver is applied to,
useful for objects, bones, to avoid having to create a variable pointing to its self.
|
|
FCurve evaluation depended on FCurve.curval, which isn't threadsafe.
Now only use this value for debug display,
and pass the value instead of storing in the FCurve for all but debug-display.
|
|
copying all variables from one driver to another
This was a feature request from a few years back (IIRC from ZanQdo?) to make it
easier to reuse one set of driver variables across several different drivers.
Dev Notes:
* Finally it's done! All that trouble for two little buttons.
* Grr... cmake... grrr!
|
|
Support for driver variables that don't resolve to numbers, eg:
objects, bones, curves... etc.
Without this, Python expressions to access this data needed to use an absolute path from `bpy.data`,
however this is inconvenient, breaks easily (based on naming) and wouldn't set the dependencies correctly.
|
|
Driver code used incomplete list of Py keywords
|
|
"blank") names
|
|
|
|
F-Curves easier
Now, when trying to insert a keyframe on a driven property (using IKEY, or with
autokeying enabled), the keyframes will get created on the Driver's F-Curve
(instead of creating a new FCurve that goes into the active action, but will never
do anything). Furthermore, the x-value of the new keyframe will be the current
result of the driver expression.
Why/Motivations:
This way, it becomes easier to create corrective drivers, as you can position all
the targets the driver depends on, then adjust the driver value until it does what
you need, and then you keyframe that value to bake it into the Driver F-Curve
(in effect, "training" the computer how to behave in that case).
Usage Notes:
* In practice, that particular workflow is still quite clunky to achieve, due to some
quirks of how the driver system and the UI widgets interact. Specifically, you'll
need to disable/mute the driver before trying to edit the setting (to prevent the
driver from immediately resetting the value - before even autokey fires!). However,
if you're using the Graph Editor to preview/monitor/manage the keying process, you'll
then want to re-enable the driver before changing the targets, so that you can see
how much of a change you'll want to be applying!
* The warning about editing driver values may need to be disabled or selectively
knocked out. I had it disabled while testing this functionality, but it's actually
harmless in its current state (if just a bit annoying).
|
|
|
|
When attempting to change a driver variable name to an "invalid" name,
an indicator will now be shown beside the offending variable name.
Clicking on this icon will show a popup which provides more information
about why the variable name cannot be used.
Reasons that it knows about are:
1) Starts with number
2) Has a dot
3) Has a space
4) Starts with or contains a special character
5) Starts with an underscore (Python does allow this, but it's bad practice,
and makes checking security of drivers harder)
6) Is a reserved Python keyword
|
|
present
This was caused by interpolation between samples being performed incorrectly
(i.e. wrong order of arguments) when sampling more than once per frame.
|
|
When the quat is known to be unit length, so we can avoid scaling
(just conjugate_qt which asserts on non unit quats).
|
|
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`.
|
|
|
|
an active action
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
shouldn't be
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.
|
|
Potential crash reading freestyle modifiers from future blend-files
|
|
Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)'
and 'strcmp(foo, bar) == 0' in several places...
|
|
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.
|
|
|
|
|
|
handles are flat
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)
|
|
NLA Strips
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.
|
|
Behavior with NULL context was wrong.
|
|
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.
|
|
Own copy and paste typo in 73d157e meant that this was not in some cases,
the bounds calculated may be incorrect.
|
|
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.
|
|
Compensate for the clamped amplitude by blending the elastic effect.
Allows for a subtle elastic effect which wasn't possible before.
|
|
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"
|
|
bypass angle calculation to avoids (asin, sqrt, cos).
|
|
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)
|
|
|
|
|
|
stacked after other modifiers
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)
|
