Learn Physics Optimization in Unity Easily

 

What is wrong with my game physics?

How to handle game physics?

What’s wrong with Unity Physics?

How does Unity handle physics?

What controls do I have over Unity Physics?

What things should I take care of before starting with game physics?

When should I avoid using physics?

Why do I see drops in frame rate? Is it physics or something else?

There is no end to questions list when it comes to physics, and it’s obvious that you might have many more questions like these.

Yes, Yes I know! We all blame that apple! Why it had to fall on that very day, and that too on Newton’s head? Why God why?

Physics may not be everyone’s favorite subject, but the truth is that Physics plays a very important role in development of the game industry.

Imagine a case where you finally decided to come up with something big! Something noteworthy! Something with loads of realistic physics and graphics! A big game with everything at stake!

Design is created, structuring is done, and everything looks in order. But then you finally sat and started working on the tricky part, "THE PHYSICS"!

Everything seems to be falling apart; you come across low FPS, weird movement, issues regarding collision/triggers, High CPU usage and what not.

Wrong or improper physics can drive away potential gamers. It’s not just about wrong physics; it’s all about proper lag free smooth gameplay.

And this is something that cannot be easily attained. It’s true that physics is the most difficult and important part of game development process and there is no hiding from it!

People can debate by saying, “Good physics needs a very fast CPU!”

But trust me it’s not always true! Most of the times proper physics can be attained by diving deep into the sea of Unity! And by learning how exactly does it work.

Early on as a fresher I had to deal with 100’s of things with physics. It took me almost a year to note down the key points to keep in mind while dealing with physics.

So I have decided to write this post and hence, help you to skip the pain of this learning phase, and become a pro physics developer!

I am not going to talk about how to work with physics in Unity, rather I’ll list out tips and points on how to optimize your physics, so if you are a beginner I would first advise you get an overview of Unity physics.

As Physics is a very, very, very, very (Running out of very s :P ) huge and wide concept, I have decided to divide into different parts and simplify as much as possible.

So let’s get going! Fasten your seat belts as this is going to be a long but enjoyable journey.

LOWER FIXED TIMESTEP..!

As Stated in Unity Docs,

“A framerate-independent interval that dictates when physics calculations and FixedUpdate() events are performed.”

Default value is 0.02 (in seconds), this shows that every 20ms Physics Update will be executed. All FixedUpdate() will also be called every 20ms.

But if your game is not heavily dependent on physics, you can always increase the TimeStep to get better results. (i.e. decrease physics calls)

You need to play around with its value to get the ideal result.

For Example:

"If you are going to make a simple card game, which has not much to do with physics. Then it’s better to reduce the number of calls made to the Physics Engine. But do take care; if you will reduce physics calls too much, you might not get proper physics."

 

Let’s understand this better with the following example

Step 1) Take 3-4 spheres. Keep them at some distance from each other

Step 2) Create Physics material and reduce the friction amount to 0 and set bounciness to 1, and set bounce combine to maximum

Step 3) Attach it to sphere collider physics material

Step 4) Attach Rigidbody to the spheres (this will show that it is an physics object)

Step 5) Take a plane and create a Physics Material as per requirement

Step 6) Keep the spheres at some distance above the plane and let gravity affect the balls on play

Step 7) Press play button and check the outcome

The Ball will keep bouncing up and down.

 

So what does this have to do with Fixed Time Step?

Well it was just a pre-setup , now we will actually play around with Fixed Time Step value

Now go to Edit >> Project Settings >> Time Here you will see the Fixed Time Step Value: the value will be around 0.02 (As I had mentioned earlier).

Now increase it to 0.1 and Execute the game.

Did you notice the difference?

Firstly you will notice the lags in the movement of spheres.

Secondly instead of bouncing back they will go right past through the plane.

Why you ask? (No need to get jumpy so fast :P)

Well if you set fixed time step to 0.1, it means physics update will take place every 100 ms, which is quite noticeable and will not be able to detect collision either.

This shows that too much lowering of Fixed Time Step is also not ideal. Now let’s change Time Step to a more practical value 0.03 – 0.04 (may differ as per your sphere settings)

Now if you execute the game, you won’t be able to see any changes. As long as physics looks perfect for you, it’s ok. If you check closely, physics collision will be a bit different.

Check out the following image:

Physics Collision is detected a bit late, and will bounce back only after this frame

This may not be visible at normal FPS in your gameplay, but it might affect the physics. As long as your requirements are satisfied it doesn’t matter.

How will it help?

Whatever processing time has been saved from physics will be passed to rendering and other processor intensive processes. And hence your game becomes superior!

KEEP A CHECK ON PHYSICS BY SETTING MAXIMUM ALLOWED TimeStep..!

As stated in the Unity Docs,

"A framerate-independent interval that caps the worst case scenario when frame-rate is low. Physics calculations and FixedUpdate() events will not be performed for longer time than specified."

 

