The Monkey Project

Python Game Development News

3D Engine roundup

with 3 comments

The overwhelming majority of retail games have been in 3D for a decade or more, and we’ve long since passed the point when the majority of indie games are 3D. Yet it nearly all standalone Python games are in 2D. Why is this? A couple of suggestions spring to mind – 3D is harder and more time consuming than 2D, for example, or that Python is too slow for 3D. But are these really the barrier that people have suggested?

Both of these rationalisations would seem to be pointing to a lack of suitable tools and frameworks for delivering 3D graphics in standalone Python games. For tools, there is of course Blender, which certainly has a steep learning curve but is at least sophisticated enough to be able to produce cutting-edge 3D graphics.

There are a variety of frameworks available, each with pros and cons. Alas many of these would appear to be poorly maintained and/or poorly documented.

More information on these will be forthcoming, but let’s take a quick run-down of what’s available:

Bindings for 3D Engines

Examples: Panda 3D, Python Ogre, pyirrlicht

There are a variety of bindings for fully-features scenegraphs/engines. These generally substitute a need to know low-level OpenGL calls with a steep learning curve of the classes and datastructures of the engine. They can require a lot of setup and compiling of dependencies, or a heavy SDK/runtime to download and install before a game is playable, which make it significantly harder for many users to run games using these frameworks. Some may not even be cross-platform at all.

Of the examples listed above, Panda3D treats Python as a first-class development language and as such is maintained and has extensive documentation, pyirrlicht is maintained but apparently undocumented, while Python-Ogre is less well maintained and poorly documented.

Python/Pyrex/Cython Frameworks

Examples: Soya3D, PySoy

There are a few frameworks built from the ground-up for faster Python 3D. In theory, using Pyrex/Cython should mean that these frameworks are tolerably fast without being inconvenient for Python developers. In practice though, Soya3D is not infrequently maintained and has incomplete documentation, while PySoy is under active development, but unfinished and undocumented after 5 years of development (You are actively discouraged from using it yet – this is not esr’s “Release early, release often” methodology). Both of these tie in a swathe of dependencies that offer far more functionality than just a scenegraph, at a cost of potential extra work to get up and running with them (Soya3D is broken on current Ubuntu, for example).

Pure Python Engines

Examples: SPyRE, tdgl, Pyggel

Pure Python (based on PyOpenGL or Pyglet) have the lowest burden of dependencies, and is also the most legible and adaptable for Python programmers, but it is also likely to be slow – how slow, and whether that is a problem, is an open question. Each of these examples seems to be relatively poorly maintained, but nevertheless, they do indicate there is a body of useful Python code available to use. If you wanted to get a pure Python engine going, you do not have to start from scratch.

Have you used any 3D frameworks and how did you get on with them? Leave a note in the comments.


Written by mauve

May 11, 2011 at 12:00 pm

Posted in Libraries

3 Responses

Subscribe to comments with RSS.

  1. Thanks for the review!

    Ram Rachum

    May 11, 2011 at 4:43 pm

  2. I’ve used Panda3d a lot up until ca. 2 years ago. Made a small (unfortunately non-open-source) game with it. I used Panda3d because all other engines you mentioned (don’t forget Blender, which includes a python-scriptable game engine as well) were simply not good enough at implementing a high-level scripting language. My impressions:

    The Fedora packages are badly maintained, but Ubuntu packages seem to be good. Since Python is indeed a first-class citizen, and the project is (mostly) well documented, you get results quickly.

    The library is not very pythonic in its design, but rather C++ish, which leads to coding-style mess when you include other libraries, including the stdlib.

    Panda3d is designed to be very easy to setup, but you will find later that it does too much import-time magic, and it uses a lot of global variables like for the scene-graph, camera and such, which really can get in your way in developing a sane architecture.

    You will have to write your own shaders at some point, so you will have to learn Cg. But it’s fun, really. Don’t bother with the built-in shader generator, performance will quickly become an issue. I guess you will have to learn to write shaders with any other decent 3d-framework as well. The Cg-integration in Panda3d is a bit “special”, but I got used to it.

    Panda has a lot of tools, including a terrain generator, sound, collision detection, a physics engine and integration with ODE (you will have to write some glue code yourself. That might have changed, though), task management, basic AI, debugging, scene graph, browser and tools for performance diagnostics. That is a huge plus in my opinion. Same goes for the demos which cover a lot of ground. Not all parts of the library are equally well maintained, but at the very least you can easily use them before you find (or write) a better replacement.

    Concluding, I would recommend it for both small and big projects, but if you plan the letter, do a toy project first, get to know the quirks of Panda3d, and then decide which high-level parts of the framework you want to use and which parts (in my opinion most of the automagic parts) you don’t want but instead want to write your own. That isn’t too hard once you get the feel of how your game architecture should look like in detail.

    When you have written something, post a link to the code! I’d be interested. Good look with the project (I assume you plan one).


    May 11, 2011 at 8:10 pm

  3. Last time I looked the built-in physics engine was crude (very few shape primitives) and the documentation had numerous omissions. The ODE stuff was poorly documented IIRC. That looks like it’s been improved a lot, ie. I don’t remember seeing this before:


    May 12, 2011 at 11:30 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: