Road to PyOgre 1.2.0

This thread is for those interested in helping with the work of updating PyOgre.

If you are interested in helping out, check out the current dev branch svn://svn.berlios.de/pyogre/branches/dev-1.2.0 and take a look at pyOgreTODO and docs/contributing.txt
When you have created a patch, and tested it, go to http://developer.berlios.de/projects/pyogre/ and submit it.

If you are working on a specific part of PyOgre, post here to say what you are working on so we can avoid code duplication.
I will begin by looking at OgreException.i to see if I can make Swig save the traceback when director methods raise exceptions. Then I'll look at ogre_typemaps.i to see why passing a float to methods that expect Ogre::Degree or Ogre::Radian crashes.

I tried to look at director exception passing issues. I noticed that if you make a change in OgreException.i like this, instead of:

%exception
{
try {
$action
}
catch(Ogre::Exception &e) {return handleException(e);}
}

put something like this:

%exception {
try { $action }
catch (Swig::DirectorException&) {
SWIG_fail;
}
catch(Ogre::Exception &e) {
handleException(e);
SWIG_fail;
}
}

Exceptions produced inside overloaded interface methods should be passed through.

I think that code that raises director exceptions is already generated by SWIG but this addition (to OgreException.i) could make it definite for all declarations afterwards,

%feature("director:except") {
if ($error != NULL) {
throw Swig::DirectorMethodException();
}
}

Good luck.

I noticed those things last week. You're completely right that we shouldn't duplicate the work.

If you would take a look at the latest version of OgreException.i you would see that this is what is done now.
The issue is that Swig seems to drop half of the traceback (or Python doesn't record it) and the exception looks like it's coming from the code that called ogre, instead of from the code that actually raised the exception.

Maybe this could help:

%{
struct PyExceptionKeeper {
PyObject *type;
PyObject *value;
PyObject *traceback;
PyExceptionKeeper() { reset(); }
void reset() { type = value = traceback = 0; }
void fetch() { PyErr_Fetch(&g_PyExceptionKeeper.type, &g_PyExceptionKeeper.value, &g_PyExceptionKeeper.traceback); }
void restore() { PyErr_Restore(g_PyExceptionKeeper.type, g_PyExceptionKeeper.value, g_PyExceptionKeeper.traceback); reset(); }
} g_PyExceptionKeeper;
%}

%feature("director:except") {
if ($error != NULL) {
g_PyExceptionKeeper.fetch();
throw Swig::DirectorMethodException();
}
}

%exception {
try { $action }
catch (Swig::DirectorException&) {
g_PyExceptionKeeper.restore();
SWIG_fail;
}
catch(Ogre::Exception &e) {
handleException(e);
SWIG_fail;
}
}


Sorry I'm missed that one. Simplifying fetch() and restore():

void fetch() { PyErr_Fetch(type, value, traceback); }
void restore() { PyErr_Restore(type, value, traceback); reset(); }


Excellent. That fixed it right away.
Thank you, the change has been committed.

I'm trying to fix up the various wx demos in SVN, and the fish demo posted by Fosk to work with 1.2.0. (Would we be allowed to distribute that?)

Mostly done, just need to figure out how to create a patch now...

Methods that expect an ogre.Radian will now implicitly convert a Python float to an ogre.Radian instead of crashing.

I will now take a look at the compositor framework.

I was looking to use the TerrainSceneManager in my project to tie pyogre and pyode together for heightfield collision/physics. Has anyone created a TerrainSceneManager binding? Unfortunately the generic SceneManager interface doesn't have the functionality I need. I'll gladly work on it and hopefully contribute some code, I just don't want to reinvent the wheel.

The TerrainSceneManager hasn't been wrapped and AFAIK no one is working on it, so any contribution would be gladly accepted.
http://developer.berlios.de/bugs/?func= ... up_id=3464

If you need any help getting started etc, let us know.

what's the current update on pyogre 1.2.0?

I have been extremely busy with school and other projects, so I haven't been doing much.
Swig 1.3.29 doesn't work with Python 2.5 and I haven't gotten around to testing the new version.

From what I have seen, it's quite likely that I will start using python-ogre rather than "competing" with it.

I also encountered problems with Swig 1.3.29 and Python 2.5 on Windows. Eventually I did get it to work,only after manually editing the *wrap.cxx file.

On Linux Swig1.3.31, Python 2.5 and Ogre1.3 seem to compile and run. Haven't tried on windows yet. Swig1.3.30/ python just doesn't work.

Swig1.3.31 raises other issues which I'm trying to resolve.

Souldn't this thread be unstickied or changed to the road to python-ogre 1.0 or something?

Forum Title still says PyOgre does it not? I think we should wait till Python-Ogre hits 1.0 and has a stable Linux and Mac build system before we switch it out for PyOgre.