| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This patch adds some new functionality to the Freestyle Python API, notably:
- MaterialBP1D, checks whether the supplied arguments have the same material
- Fixes a potential crash in CurvePoint.fedge (due to NULL pointer)
- Makes (error handling in) boolean predicates more robust
- Adds a BoundingBox type, to make working with bounding boxes easier
- Adds several new functions (get_object_name, get_strokes, is_poly_clockwise, material_from_fedge)
- Adds a StrokeCollector StrokeShader, that collects all the strokes from a specific call to Operators.create()
- Adds hashing and rich comparison to the FrsMaterial type
These new features (most of them, anyway) are needed for making a more robust SVG exporter that supports holes in fills.
Reviewers: kjym3, campbellbarton
Subscribers: campbellbarton
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1245
|
|
Python.
Many thanks to the problem report by flokkievids (Folkert de Vries)
through a comment in Patch D963.
|
|
|
|
|
|
|
|
Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)'
and 'strcmp(foo, bar) == 0' in several places...
|
|
|
|
|
|
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.
|
|
also use PyList_GET_ITEM when list size is known.
|
|
|
|
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.
|
|
Use BKE_appdir/tempdir naming prefix for functions extracted from BLI_path_util
|
|
This module is intended for path manipulation functions
but had utility functions added to access various directories.
|
|
The issues identified here are regression from 2.71, so the present code
revision is appropriate for backporting if 2.72a is planned.
|
|
only element.
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 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.
|
|
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.
|
|
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.
|
|
|
|
|
|
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)
|
|
|
|
freestyle.types.StrokeVertexIterator.
|
|
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).
|
|
|
|
Patch contribution by flokkievids (Folkert de Vries). Thanks!
|
|
Patch contribution by flokkievids (Folkert de Vries). Thanks!
|
|
|
|
This revision extends the Freestyle Python API to make for style module writing
easier.
- freestyle.types.Stroke: A proper support for reversed() is implemented. It
works the same with other Python sequence objects (returns an iterator starting
from the end). This is in effect equivalent to Stroke.stroke_vertices_end().
- freestyle.types.StrokeVertexIterator: An incremented, decremented and reversed
method are added. The first two methods return a new StrokeVertexIterator
object that has been incremented and decremented, respectively. The reversed
method returns a new StrokeVertexIterator object that will traverse stroke
vertices in the opposite direction.
- freestyle.types.Interface0DIterator: Its constructor now accepts a Stroke
object to create an Interface0DIterator that traverses stroke vertices. This is
in effect equivalent to Stroke.vertices_begin(). The new API makes stroke
shaders involving function calls much simpler as illustrated below:
# in the old API
it = stroke.stroke_vertices_begin()
for vert in it:
result = somefunc(Interface0DIterator(it))
# in the new API
it = Interface0DIterator(stroke)
for vert in it:
result = somefunc(it)
Differential Revision: https://developer.blender.org/D545
Reviewers: kjym3
|
|
|
|
count.
Changes were made in Stroke::Resample(int) in C++ to prevent a potential infinite loop
caused by an inconsistency between Stroke::_Length and the stroke length computed
based on stroke vertices. Such a stroke length inconsistency is usually caused by missing
calls of Stroke::UpdateLength() (i.e., API implementation bugs), but also may occur due
to scripting errors in user-defined style modules. This commit is meant to help script
writters to identify the latter error cases. Now Stroke.resample(int) may raise a runtime
error to signal an error condition.
|
|
- Fixed a typo in docstring.
- Replaced int with boolean constants.
- Updated lists of base classes for used-defined unary 0D/1D functions.
|
|
Paolo Acampora.
Reviewers: brecht, kjym3, #freestyle
Reviewed By: brecht, kjym3
Differential Revision: https://developer.blender.org/D246
|
|
|
|
(See commit e1771e72fbbf828dbf5bed871b814288389f3611 for more detail of
the problem).
Made changes to intern/view_map/Interface0D.h and intern/python/Director.h to
avoid #include <Python.h> and keep non-Python header files independent of it.
|
|
(See commit e1771e72fbbf828dbf5bed871b814288389f3611 for more detail of
the problem).
Fixed for #include <Python.h> not properly put in the extern "C" { ... } construct.
Also removed redundant inclusion of the header file in the Freestyle Python API code.
|
|
Addition of the path to the Freestyle Python API modules to 'sys.path' was delayed until
the first Freestyle rendering, so that any import attempt of the modules in the Python
Console always failed. Now the update of 'sys.path' is done at Blender start-up.
This allows the Freestyle-specific modules to be imported without running Freestyle,
facilitating quick interactive testing in the Console.
|
|
|
|
getter/setter methods..
These data elements are undocumented and of little use. For now they are commented out
in the implementation in favor of less memory consumption, and a very limited support for
these data components in the Python API was just removed (should be easy to recover).
|
|
|
|
the Nature class.
|
|
|
|
boolean values.
The problem is that comparisons involving the constants Nature.POINT (for vertices) and
Nature.NO_FEATURE (for edges) were evaluated in a wrong way. It is recalled that the
Nature class is a subclass of Python's built-in int type, and that these two constants are zero
when evaluated as numbers. The issue was caused by the implementation of the constants
in an incompatible way for comparison with Python int (and boolean) values. Specifically,
the zero of Python int is represented by an empty array of digits, whereas the zero-valued
Nature constants were represented by an array of size 1. Python int comparison operators
first check the lengths of the arrays of two operands, and then start comparing the digits
only when the array length is the same. For this reason, the two Nature constants were
not properly compared with int values (and thus with boolean values). It is noted that the
zero-valued Nature constants may result from bitwise operations on other Nature constants
(e.g., Nature.SILHOUETTE & Nature.BORDER), so this issue must have affected many
existing style modules.
The problem was reported by Folkert de Vries (flokkievids) through personal communications.
Thanks a lot!
|
