Archive for February, 2007

Another ship

Friday, February 23rd, 2007

This one is designed to hold lots of ammo and weapons, for the people that like to use projectile weapons. It can also hold a lot of neutronium if you like to go mining.

Fighter model

Friday, February 16th, 2007

Got another fighter model from the artists. I asked them to add some details around the canopy, but this is otherwise good:

Armored Fighter

Computed face normals

Friday, February 16th, 2007

One of the reasons I’m glad I chose Ogre 3D is the level of support available from the community. In only 3 hours I went from wanting to compute face normals to doing so, and rendering lines to show them too (something I also didn’t have). Both the computations and the rendering lines mostly came from the Ogre Wiki.

Face normals

Getting to this stage at my last job took about a day and a half, and that was with the graphics programmer sitting across from me, and already having line and point rendering tools.

If I went with some other graphics engine, it’s unlikely I would have been able to do this in any reasonable amount of time.

PhysX review

Sunday, February 11th, 2007

Last week I started integrating physics into my game. The two first two days I spent trying to learn Newton. Although straightforward, I dumped it because of a combination of outdated documentation, insufficient header file documentation, quirks, performance problems, poor forum support, and closed source. Every minor feature was a major time consuming issue and it just wasn’t worth hours of grinding to figure out why stuff as simple as acceleration = velocity * time doesn’t work. At the rate I was going, for my simple needs, I could have just written the physics from scratch faster.

Next up was a choice between ODE and PhysX. ODE was open-source which is a tremendous advantage over PhysX because if there are problems or something is unclear I can figure it out myself, rather than being at someone else’s mercy or just grinding my gears. However, PhysX used to be a commercial library which is now free for PC games. In my experience commercial libraries are usually an order of magnitude better than the free stuff. What ultimately decided me was the promise of a plugin for my 3D modelling program, and more confidence in PhysX meeting my performance needs.

Initially, I was overwhelmed by the amount of documentation and code provided in the SDK. However, after only a few hours I understood the structure of the system and found that it wasn’t that bad. There’s dozens of samples and tutorials, each of which is documented in a windows help file, which itself contains professionally written documentation covering the whole system.

At about the same time I investigated using NxOgre, a library to integrate the Ogre 3D graphics engine with PhysX. I found that PhysX was well enough documented and easy enough to use directly, while NxOgre was missing huge chunks of documentation and it was very confusing and unclear in those cases. I pretty much decided NxOgre was a solution in search of a problem, so dropped it and went with straight PhysX.

I first investigated the 3D modelling plugins. Unfortunately, they turned out to be buggy incomplete messes that were not up to production quality for a serious game. A programmer can use them perhaps, but they would never suit artists. So I was left to my own devices to come up with a physics entities exporting scheme. I wasn’t that upset about it, since nobody else has working plugins either, except Havok, which is half a million dollars + royalties. Compared to free, I’ll just write my own system. For my simple needs it’s only a day or two of work. This may be a problem for others though, especially if you plan to model physics based animation, ragdolls, or joints. If I were going with ODE instead, I could have potentially used the Sythe Physics Editor

As for the library itself, I made a lot of progress. In only two days I went from knowing nothing at all to being able to fly my ship around in the game. You can code straight from the documentation and to get started you don’t miss not having the source. Things generally work the way the documentation says they will, and I didn’t encounter too many problems where things just didn’t work and I had no idea what to do. Overall, PhysX is easy to use and well-documented.

Their architecture is based around multithreading, or offloading processing to a Physics card. This is a really nice performance feature because you take advantage of multi-core processors essentially for free. You simply lock the physics scene, send your inputs, and then unlock the physics scene. This is mostly transparent to the user, and I have to qualify that as mostly, because quirks do come up.

One quirk is that it’s very slow to do conditional evaluation of collision. For example, in my game I have force fields that only your own team can fly through. Other teams just bounce off as if they were a wall. It took me hours to figure out deal with their collision filter system to hack up a scheme to do this. Multithreaded callbacks are supported, but discouraged. The collision filter system uses logical operations with bitfields (that you set) to figure out what is collidable or not. I was able to get it to work with my scenario, but with more complicated games I don’t think it’s sufficient.

