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.
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.
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.
I analyzed the crash with gdb and PyImport_AddModule ("__main__") in Python/import.c:320 seems responsible for the crash: apparently, "__main__" is not found and causes the error "No such file or directory".
I have to figure out what's wrong with the current configuration, especially whether Freestyle's PythonInterpreter can be used as is. I am going to see whether it's just quicker to use Blender's functions.
1. instantiates the config path, the controller and the view
2. sets the controller’s view
3. loads a 3ds file (right now a fixed file)
4. inserts a style module (right now, also fixed)
5. computes the view map
The next and final step is running the Python script. A lot of information are fixed and should be changed to test the following code: see source/blender/freestyle/app_blender/*.cpp and search for fixed paths (starting in /Users/).
I am currently evaluating whether it's worth making Python run on its own environment (right now, the program crashes because of PyImport_AddModule) or whether it should use Blender's Python capabilities. Also, I need to figure out how to integrate the SWIG wrapper dynamic library into the current scheme.
