Freestyle sections of the API docs were empty due to Freestyle module reorganization
in commit rB6498b96ce7081db039354228213d72e8c70bd3aa.
Module __all__ property was added to submodules so as to properly exclude irrelevant
documentation elements such as mathutils.Vector.
Freestyle was using the default Cycles rendering settings (e.g., the number
of samples) and users could not change them. Now all render parameters
(except for film_transparent) are inherited for Freestyle stroke rendering.
Problem report by Danny Grimm on Facebook, thanks!
The problem addressed here is that there was no mean to check if an iterator
points the last of the elements being iterated over. Such checking is necessary
to reliably dereference the iterator (i.e., calling the operator*() method of the
underlying C++ iterator object).
Now Interface0DIterator and StrokeVertexIterator have an .at_last property
to check if an iterator points the last element. Using this new API feature,
the present commit partly reverts the previous commit rBeb8964fb7f19 to
better address T41464.
Differential revision: https://developer.blender.org/D752
Author: flokkievids (Folkert de Vries)
Reviewed by: kjym3 (Tamito Kajiyama)
The reported issue was caused by an old bug combined with another bug
introduced by recent Freestyle Python API updates.
The old bug was that a mutable reference to CurvePoint was treated as if
it were immutable. Iteration over CurvePoint objects is implemented by
the C++ CurvePointIterator class, whose dereference method
CurvePointIterator::operator*() returns a reference to a mutable data
member (probably originally intended for better performance). Hence the
returned reference may vary upon iteration over different CurvePoints.
This implementation detail was overlooked and the returned reference was
treated as immutable (which is the case in fact for other Interface0D
subclasses except for CurvePoint). This bug was surprisingly old as it
existed before the beginning of Freestyle integration into Blender.
The other bug was in the MaterialBoundaryUP0D predicate class that was
not properly handling the end of iteration. It is noted that when the
iter() and next() built-in functions are applied to Interface0DIterator,
it is no longer possible to reliably check the end of iteration by the
.is_end property of the iterator. Namely, the .is_end property works as
expected only when iteration is carried out in combination with the
conventional .increment() and .decrement() methods of the iterator. For
this reason the commit rBb408d8af31c9 was partly reverted to recover the
previous definition of MaterialBoundaryUP0D.
The stored context object was used for creation of shade nodes. A closer look at the
node system showed that the context is not actually used when shader nodes are
added to a shader node tree. Relying on this fact, now a NULL pointer is passed to
nodeAddStaticNode() instead of the stored bContext pointer.
Looks like the issue was caused by a UV map name starting with a lower case
letter (e.g., "color"). Capitalizing the name fixed the problem. Also adjusted
the creation of custom data layers to optimize things a bit.
Removed the previous changes for passing a line style through the Controller, and
revised the BlenderTextureShader to assign the shader node tree of a line style
(if specified) to strokes. This way the assignment of shading nodes can be done
through both the Freestyle GUI and Python scripting.
Now the shader node tree of a line style ID datablock is used to define textures
as well as their mapping and influence.
TODO: Textures alpha channel mapping and influence.
TODO: Blend mode in the Output Line Style shader node.
In addition to D319, this patch updates the parameter editor, the UI of Freestyle.
Using new API functionality and experience gained in making D319, this patch
provides a quite noticable speedup for commonly-used Freestyle linestyle modifiers.
As this patch touches a lot of code (and mainly the foundations) it is likely that
mistakes are made. The patch has been tested with a regression suite for Freestyle
(https://github.com/folkertdev/freestyle-regression-tests/tree/master), but testing
with scenes used in production is very much appreciated.
Differential revision: https://developer.blender.org/D623
Author: flokkievids (Folkert de Vries)
Reviewed by: kjym3 (Tamito Kajiyama)
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).
The cause of the crash was identified in an uninitialized member variable
`Main->lock`. Now that struct Main has a few member variables whose
values are dynamically allocated, per-render Freestyle-specific Main data
structures will be allocated and released using `BKE_main_new()` and
`BKE_main_free()`, respectively.
This revision complements the commit rB6135556f4556.
