Support NeoGAF

[gofreak]

San Francisco, CA – February 22, 2005 – Havok, a leading developer of middleware for the video game industry, today announced that it will be revealing Havok Complete 3, its integrated middleware solution at an exclusive launch event during the 2005 Game Developer Conference (GDC 2005). Havok Complete 3 features the latest release of Havok's flagship product, Havok Physics 3, combined with Havok's newest product, Havok Animation 3.

Together, Havok Physics and Havok Animation represent a powerful and flexible game-play solution that can be integrated within a broad range of game architectures and pipelines. Havok Complete 3 is fully optimized for current generation game platforms but has been designed to meet the needs of game developers working on next generation game platforms.

* Havok Physics 3 - Extends Havok Physics, critically acclaimed for its recent use many of the industry's top selling video games including Bungie's Halo 2 and Valve's Half-Life 2. Havok Physics 3 introduces Continuous Physics, an innovation that dramatically reduces game production time by eliminating "bullet-through-paper" problems that stem from high-velocity game objects.

* Havok Animation 3 - Provides a rich set of general purpose run-time animation capabilities, including animation compression / decompression, blending, inverse-kinematics, and tight integration with Havok Physics 3. Havok Animation includes an integrated export, filtering, and preview tool chain that operates seamlessly with commercial modeling and animation tools.

* Havok Complete 3 - Combines the power of Havok Physics and Havok Animation to enable next-generation game-play by blending physical, key-frame, and procedural animations simultaneously in the game to provide state of the art dynamic character performances.

The conference will be held in San Francisco at the Moscone West Convention Center from March 7 –11, 2005. Members of the media are invited to an exclusive launch event on March 8th.

Next-gen havok = I'm particularly excited to see their animation tool - that's definitely an area that needs to step up next-gen.

 

[Gorgie]

What is the "bullet through paper" problem?

 

[gofreak]

What is the "bullet through paper" problem?

I think it's a problem relating to the discrete nature of game engines. You cannot continuously check for collisions and update the physics to an infinite level of detal - you might do physics calculations every 1/60th of a second, but very high velocity objects may pass through very thin objects (like bullet through paper) in less time than that, thus you may miss such events and not register a collision (to your engine, the "bullet" was on one side of the "paper" in the previous state of the world - or frame, if you prefer - but is now magically on the other, without the engine detecting any collision when there should have been one).

 

[tedtropy]

I thought Halo 2 was using Bungie's in-house physics engine, a la the first game. Whoops. Havok literally is everywhere now.

 

[border]

I can see how bullet-through-paper might be a problem.....but how is it really a problem? Are developers just dying to make FPS games where everyone is a piece of paper?

 

[gofreak]

I can see how bullet-through-paper might be a problem.....but how is it really a problem? Are developers just dying to make FPS games where everyone is a piece of paper?

It's not literally a piece of paper..that's just how they characterise the problem, an analogy if you will. It can happen with missed collisions between very fast moving objects and even other larger objects, it's just more likely to occur with small fast moving objects and thin/small objects.

As the prevalence of physical modelling across the game world increases i.e. everything gets physically modelled, these problems become more likely, so it needed to be addressed going into next gen, where the granularity of simulation will be higher.

 

[border]

I understand that it's not just paper and bullets....but what else is as thin as paper or moves as fast as a bullet? I am just not sure exactly what this issue is preventing from happening.

Seems like bullets are already hitting planks of wood, so obviously it's not a problem if the object is a bit thicker than paper. When the objects are scaled upwards in size that means they have to be moving even faster through bullets (so that they pass through another large object in less than 1/60th of a second)...

 

[GhaleonEB]

I thought Halo 2 was using Bungie's in-house physics engine, a la the first game. Whoops. Havok literally is everywhere now.

That's what I thought, but the physics were so different from the first game that I wasn't suprised to see Havok in the end credits.

 

[GhaleonEB]

I understand that it's not just paper and bullets....but what else is as thin as paper or moves as fast as a bullet? I am just not sure exactly what this issue is preventing from happening.

Seems like bullets are already hitting planks of wood, so obviously it's not a problem if the object is a bit thicker than paper. When the objects are scaled upwards in size that means they have to be moving even faster through bullets (so that they pass through another large object in less than 1/60th of a second)...

