Blender 2.70: Freestyle NPR Rendering
Freestyle is designed to be a highly programmable non-photorealistic (NPR) rendering engine that allows users to develop their own line stylization options using the Python programming language. The present Blender 2.70 release has incorporated major revisions of the Freestyle Python application program interface (API) that may break existing application programs (style modules), now that some breakage of backwards compatibility is allowed with the 2.7x series. Python style modules written for Blender 2.67-2.69 are likely to need (minor) code updates. It is also noted that the API changes are totally internal, so that there is no artist-visible effects on Freestyle rendering results.
Part 1: Python API Module Reorganization
Freestyle-related Python modules have been reorganized in line with the bpy module and its submodules (T37565). The API updates aim to address the following issues observed in the present Freestyle implementation:
- Freestyle API constructs for style module writing in Python were not logically organized. The API modules were partly organized in terms of implementation languages (C and Python) and partly based on implemented roles (predicates, chaining iterators, and so on).
- All Python scripts for Freestyle, i.e., both API modules and application programs (style modules), were stored in the same 'release/scripts/freestyle/style_modules' directory. This made it difficult for new users to find style modules.
New Python module organization
The new Python module directory structure is organized as follows:
release/scripts/freestyle/modules- Freestyle API modules
release/scripts/freestyle/styles- predefined style modules
In Python, the Freestyle API modules are reorganized as follows:
freestyle- top-level package just containing the following submodules.
freestyle.types- classes for core data structures, and base classes for user-defined stylization rules (i.e., chaining iterators, predicates, functions, and shaders).
freestyle.chainingiterators- predefined chaining iterators.
freestyle.predicates- predefined 0D and 1D predicates.
freestyle.functions- predefined 0D and 1D functions.
freestyle.shaders- predefined stroke shaders.
freestyle.utils- utility functions for style module writing.
Code examples before/after the API revision
The effects of the API changes are illustrated below by taking the japanese_bigbrush.py style module as example. With the previous API organization (before the API updates), the import statements in the beginning of the style module were written as follows:
from freestyle import BezierCurveShader, ChainSilhouetteIterator, ConstantColorShader, \ ConstantThicknessShader, IntegrationType, Operators, QuantitativeInvisibilityUP1D, \ SamplingShader, TextureAssignerShader, TipRemoverShader from Functions0D import pyInverseCurvature2DAngleF0D from PredicatesB1D import pyLengthBP1D from PredicatesU0D import pyParameterUP0D from PredicatesU1D import pyDensityUP1D, pyHigherLengthUP1D, pyHigherNumberOfTurnsUP1D from logical_operators import NotUP1D from shaders import pyNonLinearVaryingThicknessShader, pySamplingShader
With the updated Python API, these import statements are written as follows:
from freestyle.chainingiterators import ChainSilhouetteIterator from freestyle.functions import pyInverseCurvature2DAngleF0D from freestyle.predicates import ( NotUP1D, QuantitativeInvisibilityUP1D, pyDensityUP1D, pyHigherLengthUP1D, pyHigherNumberOfTurnsUP1D, pyLengthBP1D, pyParameterUP0D, ) from freestyle.shaders import ( BezierCurveShader, ConstantColorShader, ConstantThicknessShader, SamplingShader, TextureAssignerShader, TipRemoverShader, pyNonLinearVaryingThicknessShader, pySamplingShader, ) from freestyle.types import IntegrationType, Operators
From the applicative perspective, the new organization will be much easier for style module writers to find relevant Python constructs from the freestyle.* submodules. It is remarked that there is no functional difference (no visual effects in rendering results) between the present and new module organizations.
Part 2: Better Support for the Python Iterator Protocol
Freestyle iterators now provide a better support for Python's iterator protocol (T38213). Taking the StrokeVertexIterator (used in a stroke shader) as example, iteration over stroke vertices has been traditionally written using a C++-style iterator object (
it) as follows:
it = stroke.stroke_vertices_begin() while not it.is_end: # do something it.increment()
Starting from Blender 2.70, the same iteration can be written using the Python iterator protocol as follows:
it = iter(stroke) for vert in it: # do something
The second form of iteration over vertices could be used previously, but was not working as most users might expect. The problem was that the iterator object
it and the for-loop get out of sync: specifically,
it.object refers to the next vertex of the one seen as
vert within the for-loop. Since the iterator object is often passed to predicates and functions as an argument to perform operations at each of the vertices in a loop, the second notation was not applicable because of the inconsistency between the iterator object and the for-loop. Now this form of for-loop is fully operational, and the iterator and for-loop go through the vertices in sync.
In addition, next(it) now also works reliably, e.g.:
it = iter(stroke) first_vert = next(it)
It is noted that iteration over vertices in the reversed order can be written as follows:
it = stroke.stroke_vertices_end() for svert in it: # do something