attachedRigidbdy clarification

Unity Engine
1

doc says “Colliders are automatically connected to the rigidbody attached to the same game object or attached to any parent game object.”
“or” means what here? same GO if it exists and parent if it doesn’t exist?

2

In the context of where the Rigidbody is. The Rigidbody is either on the GameObject the collider is or on a parent in the hierarchy.

3

Yes and if a rb is on the collider and on a parent what does it return?

4

The one it’s attached to which is the one on the same GameObject. When you create a collider it attaches to the nearest in the parent hierarchy starting with the GameObject its on.

attachedRigidbody.GameObject would show you this too.

1 Like
5

“nearest” - thanks.
Now you say when you create a collider… what happens to C1.attachedRigidBody in the following scenarios where R1(rb1)-C1 and R2(rb2)-C2 are similar hierarchies composed of a root R#, a colliders C#, rigid (rb#):

  • R1 is parented to R2 then rb1 is switched to kinematic
  • R1 parented to R2 then rb1 is removed
  • rb1 is removed, R1 is under R2(rb2), then we add (rb1) on R1
6

Creating different scenaios doesn’t change anything; it’s always connected as a I stated above. Changing the properties on RB changes nothing either. If you remove a RB or change the hierarchy then with respect to the collider reapply the same rule i.e. a RB on that GameObject or if not present then search “up” the hierarchy for one and attach to that. If there isn’t one at all then it’s attached to the global static ground-body which is why a GO without a RB is implicitly static.

Of course, this is what is supposed to happen and I can only speak with authority for 2D physics but both should be the same.

Also know that this kind of detaching/attaching should be avoided. The only reason it’s done is because devs can change the hierarchy and we need to ensure consistency. That doesn’t necessarily make this kind of behaviour a good or performant thing to do. Just like modifying the Transform when the Rigidbody is “in charge” of the Transform. We do it because it’s (unfortunately) changed.

1 Like
7

That’s true for simulated rb, kinematic rb are fine for such purpose, reparenting doesn’t show up in the profiler.

8

Sorry but I don’t follow what you mean here at all all; it’s always true and the body type has no relevance to which body is attached to. Wanted to clarify that is all.

Different subject? Anyway, work done when reparenting is indeed shown in the profiler so I’m wondering why you think it’s not. Here’s the 2D & 3D profiler names to watch out for.

  • Physics2D.SyncTransformChanges

  • Physics2D.SyncRigidbodyTransformChanges

  • Physics2D.SyncColliderTransformChanges

  • Physics2D.HandleHierarchyChanges

  • Physics.SyncColliderTransform

  • Physics.SyncRigidbodyTransform

  • Physics.HandleColliderHierarchyChanges

  • Physics.HandleBodyHierarchyChanges

Anyway, hope that info helps.

1 Like
9

Haha it’s funny how my don’t show in the profiler != your don’t show in the profiler.
My (and most game devs) “don’t show in the profiler” means it doesn’t spike - we only drill down in the profiler when we see a spike and Kinematic rb don’t spike when reparented. It’s probably a different story with 100s of objects.
Or maybe you were talking about something else than performance when you said that it should be avoided?

10

Actually, I’ev found that most devs seem to refer to performance/spikes/times rather than saying “it doesn’t show” but at least I know what you mean now so it’s all good.

Yes, you’re not going to have a huge several ms spike from doing a relatively small amount.

I was talking in context of the topic of this thread which is changing the Rigidbody(2D) that a Collider is attached to. You initially mentioned reparenting but that isn’t the only way this can happen and disconnecting a collider from a Rigidbody isn’t something you should be doing because, well, why would you do it? It has a cost but if that cost isn’t expensive in your case then fine. Reparenting should typically move a logical branch around and for physics that would typically be a rb and its colliders so there’s nothing for physics to do; certainly nothing related to the context of this thread (attached RB). Because you’re free to do anything you want for any reason you desire and if the cost isn’t of consequence for you then nobody is saying don’t do it. Still, it should be avoided as it doesn’t scale well. Again, this isn’t about re-parenting.

The underlying problem is that Unity allows you to do whatever you like and we have to do an awful lot of work to support what can be bad patterns and don’t have the luxury of just ignoring certain actions. Most physics sytems are designed for you to set up a body and attach shapes/joints then just simulate it. In Unity, devs split/combine the hierarchy, separate shapes from bodies, expect bodies in the hierarchy to drive each other (the physics systems know nothing of this), reconnect them and all sorts of JustDoIt™. When we say it should be avoided, it’s for many reasons some of which are performance/scale related but mostly it’s just try to “set-up and simulate”. As to the specific costs in 3D physics, it might not be as bad as in 2D (Box2D).

Anyway, this is way off the original topic. Sounds like you have your answer.