blender-archive/source/blender/freestyle/intern/python/BPy_UnaryFunction1D.h

#ifndef FREESTYLE_PYTHON_UNARYFUNCTION1D_H
#define FREESTYLE_PYTHON_UNARYFUNCTION1D_H

#include "../view_map/Functions1D.h"

#ifdef __cplusplus
extern "C" {
#endif

///////////////////////////////////////////////////////////////////////////////////////////

#include <Python.h>

extern PyTypeObject UnaryFunction1D_Type;

#define BPy_UnaryFunction1D_Check(v)	(  PyObject_IsInstance( (PyObject *) v, (PyObject *) &UnaryFunction1D_Type)  )

/*---------------------------Python BPy_UnaryFunction1D structure definition----------*/
typedef struct {
	PyObject_HEAD
	PyObject *py_uf1D;
} BPy_UnaryFunction1D;

/*---------------------------Python BPy_UnaryFunction1D visible prototypes-----------*/

int UnaryFunction1D_Init( PyObject *module );

///////////////////////////////////////////////////////////////////////////////////////////

#ifdef __cplusplus
}
#endif

#endif /* FREESTYLE_PYTHON_UNARYFUNCTION1D_H */
soc-2008-mxcurioni: canvas for UnaryFunction0D, UnaryFunction1D, 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. 2008-07-18 04:59:07 +00:00			`#ifndef FREESTYLE_PYTHON_UNARYFUNCTION1D_H`
			`#define FREESTYLE_PYTHON_UNARYFUNCTION1D_H`

			`#include "../view_map/Functions1D.h"`

			`#ifdef __cplusplus`
			`extern "C" {`
			`#endif`

			`///////////////////////////////////////////////////////////////////////////////////////////`

			`#include <Python.h>`

			`extern PyTypeObject UnaryFunction1D_Type;`

soc-2008-mxcurioni: finished porting the Freestyle API. All of the original 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. 2008-07-29 05:45:16 +00:00			`#define BPy_UnaryFunction1D_Check(v) ( PyObject_IsInstance( (PyObject ) v, (PyObject ) &UnaryFunction1D_Type) )`
soc-2008-mxcurioni: canvas for UnaryFunction0D, UnaryFunction1D, 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. 2008-07-18 04:59:07 +00:00
			`/---------------------------Python BPy_UnaryFunction1D structure definition----------/`
			`typedef struct {`
			`PyObject_HEAD`
soc-2008-mxcurioni: the native Python system now supports cross-language 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. 2008-07-31 08:50:12 +00:00			`PyObject *py_uf1D;`
soc-2008-mxcurioni: canvas for UnaryFunction0D, UnaryFunction1D, 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. 2008-07-18 04:59:07 +00:00			`} BPy_UnaryFunction1D;`

			`/---------------------------Python BPy_UnaryFunction1D visible prototypes-----------/`

Made the Freestyle Python API compatible with Python 3. 2009-09-27 00:32:20 +00:00			`int UnaryFunction1D_Init( PyObject *module );`
soc-2008-mxcurioni: canvas for UnaryFunction0D, UnaryFunction1D, 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. 2008-07-18 04:59:07 +00:00
			`///////////////////////////////////////////////////////////////////////////////////////////`

			`#ifdef __cplusplus`
			`}`
			`#endif`

			`#endif /* FREESTYLE_PYTHON_UNARYFUNCTION1D_H */`