BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
A crash in the Freestyle renderer was reported by Ton on IRC with a stack trace
below. Note that #2 is in Freestyle, whereas #1 is in the compositor. The problem
was observed in a debug build on OS X 10.7 (gcc 4.2, openmp disabled, no llvm).
----------------------------------------------------------------------
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
[Switching to process 72386 thread 0xf303]
0x0000000100c129f3 in NodeBase::~NodeBase (this=0x10e501c80) at COM_NodeBase.cpp:43
43 delete (this->m_outputsockets.back());
Current language: auto; currently c++
(gdb) where
#0 0x0000000100c129f3 in NodeBase::~NodeBase (this=0x10e501c80) at COM_NodeBase.cpp:43
#1 0x0000000100c29066 in Node::~Node (this=0x10e501c80) at COM_Node.h:49
#2 0x000000010089c273 in NodeShape::~NodeShape (this=0x10e501c80) at NodeShape.cpp:43
#3 0x000000010089910b in NodeGroup::destroy (this=0x10e501da0) at NodeGroup.cpp:61
#4 0x00000001008990cd in NodeGroup::destroy (this=0x10e5014b0) at NodeGroup.cpp:59
#5 0x00000001008990cd in NodeGroup::destroy (this=0x114e18da0) at NodeGroup.cpp:59
#6 0x00000001007e6602 in Controller::ClearRootNode (this=0x114e19640) at Controller.cpp:329
#7 0x00000001007ea52e in Controller::LoadMesh (this=0x114e19640, re=0x10aba4638, srl=0x1140f5258) at Controller.cpp:302
#8 0x00000001008030ad in prepare (re=0x10aba4638, srl=0x1140f5258) at FRS_freestyle.cpp:302
#9 0x000000010080457a in FRS_do_stroke_rendering (re=0x10aba4638, srl=0x1140f5258) at FRS_freestyle.cpp:600
#10 0x00000001006aeb9d in add_freestyle (re=0x10aba4638) at pipeline.c:1584
#11 0x00000001006aceb7 in do_render_3d (re=0x10aba4638) at pipeline.c:1094
#12 0x00000001006ae061 in do_render_fields_blur_3d (re=0x10aba4638) at pipeline.c:1367
#13 0x00000001006afa16 in do_render_composite_fields_blur_3d (re=0x10aba4638) at pipeline.c:1815
#14 0x00000001006b04e4 in do_render_all_options (re=0x10aba4638) at pipeline.c:2021
----------------------------------------------------------------------
Apparently a name conflict between the two Blender modules is taking place.
The present commit hence intends to address it by putting all the Freestyle C++
classes in the namespace 'Freestyle'. This revision will also prevent potential
name conflicts with other Blender modules in the future.
Special thanks to Lukas Toenne for the help with C++ namespace.
The problem is that the visibility of view edges in the view map may be incorrect.
The main cause of this issue is that view edges are constructed from a series of FEdges
without testing the visibility of the FEdges being concatenated. Later view edges
are split into pieces if two view edges intersect in the 2D image coordinate system.
After that the visibility of the view edges is computed by taking account of occluding
faces in the 3D scene. In many cases this procedure results in correct line visibility,
but not always (that is the problem).
A simple solution experimentally implemented here is not to chain FEdges at all.
Instead view edges are constructed from at most one FEdge now. This solution is only
applied to sharp FEdges (roughly corresponding to edges in the input mesh data; specifically,
silhouette, crease, border, edge mark, contour, external contour, and material boundary).
A better solution is to reorder the three steps of view edges construction mentioned above,
i.e., first splitting FEdges at 2D intersection, computing the visibility of the FEdges,
then concatenating them to build view edges. This solution is left for future work for now.
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.
New "face marks" and "edge marks" have been introduced in mesh data
blocks. In the edit mode of a mesh object, face marks can be put
to selected faces by choosing Mesh >> Faces >> Mark Freestyle Face
from the menu of a 3D View window or Ctrl-F >> Mark Freestyle Face
from the context menu. Similarly, edge marks can be put to selected
edges by Mesh >> Edges >> Mark Freestyle Edge or Ctrl-E >> Mark
Freestyle Edge. These marks should work fine with the Subdivision
surface modifier.
Moreover, two new conditions for feature edge selection have been
added to the Parameter Editor mode as described below:
1. The Selection by Edge Types option has now the new Edge Mark type,
which can be used to (de)select feature edges having edge marks.
This option can be used to add to (or remove from) the view map
arbitrary edges of mesh objects.
2. Selection by Face Marks option has been newly introduced, in which
face marks are used for feature edge selection in two ways. One
option is called "One Face" which is to (de)select feature edges if
one of faces on the left and right of each feature edge has a face
mark. The other option is "Both Faces" to (de)select feature edges
if both faces on the left and right have a face mark.
All of the reference to the original Material class were renamed to FrsMaterial to resolve a name collision with Blender. To keep the window context necessary to draw the strokes after RE_Database_FromScene has been called, the display_clear function is used.
IMPORTANT: The setters functions' names were normalized due to constant confusion regarding capitalization. All the function names start with set... instead of Set.... This convention was changed all throughout Freestyle. To use Freestyle as an external renderer, the SWIG library MUST be regenerated.
