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.
freestyle_init.py
* Added a generic getName() method that allows subclasses to omit the method to return their class names.
BPy_Convert.cpp
BPy_Convert.h
* Added to BPy_StrokeVertexIterator_from_StrokeVertexIterator() a second argument to specify the direction (reversed or not) of the iterator to be created.
BPy_Stroke.cpp
* Added support for Python's native iterator protocol.
* Added code to parse the optional argument of strokeVerticesBegin().
BPy_StrokeVertexIterator.cpp
BPy_StrokeVertexIterator.h
* Added support for Python's native iterator protocol.
Stroke.cpp
* Fixed a null pointer reference.
Stroke.h
* Added new method Stroke::strokeVerticeAt(i) that returns the i-th StrokeVertex of the Stroke.
All of the reference to the original Material class were renamed to FrsMaterial to resolve a name collision with Blender. To keep the window context necessary to draw the strokes after RE_Database_FromScene has been called, the display_clear function is used.
Quite a few modifications were made to finish the API:
- Freestyle's SConscript was modified to catch all files within the intern/python directory, allowing integration of future shaders implemented in C++.
- the Operators class was ported, with a special care of making its methods static (using the METH_STATIC flag in the tp_methods method definitions)
- all of the type-checking functions [ BPy_[class name]_Check(obj) ] were changed to allow subclasses to be seen as that type too: instead on looking at the ob_type value, the PyObject_IsInstance function is used.
- all of the iterators can now retrieve the object pointed to by the operator, using the getObject() method. A directedViewEdge pair is returned as a list of the two elements in the pair.
- all of the style modules were copied to a style_modules_blender/ folder and were modified to use Freestyle as a Blender's submodule. IntegrationType and MediumType was also integrated (for example, changing MEAN to IntegrationType.MEAN).
Testing now begins. If everything works correctly, I'll move on to lib3ds removal right away.
Before porting other classes, I'll resolve the List (Python) <=> Iterator (C++) correspondence problem by implementing a general class appropriately suited for the task.
IMPORTANT: The setters functions' names were normalized due to constant confusion regarding capitalization. All the function names start with set... instead of Set.... This convention was changed all throughout Freestyle. To use Freestyle as an external renderer, the SWIG library MUST be regenerated.
So far, whenever a Python object is created from its corresponding C++ object, the input object reference is copied into a new object. Due to Freestyle's functions (especially regarding the way it is iterated), it is currently impossible to deal with a pointer-based Python object. It is not a real drawback, just an aspect to keep in mind.
From now on, when a set should be output (PySet_Type), it is given as a list (PyList_Type). The reason is that it doesn't really matter what we bring back to the Python interpreter. The set is guaranteed in memory on the C++ side.
For the CurvePoint class, the userdata variable is not yet ported (and will probably available as a list or a dictionary). The CurvePoint implementation works except for the initialization from other CurvePoints: somehow, the inner variables don't seem to be correctly handled. I do not know if it is a bug in Freestyle or if the CurvePoint object's state is correct for my test case. CurvePoint needs more testing.
