This commit makes some preliminary fixes and tweaks aimed to make blender
compilable with C++11 feature set. This includes:
- Build system attribute to enable C++11 featureset.
It's for sure default OFF, but easy to enable to have a play around with
it and make sure all the stuff is compilable before we go C++11 for real.
- Changes in Compositor to use non-named cl_int structure fields.
This is because __STRICT_ANSI__ is defined by default by GCC and OpenCL
does not use named fields in this case.
- Changes to TYPE_CHECK() related on lack of typeof() in C++11
This uses decltype() instead with some trickery to make sure returned type
is not a reference.
- Changes for auto_ptr in Freestyle
This actually conditionally switches between auto_ptr and unique_ptr since
auto_ptr is deprecated in C++11. Seems to be not strictly needed but still
nice to be ready for such an update anyway/
This all based on changes form depsgraph_refactor branch apart from the weird
changes which were made in order to support MinGW compilation. Those parts of
change would need to be carefully reviewed again after official move to gcc49
in MinGW.
Tested on Linux with GCC-4.7 and Clang-3.5, other platforms are not tested and
likely needs some more tweaks.
Reviewers: campbellbarton, juicyfruit, mont29, lukastoenne, psy-fi, kjym3
Differential Revision: https://developer.blender.org/D1089
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.
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.
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! :)
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.
* 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.
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)
Made Controller::_EPSILON constant with the value 1e-6. Previously,
the _EPSILON value was computed based on the minimum edge size within
the scene being rendered (in some cases, the computed value resulted
in zero). This does not seem to make sense, because _EPSILON has been
used as a tolerance threshold of floating-point arithmetic errors
throughout the view map creation. Since Blender uses single-precision
real values for mesh data representations, the new constant _EPSILON
value looks more adequate.
Made an attempt to fix "2D intersection out of range" warnings.
These warnings may cause "3D intersection out of range" warnings,
which often lead to a crash.
The FEdgeXDetector class for silhouette edge detection and the
ViewMapBuilder class for view map creation are enhanced. All changes
are related to view point handling (i.e., the camera location). In
the perspective projection, the visibility of feature edges and edge
types (e.g., borders and crease lines) are computed based on a fixed
view point, whereas the view point in the orthographic projection is
an arbitrary point on the XY plane at the origin and is determined so
that a line segment from the view point to a point in the 3D space is
perpendicular to the XY plane. All view point related portions of the
class definitions were modified so as to deal with the two different
camera modes.
instability issues regarding the view map creation. A new iterative
solver of the 2D-to-3D inverse projection transformation problem was
implemented. Instead of directly solving the problem in the direction
from the 2D to 3D space, the new solver starts with an initial guess of
an approximated solution and asymptotically approaches to the true
solution by iteratively performing the forward 3D-to-2D projection
transformation and improving the approximation. Preliminary tests with
one simple and another complex scenes showed that the solver converges
quickly (more and less 20 iterations in many cases, with a stopping
criterion of a residual distance between the true and approximated
solutions less than 1e-6 Blender Unit).
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.
