This affected legacy solver. Note that even if I don't expect any, this fix *may* break some other IK setups, so animators, please check your IK rigs using legacy solver. ;) Easy to revert if needed, anyway.
Note that iTaSC solver is also buggy with some scaled parent, but here IK'ed bones just can’t get scaled in any way (either from parent or from there own transformation)... Will try to find what's happenning, though the code is even harder than legacy solver to follow :/
- spelling - turns out we had tessellation spelt wrong all over.
- use \directive for doxy (not @directive)
- remove BLI_sparsemap.h - was from bmesh merge IIRC but entire file commented and not used.
inconsistent with similar functions & math notation:
mul_m4_m4m4(R, B, A) => mult_m4_m4m4(R, A, B)
mul_m3_m3m4(R, B, A) => mult_m3_m3m4(R, A, B)
For branch maintainers, it should be relatively simple to fix things manually,
it's also possible run this script after merging to do automatic replacement:
http://www.pasteall.org/27459/python
Spline IK and Auto-IK working together on the same bone chain could
crash due to the somewhat hacky way that they were sharing the same
list for the "iktree" forest. Resolved by doing what I should have
done from the beginning, and made Spline-IK save its ik chains off
into a separate list.
While this fixes the crash, it might be worth investigating outright
disabling this from working in this case, since it can be a bit
confusing to have it appear to not work.
- Upgrade Eigen2 library to Eigen3
- Upgrade colamd library and placed in extern/ so other libraries from extern/ can use it
NOTE: With previous version of Eigen (3.0.1) it was necessary to define
EIGEN_DONT_ALIGN_STATICALLY macro to make it compilable on windows 32bit.
After latest upgrade it seems to be unnecessary (at least when was testing libmv),
so i removed that defines which can reduce speed and lead to other problems.
blender_add_lib now takes a separate include argument to suppress warnings in system includes (mostly ffmpeg & python).
also only build wm_apple.c on apple+carbon configuration.
globbing vs explicit is discussed here.
http://www.cmake.org/pipermail/cmake/2008-December/025694.html
Practical implications are:
- developers need to keep CMakeLists.txt files up to date.
- Users wont get strange linking errors if they build after a file is added, since CMake detects CMakeLists.txt is modified and automatically reconfigure.
- made interface, windowmanager, readfile build without unused warnings.
- re-arranged CMake's source/blender build order so less changed libs are build later, eg: IK, avi
- option only available to cmake, scons and make have this enabled always.
- without this clang/llvm can compile blender
- this was the second biggest internal lib, 192mb -> 172mb for all blenders libs (with debug flags), so gives some speedup to linking.
Rotations are now stored internally as radians, while exposing degrees in the UI -
in the graph editor and UI controls. This is done in two areas:
1) Using the unit system to convert RNA data to display as degrees in the UI controls
2) FCurves now use degrees for rotation, so you can edit in the graph editor what
you see in the UI.
All rotation data is consistently accessible in DNA and RNA as radians, degrees are only
used for the UI controls and graph editor.
This commit includes conversions will convert old files (stored data and also fcurve data)
to the new units, hopefully everything should go smoothly!
Part of this also changes a few properties that were hard-coded as degrees before (such
as IK pole angle and brush texture rotation) to also use the same consistent system of
radians (dna/rna) and degrees (ui).
Thanks to Joshua for hints and review here too.
