archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
d62f844b124b75976abf62f12306ecf14befef3f
blender-archive/source/blender/freestyle/intern/python/BPy_UnaryPredicate0D.cpp

205 lines
6.9 KiB
C++
Raw Normal View History

soc-2008-mxcurioni: renamed all Freestyle API related files with 'BPy_' prefix to avoid library name collision. Included MediumType's initialization at proper time to avoid Blender's crash.
2008-07-23 07:56:08 +00:00
#include "BPy_UnaryPredicate0D.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
soc-2008-mxcurioni: renamed all Freestyle API related files with 'BPy_' prefix to avoid library name collision. Included MediumType's initialization at proper time to avoid Blender's crash.
2008-07-23 07:56:08 +00:00
#include "BPy_Convert.h"
soc-2008-mxcurioni: completed implementing ViewEdgeIterator and ChainingIterator. Updated UnaryPredicate{0D,1D}
2008-07-26 19:32:47 +00:00
#include "Iterator/BPy_Interface0DIterator.h"
soc-2008-mxcurioni: add all predicate subclasses( BinaryPredicate1D, 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.
2008-07-28 22:53:42 +00:00
#include "UnaryPredicate0D/BPy_FalseUP0D.h"
#include "UnaryPredicate0D/BPy_TrueUP0D.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
#ifdef __cplusplus
extern "C" {
#endif
///////////////////////////////////////////////////////////////////////////////////////////
/*--------------- Python API function prototypes for UnaryPredicate0D instance -----------*/
static int UnaryPredicate0D___init__(BPy_UnaryPredicate0D *self, PyObject *args, PyObject *kwds);
static void UnaryPredicate0D___dealloc__(BPy_UnaryPredicate0D *self);
static PyObject * UnaryPredicate0D___repr__(BPy_UnaryPredicate0D *self);
soc-2008-mxcurioni: add all predicate subclasses( BinaryPredicate1D, 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.
2008-07-28 22:53:42 +00:00
static PyObject * UnaryPredicate0D_getName( BPy_UnaryPredicate0D *self );
Made predicate and function types callable in the sense that callable(I, T) returns True when I is an object of a type T or of a subtype of T. Also implemented a measure to avoid an infinite loop when user-defined predicate and function classes do not properly overload the __call__ method (including the cases of directly instantiating the base classes such as UnaryPredicate0D and BinaryPredicate1D).
2009-07-26 16:15:28 +00:00
static PyObject * UnaryPredicate0D___call__( BPy_UnaryPredicate0D *self, PyObject *args, PyObject *kwds);
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
/*----------------------UnaryPredicate0D instance definitions ----------------------------*/
static PyMethodDef BPy_UnaryPredicate0D_methods[] = {
soc-2008-mxcurioni: add all predicate subclasses( BinaryPredicate1D, 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.
2008-07-28 22:53:42 +00:00
{"getName", ( PyCFunction ) UnaryPredicate0D_getName, METH_NOARGS, "Returns the string of the name of the UnaryPredicate0D."},
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
{NULL, NULL, 0, NULL}
};
/*-----------------------BPy_UnaryPredicate0D type definition ------------------------------*/
PyTypeObject UnaryPredicate0D_Type = {
PyObject_HEAD_INIT( NULL )
0, /* ob_size */
"UnaryPredicate0D", /* tp_name */
sizeof( BPy_UnaryPredicate0D ), /* tp_basicsize */
0, /* tp_itemsize */
/* methods */
(destructor)UnaryPredicate0D___dealloc__, /* tp_dealloc */
NULL, /* printfunc tp_print; */
NULL, /* getattrfunc tp_getattr; */
NULL, /* setattrfunc tp_setattr; */
NULL, /* tp_compare */
(reprfunc)UnaryPredicate0D___repr__, /* tp_repr */
/* Method suites for standard classes */
NULL, /* PyNumberMethods *tp_as_number; */
NULL, /* PySequenceMethods *tp_as_sequence; */
NULL, /* PyMappingMethods *tp_as_mapping; */
/* More standard operations (here for binary compatibility) */
NULL, /* hashfunc tp_hash; */
Made predicate and function types callable in the sense that callable(I, T) returns True when I is an object of a type T or of a subtype of T. Also implemented a measure to avoid an infinite loop when user-defined predicate and function classes do not properly overload the __call__ method (including the cases of directly instantiating the base classes such as UnaryPredicate0D and BinaryPredicate1D).
2009-07-26 16:15:28 +00:00
(ternaryfunc)UnaryPredicate0D___call__, /* ternaryfunc tp_call; */
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
NULL, /* reprfunc tp_str; */
NULL, /* getattrofunc tp_getattro; */
NULL, /* setattrofunc tp_setattro; */
/* Functions to access object as input/output buffer */
NULL, /* PyBufferProcs *tp_as_buffer; */
/*** Flags to define presence of optional/expanded features ***/
Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE, /* long tp_flags; */
NULL, /* char *tp_doc; Documentation string */
/*** Assigned meaning in release 2.0 ***/
/* call function for all accessible objects */
NULL, /* traverseproc tp_traverse; */
/* delete references to contained objects */
NULL, /* inquiry tp_clear; */
/*** Assigned meaning in release 2.1 ***/
/*** rich comparisons ***/
NULL, /* richcmpfunc tp_richcompare; */
/*** weak reference enabler ***/
0, /* long tp_weaklistoffset; */
/*** Added in release 2.2 ***/
/* Iterators */
NULL, /* getiterfunc tp_iter; */
NULL, /* iternextfunc tp_iternext; */
/*** Attribute descriptor and subclassing stuff ***/
BPy_UnaryPredicate0D_methods, /* struct PyMethodDef *tp_methods; */
NULL, /* struct PyMemberDef *tp_members; */
NULL, /* struct PyGetSetDef *tp_getset; */
NULL, /* struct _typeobject *tp_base; */
NULL, /* PyObject *tp_dict; */
NULL, /* descrgetfunc tp_descr_get; */
NULL, /* descrsetfunc tp_descr_set; */
0, /* long tp_dictoffset; */
(initproc)UnaryPredicate0D___init__, /* initproc tp_init; */
NULL, /* allocfunc tp_alloc; */
PyType_GenericNew, /* newfunc tp_new; */
/* Low-level free-memory routine */
NULL, /* freefunc tp_free; */
/* For PyObject_IS_GC */
NULL, /* inquiry tp_is_gc; */
NULL, /* PyObject *tp_bases; */
/* method resolution order */
NULL, /* PyObject *tp_mro; */
NULL, /* PyObject *tp_cache; */
NULL, /* PyObject *tp_subclasses; */
NULL, /* PyObject *tp_weaklist; */
NULL
};
//-------------------MODULE INITIALIZATION--------------------------------
PyMODINIT_FUNC UnaryPredicate0D_Init( PyObject *module )
{
if( module == NULL )
return;
if( PyType_Ready( &UnaryPredicate0D_Type ) < 0 )
return;
Py_INCREF( &UnaryPredicate0D_Type );
PyModule_AddObject(module, "UnaryPredicate0D", (PyObject *)&UnaryPredicate0D_Type);
soc-2008-mxcurioni: add all predicate subclasses( BinaryPredicate1D, 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.
2008-07-28 22:53:42 +00:00
if( PyType_Ready( &FalseUP0D_Type ) < 0 )
return;
Py_INCREF( &FalseUP0D_Type );
PyModule_AddObject(module, "FalseUP0D", (PyObject *)&FalseUP0D_Type);
if( PyType_Ready( &TrueUP0D_Type ) < 0 )
return;
Py_INCREF( &TrueUP0D_Type );
PyModule_AddObject(module, "TrueUP0D", (PyObject *)&TrueUP0D_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
}
//------------------------INSTANCE METHODS ----------------------------------
int UnaryPredicate0D___init__(BPy_UnaryPredicate0D *self, PyObject *args, PyObject *kwds)
{
soc-2008-mxcurioni: completed implementing ViewEdgeIterator and ChainingIterator. Updated UnaryPredicate{0D,1D}
2008-07-26 19:32:47 +00:00
self->up0D = new UnaryPredicate0D();
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
self->up0D->py_up0D = (PyObject *) self;
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
return 0;
}
void UnaryPredicate0D___dealloc__(BPy_UnaryPredicate0D* self)
{
Second attempt to fix a null pointer reference in deallocators of built-in types (the first was in revision 21877). When an exception has raised within from the __init__ method of a user-defined class derived from a built-in type (e.g., UnaryPredicate0D and BinaryPredicate1D), some member variables of the base type are left uninitialized, leading to a null pointer reference in the "__dealloc__" function in the base type. To avoid this, pointer checking was added in the deallocators of those built-in types that can be used to define a subclass by a user.
2009-07-26 20:20:25 +00:00
if (self->up0D)
delete self->up0D;
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
self->ob_type->tp_free((PyObject*)self);
soc-mx-2008: SWIG dependency - wrapper functions extracted from ModuleWrapper.cpp
2008-07-09 08:24:13 +00:00
}
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
PyObject * UnaryPredicate0D___repr__(BPy_UnaryPredicate0D* self)
{
return PyString_FromFormat("type: %s - address: %p", self->up0D->getName().c_str(), self->up0D );
soc-mx-2008: SWIG dependency - wrapper functions extracted from ModuleWrapper.cpp
2008-07-09 08:24:13 +00:00
}
soc-2008-mxcurioni: add all predicate subclasses( BinaryPredicate1D, 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.
2008-07-28 22:53:42 +00:00
PyObject * UnaryPredicate0D_getName( BPy_UnaryPredicate0D *self )
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
{
return PyString_FromString( self->up0D->getName().c_str() );
soc-mx-2008: SWIG dependency - wrapper functions extracted from ModuleWrapper.cpp
2008-07-09 08:24:13 +00:00
}
Made predicate and function types callable in the sense that callable(I, T) returns True when I is an object of a type T or of a subtype of T. Also implemented a measure to avoid an infinite loop when user-defined predicate and function classes do not properly overload the __call__ method (including the cases of directly instantiating the base classes such as UnaryPredicate0D and BinaryPredicate1D).
2009-07-26 16:15:28 +00:00
PyObject * UnaryPredicate0D___call__( BPy_UnaryPredicate0D *self, PyObject *args, PyObject *kwds)
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
{
soc-2008-mxcurioni: completed implementing ViewEdgeIterator and ChainingIterator. Updated UnaryPredicate{0D,1D}
2008-07-26 19:32:47 +00:00
PyObject *py_if0D_it;
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
Made predicate and function types callable in the sense that callable(I, T) returns True when I is an object of a type T or of a subtype of T. Also implemented a measure to avoid an infinite loop when user-defined predicate and function classes do not properly overload the __call__ method (including the cases of directly instantiating the base classes such as UnaryPredicate0D and BinaryPredicate1D).
2009-07-26 16:15:28 +00:00
if( kwds != NULL ) {
PyErr_SetString(PyExc_TypeError, "keyword argument(s) not supported");
return NULL;
}
Improvements in error handling at Python-C++ boundaries.
2009-03-20 22:41:27 +00:00
if( !PyArg_ParseTuple(args, "O!", &Interface0DIterator_Type, &py_if0D_it) )
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
return NULL;
soc-2008-mxcurioni: completed implementing ViewEdgeIterator and ChainingIterator. Updated UnaryPredicate{0D,1D}
2008-07-26 19:32:47 +00:00
Interface0DIterator *if0D_it = ((BPy_Interface0DIterator *) py_if0D_it)->if0D_it;
Improvements in error handling at Python-C++ boundaries.
2009-03-20 22:41:27 +00:00
if( !if0D_it ) {
string msg(self->up0D->getName() + " has no Interface0DIterator");
PyErr_SetString(PyExc_RuntimeError, msg.c_str());
return NULL;
}
Made predicate and function types callable in the sense that callable(I, T) returns True when I is an object of a type T or of a subtype of T. Also implemented a measure to avoid an infinite loop when user-defined predicate and function classes do not properly overload the __call__ method (including the cases of directly instantiating the base classes such as UnaryPredicate0D and BinaryPredicate1D).
2009-07-26 16:15:28 +00:00
if( typeid(*(self->up0D)) == typeid(UnaryPredicate0D) ) {
PyErr_SetString(PyExc_TypeError, "__call__ method must be overloaded");
return NULL;
}
Improvements in error handling at Python-C++ boundaries.
2009-03-20 22:41:27 +00:00
if (self->up0D->operator()(*if0D_it) < 0) {
if (!PyErr_Occurred()) {
string msg(self->up0D->getName() + " __call__ method failed");
PyErr_SetString(PyExc_RuntimeError, msg.c_str());
}
return NULL;
}
return PyBool_from_bool( self->up0D->result );
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
soc-mx-2008: SWIG dependency - wrapper functions extracted from ModuleWrapper.cpp
2008-07-09 08:24:13 +00:00
Copy Permalink