Addition of the path to the Freestyle Python API modules to 'sys.path' was delayed until
the first Freestyle rendering, so that any import attempt of the modules in the Python
Console always failed. Now the update of 'sys.path' is done at Blender start-up.
This allows the Freestyle-specific modules to be imported without running Freestyle,
facilitating quick interactive testing in the Console.
Both C- and Python-coded API components were rearranged into logical groups.
New Python modules are packaged as follows:
freestyle - Top-level package
freestyle.types - Classes for core data structues (e.g., view map)
freestyle.chainingiterators - Pre-defined chaining iterators
freestyle.functions - Pre-defined 0D and 1D functions
freestyle.predicates - Pre-defined 0D and 1D predicates
freestyle.shaders - Pre-defined stroke shaders
freestyle.utils - Utility functions
The Python modules are installed in scripts/freestyle/modules. Pre-defined
styles are installed in scripts/freestyle/styles.
To-do: update styles according to the new Freestyle API package structure.
occasional unexpected long lines.
1. The Parameter Editor mode was extended to prevent strokes from
doing quick U-turns that "enable" a known bug in strip creation
that generates unexpected long lines in question.
2. A verbose warning message was added to make the existence of
the strip creation bug visible to users. When the bug affects the
stroke rendering, the following warning shows up in the console:
> Warning: problem in strip creation (the strip is most likely doing a U-turn).
3. The extrapolation option of CurveMapping (used in alpha and
thickness modifiers in the Parameter Editor mode) was identified
as another source of unexpected long lines. Now the extrapolation
option is unconditionally disabled (even when users enable it
through the GUI).
* evaluateColorRamp() to evaluate a color ramp at a given point in
the interval 0 to 1.
* evaluateCurveMappingF() to evaluate a curve mapping at a given
point in the interval 0 to 1.
(http://freestyle.sourceforge.net/doc/html/index.html) has been
incorporated into the Blender/Freestyle Python API implementation
in the form of Sphinx-based embedded docstrings. Some C++-specific
descriptions of classes and functions were revised so that they are
suitable for Python programmers. Missing docstrings were filled,
and sparse descriptions were extended. By means of the new
documentation system for Blender, an up-to-date Freestyle Python
API reference will be part of the Blender 2.5 documentation.
from within style modules. Calling this function is only valid within
style modules. Calling it from the Python Interactive Console results
in an error as follows:
>>> import Freestyle
>>> Freestyle.getCurrentScene()
Traceback (most recent call last):
File "<console>", line 1, in <module>
TypeError: current scene not available
>>>
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.
- 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)