Another quirk is your updates are not immediately reflected. If I add rotational thrust to an object, and immediately check the orientation, the orientation will be the original, and not updated orientation.

The multithreaded quirks are understandable and as long as you know what kind of issues to expect they won’t be a problem.

I’ve used 3 major features of PhysX so far: joints, triggers, and the material system. These aren’t all the features, just the ones I’ve used.

Their joint system is good and easy to use for basic stuff. There is over a dozen joints available, including limit planes, springs, motors, breakable joints, spherical joints, pully joints, and 6 degree of freedom joints. As long as you stick to their samples you can get joints in your game very quickly. However, for more complex scenarios, especially with 6 degree of freedom joints, I was so confused at times I was about to have a nervous breakdown. This is one of those cases were the code would have been less confusing than the documentation because their explanations are very round-about, lack detail and precision, in some cases wrong, and the samples do things that just make no sense. It took me 3 14 hour days of grinding and head pounding just to figure out how to get an object to freely translate and at the same time be able to roll on one local axis.

Their trigger system is good. You can attach massless shapes to actors and then get callbacks through an interface. You can attach your own userdata to both the shapes, and the actors (which are made of ships). Because triggers are based on shapes, you can get triggers for not just spheres but all the kinds of physics primitives they support. I’m using their trigger system to maintain nearby object lists for network culling.

Their material system is very good. Unlike Newton, which only supports an explicit table, you can define basic parameters of a property (bounciness, friction) and then specify how that material interacts with other materials (add, multiply, smallest, largest, and others). You can also define a specific table if you want. You can also define what kind of materials collide with other materials, up to 32 types. So for example I have it so bullets do not collide with powerups, but spaceships do (so they pick them up). You can get callbacks for collisions as well.

If I have one major complaint with PhysX, it’s support. It’s free, so it’s not fair for me to complain too much, but at the same time I need to get my game done and busting my head spending 3 14 hour days just to get something to roll isn’t something I can afford to do too often. The forums have very little activity, and while I’ll give the admins there credit for trying to help, so far all their answers have been unhelpful or wrong and made me lose even more time. This is another case where I would have been better off going with ODE, since it has more forum activity and I would have been able to just look at the source. I’m not sure if paid support or paying for source code access is an option.

In conclusion, I think PhysX is worth investigating for the $75,000 to $1 million niche. At this level there’s enough money and time to make it worthwhile to figure things out, and performance, feature set, and quality are important enough lesser solutions can’t be counted on. Over 1 million, I would require real support and source-code (such as with Havok). Under $75,000, time is too important and I’d go open source (ODE) instead.

*** Edit ***

I was told that full-source and support are available to large projects. In this case, I think PhysX can be a good, much more affordable, solution to Havok and it is worth looking at both of them.

PhysX Tip

Monday, February 5th, 2007

I lost an hour because of inadequate documentation regarding how to update the simulation in PhysX. Here is a tip:

If your objects just won’t move, it’s probably because you are only calling physicsScene->simulate. For reasons which are not explained, you have to call:


then update your inputs

then call


PhysX pretty good so far

Sunday, February 4th, 2007

I spent several hours looking over PhysX and NxOgre, a wrapper for PhysX to bridge the gap between the two systems. I also experimented with the modelling program plugin for PhysX.

Conclusions so far:

PhysX: Powerful, pretty easy to use, professional quality level. Documentation is wrong in some places but nothing to really kill my productivity. Code documentation is generally sufficient – again while there are holes, it’s not enough to kill my productivity. Overall it’s pretty much pleasant to work with and I’m making good progress. The only thing I don’t like is that it requires its own installer.

