Age | Commit message (Collapse) | Author |
|
polymorphism for UnaryFunction0D, Interface0D, Interface1D. Add to change UnaryFunction1D<void> to static UnaryFunction1D_void. Resolved namespace collision on the Image class (changed to FrsImage). There is greater support for style modules but somehow, some do not show anything yet (japanese_bigbrush being an example).
|
|
|
|
|
|
modules having with strokes without a representation and iterators not being correctly routed. For example, the cartoon style module should work now.
|
|
freestyle_init.py (for Curve, Material and Noise)
|
|
by specifying its pathname. By default, it is loaded with the contour.py path.
|
|
polymorphism for the following classes: BinaryPredicate0D (__call__), BinaryPredicate1D (__call__), UnaryPredicate0D (__call__), UnaryPredicate1D (__call__), StrokeShader (shade), ChainingIterator (init, traverse).
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.
|
|
former predicate methods were not working. As Stéphane had mentioned a few months ago, Freestyle uses SWIG directors to provide cross-language polymorphism. The API and the system I had provided did not support that feature and only implementations in C++ were supported. To correct the problem, after researching how directors are implemented in SWIG, I provided the same functionality. So far, I only provided the code for the UnaryPredicate1D class and it works. The implementation is in intern/python/Director.cpp and Operators.cpp. I will port the remaining directors tonight and continue to test it.
To prevent strokes from piling up after each render, I clear the canvas at each render now (as it should have been all along)
|
|
subclasses and Curvature2DAngleF1D. Understood that Curve and Noise classes cannot be defined in Freestyle's API because they are already given by Blender's API. Will rename to FrsCurve and FrsNoise and change the corresponding style modules.
|
|
API renders a correct result for the test style module 'contour.py'. More testing needs to be done to make sure my work was correct.
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.
|
|
API renders a correct result for the test style module 'contour.py'. More testing needs to be done to make sure my work was correct.
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.
|
|
classes, except EdgeModifier and TimestampModifier (which aren't even ported via SWIG), are available under the Blender.Freestyle module. Testing of the porting will now begin to make sure the SWIG-less system works as the original.
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.
|
|
UnaryPredicate{0D,1D} ).
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.
|
|
|
|
|
|
classes. I will do the same for the 1D unary functions.
|
|
is that My approach seems to works (even though it is not fully testable as it needs Freestyle to be running). I will now port the 80 predicate subclasses left.
In this commit, UnaryPredicate0DDouble and its subclasses DensityF0D and LocalAverageDepthF0D are implemented and integrated in the API.
|
|
Updated ViewShape class accordingly
|
|
and ChainSilhouetteIterator
|
|
ChainingIterator. Updated UnaryPredicate{0D,1D}
|
|
Material, Chain, FEdgeSharp, FEdgeSmooth. All Interface1D classes have now been fully implemented.
|
|
All Interface0D structures have been implemented
|
|
|
|
Modified functions accross API taking input boolean values.
|
|
parts of ViewVertex, SVertex and Convert to support these changes.
|
|
internal view-map data. The internal namespaces (ViewEdgeInternal, ViewVertexInternal, CurveInternal, StrokeInternal...) should NOT be included to prevent redefintion errors.
|
|
header positioning problems and adapted classes accordingly
|
|
SShape, ViewShape. Also corrected a few typos (Get#->get#).
|
|
Interface0DIterator, CurvePointIterator, StrokeVertexIterator, SVertexIterator, orientedViewEdgeIterator.
|
|
Freestyle (on the C++ side). Created the equivalent in Python BPy_Iterator with the simple interface:
- 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)
|
|
prefix to avoid library name collision.
Included MediumType's initialization at proper time to avoid Blender's crash.
|
|
|
|
MediumType (used by Stroke to define medium types) classes. The Stroke class is missing the InsertVertex method.
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.
|
|
|
|
constants used throughout Freestyle
|
|
UnaryPredicate0D, UnaryPredicate1D.
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.
|
|
passing-by-reference format. Improved the type checking for FEdge and CurvePoint. Modified FEdge C++ class to test for null vertices. Updated previous classes to support FEdge.
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.
|
|
migration. Stabilized a lot of the code for C++ -> Python conversion. Added the correct rich comparison operator and tested it. Corrected 'dupplicate' typo and changde to __copy__ for Python API.
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.
|
|
classes. The Python object type tp_new slot is now set to PyType_GenericNew, instead of the former custom functions. As a note, by default, Python does not set this slot: it is therefore mandatory for the base classes. For children classes, only __init__ is needed.
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.
|
|
correctly used as classes and not submodules. Added and integrated object lifecycle functions (__new__, __alloc__, __repr__) for the previous classes: BinaryPredicate0D, BinaryPredicate1D, Id, Interface0D, Interface1D. All of these classes were tested within Blender's Python interpreter with simple test cases and their getter/setters were corrected.
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.
|
|
|
|
Freestyle module is added. The following modules are implemented: BinaryPredicate0D, BinaryPredicate1D, Id, Interface0D, Interface1D. I added a Convert module to help in the creation of Python objects for Freestyle's data structures. I also added a missing file for guarded_alloc needed for compilation on Windows.
|
|
colour and used in conjunction with softbodies
- changing particlesystem settings for hair particles cleared & recalculated everything even when hair softbody was baked
|
|
|
|
the returned string needs free'ing (Found with valgrind).
|
|
Autokey settings were missing redraw for Info-window
|
|
|