* 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.
Now this method accepts 2D coordinates in the following three forms:
a) Python list of 2 real numbers: setPoint([x, y])
b) Blender Vector of 2 elements: setPoint(Vector(x, y))
c) 2 real numbers: setPoint(x, y)
[The log of Revision 19283 had a wrong message...]
Now this method accepts 2D coordinates in the following three forms:
a) Python list of 2 real numbers: setPoint([x, y])
b) Blender Vector of 2 elements: setPoint(Vector(x, y))
c) 2 real numbers: setPoint(x, y)
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.
Other methods could easily be supported in the future. The method now works as planned for the contour style. For style modules with Python shaders, there still is a problem that I will fix right away.
To make it work, I had to:
- update Operators to include all of its methods in the Python API
- redefine the Freestyle modules as local classes, allowing predicates to support the __call__ method (I found out that Python does not allow modules to be callable). The API is defined in the new freestyle_init.py file.
- remove all references to former Python Freestyle API (located in source/blender/freestyle/python/, under the Freestyle.py file) and replace it with the new API file.
- normalize all constants related to the Nature class
- redefine the logical_operators.py file so that AndUP1D, OrUP1D and NotUP1D would be subclasses of a UnaryPredicate1D subclass having a operator() implementation. Using UnaryPredicate1D as a superclass would somehow prevent calls to the operator(). For the time being, I chose ContourUP1D (even though it does not really matter which subclass it is, since the __call__ method is redefined in all of these classes). I will implement this classes in C++ to get rid of the problem altogether.
- turn off a few classes that somehow are not well recognized (Noise, Curve...). I will reenable them later once I understand what's going on.
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.
There is just one more class remaining to port (and probably the most important): Operators. After that, I'll be able to test whether Freestyle functions well without SWIG.
- getExactTypeName()
- increment()
- decrement()
- isBegin()
- isEnd()
Contrary to previously stated, I am reverting back to implementing iterators in the (Python) API, for different reasons:
- it will make testing quicker to achieve, as I won't have to recode a big chunk of the original Python files
- it will be a base for API refactoring
- it won't prevent the use a list-based approach later (it is simple to get it from the Iterator)
