python-ogre is a project to provide python bindings for Ogre and a large set of libraries which are often used in tandem with Ogre. It could be said that I started the project, although there was a PyOgre project before it, and I've actually provided very little code to the project. It is probably best said that I was the catalyst which fueled the original creation of a new set of python bindings for Ogre using pyplusplus. The very able Andy Miller has taken over the project and he is responsible for it's amazing progress. It now wraps quite a few C++ libraries, and is very easy to install and use on Windows, and Linux (mac coming soon). I still contribute to the project now and then, although usually only in the form of advice on the users list and some time spent on the compilation of the library.

Historical Context

The following text is from my initial post on the subject after I had created the initial bindings and ported one of the demos to python. Some of the text, (especially on the downsides of the library) are vastly out of date. In fact, the state of pyplusplus has improved greatly and it is used succesfully in many project.


Python is my favorite programming language, and Ogre is my favorite 3D engine. So I was very happy when I found the pyogre project. However, I was very disappointed to find that the Linux support was lacking. In the forums, I found many complaints that the bindings did not work with ATI cards in Linux. I spent many days trying to compile the python bindings. Once I finally succeeded, I was unable to get the bindings to run, as I own an ATI card and run Linux. This was quite frustrating. For this reason, when Roman Yakovenko offered to help someone port the bindings to his exporting toolkit pyplusplus, I gladly accepted, ready to learn something new, and hopefully produce some bindings that run across the board.


The current python bindings are produced using SWIG, because trying to produce automatic binding using pyste proved to be a formidable job. (There are forum comments in the pyogre forum backing this up). However, pyplusplus, is meant to be a replacement for pyste and is designed from the beginning to be more powerful and easier to use than pyste is. pyplusplus tries to automate as much of the process of the bindings as possible, but unfortunately, there are many cases where a computer cannot decide the appropriate course of action. pyplusplus allows the programmer to hook into the process and provide specific instructions on how to export certain portions of the API. For instance, pyplusplus has a powerful mechanism to obtain references to C++ declarations, as well as a very nice API for telling pyplusplus what to do with these declarations. This sort of approach allows the programmer to define sets of rules which govern the bindings, and pyplusplus will apply these rules consistently to the code. If you want to read more about pyplusplus please visit the site.

Features and Benefits of pyplusplus

This rule based approach is amazing for maintenance, as it reduces the turnaround for binding new code. If the new Ogre API's follow similar rules and standards as previously defined, the same set of rules will appropriately bind the new API without any effort on the part of the maintainers. For example, in the current bindings I have code which finds all getX/setX methods (accessors) which can be turned into python properties, and I add them as such. Because this is written in a rule based manner, all new Ogre code which follows the same rules for naming accessor will automatically get python properties. Also, pyplusplus and boost.python provide a very nice way to use SharedPtr's. In our current binding you do not need to worry about whether Ogre returns a pointer,  reference, or SharedPtr to an object, you use the returned object in exactly the same way.

I'm positive that SWIG must have this feature, but it's not turned on be default in PyOgre. In pyplusplus , you can ensure that the bindings are split into one class per file which make the compilation less memory intensive.

Additionally, all of the rules and binding generation is done via Python. This is very nice as one does not have to learn another custom language. Also, I believe this will lower the barrier of entry for new programmers allowing people who only deal with python to submit improvements or bug-fixes.

Down sides of pyplusplus

pyplusplus is a new library. So it lacks in the documentation area, however the code is relatively easy to follow, and the people on the mailing list are very responsive. Especially Roman Yakovenko, who was amazing in helping me with these bindings. Whenever there is a question he answers quickly, and many times there are bug fixes within a few days. Also, there is documentation available (including a very nice UML diagram), it's just not yet complete.

Also, Roman has been very responsive in adding new features to the library. So I am confident that if we find a nice way to implement certain features for these bindings, they may make their way back into the pyplusplus code, and additionally we will benefit from the work of others.

Built with Ogre