An assertion to check if `re->clipsta` < 0 (added as part of addressing
T36009 in rBrB795034c17d76bef2a15e576ac9c70ae2268a823b) was failing when
Freestyle viewport preview rendering takes place in the camera view with
an orthographic camera (in this case, the user-defined clipping range is
used without changes, so that `re->clipsta` is positive). The
`re->clipsta` property has a negative value only when the 3D viewport is
in an orthographic view but not in the camera view. It seems that this
viewport setting cannot be identified from rendering settings accessible
from Freestyle. Now a negative `re->clipsta` value is directly checked
instead, without relying on other render flags.
Previously the imported mesh data were transformed by a local-to-world projection matrix
through NodeTransform. Now that the file loader assumes the imported mesh data already
in the camera coordinate system, an indentity matrix was supplied to NodeTransform.
The present commit avoids this redundant matrix operation by using NodeGroup instead of
NodeTransform, recalling the latter is a subclass of the former with extra matrix computations.
New properties 'line_color' and 'line_priority' are added to Material ID data blocks.
The 'line_color' property allows users to specify a per-material line color that can be
used as a Freestyle line color through Material color modifiers of line style settings.
The new line color property is intended to provide a solution for line color
stylization when a proper Freestyle support for Cycles is implemented (likely
as part of the upcoming Blender 2.72 release; see Patch D632). Materials in
Cycles are usually set up using shader nodes, and Freestyle won't be capable
of retrieving colors and other properties from node-based materials any soon.
The new line color property of materials addresses this foreseen limitation by
providing artists with an intuitive alternative mean to specify line colors on a
per-material basis independently from node trees.
The 'line_priority' property gives users a way to control line colors at material
boundaries. When a line is drawn along a feature edge at material boundaries,
one of the two materials on both sides of the edge has to be picked up to
determine the line color. So far there was no way to control this selection
(which was in effect at random). Now the material with a higher line color
priority will be selected.
The new per-material line settings are shown in the new Freestyle Line tab in
the Material context of the Properties window (only when Freestyle is enabled).
Clipping start is negative when the viewport preview is used with the orthographic view,
while Freestyle assumes that imported mesh data are in the camera coordinate system
with the view point located at origin. The present solution is to adjust the clipping
start/end and introduce a Z-axis offset for mesh vertices so as to satisfy the assumption.
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 previous implementation of Freestyle edge/face marks was refactored
based on suggestions from the latest code review by Campbell. The new
implementation relies on mesh CustomData to store edge/face marks, instead
of introducing extra flags in the core Mesh and BMesh data structures.
The CustomData-based implementation will allow further additions of new
edge/face attributes because of the independence from Mesh/BMesh.
This revision is work in progress, mainly intended to address the review
comments and ask for further code review in view of the trunk merger in
the upcoming 2.67 release.
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.
A motivating example of the problem the present solution aims to address is a
quad face such that three of the four vertices are colinear (i.e., they are
lying on a line). Depending on how this quad is separated into two triangles,
one of them can be a degenerate triangle. Degenerate triangles of this form
are easy to avoid by rotating the diagonal edge of quad faces without affecting
the visual outcome. The fix implemented in this commit tries to address
degenerate triangles in this way.
This commit replaces the solution in revision 44539.
It is recalled that a degenerate triangle is a triangle such that
1) A and B are in the same position in the 3D space; or
2) the distance between point P and line segment AB is zero.
Degenerate triangles in the second form are now resolved by adding a
small offset to P (i.e., the resulting triangles have a non-zero area).
This commit replaces the solution in revision 44534.
It is recalled that a degenerate triangle is a triangle such that
1) A and B are in the same position in the 3D space; or
2) the distance between point P and line segment AB is zero.
Unlike the previous solution, the present fix is capable of
any mesh topology involving any number of degenerate triangles.
Degenerated triangles are removed in two steps. First,
degenerate triangles in the second form are transformed into
the first form by moving P to the position of either A or B
that is closer to P. This modification affects all triangles
sharing the vertex P. Then, all degenerate triangles in the
first form are removed by just ignoring them.
Obviously, the present solution has a disadvantage that
resulting strokes may appear incorrect. This drawback is
justified by the fact that the present solution is robust and
easy to implement. Users are expected to fix incorrect
strokes (if any) by manual removal of degenerate triangles
from mesh data.
This commit is an attempt to address degenerate triangles (i.e.,
triangles whose area is zero) that cause incorrect line visibility in
Freestyle.
There are two forms of degenerate triangles. Let A, B and P denote
the three vertices of a triangle. A degenerate triangle is a triangle
such that 1) A and B are in the same position in the 3D space, or
2) the distance between point P and line segment AB is zero. Note
that the first form is a special case of the second form. Degenerate
triangles in the first form is easy to remove by the Remove Doubles
command. This commit is intended to address those degenerate triangles
in the second form.
The implemented fix cannot address degenerate triangles in general.
It fails when a triangle touches with multiple degenerate triangles.
A more general solution needs to be implemented.
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.
the R_TRANSFORMED flag enabled. Now vertex normals are properly
transformed by ObjectInstanceRen::nmat[3][3] and normalized. It is
noted that in the case of R_TRANSFORMED flat faces, surface normals
are transformed and normalized by RE_vlakren_get_normal().
The bug was reported by Stéphane Grabli via personal communication.
Thank you Stéphane for the careful code review!
With this option disabled, the smoothness of faces is ignored and
jagged feature edges (when seen from a three-dimensional viewpoint)
are generated. If the new option is enabled, face smoothness is taken
into account during the view map calculation, resulting in smooth
feature edges in 3D. This generally leads to more stable strokes, and
also permits more stylization possibilities relying on the feature
edge smoothness in 3D. The downside of smooth feature edges is that
the visibility is mathematically not well-defined and may cause some
artefact in rendering results. The new option is thus intended to
allow users to try both jagged and smooth feature edges and see which
ones would fit individual application needs. This option is disabled
by default.
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)
Previously mesh vertices imported from vlak nodes were transformed
from the camera coordinate system to the object local coordinate
system. This causes a difficulty in recovering object local vertices
when mesh deforming modifiers (e.g., curve, cloth, and soft body) have
been applied. Now the view map creation is done based on mesh
vertices in the camera coordinate system. Advantages of this approach
includes: 1) faster mesh importing because of less matrix-based
transformations; and 2) proper handling of meshes with deforming
modifiers.
A straightforward clipping algorithm was implemented to
eliminate vertices that are out of the interval from the
near to far clipping distance defined by the active camera.
Previously, objects that come behind the camera could lead
to a crash. The changes in this commit is intended to
address this issue. When meshes are partially clipped, new
edges are added. These edges can result in visible strokes
if they are within the camera view.
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).
The following files were according to the Math Lib reorganization
(see the commit log of revision 24464 for more information):
source/blender/freestyle/intern/blender_interface/BlenderFileLoader.cpp
source/blender/freestyle/intern/blender_interface/BlenderFileLoader.h
The file release/scripts/ui/properties_render.py was also updated
according the RNA UI API renaming in revision 24795.
