Features

Product Review:
Havok 2: All Rag-Dolled Up

Does it do anything but driving games?" is a question that draws groans and smiles simultaneously from the Havok team, makers of their eponymous game physics middleware that recently received a major upgrade to version 2.0.

In response to what must be an all-too-frequently asked question, Havok 2.0 broadens its scope to include character physics much more prominently over earlier versions. In that sense Havok 2.0 is not an upgrade, it's a whole new product. New demos show off this functionality to good effect over previous releases.

New and improved. In the original Havok we heard a lot about dynamic characters - rag doll - but it was more akin to having a dynamic corpse. Havok 2.0 extends what is possible, thereby losing a lot of the dead-body feel of its predecessor. I'm not an animator by any stretch but I was able to develop my own walk cycles and attach the Havok physics system and character control far easier than with earlier versions. Havok has realized that I need to dictate full control over character look and movement in the game, both player and nonplayer, because that's what the game player wants. I don't always require accurate physical simulation, for example when a more cinematic or fun-focused effect is desired. Havok attempts to provide this control, and while far from perfect it's a step in the right direction. I was able to emulate parts of the standard zombie demo easily enough that as my animation walks forward I "detached" the head, allowing it to loll freely. When hitting the character with an impulse, such as simulating a shotgun blast, I switched state to playing a "knocked back" animation, detached the arms and let the physics control the flailing arm movement and torso rotation. This could have been extended to letting arms dangle limply and legs drag heavily along the ground when targeted. I was also happy to see a proper section in the Havok manual for handling characters and control, so you aren't left floundering.

	Screenshot from the author's second demo, demonstrating blending animation and physics.

You may not have heard this, but Havok does driving games! There is obvious new functionality in the vehicular component of the SDK, but the important part for me was how easy it is to create vehicles now. The original Havok Vehicle SDK provided a lot of black-box functionality that was poorly documented and nonintuitive. With earlier releases, I spent a lot of time spinning my wheels, literally, trying to figure out how to balance all the forces. Havok now assumes that you don't inherently know what anti-roll bars are for, how to tune the suspension based on terrain and vehicle type, and how to calculate friction circles for cornering. Havok details specifically how their Vehicle SDK black box works and assumptions made, removing a lot of past guesswork from the equation.

Another thing that changed was automatic construction of object groups. Havok 2.0 introduces "Islands" so that you no longer have to take an educated guess as to which group in which to place your object so that the collision system is optimal. Islands are automatically constructed at run time, containing small groups of objects based on the simulation criteria. I had a previously existing prototype inside of which was a spiral of dominos that could be knocked over. Originally, I placed all of the dominos in their own group, which was fine, so long as the player didn't attempt to knock over multiple dominos at once, causing multiple cascades, as that would slow down the simulation. Havok 2.0 took care of the grouping for me; once a few dominos came to rest, they formed their own "simulation island" and became quickly deactivated. This relieves a huge burden from me having to take what was, at best, an educated guess as to which group objects should be placed in. I also no longer need to verify that someone else has placed objects in the wrong group.

	"We've had a positive experience with Havok, although because we're about halfway through our current game life cycle, we still have issues that we need to resolve. If we are happy with Havok at the end of the game, I can certainly see us using it again, as much of the hard work of learning the API will already be done. The documentation could be better, though; a real boon would be to have more code examples in the docs themselves, rather than having to track down the usage inside a demo." - Mark Baker, Mucky Foot "Even with Havok it still takes significant work to combine gameplay and physics in a way that they enhance each other rather than detract from one another. When we originally looked at physics middleware a year or so ago, Havok looked like the most complete product on all platforms." - Sam Baker, Paradox "We aren't using the newest release yet, but during development we've given them lots of feedback and many of those issues have been addressed in Havok 2." - Jay Stelly, Valve
	Your Mileage May Vary: Havok 2 Users Weigh In

Other platforms. I've only been able to work with Havok 2.0 on VC++ 6.0 running under Windows XP. Circumstance did not permit me to compile on Sony and Nintendo dev kits, so my only experience with Havok 2.0 on those platforms is playing with the interactive demos at GDC. From what I was able to glean from their new Visual Debugger, a module similar to the real-time VTune, the frame rates on complex scenes, such as the zombie demo with a dozen animating rag dolls, and character control were rock steady. CPU and memory usage never spiked above 50 percent, usually hovering around 20 percent, and when it did climb it was only for one or two frames when multiple characters attempted to interpenetrate. This was a pleasant surprise, as in the past with Havok 1.7 I could bring my 3GHz, 512MB, 64MB Radeon 9000 to its knees with a half-dozen rag dolls. Looking through the documentation and API headers reveals that Havok has gone to great lengths to ensure that each platform is properly targeted, the PS2 build making good use of the scratchpad and vector units.

