Non-static colliders without rigidbody still cost in Unity 5?

[Alan-Liu]

Should I make sure a rigidbody is on same GameObject or parent?

[henaxing]

I don’t think so… anybody?

[MelvMay]

The question doesn’t make sense really.

A Collider that’s non-static but doesn’t have a Rigidbody means that it’s on a child GameObject and is implicitly attaching to a Rigidbody on a parent GameObject. That doesn’t have a cost, nor did it ever.

The only thing that changed in 3D physics is moving a Static Collider i.e. a Collider that doesn’t have a Rigidbody to attach to change to be far less expensive in 5.5.

[AcidArrow]

@MelvMay

The only thing that changed in 3D physics is moving a Static Collider

Is it still slower than moving a non-static collider?

[MelvMay]

@AcidArrow

Is it still slower than moving a non-static collider?

Sorry but your questions are too vague. I am even presuming you mean 3D physics and not 2D physics. How do you ‘move’ the collider? Do you set the Transform or using Rigidbody(2D).MovePosition? Why is this even an issue for you? Are you seeing some problem?

If you want to move a collider yourself instead of the physics system doing so and it to not respond to forces then add a Kinematic Rigidbody (IsKinematic=true). If you want the physics system to move it and it to respond to forces then use a Dynamic Rigidbody (IsKinematic=false). If you don’t want the physics system to move it and you’re not moving it and it not to respond to forces then use a Static Rigidbody (for 3D physics you just don’t add a Rigidbody, in 2D you can explicitly set the bodyType).

[AcidArrow]

@MelvMay

Sorry but your questions are too vague. I am even presuming you mean 3D physics and not 2D physics. How do you ‘move’ the collider? Do you set the Transform or using Rigidbody(2D).MovePosition? Why is this even an issue for you? Are you seeing some problem?

It’s not an issue, I’m just asking out of curiosity and I only had one question.

The profiler used to issue a warning, if I moved a gameobject (by setting the transform.position directly) that had a collider (I’m talking about 3D physics, which I thought was clear, since I quoted you talking about 3D physics), without a kinematic rigid body.

And since this was a thing that a lot of developers did (by mistake, or simply not knowing better), I believe this case was optimized (at least, that’s what I remember reading on a Unity blogpost, please correct me if I’m wrong).

So to be more specific:

Is doing GameObject.transform.position = new Vector3(a,b,c); (assume a,b,c are random values) faster on a gameobject that has a collider and a rigidbody set to kinematic, or on a gameobject that just has a collider (at which point, I believe the collider is considered to be “static”)?

EDIT:

From this blogpost: https://blogs.unity3d.com/2014/07/08/high-performance-physics-in-unity-5/

Moving Static Colliders will be a lot less expensive. A Static Collider is just a gameobject with a collider component on it, but without a Rigidbody component. Previously, since the SDK assumed that Static Colliders aren’t moved, moving a Static Collider would trigger an expensive AABB tree rebuild that affected overall performance badly.

In Unity 5, we’ll use the same data structure to handle the movement of both dynamic and static colliders. Unfortunately, we’ll lose the benefit of Static Colliders consuming less memory than dynamic ones. However, right now, the cost associated with moving Static Colliders is one of the top 3 causes of performance issues in Unity games. We wanted to change that.

Which makes me think that moving a static collider and a rigidbody-less collider is now the same thing, which certainly wasn’t the case in Unity 4. Is it? Or are there still differences?

[MelvMay]

@AcidArrow

Is doing GameObject.transform.position = new Vector3(a,b,c); (assume a,b,c are random values) faster on a gameobject that has a collider and a rigidbody set to kinematic, or on a gameobject that just has a collider (at which point, I believe the collider is considered to be “static”)?

I’m a 2D physics dev not a 3D one so I’m not sure on the exact improvement made. From what I understand, the overhead has been completely removed or the difference is negligible so they should be the same but it’s a really easy thing to test with the profiler surely?

I will add finally that I see this kind of thing being asked all the time as if adding a Kinematic Rigidbody is something to be avoided or bad to do if you’re explicitly moving a collider. It’s what it is designed for. I think it stems from the (in my opinion) bad decision early on in Unity to allow not adding a Rigidbody to implicitly mean Static. Note this isn’t some dig at you at all, just my observation that this implicit action raises needless question on what is a good way of doing things because yeah, less is better (not adding a component).

[AcidArrow]

@MelvMay

From what I understand, the overhead has been completely removed or the difference is negligible so they should be the same but it’s a really easy thing to test with the profiler surely?

