Moving static colliders performance

Which one would be less expensive in Unity 5.6?
Moving static colliders (i.e without any rigid body) or Moving collider with a rigid body?

 

You don't move static colliders ever. They're static.

 

Moving static colliders became much less expensive with the release of Unity 5. I would suggest a bench mark scene if its important.

 

But I'm curious, as it was also discussed in another thread. Is there any reason not to attach a rigid body to any game objects that is supposed to move?

Adding a rigid body component is quite trivial, and I haven't met any cases where having a rigid body could make it more complex, or interfere with existing functionalities.

So, is there any valid reason why someone may want to avoid adding a rigid body in a moving object?

 

Moving colliders with a rigidbody should be less expensive. As @BoredMormon said, moving static colliders became less expensive, but still a good idea would be to attach kinematic rigibdody instead.

 

I would expect the presence of rigidbody components to affect the cost of other things, like raycasts, because for the static colliders afaik some kind of spatial pre-processing is done as an optimization step, that needs to be re-done when the static collider is moved (which is why that's slower than moving rigidbodies).

What I'd like to know is what to do when I have plenty of colliders, that "go away" at some point. Like in an RTS where every building has at least one collider, but buildings can be destroyed, and there can be many of them, should they all get rigidbodies?

Does anyone know? I'm not sure how to benchmark this because I'd expect the cost from putting rigidbodies on there to show up as something else, like raycasts for example.

 

A stress test bench mark might be applicable. Basically load a scene up with a ridiculously high number of colliders under the various situations. See which one performs better.

Its not likely to be super accurate, but it will give you a rough idea.

 

Yes, and that's my current understanding of how adding rigidbody to a collider that's supposed to move might help boost performance, as it's excluded from the said optimization process, so it won't trigger recalculations when it moves.

By the way, my question was actually the opposite case, as I was curious if there could be any occasion where not attaching a rigidbody to a moving collider would make sense.

Anyway, as to the destructible structures, I don't think I'm knowledgeable enough to say much about it. But if my understanding of how a rigidbody to a moving collider could make it perform better as I mentioned above, then I suppose the same thing might apply to this case as well.

If the reason of a performance boost is indeed because of those dynamic objects being excluded from the optimization process, then I guess destroying a wall object with a collider, for example might trigger a recalculation, if it doesn't have a rigidbody.

But probably it could be a matter of a trade off between the potential performance boost of including that wall in the optimization process while it's intact, and the potential performance loss of a recalculation when it gets destroyed.

My gut feeling is that unless the performance penalty is severe enough to cause a lag when it gets destroyed, it might be better to squeeze the performance gain of including such a wall in the optimization process, as it will probably spend much more time in its initial status than in a being destroyed status.

But again, I know little about these matters so please don't take my words too seriously

 

I think this is the case, and the problem is I can't reliably quantify which is the better tradeoff. With the caveat that I only tested in editor with deep profile on (which in itself can really skew results big time) because I don't have the time to compile different builds the whole day, I would say it's inconclusive. I do see some difference, but it depends on the exact situation which one actually performs worse. I'm leaning towards not having rigidbodies on them, because I can be sure that there will be lots of raycasts (aka shooting) going on, but I can't guarantuee the player will actually be destroying buildings in large numbers.

 

It is hard to say which one would be faster without reading physx source. I'd expect non-moving objects to have next to no overhead, as long as their rigidbodies are set to "kinematic".

 

I suspect it's not about the overhead of the stationary kinematic rigidbodies themselves (I agree that that's probably negligable), but rather things like raycasts near them, where possibly static colliders without rigidbodies get put into a more advanced spatial optimization structure, so that they can be discarded from expensive checks like raycasts, where the rigidbodies might be put through more calculations than necessary. But like you said, it's a blackbox so we are kinda guessing here.

 

I wouldn't be so sure actually.

 

To clarify, the "static colliders" performance, is when there are no rigidbodies in the scene at all.

As soon as you introduce a rigidbody, the performance becomes much worse.



But even then, just having one kinematic is still faster than having everything be kinematic. So I don't know why Unity is still suggesting to us that we add kinematic rigidbodies to our colliders.

 

That's to be expected. With no rigid bodies, there can be no collisions. So Unity can turn off PhysX entirely. But if you are going this route, you might as well have no colliders at all.

Are all the colliders moving in your scene?

If not that's a significant departure from performance in previous versions, which is worth taking note of.

 

What if I want colliders for Raycasts only (and I do)?

They are all moving, yes.

 

Point taken. I would imagine the use case for ray casting only with no collisions would be fairly limited.

 

I don't think so. If it was limited how would "the cost associated with moving Static Colliders is one of the top 3 causes of performance issues in Unity games" (taken from here : https://blogs.unity3d.com/2014/07/08/high-performance-physics-in-unity-5/ ), if no one was was using colliders without rigidbodies?

EDIT: Also, Kinematic rigidbodies don't do collisions with themselves either, so practically, moving a whole ton of kinematic colliders and "static" colliders is functionally the same, but one of them performs 10x times faster.

EDIT #2:

In short, I haven't found any situation where adding a kinematic rigidbody improves performance, and AFAIK this has been the case for all of the Unity 5.x cycle. At best it's the same, often it's slightly worse and in some cases it's like 10x slower.

But the "add kinematic rigidbody" if you move colliders advice is still being thrown around (like in this thread and many others and even by devs) and even the manual still warns about the costs of moving static colliders. But to the best of my knowledge, that advice has only been relevant in the Unity 4.x days.

If someone has found a situation where adding a kinematic rigidbody to a collider actually makes performance better, let me know.

Because I can see 3 possibilities, either I'm missing something major somewhere, or there's a bug somewhere, or the manual is really bonkers and even devs themselves are confused on the issue. I'm leaning towards option 3 being true.

 

Old thread but turning of PhysX using

Physics.autosimulate = false;

REALLY boosted my performance and still allows Raycasts. Although it is a feature of newer Unity versions.