This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Havok Your Way: An Interview with Havok's Jeff Yates

Tool creator Havok has been at the forefront of physics engine development for some time now (as seen in games like Half-Life 2, Dead Rising, MotorStorm),
and has recently has branched out to include products like Havok FX for
special effects and HydraCore for multi-threaded optimizationan.
They've also released animation SDK and tool (Behavior) which, as
demonstrated to Gamasutra, uses intelligent and rather intuitive
scripting and naming trees to create a very clean interface for
animators, and also has a very simple system for blends.

On
the occasion of this tool’s unveiling, we spoke with Jeff Yates,
director of product management for Havok, and discussed the company’s
plans for the future. Yates also provided a host of information useful
for both developers and consumers interested in what goes on in the
bowels of the industry, including a comparison of the respective
strengths of the current crop of consoles, and a breakdown of a number
of points of popular confusion, such as the necessity of a hard drive
for data storage, or the difficulty of porting games from the 360 to
the PS3, from the technical side of the game industry.

Gamasutra: How long has Havok been dealing with animation?

Jeff
Yates: As a company on the SDK side, a good two and a half years. We
launched our SDK at the end of 2004, and a lot of that work revolved
around really good compression of the animation. What we do is to
maximize and sample every key frame, then we compress it down and play
it back exactly like you just saw. That's been going on for about two
years, and a full half of our sales now include animations. It's a
really good attach rate. In terms of this higher-level, broader view of
character animation, it's probably been about a year and a half to two
years we've been working on this. Some of us have been working with
other companies too.

GS: How far do you
think you're going to go with what Havok covers? It seems like it's
continually expanding toward being a full engine competitor.

JY:
We obviously like to grow, and our customers generally want us to grow
and stay healthy too, as long as we don't take our eye off the ball
with physics. What will make us unique is that we'll probably try to do
only one or two components at a time, and we'll make those the best of
their class. We'll really try to make those true components, in the
programmer's sense of the word.

We could take a
path where we say it's all one black box and we're going to grow it
constantly, but we're very careful to make sure you can say, "I want
this one or that one, and not all of it at the same time." A good
amount of effort goes into making these things first-class SDK
components, and I think that's the way we'll stay. I don't see us
becoming a monolithic solution provider. I think we'll provide related
components that know about each other, and will integrate well out of
the box.

The Havok Behavior Tool

GS:
Will it be possible in the future for scripted animations (such as idle
animations) to feature slight variations? Right now they’re generally
looped canned animations.

JY: Right now I
think there are a lot of clever things you can do with blends. There
are a couple of approaches to that. The extreme one is to have eight
different ways the character might idle, then support random selection,
so you can pick a different one every time and get randomization that
way. That's a bit brute force, but surprisingly effective, because you
know exactly how long it will take, and how much memory it will take in
advance. Another approach that is a little less explicit is to have
extreme ranges of motion, then blending those and having a variable
that modulates. For example, if the AI is tired, maybe his arms will
come down a little bit and then raise up. We try to enable that by
letting you put variables on these blends.

I
think full procedural stuff is even cooler. It's most doable for the
upper body. Full procedural locomotion for the base of the body and for
momentum and stuff like that is just now starting to come out into the
open.

GS: Is that going to be difficult to blend into other animations?

JY:
Yeah. I tend to sometimes think about procedural textures when I think
about this stuff. They held so much promise, and then people saw that
they had like twenty variables that all had to be tuned and simulated.
It really depends. I think that almost anything that you look at -
either through runtime or 3D authoring - the algorithms you choose have
to be very predictable. To be honest, we haven't really tackled that
part of the equation yet. But I think anyone can plug it in.

GS: It seems like that's the direction that things might want to go in the future.

JY: I think so, yeah. As long as the artists like it and can control it - that's key.

GS: It seems like when characters go into ragdoll state in games like Gears of War, they go completely limp. Is it possible to give it more rigidity?

JY:
Oh yeah. You can blend the amount of keyframe animation - say for
example if the keyframe pose says, "I want to be here at a particular
time," but the physics say "You're dead over here," we can blend and
have a certain stiffness between the two, and that can be animated. A
lot of times you'll see tech demos where a ragdoll character will hit
the ground and he'll be stiff for a second, and then he'll go totally
limp. There's that kind of death pose that he holds before he goes
down. That's totally possible.

Epic's Gears of War

The
way we do it in this tool is to blend between a certain amount of
physics and a certain amount of keyframe animation. We think that makes
up so much territory. It's certainly not be-all-end-all, but it
certainly makes ragdoll seem so much more alive. The ragdoll can serve
a lot of brief, high-value purposes. You can take a hit, then go a
little bit to ragdoll and then recover, and never go to the ground. You
get a lot more variability in response that way. The Ubisoft talk at
GDC had some great examples of that.