There have been tests, they were kinda inconclusive (but it seems they are now roughly in the same ballpark in terms of performance)

@MelvMay

will add finally that I see this kind of thing being asked all the time as if adding a Kinematic Rigidbody is something to be avoided or bad to do if you’re explicitly moving a collider. It’s what it is designed for. I think it stems from the (in my opinion) bad decision early on in Unity to allow not adding a Rigidbody to implicitly mean Static.

I’m adding rigidbodies when I intend to move colliders, so it’s not an issue for me personally. It’s a bit weird workflow though (which you seem to agree on).

The thing is, on the forums, there was a big push to educate people on this issue, since a lot of people did it wrong (in the Unity 4 era).

Then there was the blog post I posted above, which led people to believe, that for Unity 5, kinematic rigidbody or not, it’s the same thing now, at least performance wise.

But then the manual ( https://docs.unity3d.com/Manual/CollidersOverview.html ) says

The physics engine assumes that static colliders never move or change and can make useful optimizations based on this assumption. Consequently, static colliders should not be disabled/enabled, moved or scaled during gameplay.

Which is the opposite. But then again, as a lot of things in the manual, it could just be very outdated.

So you can probably see why people are a bit confused as what the “best practice” is.

[AcidArrow]

And to confuse things even further, it seems moving colliders without rigidbodies is actually much faster according to a quick test I just did.

[AcidArrow]

Yeah, so, moving 1000 box colliders takes about 2.8ms, and if I attach a Kinematic Rigidbody on the parent object (or to all cubes individually, it makes no difference it seems), it needs around 27ms.

So maybe I’m doing something wrong, or the manual is flat out wrong, or there’s a bug?

[MelvMay]

At this point, it’s better to speak to a 3D physics dev such as Anthony Yakolev ( @yant ).

[yant]

Can I have a look at your particular project with 2.8ms / 27ms difference?

In general, one is advised to have a RB on all the physics objects that are moved from scripts as otherwise some parts of the world might not get updated properly (example: a ball sleeping on a static box won’t always be awaken if you remove the static box; a performance optimisation in the physics engine).

As for your earlier questions, we’ve had moving of static objects sped up significantly in Unity 5.0 Unity Blog that’s why the performance warning was removed.

Anthony

[AcidArrow]

@yant

I submitted a bug report (as a documentation bug, since I really don’t know if it’s an actual bug, or if the docs are simply outdated). I had a repro scene attached with it. It’s case 873057.

[PhilSA]

From the tests I’ve made, it seems like moving non-rigidbody colliders is now the fastest thing. It’s faster than moving kinematic rigidbody colliders or non-kinematic rigidbody colliders.

This surprised me because it was kind of a well-known Unity thing that everytime you had to move colliders, it was better if they had rigidbodies, but apparently this isn’t true anymore

[silentneedle]

@yant Any update on this?

[AcidArrow]

@PhilSA

From the tests I’ve made, it seems like moving non-rigidbody colliders is now the fastest thing. It’s faster than moving kinematic rigidbody colliders or non-kinematic rigidbody colliders.

This surprised me because it was kind of a well-known Unity thing that everytime you had to move colliders, it was better if they had rigidbodies, but apparently this isn’t true anymore

Which is fine, btw. Having to add a rigidbody just to mark a collider as “non-static” was always kinda weird.

So it’s good that it was changed. The thing is we don’t know how exactly it was changed and the manual saying the complete opposite of what is happening isn’t helping.

I’m not sure there’s an actual bug here, the thing needed could be a complete rewrite of that section in the manual.

[silentneedle]

@AcidArrow What Unity version do you’ve used with your test?

I’ve tested it myself with 1000 moving cubes and got the same result (kinematic rigidbodies are slower) @ Unity 5.4.

[Ali_V_Quest]

Hi
I’m moving thousands of trigger colliders every frame ( using their transform )
I’ve had a kinematic rigidbody attached to every trigger, but I’ve tried removing it and the performance changed significantly ( from about 15 fps to 40 fps )
The player ( with a rigidbody ) is still able to collide with the triggers without any issues.

I wanted to know if this might introduce bugs or if some collisions might not be detected ?

[URocks]

maybe it can helps 2D coliders or triggers are making huge overhead if they have animated parent

[Ali_V_Quest]

@larex39 Thanks, but I think I have the opposite issue
removing the kinematic rigidbodies really enhances performance
Right now i’m just concerned of getting weird physics behavior since unity recommends adding rigidbodies to any trigger collider that moves