Cool. I figured that, Linux being a more obscure OS, that making a linux version would be lower priority.

As it should be. Linux is a big deal amonst technical enthusiasts. It's not a big deal amonst a vast majority of desktop users who would run the client and couldn't care less about the Operating System religious debates. Linux has its place and it's a great thing. And an open source project would be wise to offer itself on Linux. But the obvious priority is what the code runs on now and how many people will benefit now.

As it should be. Linux is a big deal amongst technical enthusiasts. It's not a big deal amongst a vast majority of desktop users who would run the client and couldn't care less about the Operating System religious debates. Linux has its place and it's a great thing. And an open source project would be wise to offer itself on Linux. But the obvious priority is what the code runs on now and how many people will benefit now.

Edit: Added two missing 'g's.

Uru CC doesn't work right on Vmware

what are we going to do with respect to physics engines?

ODE in Myst V: A Postmortem

I've pretty much wrapped up the physics work in Myst V, so I figured I'd send out an email to the list with the details of what kind of issues I ran into.

For our previous game, Uru, we used the Havok 1 engine for our physics. The characters were simulated as 3 different size spheres stacked on top of each other. Movement was accomplished by just setting the linear velocity based on the player animation. This worked well since Havok resolved all collisions each frame, so there wasn't any "jittering" when you pushed yourself into a wall. We had some physical objects scattered around that you could push, but no real fancy physical interaction.

When we were reworking the engine for Myst V though, we decided to drop Havok and go with ODE. The main reasons were that we wanted to ship on Mac, which Havok didn't support (thus killing the Uru Mac port we were going to do), and ODE was free. We had evaluated ODE during Uru, but at that time it didn't support trimeshes, which was a deal breaker.

Going from Havok to ODE, the main issues were the lack of convex hull support and the fact that collisions weren't completely resolved each step. In Uru, pretty much all detectors were made from convex hulls. Since they have a definite inside and outside they can detect when another physical is completely inside them, unlike a trimesh. Since ODE doesn't have hulls I had to make the artists use either box or sphere detectors, or use a trimesh and make sure the object that's going to be inside them will always be touching a triangle. That was unfortunate, but they adapted to those restrictions.

The bigger problem was the collision resolution. Since ODE uses the ERP to resolve collisions over multiple steps you can run into cases where an object being forced into some static geometry will push in and out instead of stopping dead. In Havok the penetrations were always resolved, so our character controller was much simpler.

For the Myst V avatar I used a capped cylinder. In Havok we kept our characters upright by setting an inertial tensor that was wacked out enough to make it impossible to get any angular rotation. (Then for turning we would just manually set the rotation.) That didn't work in ODE so I initially tried making a joint that would disallow any rotation in the x and y. That worked, but after scooting around a little the character would begin slowly tipping over. It was a problem I ran into more than once, where a joint just wasn't stable. So, I gave up on the idea of a joint and went with what Alen from Croteam suggested and just created a flag in ODE that would prevent a body from ever getting angular velocity. (I just added a few checks in the step for the flag and didn't add angular velocity in those cases.)

Moving the avatar by setting the linear velocity directly, like we did in Havok, didn't work too well. I don't remember exactly what happened, but I do remember that everyone on the mailing list said it was a bad idea. Again I went with Alen's suggestion here and made a custom joint that set the x and y linear velocity. That worked fine but due to the collision joint sponginess I needed an additional check to keep the avatar from running full force into walls. I added an additional capped cylinder that was slightly bigger than the collision one and it just detected collisions without making any contact joints. Then I took the normals from all the contacts and decided if we were about to run into a wall. If so, I would redirect the velocity to slide along the wall, or just kill it if there was nowhere to go.

To get good contact normals from the trimesh I had to add another special flag to only return normals. By default you'll get the best separating axis, which isn't necessarily the normal of the triangle you hit (for instance, if you're on an edge). In addition, to clean up the amount of contacts I implemented the contact reduction method from Game Gems 4(?), which is checked into the unstable tree.

The main problem I ran into was with the instability of the ODE joints. I run our simulation at a fixed 100 Hz, and clamp the per-frame delta to a max of 100 ms (so we don't kill the framerate even more by doing too many steps during a slow frame). That works great on fast machines, but on slow ones (ie dropping below 10 fps at times) the joints tend to get unreliable. The avatar can run pretty fast (around 20 feet per second I believe) and we ran into a problem near the end of development where in low framerate situations the avatar would sometimes pass through boxes. Changing those to trimeshes fixed the problem, I think because they generate more contacts. I did a lot of work playing with different ERP values, step sizes, stepping methods, etc, but nothing fully cured the problem.

Overall I'm fairly happy with ODE, in the sense that the price is right and it allowed us to do a Mac version. However, I wouldn't recommend it to any other commercial game developers. The community is pretty helpful, but it just isn't the same as having support from a commercial physics engine. Also, development is pretty stagnant right now. The biggest reason I'd recommend against it though is the fact that Novodex is basically being given away for free if you commit to using a decent amount of physics in your game. Ageia wants to create a market for its physics accelerators, and they're willing to take a bath on Novodex to do that. I'm sure Havok is not happy about that.

Anyway, if anyone has any questions or comments I'll be happy to reply.

Colin Bonstead
Lead Engine Programmer
Cyan Worlds

ODE would appear to make the most sense.

No, no Linux port. The Linux game market is even smaller than the Mac one, which is already hard to justify. In general, it's just not cost effective to make a Linux port. Of course, I'm sure all the zealots on Slashdot will tell you otherwise.