!!! 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.
Skip doing particle update in object_handle_update if object is in
edit mode.
Object will be re-evaluated on exit from edit mode anyway, so it's
_expected_ to be a safe change.
It's not that trivial to support disapearing tracks in the sequence,
and since we're having ongoing 2D stabilization rework patch wouldn't
want to start doing rather bigger changes here now.
Let's just stick to legacy behavior for this release.
This reverts commits 91429d0, 543ce85
Seems to be caused by the way how the most bottom strip in the stack
used to apply effect. Just rendering strip in this cases will not give
proper results.
Made it so effect is applying between empty imbuf and actual strip.
Seems to work by tests, but more intense testing is required.
The helper function `make_freestyle_edge_mark_hash()` was referring to the
original mesh to determine Freestyle edge marks for individual derived mesh edges.
This is no longer necessary now that derived meshes deliver CD_FREESTYLE_EDGE
and CD_FREESTYLE_FACE layers of their own. The reference of the original mesh
was also inappropriate since the edges coming from one of the operands of a boolean
modifier don't have proper CD_ORIGINDEX values but ORIGINDEX_NONE's.
Many thanks to Sergey Sharybin for patch contributions and discussions.
Looks like the normal update flag is used internally in the modifier
itself. So as a workaround just pass normal update to the nodes when
flood filling
Issue was caused by _wstat returning EOVERFLOW error because
of file size didn't fit into stat structure which was using
long datatype.
The idea of this patch is to use _wstat64 and _stat64 structure
which is capable storing 64bit file sizes.
Made it a typedef for stat structure used by BLI_stat function
in order to make code easier to follow and avoid ifdefs all
over the place.
Additionally solved issue with BLI_exists which was wrongly
returning False in cases destination file is larger then 4GB.
Better fix than rBbef5cb3aa2e5a: consider edges between faces with opposed normals as sharp.
In fact, previous code was broken more deeply in this case (inconsistent normals across
a 'smooth fan') - some loop normals would even never be computed!
Fixing this is possible (even wrote it, actually), but this adds more complexity
to a piece of code that is already awfully complicated, *and* normals in that kind
of smooth fan do not make much sense anyway. So simpler and nicer results with
assuming sharp edges between such 'opposed' faces!
Note that there is some face (loop) ordering black magic at work here, added more comments
to try to explain how and why all this works.
As a bonus, we do not need to check for already computed loop normals anymore, since we
know each 'smooth fan' will be walked once, and only once.
This crash can only happen in case faces in same 'smooth fan' have reversed normals.
To support this, we have to always keep a way to get real values in loop_to_poly,
even when loop itself is tagged as done, it might be needed in computation of one of
its neighbor's split normal later.
Check that up_axis is not aligned with bone was wrong in at least two aspects
(not working against negative alignement case, and since ages it seems,
using Z axis when bones are along Y axis...).
Also optimized a bit here, better to have a normalized version of vec_roll_to_mat3(),
since it needs normalized vector anyway, and we have to normalize it for the tests
before calling it anyway (so now, we only do that twice in Transform code, instead
of three times).
And we can perform aling test *before* calling vec_roll_to_mat3!
The bug was caused by using negative numbers as the end for playing forever (or until the end of the sound is reached) in the library. This was used with speaker objects which have an end of FLT_MAX now instead and the negative number interpretation was removed. I hope this doesn't break anything else.
Revert small part of own rB8714ae09f894, which changed scale setting from absolute to relative
(was good in absolute, but bad because it breaks existing rigs).
So! First, frame for absolute shape keys: never allow a new key to have the same pos as an
existing one (this does not make sense). This way, the two workflows are possible (create
all keys and then animate ctime, or animate ctime and then create keys where you need them).
Also, fixed UIList for shapekeys, the "absolute" test was wrong, and better to show frame
value, even though not editable, than nothing in case of absolute keys.
And finally, add getter to RNA 'frame' readonly value, so that we output real frame values,
and not dummy internal ones (which are /100) in our API.
Joshua Leung
Campbell Barton
Sergey Sharybin
Tamito Kajiyama
Bastien Montagne
Antony Riakiotakis
Lukas Tönne
Jörg Müller
Brecht Van Lommel