ShrimpWorks

Guess it shouldn’t have taken so long for me to get around to doing this, but at least it’s done now.

Attached to this post you’ll find a zip file, containing a small example application which allows you to spawn PyODE physics-enabled cubes with the middle mouse button into a PyOgre world. You can then bounce and roll the cubes around by holding the left or right mouse buttons.

The code is fairly straight-forward, and I’ve included quite a number of comments. Should be easy enough to follow what’s going on if you’ve been through the PyOgre tutorials.

A note of performance and stability - you can safely spawn loads of cubes as long as there are not too many collisions going on at once (after around 50 cubes, things start to get really sluggish if there are too many inter-cube collisions going on). In practice though, I doubt you’d need that many collisions happening at any one time. Also, If you make a large pile of cubes, lift them all up, and let them fall down together, it seems to bomb out as there are too many collisions happening when they all land on top of eachother at once. I haven’t debugged this very much, so I’m not sure yet if it’s a ODE limitation, or something bad I’m doing in the code. If anyone works it out, I’d be interested to know.

Please don’t ask for advice on stuff like per-polygon collisions, terrain collision and the like, I have not really messed with this beyond the state of this example. Once you get the basics going after checking out the example, I’m sure a few questions shot off at the PyOgre Forums would turn up more useful results than asking me :).

Have fun ;).

My idea for implementing non-physics physics into my little game framework didn’t work out too well, so I gave in and took a look around for options.

It seems only ODE is available to Python, via PyODE. Not many [open source] physics engines seem to have Python bindings, which I find rather odd.

As it turns out, it isn’t actually all that of a mission to get ODE and Ogre working together, and the results I’ve got so far are quite acceptable. I can spawn loads of cubes (of varying sizes) and throw them around the scene and they bounce and jump around in a suitable fasion.

I haven’t tried with balls or polygon-accurate stuff yet, that’s next on the to-do list. I also intend writing a short how-to for PyODE and PyOgre integration at some point, as I was a little confused to start with, not knowing quite where or how to begin, and there is no PyODE/PyOgre example code floating around to reference.

EDIT: Example using PyODE and PyOgre now available -

It seems as though the guys at work are seriously looking into the option of doing some game development next year some time, and they’ve been busy checking out various engines and frameworks to help with this. Despite being the only person at work who plays games seriously, and my history of developments on the Unreal engine, I haven’t really been included much with what’s going on.

However, since game development (of any kind) is the number one thing I’d like to be doing with my life (NOT point of sale systems!!), I’ve decided to involve myself anyway :D.

I have been playing around with a couple of game and physics engines (games being discussed are potentially vehicle-based), and Irrlicht particularly seems rather nice. Korpse however, suggested I take a look at Ogre. I was very pleasently surprised to find the PyOgre project, which exposes about everything Ogre can do, to Python (you don’t even need the Ogre SDK, it works completely on it’s own), and seems very well supported. I’m a lot more comfortable with Python than I am with C++ :).

The only down side, is that Ogre is not a complete game engine, but rather simply a graphics engine. Meaning, I’ll have to work out how to add sound, physics, advanced input options (Ogre does support keyboards at least), etc on my own. There are a lot of options available for all of those, so I’m not really worried about it at the moment.

I’ve begin putting together a bit of a basic framework for myself, trying to base how things work around how UnrealScript works and interacts with classes and objects. It’s working out pretty cool, thanks again to Python.

As a test project, I’ve decided to put together a sort of basic World War II flight sim. All you need really is a model, some terrain, and basic flight physics (which I plan on simulating without the use of a physics engine, in a similar fasion to how I did some stuff in Unreal Tournament [pre-Karma]).

Since the scripting is going well, I decided to take a shot at a quick model. I came across Wings 3D – a simple “subdivision modeler”. Basically you start off with whatever primitive shape (cube, spheres, cylinder, etc) you think will suit what you’re going to build, and stretch and warp it into the final product. I’ve never modeled like this before, but it works surprisingly well.

After 2 hours work, I got the following result from a 16-sided cylinder:

There are quite a number of rather ugly polygons, but it was a learning experience :).