There is no good solution here, since RNA props can only have one type/unit.
Tried to find the less worse one - have different RNA props for same DNA value
(a bit like the angle/length for camera lens).
Also fixed two other issues with Transform conctraint:
* Angle were still in degrees (yes, another backward-compatibility breacking).
* Scale was absolute, unlike loc/rot.
Also cleaned up a bit the code, replaced some magic numbers by proper enums, ...
See T39470 and D436. Code by @tippisum, with some minor edits by @mont29.
Tested with various rigs, including Rigify, CGcookie flex rig, and gooseberry/pataz caterpillar.
Riggers, please test it, no change expected in behaviour.
Reviewers: aligorith
CC: tippisum
Differential Revision: https://developer.blender.org/D436
These data elements are undocumented and of little use. For now they are commented out
in the implementation in favor of less memory consumption, and a very limited support for
these data components in the Python API was just removed (should be easy to recover).
Symbol 'real' is an alias of double and is subject to future change, while the interface of
0D/1D functions is part of the stable Freestyle Python API. So all occurrences of this type
in the class definitions were replaced with double.
Almost all pools allocated 2 chunks on initialization,
every element needed to be added to the free-list which
would never be used for small pools.
Now allocate only one, gives minor speedup for some bmesh operations.
This function used ugly hack with static variable which was
preventing some type checks in DAG nodes. Using this variable
form multiple threads is not considered safe, apparently.
Solved by moving this variable inside the DAGForest structure.
so it's global for the graph now, but different graphs does not
run into conflicts.
This required passing the forest to some functions, which doesn't
look so much nice, but don't want to spend time on making this
code look beautiful because it is really to be replaced by the
new dependency graph.
This is really bad bug actually which is must go to 'a'.
This actually implements the idea used in Gimp which is grabbing
an arbitrary point on the spline and dragging it, ensuring spline
goes over this point. This is really useful way to tweak spline
curvature.
Currently only affects on a closest handle, meaning no weighting
on changes for both handles which are adjacent to the same segment
will happen just yet,
Another limitation is that currently such a slide is a big jumpy
when you start sliding. This is because projection is not used
to calculate u value because projection used to fail a lot for
me here and didn't find a nice solution for this yet. But this is
to be improved for sure!
Vertices of two edges were swapped by mistake. Also fixed indentation and added
a couple of debug prints to make it easier to visualize the lines using Matlab.
