The instability considered here is due to a persistent failure of the
getFEdge() method in the Interface0D class and its subclasses in the
presence of smooth FEdges. When the Face Smoothness option is
enabled, the view map is populated with not only sharp FEdges (i.e.,
edges in the original meshes) but also smooth FEdges (i.e., newly
built edges lying on triangular surfaces). The failure of getFEdge()
caused many related issues because the method is widely used in other
predicates and functions that rely on it. The most prominent example
of related user-visible problems is a constant failure of the built-in
MaterialF0D.
The main issue and related problems were addressed as follows:
* A bug in the construction of smooth FEdges was fixed. Individual
smooth FEdges, even when they were detected as a series of smooth
FEdges that constitute one smooth ViewEdge, may have some irregular
geometry in the form of non-uniform OWXFaceLayer::order values. The
OWXFaceLayer::order values were used in an inappropriate way, so that
resulting smooth ViewEdges may have an FEdge between two subsequent
SVertices that were indeed the same SVertex object. This was an
unexpected situation that getFEdge() could not handle.
* Another issue in the construction of smooth FEdges was resolved.
When sharp FEdges are constructed, two SVertices at both ends of an
FEdge are generated only when no SVertex exists in a given 3D position
(this way, the original mesh topology is reconstructed from a bunch of
independent triangles that the BlenderFileLoader class passes to the
view map creation process). This sharing of SVertices was used also
for the generation of SVertices at the two ends of each smooth FEdge,
causing the getFEdge() failure in the presence of smooth FEdges. The
workaround implemented here is to simply suppress the sharing of
generated SVertices when smooth FEdges are created.
* In the Parameter Editor mode, the built-in MaterialF0D was replaced
with a better implementation that works well with Curves and Strokes.
MaterialF0D does not work with these 1D data types.
pyMaterialColorShader, pyBluePrintEllipsesShader and pyBluePrintSquaresShader.
* Fixes for Vector instantiation that now takes only a sequence object of
2, 3, or 4 elements -- an API change in revision 28417.
* Deleted vector.py that is no longer used.
This allows users to test the types of those objects that are returned
by API functions, by means of usual Python idioms such as "type(I) is T"
and "isinstance(I, T)".
* Removed all occurrences of ViewVertex::castToTVertex() in the following
modules and rewrote the code segments using it by means of the "type(I)
is T" idiom mentioned above:
ChainingIterators.py
PredicatesU1D.py
* Replaced all occurrences of vector.Vec2, vector.Vec3, Vec2f and Vec3f
by Blender.Mathutils.Vector in the following modules:
anisotropic_diffusion.py
Functions0D.py
shaders.py
sketchy_topology_broken.py
* shaders.py: Fixed NameError's concerning math.pow().
* shaders.py: Added a Python equivalent of getFEdge function, defined
in source\blender\freestyle\intern\view_map\Functions0D.cpp as follows:
FEdge* Functions0D::getFEdge(Interface0D& it1, Interface0D& it2) {
return it1.getFEdge(it2);
}
* shaders.py: Replaced fe.qi() by fe.viewedge().qi().
* contour.py: Fixed the import statement for freestyle_init.py.
