6
\$\begingroup\$

So typically Havok works best with normal human sized objects with a gravity of 9.8m/s^2 and dealing with everything in meters.

In my Game though there will be a large variety of scales from millimeter sized objects to meter sized objects.

Typically this rules out running a standard Havok setup and dealing with things in a meter scale.

Would it be best to increase everything by 10x or some scalar like this and increase gravity likewise?

I understand this would also decrease how far objects can be away from the origin but for the sake of this question assume everything is relatively close to the origin, a hundred meters max.

Issues of concern

Object penetration - Havok usually allows some object penetration in the 2-3cm range in the meter scale.

Floating point precision - Issues dealing with distances of objects etc, typically physics breaks down at the kilometer scale in Havok.

Unseen - other unseen issues that may result with such large differences in scale.

\$\endgroup\$

1 Answer 1

3
\$\begingroup\$

Havok has a few spatial constants you will want to tweak for the size of your world, but otherwise the scale of the world shouldn't matter. Rather, the scale of the objects relative to one another matters quite a bit. Below I've tried to address the issues you will need to be aware of:

Collision 'tolerance' - When rigid bodies touch they do not rest exactly touching but are kept at a separating distance. This is because Havok has a more difficult time simulating bodies that are inter-penetrating. You will need to tweak this value to be appropriate for your world, so that the separating distance is not noticeable. It is also typical to shrink the collision shapes a bit so the separating boundary aligns more closely with the visible surfaces.

Maximum velocity - When creating your world and your rigid bodies you may define a maximum linear velocity. You will want to scale this value up or down to be appropriate to the size of the world.

The bullet-through-paper problem - When you scale an object to be very small, you also want to consider of the maximum possible speed of the object relative to its size. Because havok simulates in discrete time steps a small and fast object may move several times its length in a single timestep, and so it may travel through a thin surface without detecting the collision, or worse, it will become stuck inside. To alleviate this, you can enable continuous collision for rigid bodies that are small and fast, but CCD is expensive, and causes bad performance spikes if you accidentally teleport a CCD body into another body. Another approach is set the maximum linear velocity (see above) to something ok relative to the object's size... however varying maximum linear velocities can cause problems (imagine a fast moving truck full of small objects... the small objects cannot move as fast as the truck so they will tunnel through it).

The level of detail problem - The cost of detecting a collision is generally relative to the number of polygons that are near touching on each side. When you have objects that are very large relative to the player, they tend to have many polygons to look sufficiently detailed at the player's scale. If two large high detail objects collide, you may have a 100 polygon surface collide with another 100 polygon surface, which requires 10,000 collision tests. One solution is to have multiple shapes in the rigid body with different levels of detail (two levels of detail is usually enough) and set the collision filters on those shapes so that two large colliding bodies only detect collisions between their lower detailed shapes.

Mass and momentum - Larger objects need to have much larger mass, which means that when they are moving and collide with objects of much smaller size/mass, the momentum transferred to those smaller objects will make them move very fast. Small fast moving objects cause the bullet-through-paper problem I mentioned above, and may also look undesirable, as your objects go hurtling out of the world. You can deal with the bullet-through-paper problem as I mentioned above, or you can fudge collision and explosion forces so that they are constrained to a manageable range.

Floating-point precision - If your world is very large relative to the smallest object, motion will begin to stutter visibly when viewed at the smallest scale and those objects are very far from the origin. This is because the margin of error on large floating point values (positions) will be large relative to very small floating point values (small velocities and small differences in position). One way to fix this is to only keep a relevant area of rigid bodies in the world, and occasionally translate all of those objects toward the origin when the player wanders too far away. As long as you maintain the relative positions of all the objects, the player won't notice.

Other spatial constants - Look at the parameters you can adjust when setting up the world, rigid bodies, and constraints... there are probably some other constant values in units of length that need to be adjusted to fit the scale of the world.

\$\endgroup\$
7
  • \$\begingroup\$ Excellent post, I'm worried about object penetration depth as well. Small objects have the tendency to fall through thin objects regardless of velocity. This is because of the allowed penetration depth in Havok is typically a few centimeters. I would need to turn this down to nearly nothing to support millimeter scales. Is this acceptable based on floating point precision? This is where I was going with possibly scaling the entire world. \$\endgroup\$ Commented May 11, 2011 at 18:29
  • 1
    \$\begingroup\$ I think penetration depth can be adjusted on the fly, but you will start to see more penetration happening with larger objects. Floating point precision should only be a problem when you are very far from the origin as the position coordinates become too large to deal with small differences in position... You could alleviate that by translating everything closer to the origin, you wouldn't necessarily need to scale the world, but either approach might work. Regardless, some threshold of size difference will make the simulation too unstable for Havok, you would need an engine that uses doubles. \$\endgroup\$ Commented May 11, 2011 at 18:53
  • \$\begingroup\$ Another reason that scaling may be undesirable is you will need to adjust the mass, inverse mass, and inertia tensors of every object or your shrunked world will be super dense. \$\endgroup\$ Commented May 11, 2011 at 18:58
  • \$\begingroup\$ Would using a physics engine that uses doubles internally be worth the effort in this case? The only popular 3D physics engines that allows this would be Newton and ODE to my knowledge. Giving up a visual debugger and maya plugins for tuning physics would definitely be painful. \$\endgroup\$ Commented May 12, 2011 at 18:34
  • \$\begingroup\$ I doubt you want to use doubles, I was saying that is last resort if for some reason you need huge differences in scale. More often in games you can cheat by only using part of a large object when viewed up close, or ignoring tiny objects when viewed from afar. \$\endgroup\$ Commented May 13, 2011 at 1:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .