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.
When path to resolve "finishes" on a collection prop, do not erase the returned prop!
This caused py's path_resolve to return same PointerRNA as the one passed as parameter, leading to
inifinte recursion in Operator's accessor func (__getattribute__)...
When leaving cam view, if autopersp is ON, and previous view was an axis one, we have to force new view in perspective mode - else, we reuse previous stored mode (persp or ortho).
Fluid sims have a very nasty feature for interaction, in which a psys
can directly update the bvhtree for //another object's psys//. This
breaks with threaded depsgraph evaluation and is generally a no-go.
To avoid crashes for now, use a global mutex to avoid concurrent writes
to an object psys' bvhtree.
The issue was caused by assumption object matricies can be modified
by DupliObject->obmat outside of the duplilist iteration cycle.
This isn't really true. The thing is, old code used to modify object
matrix based on the duplicated matrix to make it so modifier evaluation
kind of works (it'll use proper matrix in most cases, but think there
might be some cases when this assumption also breaks).
Even when matrix is copied from dupliobject to object in advance
(to mimic old behavior or dupli system) you're still to use matrix
from dupliobject inside a cycle body. This is because the same object
might be modified multiple times by different dupliobject. For example,
in case of duplifaces loads of faces will modify object's matrix and
before this change matrix from the last face would have been used.
The fix is simple one-liner which makes it so render instance will
use proper matrix from dupliobject.
All the rest bits here (pre-loading matrices and restoring them in
the reverse order) totally matches old behavior of duplilist.
This is a regression and to be ported to 2.70 tag!
Make HSL wheel useful in compositing.
In HSL, 0.5 lightness corresponds to most vibrant colors so make that
default for locked wheels (previous value of 1.0 just made it white).
Also, unlock the wheel for both very bright and very dark colors.
and value/lightness slider stops midway.
Issue here is manyfold:
Color wheel does not support properties with different soft min/max
values than 1.0 (which after experimenting a little I left as is), and
also color management is completely destroying the mapping between the
value slider and the RNA property value range. To solve this I have
disabled color management by setting the property to gamma corrected
(only in RNA, Sequence editor coders please check!), otherwise it will
just become a big mess of tracking where color comes from and what kind
of color transforms it needs in different color pickers (if property has
non normalized range etc). HSL is not really meant to represent colors
outside a normalized space so I have disabled setting lightness above
1.0 in this model.
This will work, however it is hacking a color picker to do something
other than what it is supposed to do: pick a color from the screen
accurately. Which means normalized values always. The non normalized
colors picked for lift/gain/gamma through the pickers do not correspond
to any accurate colors; they are rather a user friendly way to 'sort of'
choose a color and a gamma with an indication of maximum value.
I think that lift/gamma/gain nodes need a dedicated widget for this
(besides it is quite clear that some options are written for that use
case) -or- a separate gamma multiplier for the picked color (which
should itself be in a normalized space)
Was using wire or black in many places, this color is used for cursor,
camera guides, transform helper lines. So its possible to have a dark
background with light overlay color.
Patch D331 by Brita, with some edits.
Issue was in BLI's rotation_between_vecs_to_quat(), which did not handled correctly cases where both vectors are colinear.
Patch by Campbell Barton and me.
Issue originaly tracked down by Yan Shi, many thanks!
This is a regression caused by rB67134a7bf689279785e2e40b29cd24243813998b
The UV coordinates read from the UV input must be scaled by the Image
input size instead of the UV input size.
Also now this node uses the UV input resolution instead of the Image
resolution, since this is what determines the available resolution. The
image is EWA-sampled anyway, it's resolution does not have a direct
impact.
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
To reduce user confusion, we were already presenting users with an error message
when they tried to edit constraints for bones from the Object Constraints tab.
This commit just makes things more convenient by adding a button which takes
users to the right tab when clicked.