So what does this mean exactly?

To understand this, let us first take a normal game scenario,

If your game is playing at let’s say 60 fps, that means that each frame is executed in 0.01666 seconds. That is each frame takes 16.7ms.

Now let’s say Fixed TimeStep (as discussed earlier in this post) is set as 0.01 ? that shows that each physics update will be executed every 10ms.

This shows that during each frame, approximately one physics call is made because 10ms<16.7ms. Now let’s suppose frame rate has decreased to 30 fps due to some reason.

So each frame will take 0.0333ms. That also means that on every frame approx. 3 physics calls are made (as each physics call takes 10ms). This means that if frame rate will go under 30 fps, even more physics calls will be made.

This will be kind of over kill. So to deal with this Maximum Allowed TimeStep was introduced.

Its Default value is set to 33 ms. As per the definition of Maximum Allowed TimeStep, whenever physics will take more than specified time, the physics execution will stop and hence saving up resources for other processes.

So if frame execution time in our example increases to 40ms, it will result into more physics calls.

But now as we have set Maximum Allowed TimeStep to 0.333 >> 33ms, no physics call will be made after 33ms time has passed , i.e. not more than 3 physics call will be made, even if execution time goes to more than 50 ms.

Hence saving some resources for other heavy processes.

 

It sounds too good to be true

But there is some negative effect of this limiting. The animations and physics will slow down a bit whenever performance hitch occurs.

Hence Maximum Allowed TimeStep is an equally important factor to be kept in mind, and if used wisely than results would really be very compelling.

ALWAYS HAVE 1-1-1 SCALE

Scaling objects without physics is alright, but when an object is going to act as a physics object, I would rather advice you to not to mess around with scale. Scaling can cause weird collisions and can also affect how the object will fall.

For example:

"A big rock without any air resistance will fall to the ground in a matter of a few glimpses (dropped from a tower or something). But if suppose everything around is scaled up large then the resulting fall will look quite slow."

There is always an option to mess around with gravity to get it right, but that is also not the right way to go. The simple way around is to control scale to 1-1-1, as Unity’s physics works the best in that case.

GET YOUR OBJECT MASS RIGHT

Just like scale, mass is also required to be kept accurate.

Would 1kg mass for an airplane be correct?

If you consider metric system, than Unity’s 1 unit will equal to 1kg mass. As such Unity’s physics system is dimensionless. But, if you assume Unity's units of length to be meters, then its units of mass are kilograms.

You can work around to get the perfect result. Also, Unity does struggle with high floating point issue, so it would be ideal if you could downscale its value as much as possible.

It means that, if suppose your airplane weights 1 kg, than surely your wheels should not be more than 1/1000 kg.

AVOID MESH COLLIDERS AS MUCH AS POSSIBLE

It’s a fact that calculations for mesh based collision detection is expensive as compared to primitive colliders in any Physics Engines. Unity also uses Nvidia’s PhysX internally, so this is no different.

Generally speaking,

"The relative costs of collision detection of types are in the following order, from most expensive to least: triangle mesh, convex hull, capsule, sphere, box, plane, point."

Usually, mesh colliders are marked as convex (and also recommended) as that will limit to 255 triangles. A collision between different mesh colliders will only work if they are marked as convex.

Unity Docs states,

"There are some limitations when using the Mesh Collider. Non-convex Mesh Colliders are only supported on GameObjects without a rigidbody. If you want to use a Mesh Collider on a rigidbody, it needs to be marked as Convex."

Ideally, usage of mesh colliders needs to be avoided as much as possible as they require a lot higher processing overhead than collisions involving primitive colliders (sphere, box, capsule) and so it is best to use Mesh Colliders sparingly.

 

What is the Alternative..?

A simple alternative is to group primitive colliders in the objects child (as shown in the image above). This will result in lesser calculations for this object, as primitive colliders are meant to be faster.

For complex mesh, you can always break it to smaller ones using Blender or such tools. And apply primitive colliders directly to those child meshes.

I wish I could have given you an exact figure of amount of optimization, but sadly as it differs widely from mesh to mesh, it was difficult for me to get the exact figure.

MUCH MORE TO COME SOON

The list is quite long and there seems to be no end to it, so let’s take a break here and continue with new tips in the next post.

Also I don’t want you to get sick from physics overdose ;).

Till then stay connected and start working on the above points, If you do find a better alternative then please do share with us as well. If you have any questions regarding anything discussed above or if it was confusing just drop a comment below, I will be happy to help.

P.S.: The word “easily” written in the title of this post was just to make you read this post, so don’t take it literally. Keep working on Unity physics and you will understand it eventually. :D

Learning Unity sounds fun, right? Why not check out our other Unity Tutorials?

Got an Idea of Game Development? What are you still waiting for? Contact us now and see the Idea live soon. Our company has been named as one of the best Unity 3D Game Development Company in India.