Mass Ratio Workaround?

[Evan Christensen]

Hi,

The solver that I?m using to resolve collisions has the limitation that it does not converge well for large mass ratios. (I believe this is the case for most real-time solvers) but the game I?m working on calls for objects with vastly different weights. (E.g. think of a soldier being able to push a gigantic tank)

How do most solvers work around this issue? I can easily detect that one object should be heavier than the other and regard it as infinitely massive, but this opens up the door to objects being pushed through the ground. This seems like it?s an issue most games need to solve but I?ve never seen it mentioned.

Any ideas or tips would be greatly appreciated?

-Evan

[Erwin Coumans]

Hi,

The solver that I?m using to resolve collisions has the limitation that it does not converge well for large mass ratios. (I believe this is the case for most real-time solvers) but the game I?m working on calls for objects with vastly different weights. (E.g. think of a soldier being able to push a gigantic tank)

How do most solvers work around this issue? I can easily detect that one object should be heavier than the other and regard it as infinitely massive, but this opens up the door to objects being pushed through the ground. This seems like it?s an issue most games need to solve but I?ve never seen it mentioned.

Any ideas or tips would be greatly appreciated?

-Evan

Instead of setting heavy objects as infinitly heavy, you can just scale the masses (during the solver preparation/jacobian building) around some value (can be logarithmically) to clamp the mass ratio to a certain value.

I noticed such a solution in True Axis:

The mass distribution scaled so that it is centered about the given range. Then, if the objects can't fit into the specified range, the masses are scaled towards the center mass untill they fit.

The centering and scaling is done logarithmically.

So, if you have a mass of 45 and 30 and a max mass of 20, the 2 objects mass will be scaled down so that they keep there ratio. (Unless you set the min mass hight to 19 or something)

http://trueaxis.com/forum/viewtopic.php ... mass+ratio

Some Havok users (Bungie, Halo 2) mentioned a similar solution:

I feel ashamed for admitting this, but we sidestepped the whole problem of mass ratios in Halo 2. Havok allows you to mess with the collision response directly, so we simply pin the relative masses of ...

See http://www.continuousphysics.com/Bullet ... or=butcher

Another workaround is to embed some smaller 'CCD object' inside dynamic rigid bodies. This CCD object should never penetrate other objects. This is not ideal, a character would stop a tank, but at least it stays inside the valid world, and it will get pushed away, because of the shallow penetration.

Hope this helps,
Erwin

[Evan Christensen]

Hi Erwin,

Thanks for the response... Actually managing the mass ratios is not a problem. Sorry for not being clear about my question. The problem is coming up with a solution that keeps the motion of objects that *should* have a large mass ratio plausible.

[Erin Catto]

Such mass tweaking will obviously have a bad result for some situations. Consider a train car with a crate on top. The train car is dynamic and can collide with the terrain, but the crate should not affects it's motion.

[Nathanael]

A approach that i used with success is to calculate some kind of 'stress', if you use an impulse based solver something like this should do it:
before solving, for each body:
reset LinearStressV=0,0,0 and LinearStressM=0
then each time you apply an impulse to a body, you accumulate:
vector3 LinearStressV+=impulse;
float LinearStressM+=|impulse|;
(and so on for angular impules)
after solving LinearStressM-|LinearStressV| give of value from 0 to +Inf that can be used to artificially increase the mass the body (or break it, play sound , whatever).
Its a bit noisy value, so some kind of smoothing is welcome, and its one step late, but it worked for me.
Hope it help.

[Erin Catto]

Here's another approach which could measure this "stress" more directly. The solver could simply measure the convergence of the velocity error. If the velocity error is not converging to zero fast enough, then the mass difference could be reduced for the next time step (or even the next iteration).

I'm guessing this would require a bit of tweaking to get a good benefit, but it should handle the different cases gracefully. In other words, we don't want to tweak the mass values when convergence is good.