This commit is intended to fully fix the problem described in
https://developer.blender.org/T36425#19 (see also the previous commit rB08528f577dcb).
Addition of a small offset (to avoid singularity in stroke rendering due to overlapping vertices)
was not performed for all overlapping vertices.
Removed the StrokeCleaner and related helper functions which were added as a
temporary workaround in rB2a5b6d9c8f16.
A description of the problem is found in https://developer.blender.org/T36425#19 .
The cause of the issue was identified as roudning errors in Operators::createStroke() due
to insufficient numerical precision. Precision promotion from float to double was done in
the return values of getPoint3D/2D methods in Interface0D and its subclasses in C++
(data members stored in the 0D classes have already been in double precision).
before entering the recursion check.
Now use group tags instead of object tags, which could be a little more
efficient and was used before this patch too.
It still warns the user that there may be an error, but the baking goes
on. Also using the new is_uniform_scaled_m4() instead of float comparison.
Reported and fix suggested by Campbell Barton as a concern over 2bfc3deb
The scene file provided by the problem report has many degenerate faces coming from
a particle system. These zero-area faces were not expected in the ray-casting line visibility
algorithms of Freestyle. Now degenerate faces are properly excluded from the imported
mesh data and not fed to the line visibility algorithms.
The new recursion check for groups duplicating themselves has to un-set the LIB_DOIT flag after each object, otherwise it will prevent duplicating a (non-recursive) group multiple times.
To get the versioning code properly work, the condition should have been:
DNA_struct_elem_find(fd->filesdna, "FreestyleLineStyle", "MTex", "*mtex[18]")
The present commit uses another new structure member instead, to avoid referring
to the magic number 18 in the last string literal.
This was because to the filtering code, those FCurves still weren't in any
groups, and so couldn't be visible (since a temporary group is created to
house them). As a result, the visible-channels list would be empty, causing
all hidden FCurves to be treated as hidden.
These were broken by 1f3655d224, since
an argument of the wrong type was getting passed to ANIM_animdata_filter(),
resulting in no channels ever being picked up for the "visible channels" list.