* Added to python/BPy_Convert.{cpp,h} 4 utility converters below for
better introspection-based automatic type conversion.
PyObject * Any_BPy_Interface0D_from_Interface0D( Interface0D& if0D );
PyObject * Any_BPy_Interface1D_from_Interface1D( Interface1D& if1D );
PyObject * Any_BPy_FEdge_from_FEdge( FEdge& fe );
PyObject * Any_BPy_ViewVertex_from_ViewVertex( ViewVertex& vv );
There are 4 corresponding converters without the "Any_" prefix. All
calls of them in the code base were replaced with these new converters
so that the introspection-based automatic conversion would take place
universally.
* python/BPy_Convert.{cpp,h}: Those C++ to Python converters having
had a "_ptr" suffix were renamed to a name without the suffix, and
their arguments were changed so as to take a reference (e.g.,
ViewVertex&) instead of a pointer (e.g., ViewVertex *). The changed
converters and their new function prototypes are listed below. These
converters now return a Python wrapper object that retains the passed
reference, instead of retaining a newly created C++ object by the
converters.
// Interface0D converters
PyObject * BPy_Interface0D_from_Interface0D( Interface0D& if0D );
PyObject * BPy_CurvePoint_from_CurvePoint( CurvePoint& cp );
PyObject * BPy_StrokeVertex_from_StrokeVertex( StrokeVertex& sv );
PyObject * BPy_SVertex_from_SVertex( SVertex& sv );
PyObject * BPy_ViewVertex_from_ViewVertex( ViewVertex& vv );
PyObject * BPy_TVertex_from_TVertex( TVertex& tv );
PyObject * BPy_NonTVertex_from_NonTVertex( NonTVertex& ntv );
// Interface1D converters
PyObject * BPy_Interface1D_from_Interface1D( Interface1D& if1D );
PyObject * BPy_Chain_from_Chain( Chain& c );
PyObject * BPy_FEdge_from_FEdge( FEdge& fe );
PyObject * BPy_FEdgeSharp_from_FEdgeSharp( FEdgeSharp& fes );
PyObject * BPy_FEdgeSmooth_from_FEdgeSmooth( FEdgeSmooth& fes );
PyObject * BPy_Stroke_from_Stroke( Stroke& s );
PyObject * BPy_ViewEdge_from_ViewEdge( ViewEdge& ve );
PyObject * BPy_directedViewEdge_from_directedViewEdge( ViewVertex::directedViewEdge& dve );
// some other converters
PyObject * BPy_ViewShape_from_ViewShape( ViewShape& vs );
PyObject * BPy_SShape_from_SShape( SShape& ss );
PyObject * BPy_FrsMaterial_from_FrsMaterial( FrsMaterial& m );
PyObject * BPy_StrokeAttribute_from_StrokeAttribute( StrokeAttribute& sa );
* Added a "borrowed" flag to the definitions of Python types being
used to wrap C++ components of Freestyle's internal data structures.
The flag indicates whether or not a Python wrapper object has a
reference to a C++ object that comprises the internal data structures.
The deallocation routines of the Python types check this flag and
release a wrapped C++ object only when it is not part of the internal
data structures. The following files were modified:
python/BPy_FrsMaterial.{cpp,h}
python/BPy_Interface0D.{cpp,h}
python/BPy_Interface1D.{cpp,h}
python/BPy_SShape.{cpp,h}
python/BPy_StrokeAttribute.{cpp,h}
python/BPy_ViewShape.{cpp,h}
python/Interface0D/BPy_CurvePoint.cpp
python/Interface0D/BPy_SVertex.cpp
python/Interface0D/BPy_ViewVertex.cpp
python/Interface0D/CurvePoint/BPy_StrokeVertex.cpp
python/Interface0D/ViewVertex/BPy_NonTVertex.cpp
python/Interface0D/ViewVertex/BPy_TVertex.cpp
python/Interface1D/BPy_FEdge.cpp
python/Interface1D/BPy_FrsCurve.cpp
python/Interface1D/BPy_Stroke.cpp
python/Interface1D/BPy_ViewEdge.cpp
python/Interface1D/Curve/BPy_Chain.cpp
python/Interface1D/FEdge/BPy_FEdgeSharp.cpp
python/Interface1D/FEdge/BPy_FEdgeSmooth.cpp
* view_map/Interface[01]D.h, python/BPy_Interface[01]D.cpp: Removed
from the Interface0D and Interface1D C++ classes a back pointer to a
Python wrapper object and all "director" calls. These classes (and
their subclasses) are used to build Freestyle's main data structures
(such as a view map and strokes) and their class hierarchy is static.
Python wrappers of these C++ classes are only used to access the data
structures from the Python layer, and not intended to extend the data
structures by subclassing the Python wrappers. Without the necessity
of subclassing in the Python layer, the back pointer to a wrapping
Python object and "director" calls would be useless (actually they
were not used at all), so they were all removed.
* python/Director.{cpp,h}: Removed the definitions of directors that
were no longer used.
* stroke/Stroke.{cpp,h}: Removed an (unused) back pointer to a Python
wrapper object.
* python/BPy_ViewMap.cpp: Fixed a possible null pointer reference.
* python/Interface1D/BPy_FEdge.cpp: Fixed parameter checking in
FEdge___init__().
method returns a non-functional orientedViewEdgeIterator instance.
The iteration from the end to the beginning of the sequence relies
on orientedViewEdgeIterator::decrement() which is not actually
implemented in the C++ class. As a quick fix, the edgesEnd method
now raises a NotImplementedError.
orientedViewEdgeIterator.
* Simplified Python-related error handling in C++ class definitions.
The definitions of the following C++ methods were simplified and most
code segments using the C/Python API were moved to Director.cpp.
ChainingIterator::init()
ChainingIterator::traverse()
UnaryPredicate0D::operator()()
UnaryPredicate1D::operator()()
BinaryPredicate0D::operator()()
BinaryPredicate1D::operator()()
UnaryFunction0D::operator()()
UnaryFunction1D::operator()()
StrokeShader.shade()
* Moved part of the introspection-based automatic type conversion code
from BPy_Interface0DIterator.cpp and Director.cpp to BPy_Convert.cpp
for the sake of better code organization.
* Fixed an uninitialized member in StrokeVertexIterator___init__().
iterator protocol. Now the following code in the conventional
SWIG-based syntax:
it = AdjacencyIterator(iter)
while not it.isEnd():
ve = it.getObject()
...
it.increment()
can be written using the iterator protocol as follows:
for ve in AdjacencyIterator(iter):
...
* Fixed uninitialized fields in the "__init__" methods of UnaryFunction0D
types. Also added missing argument validation codes to some of the types,
and removed redundant validation error messages.
built-in types (the first was in revision 21877). When an exception
has raised within from the __init__ method of a user-defined class
derived from a built-in type (e.g., UnaryPredicate0D and
BinaryPredicate1D), some member variables of the base type are
left uninitialized, leading to a null pointer reference in the
"__dealloc__" function in the base type. To avoid this, pointer
checking was added in the deallocators of those built-in types that
can be used to define a subclass by a user.
callable(I, T) returns True when I is an object of a type T or
of a subtype of T. Also implemented a measure to avoid an
infinite loop when user-defined predicate and function classes
do not properly overload the __call__ method (including the
cases of directly instantiating the base classes such as
UnaryPredicate0D and BinaryPredicate1D).
AdjacencyIterator::isBegin() and AdjacencyIterator::isEnd() always
returned a False value and printed a "not implemented" warning message.
This caused an infinite loop in a few chaining iterators, resulting in
a crash of the program. The origin of the issue seemed to be a fact
that in the C++ layer, the AdjacencyIterator class had not properly
overloaded the definitions of the methods in the Iterator superclass.
The fix here looks okay, although I'm not sure why this inconsistency
was not addressed for a long time.
Now the following methods in the Freestyle Python API accept
not only Blender.Mathutils.Vector instances but also lists and
tuples having an appropriate number of elements.
FrsNoise::turbulence2()
FrsNoise::turbulence3()
FrsNoise::smoothNoise2()
FrsNoise::smoothNoise3()
SVertex::__init__()
SVertex::setPoint3D()
SVertex::setPoint2D()
SVertex::AddNormal()
FEdgeSharp::setNormalA()
FEdgeSharp::setNormalB()
FEdgeSmooth::setNormal()
CalligraphicShader::__init__()
StrokeAttribute::setAttributeVec2f()
StrokeAttribute::setAttributeVec3f()
StrokeAttribute::setColor()
StrokeVertex::setPoint()
* Added the following converters for the sake of the improvements
mentioned above.
Vec2f_ptr_from_PyObject()
Vec3f_ptr_from_PyObject()
Vec3r_ptr_from_PyObject()
Vec2f_ptr_from_PyList()
Vec3f_ptr_from_PyList()
Vec3r_ptr_from_PyList()
Vec2f_ptr_from_PyTuple()
Vec3f_ptr_from_PyTuple()
Vec3r_ptr_from_PyTuple()
Those converters with the suffixes _PyList and _PyTuple accept
only lists and tuples having an appropriate number of elements,
respectively, while those with the suffix _PyObject accept lists,
tuples, or Blender.Mathutils.Vector instances.
* Fixed a null pointer reference in Interface0D___dealloc__().
* Corrected the names of 3 methods in the FEdgeSmooth class.
to a specific Python object. The conversion takes place in the following
places.
- Interface0DIterator_getObject (BPy_Interface0DIterator.cpp)
- Director_BPy_BinaryPredicate1D___call__ (Director.cpp)
- Director_BPy_UnaryPredicate1D___call__ (Director.cpp)
- SVertex_viewvertex (BPy_SVertex.cpp)
- BPy_FEdge_from_FEdge (BPy_Convert.cpp)
This is a tentative list and more conversions are expected to be added.
* Added the following two converter functions to BPy_Convert.{cpp,h}:
- BPy_NonTVertex_from_NonTVertex_ptr
- BPy_TVertex_from_TVertex_ptr
Freestyle's pipeline is now fully controllable at the layer level. It can be used:
- in any render layer
- with as many style modules per layer
DETAILS:
Freestyle usage has not changed:
- all the configuration happens in the "Freestyle" render panel, after it is enabled in the "Output" panel with the 'Freestyle' toggle.
- each render layer can choose to render Freestyle strokes by togglingo on 'FrSt' (in the "Render Layers" panel)
- it is fully compatible with compositor nodes
In the "Freestyle" panel, a render layer is selected via the menu list next to the "Render Layer:" label. The options displayed below are those of the currently selected render layer (and are not global to all render layers, as was previously the case).
Style modules are added by pressing the lower button "Add style module". Once added, the following operations are possible:
- deletion (cross)
- reordering (up/down arrows)
- toggling of display (check)
The order of the style modules follows Freestyle's original convention: the modules in the list from top to bottom are respectively the first to the last composited in the render layer. For example, if the module list is "contour" followed by "cartoon", the "cartoon" strokes are rendered on top of the "contour" strokes.
The "Freestyle" panel is constantly synchronized with the "Render Layers" panel: if render layers are added, deleted or toggled off display, Freestyle will take note of the changes.
The current pipeline works as follows:
----------------------------------------------------------------------------------------------
for every scene that is being rendered
if Freestyle is enabled globally
Freestyle is initialized
camera and view settings are transferred from Blender to Freestyle
for every render layer
if: - layer is enabled
- layer enabled Freestyle
- the number of displayed style modules is non-zero
canvas is cleared
geometry is transferred from Blender to Freestyle
settings are fixed for current iteration
view map is calculated
strokes are computed in the canvas (based on view map and style modules)
strokes are rendered in separate Blender scene
scene is composited in current layer
----------------------------------------------------------------------------------------------
A number of changes were made on the codebase:
- the rendering interface between Freestyle and Blender was simplified. The following naming convention was used: functions that are called from within Blender pipeline are prefixed with 'FRS_', while the variables are prefixed with 'freestyle_'
- Freestyle data structures that were put in Blender's render pipeline were removed
- Freestyle cleans up its data structures on Blender exit and shouldn't leak memory
- to ease the configuration in the "Freestyle" panel, a centralized configuration data structure was used and can be easily extended
LIMITATIONS
Even though the current commit is stable and achieves the intended result, it is not as efficient as it could be:
- the canvas and the style modules are at cleared at each layer-level render
- geometry is reloaded at each frame and is duplicated across render layers
This revision clarifies my understanding of the future role of the view map in the compositor. Unfortunately, contrary to what the original proposal said, it is impossible to provide the view map as a render pass because render passes are defined (RE_pipeline.h) as raw floating-point rects. We will have to determine whether or not to extend the notion of render pass to fully integrate the view map in the compositor.
* Changed BPy_CurvePoint_from_CurvePoint( CurvePoint& cp ) to
BPy_CurvePoint_from_CurvePoint_ptr( CurvePoint *cp ) so that it
retains a CurvePoint pointer instead of a CurvePoint instance.
