What exactly is considered "moving static colliders"?

I have read and heard ( from UNITE videos ) many times that moving static colliders is a big no-no, so if you’re gonna move something that has a collider then you should always add a rigidbody.

But I’m confused as to what is considered “moving” a static collider? For example, in my scene I have some object which all have a MeshCollider, but no rigidbody. Each of them has a script attached which changes their position when something happens, like so:

public Transform target;
Vector3 oldPosition, newPosition;

void Start()
{
    oldPosition = transform.position;
    newPosition = target.position;
}

void Update()
{
    // Here I move my object to a new position in 1 frame. This object has a MeshCollider attached.
    // Is this considered moving a static collider and should I attach a rigidbody to this object?
    if( timeToMove == true )
    {
        transform.position = newPosition;
    }
    else
    {
        transform.position = oldPosition;
    }
}

Thanks for your time guys!
Stephane

Moving a collider that doesn’t have a rigidbody is moving a static collider.

–Eric

1 Like

What about if you have a GameObject with children, setup like this:

  • Parent (Collider Rigidbody)
    – Child1 (Collider)
    – Child2 (Collider)
    etc…

and you’re moving the Parent, should each child which has a Collider also have a Rigidbody, or are they fine without since you’re not moving them directly, they’re just changing global position because of the Parent being moved, but their local position remains the same? Also, is enabling/disabling static colliders also considered “moving” them?

Thanks Eric!

AFAIK, that setup acts as a compound collider (several colliders acting as one through parenting). as long as the parent has a rigidbody, you’re fine.

2 Likes

Correct; you should not use a rigidbody for children if the parent has a rigidbody.

–Eric

Got it, thanks guys!
One last question if you don’t mind? What if I move one of the children directly - parent remains still, children moves - then does that child need a Rigidbody or is this still acting as a compound collider?

Thanks again :slight_smile:

interesting…

adds rigidbodies back to projectiles.

Yeah, it’s actually in the unity docs regarding using a rigidbody for speed in these cases. I’m not going to lecture anyone, just pointing out this could be clarified in the docs more, perhaps.

Just had a read through the docs for rigidbody component and couldnt see anything that specifically stated if its moving, put a rigidbody on it, but this hardly surprises me.

I find unity docs lacking at best

2 Likes

http://docs.unity3d.com/Documentation/ScriptReference/Collider.html

Rigidbodies are for physics (eg: moving things), I think it was safe for the author to assume you knew that when you got there.

It could use clarification though. Saying recommended isn’t really clear. It’s also mentioned in a similar manner elsewhere in the docs, and equally as vague. The docs need to be a bit more verbose given so many people are asking the same question. Not all of them are dumb enough to not read docs.

It’s also important to use the rigidbody MovePosition and MoveRotation functions instead of directly changing the transform - last time I checked, changing the transform of a kinematic rigidbody was actually a lot slower than moving it as a static collider.

To illustrate or help quantify this point, here are the results of a test I did a while ago. The performance difference is significant.

It annoys me that I’m going to have to build performance scenes just to verify what costs the most. Its something ive been thinking about doing for a while though.

Cant say I ever looked at the collider docs… it would make much more sense to put statements like that into the rigidbody component…

More definitive statements like this would be great…
“If you are moving a collider, you must put a rigidbody on it to reduce physics calculations” or something along those lines so its blatantly obvious that if you dont do it, youre taking a performance hit.

The funny part was during my ‘performance optimisations’ I removed all the rigidbodies from my projectiles and put in some object pooling. Everything seemed alot faster, but i guess it was probably more the pooling than anything.

Wow…what a huge difference! It would be nice if the docs mentioned this as well, I had no idea it was THAT much slower! What about the difference between moving a static collider and a rigidbody through transform.position instead of rigidbody.MovePosition or rigidbody.position?

I hear you…I think that things like these which take a big performance impact should really be talked about in-depth in the docs.

BTW guys, is enabling/disabling a static collider considered “moving” it, since the collider isn’t part of the scene anymore?

So I just did my own tests…

The code for the test iterates 500000 times in Start and moves the object to Vector3(0,0,0) each iteration.

Object with NO Collider and NO rigidbody:
transform.position: 2.540ms

Object with Collider and NO rigidbody:
transform.position: 11.296ms

Object with Collider and Rigidbody:
transform.position: 20.429ms
rigidbody.position: 1.689ms
rigidbody.MovePosition(): 1.701ms

So, if you’re gonna move/rotate/change an object which has a collider, add a rigidbody and move/rotate the object via its rigidbody. And as you can see above, if you’re moving the object via its transform, IT’S FASTER TO MOVE A STATIC COLLIDER THEN A COLLIDER/RIGIDBODY SETUP! So unless you’re going to changes all your movement to use rigidbody instead of transform, do not add a rigidbody as it is slower. But if you care about performance, then add that rigidbody and change all your movement code to rigidbody.position instead of transform.position.

Then again, the test above is over 500000 iterations, so none of this matters much if you’re only doing it once a frame…

3 Likes

Interesting stuff.

You should extend your tests a bit…

try doing transform.move with a kinematic rigidbody/collider… be interested to see those results.

which is fine if you have 1 object, now multiply that by 1000/objects and it definitely matters.

In my test above, the rigidbody is kinematic on the collider/rigidbody setup. I haven’t tried testing with a non-kinematic rigidbody since it is not the issue. Unless I understood you wrong? And yes, the results are interesting!

Very true, very true!

Man, now I’ve got to rewrite my movement scripts. At least it’s reasonably simple to switch from tx.position to rb.position. Thanks!