Trying to use mat game settings in 3DView makes sense - but only when we are using "Game Engine" as 'renderer'!
Note GLSL code completely ignores mat game settings currently, could be added too...
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.
