rotated close to 180 degrees and there were edges both below and above
the 180 degree threshhold. Separating and averaging the negative and
positive angles seems to solve the issue making the tool a bit more
robust ;)
The problem is that, when HAVE__BOOL is not defined (as it is the case in scons currently), BLI_utildefines.h defines bool as a standard type. Was using signed char, which makes eg "bool foo = 1024" be false (overflow)! Especially nasty when using bitflags (think we have been lucky to not have worse bugs because of that)!
So changed fallback bool type to unsigned int.
This is useful for gcc which does not define sqrtf/powf/... functions with preprocessor and therefore always used sqrt/pow/...
Float functions are generally 20-50% faster than their equivalents for double type.
non-threadsafe usage of guarded allocator.
Also added small chunk of code to check consistency of begin/end
threaded malloc.
All this additional checks are commented and wouldn't affect on
builds, however found them helpful to troubleshoot issues so
decided to commit it to SVN.
mat4_decompose() is similar to mat4_to_loc_rot_size() but returns
rotation as quaternion.
mat4_to_loc_quat() just returns location and rotation without size.
projecting it. The original paper suggests to simply interpolate between
the two points of an edge if the distance of the point to that edge is
smaller than a threshold.
* Fixed both 3D and 2D code to utilize this. Possibly other places in
blender where this scaling is done will have to be adjusted.
* Changed vertex interpolation to use 2D interpolation, since it already
did projection on plane and 2d calculations are faster.
* Also added notifier on hard recalc when uvcalc_transfor_correction is
used. Results in instant feedback on UV editor when edge sliding.
Additional changes:
- Made mipmapping operate with unsigned short instead of char
which allowed to eliminate extra division by 255, so prevision
should be a bit better now.
- Actually, this is not real unsigned short range, but it's a
range of 255*255 which is more convenient for mipmapping, so
made conversion functions private for scaling.c
Not sure it worth making this functions operate in 65535
range, for now current behavior seems to be just fine.
Regression was caused by alpha premul cleanup commit and the reason
of slowdown was uchar <-> float conversion which is slow.
Replaced with uchar <-> int conversion which seeps to be accurate
enough and mostly eliminates slowdown.
Slowdown was easy to notice when movie clip is used for 3d vierport
background and undistortion is enabled. In this case every frame
will re-calculate mipmaps.
It's still a nit slower than mipmap generation before cleanup
commit, but couldn't think about extra boost here atm.
- add option to calloc or not, existing code wasnt consistent here, would calloc on first alloc but not on realloc, also - the static memory was never zero'd.
use flag BLI_BUFFER_USE_CALLOC to ensure all new memory is zero'd (static/alloc/realloc's).
- add BLI_buffer_declare_static / BLI_buffer_declare so its possible to have a buffer that never uses static memory.