This issue is apparant in Halo 2, where on MP certain shots or objects go through certain surfaces. I think the bullet/paper is just an analogy and it impacts objects going faster than bullets and thicker than paper.

 

[Datawhore]

That's what I thought, but the physics were so different from the first game that I wasn't suprised to see Havok in the end credits.

They probably used a combination of custom physics and Havok for their end result. Several devs are doing similar combinations of in-house physics tech & Havok middlewear.

 

[border]

What Halo 2 shots go through walls? You can empty bullets into a pane of glass and none of them will go through.

 

[Tain]

Awesome, awesome, awesome.

(so that they pass through another large object in less than 1/60th of a second)...

The thing is, most games don't check for collisions that often.

 

[gofreak]

Awesome, awesome, awesome.



The thing is, most games don't check for collisions that often.

Indeed, that is true, and it only makes the problem worse. The larger the timestep is, the more likely you are to miss a collision with (relatively) small fast moving objects.

 

[Azih]

Imagine the Crazy 88 fight in Kill Bill, Japanese tea house with those paper frame walls. Now make it a gun fight instead of a sword fight and you would have situations where a bullet could go through the paper frame but no hole would appear. That's a problem.

Now this isn't a huge problem, you can work around it (don't set the game in a Japanese tea house, make the 'paper' width thicker), or you can ignore it in this instance (a few holes don't appear, big whoop). But it's a much better situation for the developer if they can just create the scene and not have to worry about developing and testing work arounds.

Also as has been said this is just an example.

Imagine a FPS, you aim your sniper at someone's head, they notice and start ducking just as you fire. It's an extremely close situation and for less then 1/60th of a second the bullet is in the top of the guy's skull (he's ducking remember). Unfourtunately the physics engine wasn't checking for collisions in that little while and the guy gets off. No headshot for you. Bigger problem. Now sure in this case the guy was ducking and it was an extremely close situation (for all you know the guy managed to duck just in time). Nevertheless, you should have gotten the headshot and a subtle defeciency in the collision system screwed you. Havok Complete 3 claims to solve it.

Edit: plus yeah, checking collissions 60 times a second is really high. I kinda doubt any game does it even that much.

 

[Lathentar]

I understand that it's not just paper and bullets....but what else is as thin as paper or moves as fast as a bullet? I am just not sure exactly what this issue is preventing from happening.

Seems like bullets are already hitting planks of wood, so obviously it's not a problem if the object is a bit thicker than paper. When the objects are scaled upwards in size that means they have to be moving even faster through bullets (so that they pass through another large object in less than 1/60th of a second)...

In Tribes Vengence this was a problem. Players are allowed to accelerate to ANY SPEED their skill allows it. They could go so fast that they might pass through thin walls or trees, etc... Does that help?

 

[border]

How often did Havok originally check for collisions?

 

[Azih]

How often did Havok originally check for collisions?

I'm sure Havok left that under developer control and it can be tuned up or down. No matter how hight you make it though the problem remains, it gets reaaall minimal at absurdly high frequency of collision detection (but that's really expensive in terms of processing power) but it would remain. Havok 3 isn't just checking for collisions more often (that would merely *reduce* the problem). It's doing something different to claim the Continuous Physics buzzword.

 

[gofreak]

How often did Havok originally check for collisions?

As often as the developer wanted, I would think - they'd specify that, it wouldn't be standard across all Havok-powered games. I'd say they've come up with something that doesn't depend on the update rate, though...just relying on faster update rates wouldn't be a "new" development.

 

[McFly]

How often did Havok originally check for collisions?

I think the new system does not check more often, but it stores the previous location of the object and checks if there was something in the path of that old position and the new position. This way it's nearly impossible to miss a collision, it's exactly what I did in my last physics engine for a Flash ball game and I really can't think of a way to miss a collision this way.

Fredi

 

[gofreak]

I think the new system does not check more often, but it stores the previous location of the object and checks if there was something in the path of that old position and the new position. This way it's nearly impossible to miss a collision, it's exactly what I did in my last physics engine for a Flash ball game and I really can't think of a way to miss a collision this way.

Fredi

What if the paper's moving? Do you check against the old world state, or the current world state? Even if you do both, if a piece of paper moved very quickly across that line between checks, you could miss a potential collision (?)

That may be a different problem, though. The "bullet and paper" problem probably suggests static paper versus high velocity bullets In which case your solution would work.

 

