Product Review of Physics Engines, Part Two: The Rest of the Story

Gama Network Presents:

Product Review of Physics Engines, Part Two: The Rest of the Story
By by Jeff Lander and Chris Hecker
Gamasutra
September 20, 2000
URL: http://www.gamasutra.com/features/20000920/lander_01.htm

Last month ("Product Review of Physics Engines, Part 1: The Stress Tests," September 2000), we put three licensable rigid body physics engines through their paces with a series of stress tests specifically designed to find stability problems. MathEngine's Dynamics Toolkit 2.0 and Collision Toolkit 1.0, the Havok GDK from Havok, and Ipion's Virtual Physics SDK all made their way through the 12 tests with varying levels of success.

This month, we are going to take a broader look at each package. But first, you are probably asking yourself...

Should I License a Physics Engine?

Game physics is a complex issue. We are not going to answer the question, "Should I use rigid body physics in my game?" That's a decision you will have to make. However, if (or, we hope, when) you decide to try physics in your game, should you build or buy? That too, is a complicated question.

Rigid body dynamics is a relatively new technology for the game industry. It is mathematically intense and difficult to implement. This would seem to make it perfect for licensing, because a third party has already done the hard part, and you can just buy the technology from them. This is true to some extent, but it remains to be seen how knowledgeable programmers and designers need to be about physics to use a physics engine. As you saw last month, physics is not a technology you can put in your game and have it work perfectly every time. Current simulators are quite sensitive to initial parameters and tolerances, and require hand-holding and tuning.

We feel that developers using physics simulators to make games in the near future will need to know a fair amount about physics and the underlying simulation algorithms in order for such implementations to be successful. However, we also feel this level of knowledge is less than what's required to implement a physics simulator in the first place, so licensing might be a good idea. You won't know exactly why things are breaking, but you'll be a year ahead of the guy down the street trying to implement his simulator from scratch.

Criteria & Disclaimers

Even after reading this review, anyone who is contemplating licensing a physics engine should arrange for an evaluation period to determine how it might fit into an individual project. With a high-risk piece of core technology, there is no substitute for first-hand experience.

We reviewed each package as if we were going to license the package and either integrate it into an existing game or start a new game with the engine. These are subtly different goals, and we'll point out areas where this distinction is important later on. For this review, we looked at the following factors:

Feature set: What are the elements of each system? Can it be used to simulate a great variety of things, including machines, environments, and so on? Is the collision detector full-featured? How many constraint types are there? How many types of friction? We're focusing on the rigid body dynamics features, not things like cloth, soft bodies, water, or domain-specific subsystems such as cars and airplanes.
Documentation: Is the information included adequate and well presented? Does it address nonintuitive problems that arise? Does it discuss tuning tolerance parameters in detail? Are there clear and instructional sample programs included?
Ease of use: Are the libraries intuitive to program with?
Production: Does it include export and preview tools to simplify production and artist use? Can you save internal object representations on the disk so you don't have to let the engine preprocess them every time you load? Does the library include source code? Is it cross-platform?
Integration: Is it easy to integrate into a production? Is it modular, and are the modules well designed? Do the modules work well together?
Input and feedback: Can the game interact with the objects effectively via forces and impulses? Is useful information available from the simulation, such as object speed, contact state, and so on?
Cost: What is the cost, both in licensing and support?
Technical support: How well do the companies respond to problems?

What We're Missing

The most glaringly omitted criteria are stability and performance. We covered stability last month with the stress tests, and as we said in that article, we cannot cover all cases. You have to test situations specific to your game design.

Performance is another complicated and hard-to-review feature. All three engines seem fast in the demos, but we implore you to try them on your representative data sets before making a judgment. Related to performance are memory and resource usage. Does one engine allocate 100MB under certain special circumstances? We don't know.

We haven't covered track records or postmortems. To our knowledge, no hit games have shipped with any of these SDKs. We've talked to a few developers using the engines, but a thorough set of interviews and developer feedback would be very interesting and useful.

