Physics are expensive

Last week we talked about the issues I created for my mobile processor by using overly complicated mesh collider geometry. This week we will look into some of the physics issues I created, subsequently avoided, and the mitigation techniques used. Let’s get right into it.

1. Mesh Collisions are expensive (especially with overly complex geometry)
2. Physics are expensive
3. Object creation the easy way (instantiation vs pooling)

Physics 2D

Again the easy way to get things moving in Unity is to throw a Rigidbody (2D for my use) and a Collider component on the gameobject and voilà! you have a physics object. Again this is excellent to use for the main character or if you only have a few simple objects to manage but I am building an asteroid belt here. Each asteroid can drop from one to six items. After optimizing my meshes my physics draw went way down but was still not as low as I wanted it to be. For materials that the asteroids dropped I used the same setup as I did with the asteroids, Rigidbody2D and Collider2D. This was great for the quick setup but did I really need all that physics overhead to blow materials out of the explosion? Nope! So I created a class for the materials that set the velocity variable from the blast and moves the object away from the blast at a constant velocity using kinematic movement. Utilizing Unity’s Random.insideUnitCircle() function and multiplying by the max velocity I set the objects velocity variable on creation. This vastly reduced the drag from hundreds of materials floating around after a player went on a mining spree. Another thing I did was to reduce the number of materials dropped. Initially, each type of material could be dropped multiple times, I changed this to accumulate the amount of dropped items to one single object.