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 is mainly a maintaince commit which syncs changes
between Blender and Libmv upstream also bringing new
GLog version.
This GLog version is presumably have better support of
MinGW from "the box".
This commit is also aimed to make further 3d part libs
update easier.
the inline definitions are included, which gives lots of warnings
"attribute declaration must precede definition".
See also rB83617429cf28f2a19e991a0f71d892fc159a4419
Basically issue was caused by the fact that strip for proxy has been
post-processed but proxy files were considered pre-processed. This lead
to situation of postprocessing being applied twice.
GPC_Canvas::GetWindowArea() and KX_BlenderCanvas::GetWindowArea() are tracking two
different things. The 2d filter system doesn't actually need the window area and
can get by just using the viewport dimensions, which it now does. The GetWindowArea()
mess should probably be cleaned up.
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)
