So I’m doing some optimization for moving obstacles in my 2d game. At first the FPS dropped like a stone when I had more than 10 obstacals at once.
When I looked it up physics were by far the biggest CPU hog. So I redid the colliders for the obstacles and made them much simpler which made it run much better.
However, it’s still not quite where I want it.
So I’m thinking I want to turn the colliders on and off. And it seems like I can do this one of three ways.
I could use a very simple collider as a trigger to turn on the detailed collider. I’m not sure if circles or squares are cheaper though.
I could track the distance from the obstacles to the player and then turn on the collider when it gets within a certain range.
I could compare the x and y coordinates of the player and the obstacle, then turn it on when both are close enough to one another.
I’m guessing #3 is the cheapest, but I figured I’d ask and see if anyone has an idea.
I’m pretty sure your solutions 2 and 3 are the same, and I’m pretty sure that’s exactly what the sphere collider does. The sphere collider is just the range to a point, so that just does a range check (I assume).
My FPS is terrible. I’m getting about 70 with 100 obstacles on my 5 y/o Samsung laptop with 4 gigs of RAM and 2.5 Ghz Dual core AMD. It’s just that I want to make sure that it’ll work on low end tablets and phones with 100 or so. Like iPhone 1 low end.
If it’s Unity 4, and your obstacles are moving and have colliders, you have to put kinematic rigidbodies on them, or your performance is going to crash hard - Unity 4 assumes that everything that has a collider, but no rigidbody, is never going to move, and optimizes for that. This means that whenever you move one, Unity has to rebuild a lot of it’s internal representation of the world.
The same thing shouldn’t be a problem in Unity 5, as they stopped making the same assumption - it was messing with too many people, and wasn’t very obvious.
I personally prefer event driven calculations rather than polling calculations.
Your options 2 and 3 are going to be polling on some interval (probably Update) for every detailed collider.
Where as option 1 will signal a message on the single moment when you intersect it (sure the physics engine is doing a bunch of continuous tests… but it’s a lot more efficient at doing that rather than you doing distance tests).
Well if it’s Unity 5, the physics are all multithreaded and it’s a much faster version of physx. You do not need rigidbodies on colliders in Unity 5 if you want to move them.
using UnityEngine;
using System.Collections;
public class ColliderSwitch : MonoBehaviour {
public GameObject myPlayer;
public GameObject myCollider;
public float minDistance;
// Use this for initialization
void Start () {
myPlayer = GameObject.Find("Player");
myCollider = gameObject.transform.Find("Collider").gameObject;
}
// Update is called once per frame
void Update () {
float distance = Vector2.Distance (myPlayer.transform.position, gameObject.transform.position);
if (distance < minDistance) {
myCollider.SetActive (true);
} else {
myCollider.SetActive (false);
}
}
}
and it made a MASSIVE difference.
I can now run like 500 with minimal dip in performance so long as they aren’t all in range.
I would suggest looking at Geographic Grid Registration, basically creating an imaginary grid of whatever size squares you want to assume. Then attach a behavior to your objects that register them with whatever “block” they are in on the grid. When your player moves between blocks just activate and deactivate colliders as needed, only those within the player and neighboring blocks if necessary. It’s a very efficient pruning mechanism as you can quickly determine which groups of objects you need to interact with.