NxOgre: Very easy to use if you already know what you’re doing. Otherwise about 70% of the documentation is missing and it’s definitely not clear what to do in these cases. Coding quality is above average relative to other freeware stuff, but still not up to the level I like to work with. In the end, I decided not to go with it. This is for three reasons:
1. Unclear memory management. While it’s clear that NxOgre handles most memory management for you, I don’t feel very comfortable putting new calls all over the place and trusting they were handled correctly. The architecture pretty much requires you do this.
2. Unique name convention for objects. This is similar to what Ogre does, and is one of the biggest annoyances about Ogre. I don’t want to name every damn class I want with a text string, especially not if I have to constantly work to make sure it’s unique.
3. Overhead. The documentation and samples for PhysX are just much more clear and straightforward, with better documentation, and it seems relatively easy to use. I don’t see the point of using NxOgre except to save me time, and without clear documentation it won’t save me much of anything. Plus, if I’m going to use a library it needs to be written at a higher quality level than what I saw or I’m not going to trust that it won’t crash or leak memory somewhere.

Modelling plugin: A buggy terrible mess, with outdated and wrong documentation. It looks like it was written halfway, then abandoned. I’m going to just integrate with the exporter I already have and parse out objects.

Right now I have PhysX integrated with my engine and creating a physics scene. I look forward to seeing how fast I can get the ship flying around.

Changing to PhysX

Sunday, February 4th, 2007

In the end, after another few hours, I got Newton sort of working. Sometimes thrust would stop working for no reason, until I died and respawned, usually. Sometimes it would stay not working. And I wanted to fix the location of the fighter’s shield to the fighter’s body, and that never worked. Also, doing the same simulation on the client and the server was less accurate than with my own code.

It took me 2 days to get Newton sort-of-working. It took me 15 minutes to rewrite my old code back in, as all I wanted was a rotating ship in space with thrust.

My biggest problem with Newton is that if something doesn’t work, you’re basically fucked. The forum is unhelpful, the manual is incomplete, the tutorials don’t help much, and there’s no feedback from Newton as to why. So even if I were to attempt to fix the problem of “Why does my thrust suddenly stop working, but rotation still works?” I have absolutely no idea where to even look, with no source code to rely upon. These kind of things take hours, where just writing my own system velocity = thrust / mass * time takes about 10 seconds and consistently works.

It also lacks in easy-to-use features. For example, people have asked for efficient trigger bounds in the forum over a year ago, and it’s not there. I tried using my own system with AABB collision boxes and Newton was so slow I gave up on that and wrote my own system, again in not much time, which worked perfectly and was O(1). I have no way to update a single entity given a past time and state, which I need for networking. I don’t have access to the physics octtree which I also needed for network culling. There’s no easy way to do explosions or springs, and it goes on and on. I could spend another day guessing and probably get everything working, until I run into the next problem, and then lose another day, and so on.

So PhysX is free for PC games now and I got a developer account with them. I’m going to read over what they have and see if I can make the switch in a day or less. The nice thing about them is
1. A lot more people use that than use Newton, so I can get better support
2. There is a plugin for 3D modelling programs
3. It’s from a professional company so I have a feeling the quality and speed will be much better.

Integrated Newton Game Dynamics

Saturday, February 3rd, 2007

I spent the last two days integrating the basics of Newton Game Dynamics physics with my game. It took about 2 days – in some ways easier than I thought, but due to lack of forum responses and incorrect documentation I also wasted a lot of time. Note to others: setting an angular velocity on an object that isn’t moving is ignored unless you unfreeze it, even though it doesn’t say this in the manual yet does for other similar function calls.

I got Newton integrated enough to have the fighter fly around and shoot bullets. My FPS went from 30 to 2 with as few as 10 bullets on the screen. I actually set all those objects to use non-collidable ‘materials’ with respect to each other, (or I think I did, it’s hard to tell with the poor documentation and closed source) so I don’t know what the problem is.

I’m going to debug and profile where the slowdown is coming from. I really hope the fault isn’t with Newton, because I’ve finally learned how to use it and don’t want to waste another 2 days learning something else.

As an aside, I’ve found that in general I have a far easier time with open source libraries than closed ones. For example, I just spent 2 hours trying to track down why my objects weren’t moving, while they were immediately before I checked in. It turned out a bad merge set my world size to have the same value for z on both the min and max axis – so all objects were outside the physics world. Rather than asserting, or returning false, Newton just silently doesn’t work. If I had the code, I could have figured out why in about 10 minutes, as opposed to nearly giving up and changing to PhysX.