Stop colliding Rigidbody object in world permanently (best approach)

I've read a lot of threads talking about what constitutes a "static collider" and I understand you don't want to be moving them around or disabling/enabling them. But I'm having a surprisingly difficult time learning exactly how these create inefficiency.

My case involves a previously moving Rigidbody which can "attach" to the ground in a way that will no longer move, ever. I have two approaches that I would like some feedback on to decide which is more optimal:

1) First position the object in world space, then remove the Rigidbody component to make it a static collider.

2) First set the Rigidbody to kinematic, then position the object in world space and leave it sitting there indefinitely. Obviously this object is still "move ready" and therefore collisions will cost more than if they were static.

It's unclear to me from reading docs whether adding a new static collider requires a single "static collider calculation" for the new static collider (previously attached to the Rigidbody) or if this requires a "static world recalculation" for all the static colliders in the scene.

Clarification would be greatly appreciated, thanks!

 

They create inefficiency because under the hood the calculations they do are much more intensive. Try not to worry about it, essentially dont mark an object as "static" if it is going to move. If it is going to move and collide, give it a rigidbody

 

I understand what you're saying but I'm asking for the case where something WAS moving but will NEVER move again (but will stay in the game for a very long time and grow in number of non-moving colliders). It's something I very much need to worry about.

If someone can clarify whether this "more intensive" calculation is contained to the one static collider being added or if it causes the "static world" to be recalculated it would be extremely useful information. A one time cost to make a collider static is acceptable to me. However, a gradually increasing one time cost is obviously not.

 

If it WAS moving but never will again, then start it dynamic and have a static version as a prefab that you replace it with at the right moment.

There isnt really any cases where you need the same prefab to be able to be dynamic and static at different points. just switch out the prefabs at runtime and link all relevant references up so the behaviour continues using the new prefab in its place.

 

But enabling/disabling/creating a static collider also triggers the static calculation, so performance wise these are equivalent actions to removing a rigid body component. In my project new collider objects become children of rigid bodies on collision in unpredictable ways before reaching the static state so it is much simpler to just remove the rigid body or make it kinematic (there cannot be a predicted pre-created prefab).

Either way, the question remains the same. Does the addition/removal of a static collider cause a "static world" recalculation? I would like an official answer if possible, but it sounds like I may need to devise some tests to infer what is going on.

 

Honestly getting an official answer is not easy, otherwise you wouldnt see people like me popping up all over the place. Unity still have to get back to about 3 threads ive posted in this week, all of which have been awaiting an answer by multiple users on project breaking issues and inconsistencies.

Also even though in theory yes what you say is true, from my own profiling and test harness tests I have found that doing what I said is better performance wise, also dont "create" them, pool everything at the beginning and then just toggle the states of components / objects. Kinematic setting would probably be better than removing altogether as there is an overhead there too.

Honestly though doing unit tests for this kind of thing is much better than asking on the forums, youll never get a definitive answer that way! I usually unit test everything so I can be sure, because just because something is in the unity docs does not mean its true!

 

Yeah, I'm familiar with pooling and use it all over. That's why I included "enabling/disabling/creating". And while adding or removing components has it's cost, I'm not so much concerned with "many components being removed at once" as I am with "removing one Rigidbody component triggers a static calculation which scales with how many static objects there are". I'll post here if I discover anything.

 

I believe physics engines tend to optimise the case of rigid bodies that come to rest and put them in a sleep state, and group them together in islands of sleeping RBs that only wake up if disturbed by collision. In the sleep state the cease processing rigid body calculations.

I'm not exactly clear on the issue you are trying to solve here, but I'd be weary perhaps of reinventing that wheel.

 

You are correct about sleeping rigidbodies stopping physics calculations. This is also accomplished by making them kinematic. This, however, does not impact collision performance (except that only moving objects will check against it so less moving objects means it will be faster).

But, in the case of static colliders there is a one time calculation which assumes the collider will never move and makes collision detection much more efficient. So if the one time cost of making a new static collider does not grow it would be much faster in the long run. I'm not so much reinventing the wheel as I am implementing an uncommon behavior.

 

I didn't assume I just felt it needed to be made explicit - just incase

I presume this boils down to the cost of adding the AABB for the collider to a spatial structure for broadphase collision detection? Though not zero it should be fairly small

I don't know if layers can help you have your cake and eat it too? As in where you can use a 2nd layer for your static colliders to ensure you only rebuild those static broadphase structures?

 

I like where your heads at with layers. I'm going to first test out comparing setting kinematic versus removing the rigid body and if the problem arises I'll give it a shot using different layers. It looks like documentation doesn't really get specific enough so testing is the only remaining option (probably a good idea anyway ).

 

I'll be interested in your results when you have them... I don't know if this holds any relevance: https://blogs.unity3d.com/2014/07/08/high-performance-physics-in-unity-5/ particularly:

 

It's so hard to compare information shared in the forums against versions of unity. Seems like unity is moving towards accounting for common bad behavior by eliminating the more obscure optimizations (understandable but disappointing for someone like me).

From that article it sounds like this entire problem is irrelevant. It'll be a shame if the optimized route is now impossible to accomplish. Haven't had time to setup tests as I'm currently busy with some implementation deadlines but I'll post my findings when I do.

 

I think a better way of looking at your problem is like this: Do you really need to worry about it? Have you actually used it in your project and found it to show significant performance issues? Either of these answers will work functionally and it's not so complicated that if one turns out to be better down the road than the other that you can't simply change the behavior later.

I'd say pick one and move on. There are probably bigger issues to tackle. I suppose that if your really want to put the science in computer science then try them both and measure the results. I'd be interested in knowing myself. But every hour you spend on this rather trivial issue is probably an hour you could have spent working on a killer feature.