Require help with rigidbody issues regarding to mass and surfacearea

Hey,

I've been tinkering around physics and I recently noticed that physics don't seem stable when a heavy (say 1000 kg) object falls on lighter object (1 kg) the heavy one sort of overlaps the lighter one and squeezes it away from underneath it. I tested this with two same size objects and the difference in height was limited to something along the line of 5 cm. I really hope someone who's dealt with such problem before could enlighten me how I can improve the physics behind the simulation since we're not talking about large velocities or too big differences in masses (as far as i know).

If need be I'll try to post a pic or video, but this is very easily testable in editor and the setup I had was consisting of just 2 cube primitives in default sizes of 1^3 and masses of 1 and 1000, problem persists even with 10 kg which is just blowing my mind.

Best regards,
Qidrokun

 

No surprises... you should be able to get a 10:1 working reasonably easily. 1000:1 is going to give you quite a computational hit if you are using a lot of other physics. Nearly all the settings you can change will have a global effect, so if you use a lot of physics in your project it will get expensive quickly.

If you want more stability, I recommend this sequence:

Check you have sensible physics materials assigned to ALL of your colliders (e.g. zero bounce, 0.6 static/dynamic friction) - or in Edit - Project Settings - Physics add your own default physics material.

Edit - Project Settings - Physics
Solver Type: Temporal Gauss Seidel
Default Solver Iterations: set it up at 50 and then decrease it until you find the best performance vs behaviour

Edit - Project Settings - Time
Fixed Timestep - try 0.01 s and see how the response varies, play with it to get the best balance of performance / behaviour.

 

A mass ratio of 1000:1 is huge. Iterative physics engines (which account for 99% of all physics engines used in games) tend to have problems with large mass ratios.

These problems can be minimized by allowing the engine to spend more time in calculations (chopping time up into smaller slices by decreasing your fixed timestep, or performing more solver iterations per step) but that's the issue: you generally want to spend as little time as possible.

As AITheSlacker said, always keep the mass ratio of objects that interact with each other below 10:1. In fact the closer to 1:1, the better. This applies to contacts and joints of any kind.

Engineering-level physics engines usually employ direct solvers, that can easily deal with very large mass ratios. However these are orders of magnitude more complex and slower than the engines used in games.

 

I don't know what sort of wizardry source engine is using but they don't seem to face these issues atleast, I tested the mass ratio even at 10kg to 1000 kg and it failed, so it seems like i have to mess with time and other solver parts, but it's pretty weird that 15 year old engine can go easily with mass ratios bigger than the 1:100 (50 tons is the max weight of that engine and min weight is 1 kg, and although constraints have issues with those differences, collisions never do).

 

This def helped with the issue but might need to tweak values still, to be able to demonstrate the true effects I'd need to test few different platforms and scenarios, thanks a million though i lost my **** before you showed up with the answer.

 

All game engines have to deal with this, I can guarantee it.

Many engines use a very simple trick: to clamp or scale the mass ratio of interacting objects. So for instance if a 1000 kg object and a 1 kg object interact (trough collisions or joints), response impulses are calculated and applied as if the objects were 900 and 90 kg (to keep the 10:1 ratio, or even a smaller one). As far as I know, this is what Source does. Even though you use very different mass values for objects, the engine simply scales them closer together until they’re within a reasonable ratio.

This of course results in completely incorrect behavior (momentum is not maintained, objects behave too “floaty”) but at least keeps things stable. So to the naked eye, it’s a better alternative. In Unity, joints expose a massScale parameter that does just this. Not sure if there’s a way to do the same for contacts.