Before we get into the reviews, we must note that Ipion was recently purchased by Havok, and the Virtual Physics SDK will eventually be integrated into the Havok GDK. For the time being, we will treat them as separate products and consider them separately here. The packages are presented in no particular order.

Ipion's Virtual Physics SDK

Features: Ipion's collision detection system has all the necessary features, including broad and narrow phase algorithms, and functions and utilities for generating collision volumes from meshes. You can apply forces to the objects through actuators, such as motors, springs, and even a simple buoyancy simulation. The system supports a constraint system where you can specify the degrees of freedom between the constrained objects or use built-in joints, such as hinge or ball-and-socket.

Documentation: The manual is a relatively scant 76-page Microsoft Word document. It covers the main features, but it does not go into great depth, making thorough examination of the samples and header files imperative. It would have been very helpful to have all of the classes fully explained and an overall description of the architecture. Tuning parameters are hardly documented. The examples are numerous, providing a demonstration of the complete functionality of the system, as well as creating a starting point for most situations one would typically encounter in the development of a game. The example code comments are a little sparse. All of the examples are in an example framework, so it's hard to tell how to use the engine on its own.

Ease of use: The library has been engineered as a class hierarchy. Objects need to be allocated and owned by the system. Sometimes the public sections of classes have many "comment enforced" rules. We could not find a clear way to control the simulator step-size. No access is provided to the low-level dynamics algorithms, such as the contact solver.

Collision detection with random polygons in Ipion's Virtual Physics SDK.

Production: Ipion doesn't include much in the way of production tools. There are no exporters for standard 3D modeling packages, nor any importers for generic 3D model files. Quake 2 .BSP files are supported with sample code. Most of the example programs generate models using custom code. Users would need to create tools in order to let artists try out their models easily. Ipion does provide a tool for creating a custom convex hull for complicated concave models; however, this tool doesn't load any standard file formats, either. There is an example of saving internal collision information to disk, but it is not documented and doesn't appear to be cross-platform-safe or version-controlled. The engine supports PC and Playstation 2. Ipion has licensed the complete source code to game developers in the past, although it's not clear if the Havok acquisition will affect this stance.

Integration: As mentioned above, the class hierarchy might make integration with an existing architecture more difficult than with a more procedural API. The classes are well organized and mostly documented. The libraries are composed of two pieces, the physics engine and the surface builder, which allows users to create optimized convex hulls from polygon meshes at run time. If you don't need the surface builder function, you can choose not to include it.

Input and feedback: The engine has a few different ways of physically affecting the simulation, including applying impulses to objects and attaching actuators and controllers (like springs, magnets, and user-defined impulses). Ipion includes a class of "listeners" that allow the game to get information about objects and collisions in the system. With these you can determine if objects are actively being simulated or are "asleep." The collision events are very important for adding things like sound effects to a game. These listeners look very useful, though they are not terribly well documented.

Cost: The base price for the Ipion SDK is $50,000 to $60,000 for a single title. Royalty-based fees can be negotiated on an individual basis.

Technical support: Technical support for the Ipion system is now handled by Havok. They have a web-based forum for answering developer questions as well as telephone and e-mail support. It is not yet clear how support will be handled between the Havok and Ipion packages.

A car built by connecting rigid objects with springs in Ipion's Virtual Physics SDK.

MathEngine's Dynamics Toolkit 2.0 and Collision Toolkit 1.0

Features: The MathEngine system is composed of two pieces intended to work together. The Dynamics Toolkit simulates rigid bodies, constraints, and contacts. A number of constraints and contact friction types are included, and access to the dynamic simulator is provided at a number of levels. The Collision Toolkit handles collision detection between objects, but it is very basic. It only supports a small set of collision primitives (sphere, box, plane, and cylinder) and their unions. The API is modular (more on this below), so adding a custom collision detector is possible, but it would be a lot of work - work you were hoping to save by licensing a physics engine.

