- 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)
Before porting other classes, I'll resolve the List (Python) <=> Iterator (C++) correspondence problem by implementing a general class appropriately suited for the task.
I realized today that it will not be possible to implement getter/setter functionality easily for our Freestyle API. The reason is that Python does not support function overloading as-is. It is possible to 'fake' overloading by taking a general argument object and count the number of arguments in the object (rgbTuple_setCol in Blender's API is a good example of how to go about it).
For the time being, we'll get around that problem. The tangible effect of that constraint is that all API setter functions return a 'None' PyObject, instead of returning an integer status code. It is important to note that this problem is due to Freestyle's API being C++ in nature. Fortunately, this shouldn't really impact the usage of the API.
If the Blender Python group wants me to correct that, I'll be able to do it. It is just going to take me quite some time correcting it, writing support functions for methods having different types of arguments.
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.
UnaryFunction0D and UnaryFunction1D implementations are going to be really challenging due to the changes in the infrastructure: UnaryFunction0D<T> and UnaryFunction0D<T> are templates and must be determined for compile-time. The easiest solution is to support each type individually; unfortunately, it removes the benefit of using an interface. To find a middle ground, a general unary function Python object type was created for 0D and 1D. In both cases, the types have a void* pointer keeping the address of the current unary function type. I am not sure yet if it will work.
Interface0DIterator being removed by a list type, the t() and u() coordinate functions will to be transferred somehow, probably directly at the Interface0D level.
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.
To make our base classes subclasses, the Py_TPFLAGS_BASETYPE flag was added to the object type tp_flags slot.
Finally, I began to implement CurvePoint, descendant of Interface0D. This commit allowed me to verify that my SWIG replacement method works: interfaces are well taken into account by children. For a test, use the following code:
================================
import Blender
from Blender import Freestyle
from Blender.Freestyle import *
print Interface0D()
print CurvePoint()
================================
The __repr__ method is only implemented in Interface0D:
PyObject * Interface0D___repr__(BPy_Interface0D* self)
{
return PyString_FromFormat("type: %s - address: %p", self->if0D->getExactTypeName().c_str(), self->if0D );}
and the result is of the form:
type: Interface0D - address: 0x18e5ccc0
type: CurvePoint - address: 0x18e473f0
As you can see, the correct getExactTypeName of the class is called.
Interface0DIterator was modified to allow BPy_Interface1D to be instantiated: verticesBegin(), verticesEnd(), pointsBegin(float) and pointsEnd(float) are not pure virtual functions anymore. If they are called directly from BPy_Interface1D (instead of its subclasses), an error message is displayed.
