swig question: using another lib that deals in ogre classes?


31-08-2006 14:41:05

hey there,

regarding swig and python, i am still relatively noobish, so i apologise that this idea might be fundamentally flawed. i'm just trying to work out whether this is a sensible idea, before diving in.

so, i'd like to create some extra classes in c++ that return ogre types. for example, a factory that returns some custom renderable. i'd like to store these classes in my own lib (rather than hacking them directly into ogre) so that i can continue to track new releases of ogre with minimal fuss.

my question is, if i do this, how would i go about making a python interface to my library so that it can return types defined in the ogre library (like a subclass of Ogre::SimpleRenderable)?

i'm assuming it would work if i just made my own additions to pyogre that supported my library objects, but is there a way to do it such that my library is it's own python module? i'm not sure if in python, you can have a proxy object that is from one module (a proxy of Ogre::SimpleRenderable created by my library), and then hand it to a method in another module (SceneNode::attachObject() in pyogre), even if it is a proxy for the same kind of object on the c++ side?

any swig gurus have any hints?



31-08-2006 15:52:36

Have a look at the %import SWIG command, it tells SWIG to read type info from the interface file without creating an interface for it.

So if you have something that returns an Ogre::Renderable you would do your interface normally and then do %import OgreRenderable.i so it knows that another library has that interface covered.


02-09-2006 13:09:54

Have a look at the %import SWIG command, it tells SWIG to read type info from the interface file without creating an interface for it.

Ah thanks. When I tried this, I wasn't able to get it to work.

I didn't try with OgreRenderable straight out, I tried a really simple example with a function that makes an Ogre::Vector3. If I try to %import OgreVector3.i it complains about "%extend defined for an undeclared class", and about the %ogre_attribute macro. I tried importing ogre_attributes.i and putting in a forward declaration for Ogre::Vector3, but it still complains about Vector3 being undeclared. I even tried %importing ogre.i but then swig returns with an error code even though it only prints warnings to the output:

make[2]: Entering directory `/home/pix/work/ogre/basic_library/wrapper'
/usr/bin/swig -c++ -Werror -python -I/usr/include/python2.3 -I../include -I/usr/local/include -I/usr/local/include/OGRE -I/home/pix/build/pyogre/dev-1.2.0/pyogre/ogre -o pixBasicLib_wrap.cpp pixBasicLib.i
/usr/local/include/OGRE/OgreCommon.h:268: Warning(362): operator= ignored
/usr/local/include/OGRE/OgreVertexIndexData.h:189: Warning(362): operator= ignored
/usr/local/include/OGRE/OgreFont.h:355: Warning(362): operator= ignored
/usr/local/include/OGRE/OgreRenderQueueSortingGrouping.h:47: Warning(314): pass is a python keyword, symbol will be renamed as '_pass'
/usr/local/include/OGRE/OgreFileSystem.h:106: Warning(402): Base class 'ArchiveFactory' is incomplete.
/usr/local/include/OGRE/OgrePrerequisites.h:189: Warning(402): Only forward declaration 'ArchiveFactory' was found.
/usr/local/include/OGRE/OgreRibbonTrail.h:62: Warning(401): Nothing known about base class 'Node::Listener'. Ignored.
make[2]: *** [pixBasicLib_wrap.cpp] Error 7

anyhow, in the process I learned something about swig which I wish I'd known a few days ago, from 5.3.3 in the docs, "Everything else is a pointer".

so everything works fine if i don't import anything from pyogre, and just hand around pointers from my library. you can't look directly at them in python, but you can hand them on to the methods of pyogre. this should be fine in most cases, i think.

even in the case of something like Vector3, if you really need to fiddle with it on the python side, you can do something like this:

myV = mylib.createVector3(1,2,3)

# myV is just a pointer you can't inspect

ogreV = ogre.Vector3(myV)

# ogreV is a real ogre vector created using myV..

when i find a case where just working with pointers doesn't work, i'll revisit this problem.

thanks for the tip :)