Documentation: MathEngine's documentation is the best of the three packages. The manual is very thorough with both a user's guide and complete reference to all the classes in the architecture. There is even a glossy foldout that shows frequently used information. The code is well organized and documented. There is a small amount of inconsistency in the documentation; for example, it uses the terms alive/awake and dead/asleep interchangeably. The friction parameters are nonintuitive and nonphysical. Some guidelines and a bit more documentation on setting them would have helped. The tolerance values used by the simulator are documented, and some effort is made to describe them. Additionally, there is a section on optimizing and constructing good simulations. While easy to read and understand, the demonstration programs were too basic.

Ease of use: The system is a class hierarchy in structure, but the access to the library is through fairly lightweight standard C functions and data structures. The API is clean and relatively well designed. The dynamics and the collision toolkits are completely modularized and loosely coupled, so a developer could easily use either the toolkit by itself, or call the well-documented contact-resolver function directly. This layered approach is the right way to design a physics engine API for licensing, in our opinion. However, MathEngine has not provided a complete interface between the systems, so you have to do extra work to get them to cooperate. The system has no matrix helper functions. Simulation memory allocation is error-prone.

A dynamically controlled object in a scene in MathEngine.

Production: Similar to the Ipion library, the MathEngine system is designed mainly for coders. Any tools needed for importing models or allowing artists to preview the system will need to be created. The Collision Toolkit can use Renderware models, but no other formats. There appears to be no way to write internal preprocessed data to the disk. The engine supports the PC and Playstation 2 platforms. MathEngine does not generally license complete source code, but said they would discuss it on a case-by-case basis.

Integration: The layered approach to the API makes integration very easy, probably much easier than the other two engines. If your program already handles collision detection, you can easily use only the dynamics system or vice versa. MathEngine provides most of the source code to the abstraction layer that communicates with the dynamics and constraint solver.

Input and feedback: There are simple APIs for exerting torques and forces on bodies, but the programmer must apply joint forces and torques manually. Some of the toolkits and subsystems have callback functions for feedback, while others have "get" functions; most of the rest have enough sample code included that direct access of the data structures is possible.

Cost: MathEngine has two pricing plans, either a single fee of $50,000 per project, or $5,000 plus royalty of 50 cents per unit.

Technical support: The MathEngine web site has a developers' forum for discussing the toolkits. Support over both e-mail and telephone is very good, although we did not test this support anonymously

Havok GDK 1.2

Features: Havok provides an underlying rigid body simulator and a toolkit for higher-level access layered on top. Havok's constraint system is weak compared to the other libraries, supporting only spherical joints and point-to-path. The collision subsystem is full-featured, supporting simple collision volumes as well as convex hulls and true concave objects. A number of contact-solver friction types are included. In addition to basic rigid body dynamics, the system simulates soft body objects (such as blobs and cloth) and particles, as well as a simple fluid model; however, we didn't test these features and can't vouch for their completeness.

Documentation: Havok provides a nice set of documentation along with updates on Havok's web site. While not as thorough as MathEngine's documentation, the documents were useful. There were a few minor consistency problems with function names and terms. There is a great variety of well-documented examples of various levels of complexity. The underlying simulator API is not as well documented.

Ease of use: The Havok GDK toolkit is very easy to use, with the code organized in an easy to understand class hierarchy. The system provides helper utilities for common math functions. The underlying simulation API seems slightly more difficult to use and not quite as completely exposed as MathEngine's, but is more complete because of the advanced collision detector.

Production: Because the system provides a plug-in for 3D Studio Max, artists can easily start using it. They can create models with boundary volumes and run them in the simulation without programmer involvement. Another nice feature allows you to dump the state of the objects in the simulation at any point to a file to reload later or examine for debugging purposes. When trying to debug a physics-heavy game, features like this are very useful. The library is available for the PC, Macintosh, and Playstation 2 platforms. Havok does not license the engine source code, though they will discuss full source-level needs individually.

Dynamically controlled objects in a scene in Havok.

Integration: Havok breaks the package up into several libraries. While it may be possible to leave out unused portions, they are very tightly integrated. This makes programming easier at the expense of modularity.