How useful Havok's Visual Debugger will prove is questionable. It certainly gives you insight into the work being performed by the physics engine, but I'd like to see more hooks to allow integration into standard profiling tools such as VTune and ProDG's tools for Gamecube and PS2. I've worked on projects where the team has provided a profiling solution, and my experience with the Havok VD suggests that it does not provide the hooks that will be needed.

Support. Unlike a few middleware companies I have dealt with, Havok is going to great lengths to ensure that the people providing tech support for the licensees are qualified to do so, ex-game and physics programmers to a man. They're tech support is second to none. From prior experience with the 1.8 SDK on a real project, technical queries submitted late in the afternoon would elicit a response by the time I returned to my desk the next day. Still, Havok seems to understand that as a middleware provider, customers' project deadlines don't wait for them. Pertinent questions that would apply to other developers are often placed in the FAQ - even if they are only asked once - along with useful code snippets; even small features are quickly rolled back into the main Havok code base. I saw just how quickly this happens when attempting to create a vehicle that behaves as the Warthog in Halo, with all four wheels steerable. Within 18 hours I had my answer, and a day later it was a FAQ and code snippet on how to modify the Vehicle SDK. Havok supplies 95 percent of the source code once you move beyond evaluation, and that can save a lot of time when you are hunting down an elusive bug or attempting to optimize your game. Havok is quite happy to let you look inside their physics black box as much as you like.

Documentation. I'm of two minds concerning the way that Havok is pursuing documentation. The learning curve for the Havok SDK can be steep, and one reason is that they rely more on demos than documentation to illustrate a point. That causes two learning bottlenecks: First, you have to spelunk through many, many source files looking for the demo or snippet of code that you think you need (the "I'll know it when I see it" approach). Second, because the Havok demos are built around a common framework of code, the body of which pulls in every feature that Havok provides, it requires more support functionality. You have to build up a mental roadmap of that in your head, learning what's important and what's immaterial to the particular demo before you can delve in to the small piece of code that you really should be concentrating on. The demos are good starting points, but better documentation that shows the bare minimum you need and why you need to do the particular steps, would make the job easier.

Terms. Licensing terms vary based on numerous factors such as the number of titles and platforms involved, and there are numerous support options from which to choose. One thing that is consistent is that license fees are one-time-only, with no royalties involved.

Final word. The star rating I assigned for Havok 2 represents my best stab at mapping my experience with a very complex product to a simple, five-point scale, which isn't a neat fit, especially given how different real-world game production needs and environments can be.

The bottom line is that Havok is maturing. Version 2 shows great strides forward beyond Havok's driving-game roots, especially in the realm of character-based physics, making it worthy of evaluation by developers on a wide range of projects.

	Each project is different, and a physics simulation, like Internet traffic, changes moment to moment, making it difficult to provide hard data that you could form a judgment around. My test rig was 3GHz, 512MB DDR 2100, 64MB Radeon 9000-equipped notebook computer running Windows XP and DirectX 9.0. I assembled two demos for this review. The first test project consisted of approximately 150 objects in close proximity, 10 of which were considered complex; small-scale versions of the St. Louis Arch that were pinned, i.e. infinite mass and immovable. The rest of the objects were mostly simple geometric shapes (boxes, wedges, and spheres) that the player could interact with in varied fashion. There were also a half dozen rag dolls consisting of 15 bones each; a rag doll was connected to its immediate neighbor via 2D dashpots, forming a loosely coupled chain. The player was represented as a single, two-wheeled vehicle that rode as a child's tricycle, constructed from one large wheel at the front, and a single small wheel positioned just slightly behind for stability. Due to the small distance between the wheels, the vehicle possessed a very small turning circle, enabling the player to negotiate the tight environment. The second demo - a simultaneous blending of animation and physics - consisted of two dozen rag dolls animating a walk cycle that the player could shoot at with the mouse. The quoted memory footprint covers the entire demo,including graphics. Peak Frame Rate Average Frame Rate Peak Memory Usage Average Memory Usage Demo 1: Large, 150-Object Scene 120 80 10.1 MB 9.4 MB Demo 2: Animation and Physics 174 98 2.9 MB 2.7 MB
	The Testbed

______________________________________________________

join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2003 CMP Media LLC

privacy policy | terms of service