[Dr_Cogent]

I can see how bullet-through-paper might be a problem.....but how is it really a problem? Are developers just dying to make FPS games where everyone is a piece of paper?

No, but maybe they would like to render thin things getting holes in them.

 

[McFly]

What if the paper's moving? Do you check against the old world state, or the current world state? Even if you do both, if a piece of paper moved very quickly across that line between checks, you could miss a potential collision (?)

That may be a different problem, though. The "bullet and paper" problem probably suggests static paper versus high velocity bullets In which case your solution would work.

Yes, that can happen, but all other objects are normaly not moving nearly as fast as the bullet and so a combination of a high enough sample rate and the path method gets nearly all possible collisions. However, if you want to check if two fast and small bullets collide, you would need to do something more extreme.

Fredi

 

[gofreak]

However, if you want to check if two fast and small bullets collide, you would need to do something more extreme.

Hehe, indeed. Perhaps something for the boys at Havok to ponder over for #4

 

[McFly]

Hehe, indeed. Perhaps something for the boys at Havok to ponder over for #4

I don't think it's a problem of how to do it, more a problem of how to do it fast enough on current hardware.

Fredi

 

[SKluck]

The issue isn't just about things going completely through walls or what have you. It's mainly about objects moving slightly into each other then 'bouncing' back out if they are going somewhat fast. Anyone that has played around with HL2 or Garry's Mod for HL2 is extremely familiar with it.

This is the most apparent and obvious manifestation of this problem I've seen.

 

[Phoenix]

I understand that it's not just paper and bullets....but what else is as thin as paper or moves as fast as a bullet? I am just not sure exactly what this issue is preventing from happening.

You're in your hot rod racer going 300 MPH and you enter a city filled with objects. You want to collide with everything in the scene, but your rate of speed allows you to pass through a number of stationary objects.

 

[Phoenix]

I think the new system does not check more often, but it stores the previous location of the object and checks if there was something in the path of that old position and the new position. This way it's nearly impossible to miss a collision, it's exactly what I did in my last physics engine for a Flash ball game and I really can't think of a way to miss a collision this way.

Fredi

I solved it a cheaper way. I created a bounding box in front of my moving object that represented my object along a trajectory (made box longer). I then performed my collisions against the world with this box as it would tell me what I might hit along my path at my current velocity (and a decent bit beyond). Objects would then be discriminated based on their future orientation to the 'velocity box'. I could also check if two moving objects at speed could possibly hit each other as their velocity boxes would collide with one another.

Was cheap (stupidly easy math), and worked fine.

 

[McFly]

Was cheap (stupidly easy math), and worked fine.

I think with your way of doing it you could have kind of a trap bug where an object is always colliding with something if the speed of the object is high and the surrounding space small.

Fredi

 

[Dsal]

I worked with the Havok SDK for a bit on an old project. Great product.

The people there are really cool too. At a certain GDC dance party where I was already precariously just hanging on to consciousness from the previous booth crawl drinks and from a bunch of Cape Cods my friend kept buying for me and Cliffy B in his sharkskin suit. Then one of the guys from Havok we had meetings with earlier handed me a beer...

I kinda blacked out after that only briefly coming back into lucidity at some undefined time later briefly enough to see some vomit in front of me on the pavement. The next thing I know it's the next morning, I'm face down on the floor of some strange hotel room, and I just have this Havok T-Shirt in my hand.

 

[Phoenix]

I think with your way of doing it you could have kind of a trap bug where an object is always colliding with something if the speed of the object is high and the surrounding space small.

Fredi

Haven't seen it in practice though I don't doubt that it could happen. The purpose for the system is more to determine if collisions are possible - then I perform more granular checks to determine if it actually happened. Seemed to be a cheap way to determine the 'bullet through paper' problem. If the velocity box passes through the paper then you know that eventually that object will intersect with that other object in this 'time slice' and you can even compute 'when' it will based on the intersection point of the plane and the box.

 

[Phoenix]

I kinda blacked out after that only briefly coming back into lucidity at some undefined time later briefly enough to see some vomit in front of me on the pavement. The next thing I know it's the next morning, I'm face down on the floor of some strange hotel room, and I just have this Havok T-Shirt in my hand.

Oh the parties, they will be missed

 

[McFly]

The purpose for the system is more to determine if collisions are possible

Makes sense.

Fredi