Input and feedback: Input to the simulation is through "action" classes that are called back during integration, and through a complete set of access functions on the bodies. Because the constraint system only supports one type of constraint, there are no constraint actuator functions. The Havok GDK provides a complete set of event callbacks and access functions to determine what is happening inside the simulator.

Cost: The Havok 3D Studio Max plug-in is $495 per seat with multi-seat discounts available. The Havok GDK is available for $65,000 to $75,000 per title without royalties. Royalty pricing and other pricing options are available on an individual basis.

Technical support: Like MathEngine, the Havok web site has a developers' forum for discussion of the toolkits. Technical support was very good, but again, it was not attained anonymously.

Conclusions

All three of these packages performed better than we expected. They are clearly up to the task of handling most rigid body simulation needs. But which one is right for you? We arrived at some general conclusions.

While its collision detection system is very fast and flexible, the Ipion Virtual Physics SDK has some problems. It lacks adequate documentation, and the code architecture may make integration with your game application more difficult. It is a product at the end of its lifetime, and unless your needs are very near-term and it is a perfect fit for your code structure, we would hesitate to recommend it. We do hope that Havok can integrate many of Ipion's good features into their architecture.

The Havok GDK is the most full-featured physics engine available. The system handles collision detection of arbitrary geometries and has models for soft bodies, particle systems, and basic fluid dynamics. The documentation is fairly good (though we hope it continues to improve), and the code examples are plentiful and very useful. The availability of a 3D Studio Max tool for artists is a great aid to production. If you need a one-stop, do-everything physics engine, this is the one for you. The only weak points are its constraints (admittedly, a very large weak point, especially if you're interested in simulating articulated figures), library modularity, and occasional collision resolution issues.

The MathEngine Dynamics Toolkit 2.0 and Collision Toolkit 1.0 is a very well designed SDK. The documentation is the best of the three, and technical support is outstanding. The well-documented architecture makes the engine easy to integrate with existing game projects. Programmers with knowledge of dynamic simulators should be able to dig right down into the core and control the simulation. The dynamic simulator is very good, and the rigid-constraint support is the best of the three systems we looked at. However, the lack of advanced collision detection methods might be a showstopper of a problem. (We must note here that as we went to press, we learned that a new beta version of the MathEngine Toolkit was released that includes collisions with convex objects among other new features. We didn't have time to check this out thoroughly, but because all of these packages are constantly evolving, we again encourage you to do your homework when weighing your options.) Finally, the simplicity of the demos may also make it tough to find specific examples to build on.

As we've said many times, you must review the packages for your specific needs before making a decision. Physics is not mature enough to buy a package based simply on a recommendation. All three packages are available for evaluation, and this is really the only way to make sure you get the package that is right for you and your project.

Sidebar: "Other Choices"

There are other options beyond the rigid body dynamics simulators we discussed here. Several middleware providers have created tools to aid the development of physical simulations. Here are a couple we haven't looked at closely, so "caveat programmer."

The ReelMotion Animation Tool (www.reelmotion.com) is a simulator for generating animation data for a variety of vehicles such as cars, helicopters, airplanes, and motorcycles. It uses dynamic simulation and sophisticated physical models for the objects to generate the motion data.

Hypermatter from Second Nature (www.hypermatter.net) provides a real-time system for animating soft body objects. The stiffness of the object can be controlled so the objects can vary from rigid to very soft while still preserving the volume of the original object. The system contains a number of features common to a rigid body simulator, such as constraints. The toolkit is currently available for the PC, and a Playstation 2 version is in development.

For more information:

Havok GDK and Ipion's Virtual Physics SDK
www.havok.com

MathEngine's Dynamics Toolkit 2.0 and Collision Toolkit 1.0
www.mathengine.com

Biography:

Jeff Lander (jeffl@darwin3d.com) is the Graphic Content columnist for Game Developer. Chris Hecker (checker@d6.com) is Game Developer's editor-at-large.

http://www.gamasutra.com/features/20000920/lander_01.htm