koobas.hobune.stream
How to scale down physics engine
Hello everybody,
I found some questions and answers on the topic, but none provided a clear answer for me.
I know that in Unity 1 unit = 1 meter in the physics engine. In the game I am creating, it makes more sense to have 1 unit = 1 centimeter.
So, I have changed the gravity to be 98.1 instead of 9.81 (as an interim step towards 981) in the editor -> physics settings, but things are not acting as expected. Everything looks too heavy, and things do not bounce properly. In some cases, objects just keep bouncing (shaking) forever.
Can anyone tell me what are the other parameters I need to set, either in physics settings or in each rigidbody component, so it will scale down properly and keep the natural physics feel?
Specifically, do I need to change any of these, and if so, should I simply multiply by 100?
In physics settings:
Bounce threshold (increasing this stopped the eternal bounce)
Sleep velocity
Sleep angular velocity
Max angular velocity
Min penetration for penalty
Solver iteration count
In rigidbody:
Mass
Drag
Angular drag
Thanks in advance.
Correct of course, thanks :) I just started by scaling by 10, and then saw things got broken even here, so did not scale more.
Let's take a look at the units of measurement for each value:
gravity is similar to an acceleration:
9.81 m/s^2 = 981 cm/s^2.linear velocities (i.e. speed) are in m/s:
1 m/s = 100 cm/s.angular velocities are in radian/s. Scaling down (or up) does not change it.
bounce threshold is a relative linear velocity (see 2.).
Min penetration for penalty is a distance in meter. But you can consider it to be a distance in unit and keep its value.
Mass is in Kg. This should not be affected by a scaling.
Drag is like an acceleration but in the opposite direction of the movement. Drag in real life is affected by mass density of the fluid (here the air). But I think that in the case of the physics engine this is simplified. So you can consider its unit to be in
m/s^2.Angular drag is similar to an angular deceleration. Its unit should be radian/s^2.
Maybe I'm wrong, but it looks like you only have to change the value of linear velocities and linear accelerations.
Thank you for the detailed answer, but I am definitely still missing something.
Starting with a simple ball falling on a flattened cube (ball at 1x1x1, cube at 0.2 thickness)
At default gravity of -9.81, things are ok, but the bounce is not realistic for the size of ball I need.
At 10 times gravity if -98.1, the ball seems very heavy and not bouncy enough, but relatively ok.
At 100 times gravity of -981 the ball does not even hit the cube - it just passes right through it.
So, should I just stick to "what works" and ignore the engine scaling (i.e. work with -98.1 gravity, eventhough it is not accurate)? Or is there anything I can do to make the -981 gravity work?
make 'collision detection' in rigidbidy's props to 'continuous' to avoid fall through at great velocities
I have tried playing with that as well. This engine is quite frustrating. Any small change I make in any of the important settings either make the objects jitter (not come to rest), or fall through or be too light/heavy, or penetrate the object they sit on slightly (once they come to rest).
I am trying it now with a decimeter scaling, as it seems the most promising compromise so far, although it is still not solved for me.
Just trying to make a 1cm ball bounce normally on a cube... that's the Hello World of physics engine and I am failing miserably... :)
pack $$anonymous$$imal set of assets you use (to reproduce issue) to package and share it, i'll check if you want.
@Scroodge$$anonymous$$ - appreciate it.
Here is a webplayer demo with the best settings I could get to: http://goo.gl/tJfsu
Here is the project ZIP - just three balls and three cube platforms. http://goo.gl/7CI9A
This is trying to simulate a 2cm chrome ball, falling on wooden platforms.
(changing to continuous detection gets very unexpected results here...)
i'd check you project and here's the answer:
your objects are too small and speeds too big (in unity units that you use as 0.01 meters), so, to use your scene correct with gravity -981 units you should:
make a Fixed TimeStep value lower. value about 0.0025 works perfect in your project.
Aha! Thats a preferences area that I did not think to look at. I will read that page, check the settings soon and report back. Thanks a lot for the effort.
Ok - I have read the docs on Time$$anonymous$$anager and tested the settings. Indeed reducing the fixed update makes this behave more naturally, but I think it will probably be unrealistic to expect it to work without problems with lower values. 0.0025 as the fixed update value means 400 fixed update frames per second. I believe this will be too taxing on some CPUs (targetting mobile) if at all possible.
So interim conclusions:
The Fixed Timestep value is the one to play with.
Values below 0.02 may be unrealistic for mobile.
The Unity/PhysX engine is not suitable for small scale simulation (with objects at ~2cm size)
I would love to be wrong on #2 and #3 conclusion, if anyone can comment.
hmm... i tested it with 2 mm balls 8)
-981 m/s^2 gravity and sphere scale 0.2 - it's 2 mm diameter... so try to use really 2 cm - may be will work good on default timestamp
Heh :)
The project I linked above is a scaling compromise: 98.1 gravity, and 0.2 ball size. The gravity feels right here, but as you know, balls are passing through platforms.
So I tried with 0.01 as fixed timestep and it works, but then again, it means 100 fixed frames per second, which I believe (read: wildly guess) will be challenging to some devices.
In any case, both you and $$anonymous$$ryptos helped me hit that nail on its head and at least now I know all the settings that are in play.
Unless someone else comes to say how terribly wrong I am, I will probably stick with a bigger scale (balls at 0.8 units, gravity closer to -10 than to -100) and learn to live with the fact that the gravity will feel a little floaty.
It will be "Balls in Space"... :)
one more hint: you can implement your own simple physic. i did it it one game with a cannons and really very fast bullets that bounces etc.
this will need a little geometry and program$$anonymous$$g skills 8)
make a sphere trigger for ball.
change it's radius so it always no smaller than way a bullet can pass between fixed steps, to not miss a hit
every update check if there's something that you can collide with. if found something, manually reflect speed from surface, using bounce values etc
