The reported problem was due to a special case where there are no strokes
to be rendered. Since rendering an empty scene is a waste of time, the issue
was addressed here by skipping the stroke rendering process entirely.
Setting all values of a tuple is such a common operation that it deserves its own macro.
Also added Py_INCREF_RET to avoid confusing use of comma operator.
remove 'type' argument, very few mathutils objects are wrapped,
add new function for creating wrapped objects.
also fixes unlikely memory leak if the data-array can't be allocated.
Previously individual strokes were represented by distinct mesh objects
no matter how many vertices and materials each stroke has, although
the vertex and material counts can be quite small depending on the input
scene data. Now stroke meshes are packed into a minimum number of
mesh objects, so as to reduce the overheads of Blender object creation.
A StrokeVertexIterator ignores the first element when it is the only element.
Such an iterator can be created by the .incremented() method from an iterator
over two stroke vertices.
This problem is a regression from 2.71. The present fix is appropriate to backport
if Blender 2.72a is planned.
Problem report by Kazuhiro Murakawa through personal communications, thanks!
This patch removes several stroke shaders written in C++ that are unused
and don't serve a real purpose any more. The removed shaders are:
- BPy_ColorVariationPatternShader
- BPy_StrokeTextureShader
- BPy_TextureAssignerShader
- BPy_ThicknessVariationPatternShader
- BPy_fstreamShader
- BPy_streamShader
and a few more that weren't even exposed to the Python API.
Some minor edits were made by the reviewer.
Differential Revision: https://developer.blender.org/D801
Reviewed by: kjym3
The view map is mostly treated as a read-only data structure by line stylization
operations (i.e., selection, chaining, splitting, sorting and stroke creation). The
only exception is the chaining operation in some cases where insertion of extra
FEdge objects is necessary to ensure the continuity of underlying FEdges from
which a chain is constructed.
The present revision addresses the removal of extra FEdges so to keep the view
map clean and suitable for reuse in subsequent render frames.
New render layer option named "View map cache" is added to reuse a
previously computed view map for subsequent rendering. The cache is
automatically updated when the mesh geometry of the input 3D scene has
been changed.
This functionality offers a major performance boost for Freestyle
animation rendering when camera-space mesh geometry is static, as well
as for repeated still renders with updates of line stylization options.
Although the "View map cache" toggle is a render layer option, the cache
memory is shared by all render layers and scenes. This means that if
Freestyle is used for two or more render layers (possibly in different
scenes through the compositor), then the cached view map for one render
layer is replaced by a new view map for another render layer and hence
no performance gain is expected.
The Operators.reset function is exposed to the Freestyle Python API, which makes
it possible to combine multiple style modules into one file.
Differential revision: https://developer.blender.org/D802
Author: flokkievids (Folkert de Vries)
Reviewed by: kjym3 (Tamito Kajiyama)
Fixed dead references of API identifiers (e.g., freestyle.types.Interface0D)
due to relocations of the identifiers into submodules. Also made various minor
revisions of mark-ups and typos.
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.
