Changes for VC2013
Now, I can build Blender with VC2013 with Cycles, Collada, OpenExr,OpenImageIO disabled. Also, you need VC2008 sp1 installed to make old libs compatible.
- add missing headers from cmake (own omission)
- quiet rna_test.c unused define warnings.
- minor style edits
- spelling corrections and ignore all uppercase words with spell checking script.
The reported line visibility issue was caused by a wrong calculation of a 2D
bounding box (so-called "proscenium face" in Freestyle) in the case of a
spherical grid data structure used for a perspective camera. The problem was
resulting from the proscenium computation based on two corners (min and max)
of the 3D bounding box of imported mesh data. Aware of the spherical coordinate
transformation involving non-linear (arctangent) functions, now the proscenium
is computed by taking in account all the eight corners of the 3D bounding box.
Also added minor code changes to facilitate future debugging.
The cause of inconsistent edge connectivity in the view map (documented in the commit
log of revision 58006) was identified and fixed. The problem was that when a ViewEdge
was split at a cusp vertex (ViewMapBuilder::computeCusps()), the ViewVertex at one end
of a newly created ViewEdge in ViewMap::InsertViewVertex() was not properly updated to
take account of edge connectivity changes.
There were two issues:
- Line visibility computations are very slow in the case of the provided .blend file, which gave
an impression that the rendering process got stuck. The slowness can be explained by the present
data structures used for the line visibility computations, together with the specific mesh distribution
of the test scene. At the moment Freestyle uses a regular grid in the 2D image coordinate system
to divide tris/quads into small groups in order to accelerate the line visibility computations.
On the other hand, the test scene is populated a big plane (made of one quad) and a moderately
detailed mesh object (22K tris). The scale of the latter mesh is animated from nearly zero to
about 0.2 to make the object show up over time. When the scale is nearly equal to zero, all the
tris concentrate in one grid cell, so essentially there is no performance gain from the grid data
structure optimized for speed. It looks like a better grid data structure (possibly based on
adaptive grid refinement) is necessary to genuinely address the identified performance issue. For now
the progress bar of Blender is employed to better inform users of the amount of work done in the line
visibility computations.
- A crash was caused by an excessive memory allocation request. The X and Y dimensions of the grid
data structure are determined based on the average area of mesh faces in the given scene. When the big
plane in the test scene is excluded from the rendering, the average area is almost zero (on the order
of 1e-5). As a result of this extremely small average area, the X and Y dimensions were set to a very
large number, causing a fatal memory allocation error. The present revision has introduced a hard
upper limit to the dimensions of the grid data structure to avoid this kind of numerical instability.
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.
on the console during Freestyle rendering. The debug prints are turned off
by default now. Errors are still printed on the console.
A patch set implementing this functionality was provided by Bastien Montagne.
Many thanks! :)
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.
This commit is meant to improve the response of the ESC key for stopping Freestyle rendering
throughout the rendering process. The rendering with Freestyle consists of several steps
including: (1) mesh data loading, (2) winged edge construction, (3) silhouette edge detection,
(4) view map construction, and (5) stroke drawing. All these steps have been extended to
frequently check if the ESC key is pressed, so that users can abort time-consuming rendering
at any point of time.
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.
reported by macouno. Thanks!
The crash was caused by a lack of curvature information required
for smooth edges. Now the curvature information is computed if and
only if there are smooth edges. This leads to a minor performance
improvement, because in the past the curvature information was
always computed when the Face Smoothness was enabled.
(To be precise, the above description is true when both the Ridges
and Valleys and Suggestive Contours options are disabled. If they
are enabled, the curvature information is always computed because
it is necessary for the determination of these edge natures.)
* View map calculation has been intensively optimized for speed by
means of:
1) new spatial grid data structures (SphericalGrid for perspective
cameras and BoxGrid for orthographic cameras; automatically switched
based on the camera type);
2) a heuristic grid density calculation algorithm; and
3) new line visibility computation algorithms: A "traditional"
algorithm for emulating old visibility algorithms, and a "cumulative"
algorithm for improved, more consistent line visibility, both exploiting
the new spatial grid data structures for fast ray casting.
A new option "Raycasting Algorithm" was added to allow users to choose
a ray casting (line visibility) algorithm. Available choices are:
- Normal Ray Casting
- Fast Ray Casting
- Very Fast Ray Casting
- Culled Traditional Visibility Detection
- Unculled Traditional Visibility Detection
- Culled Cumulative Visibility Detection
- Unculled Cumulative Visibility Detection
The first three algorithms are those available in the original
Freestyle (the "normal" ray casting was used unconditionally, though).
The "fast" and "very fast" ray casting algorithms achieve a faster
calculation at the cost of less visibility accuracy.
The last four are newly introduced optimized options. The culled
versions of the new algorithms will exclude from visibility
calculation those faces that lay outside the camera, which leads to a
faster view map construction. The unculled counterparts will take all
faces into account. The unculled visibility algorithms are useful
when culling affects stroke chaining.
The recommended options for users are the culled/unculled cumulative
visibility algorithms. These options are meant to replace the old
algorithms in the future.
Performance improvements over the old algorithms depend on the scenes
to be rendered.
* Silhouette detection has also been considerably optimized for speed.
Performance gains by this optimization do not depend on scenes.
* Improper handling of error conditions in the view map construction
was fixed.
* Fixed a bug in MaterialF0D::operator() that an error condition was ignored due
to a wrong return value.
* Fixed a typo in the docstring of StrokeVertex::setPoint().
Fixed a complicated bug that caused a failure of CurvePoint::getFEdge()
which had affected a number of C/Python API functions such as MaterialF0D.
The current view map building procedure may generate ViewEdges whose
two-dimensional (2D) length is almost or exactly zero. Such a zero-length
ViewEdge is possibly chained with other ViewEdges to form a stroke. When
the stroke is finally generated by Operators::create(), an attempt to remove
redundant vertices at the same 2D point is made. This possibly breaks the
links of ViewEdges on top of which the stroke has been built, and eventually
result in a fatal error of CurvePoint::getFEdge() when API functions that
rely on this method are called from within a style module.
The present fix addresses this issue by automatically removing zero-length
ViewEdges (and Chains of them) before stroke drawing is started and after
splitting is performed (e.g., using Operators::sequentialSplit()).
original Freestyle:
* Fix for making the stroke construction more robust to nearly
overlapping vertices.
* Fix for a bug in the computation of the occluded surfaces.
These changes make the visibility computation more robust and
the line quality generally higher.
ViewShape objects in the view map, as well as SShape objects
that can be retrieved with ViewShape::sshape(), now have a
getName() method that returns the name of the object from
which each shape is created. For instance, visible feature
edges of specific mesh objects (e.g., Cube.001 and Cube.002)
can be selected using custom predicate ObjectNamesUP1D as
follows:
class ObjectNamesUP1D(UnaryPredicate1D):
def __init__(self, names):
UnaryPredicate1D.__init__(self)
self._names = names
def getName(self):
return "ObjectNamesUP1D"
def __call__(self, viewEdge):
return viewEdge.viewShape().getName() in self._names
upred = AndUP1D(QuantitativeInvisibilityUP1D(0),
ObjectNamesUP1D(["Cube.001", "Cube.002"]))
Operators.select(upred)
An entry "Crease Angle" has been added to the Layers tab of the Render
buttons, to allow users to specify an angle (between 0 and 180) used for
crease edge detection. An edge is considered a crease edge if the angle
between two faces sharing the edge is smaller than the threshold. The
default value is 134.43 degrees (for backward compatibility). Be aware
that a larger threshold leads to a larger number of feature edges and
thus a larger memory consumption.
A checkbox "Material Boundaries" has been added to the Freestyle
options in the Layers tab of the Render buttons. By enabling the
option, any edge between two faces with different materials is
detected as a feature edge. In style modules, edges at material
boundaries can be tested with pyNatureUP1D(Nature.MATERIAL_BOUNDARY).
