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.
Logic here was very stupid, texboxes would have their initial
locations scaled by font size but not their width/height.
Now its possible to change font size while keeping the textbox layout.
Other fixes
- tab character didn't work properly with textboxes.
- memory leak when VFontData was missing.
- underline faces had flipped winding by default.
- BKE_vfont_to_curve_ex disallowed 0 underline height (annoying when sliding value)
- disallow negative underline height since it flips underline direction (just change position + height)
Problem happens when removing a rigid body reference in a constraint,
and then jumping to the start frame right away. This will cause a full
rebuild of the rigid body world. However, the btRigidBodys are removed
before the constraints, and this leaves dangling pointers in the
btTypedConstraints, which causes corruption when deleting those
constraints later.
Fix for now is to explicitly delete constraints in advance when
rebuilding, while they still have valid btRigidBody pointers.
Ultimately the whole memory management and ownership of Bullet data
needs redesign. This is already happening in the particles_refactor
branch and could be ported to master separately:
https://developer.blender.org/diffusion/B/browse/particles_refactor/source/blender/blenkernel/intern/rigidbody.c
