2D Center of Mass Characteristics for Trigger vs. No Trigger.

Physics
1

Should I expect the CenterOfMass/Rotational Inertial of a 2D RigidBody/Collider to change based on whether or not the collider is a trigger or not.

It does seem to be the case but it doesn’t seem like it should matter.

-Jeff

2

Triggers are ignored when it comes to calculating the center-of-mass/rotational-inertia for a Rigidbody2D.

3

So, if they are ignored, then I assume the Rigid Body just falls back to defaults when I flip the trigger switch progromattically?

That seems to be what I’m experiencing.

I just did a simple test on one of my Rigid Bodies with a collider:

With trigger box un-checked:

  • RigidBody.CenterOfMass = 0.1, -0.1
  • RigidBody.Inertia = 0.009968621

With trigger box checked:

  • RigidBody.CenterOfMass = 0, 0
  • RigidBody.Inertia = 1

I guess I can work around this by setting the Intertia and CenterOfMass explicitly so it doesn’t change when I switch from trigger to non-trigger and back.

By the way, I wouldn’t need to switch from trigger to non-trigger if I could cancel a collision response after the collision was detected. :slight_smile:

Thanks for the info!

-Jeff

4

Sort of. If the only collider on your body is a trigger then yes.

The COM and mass and rotational-inertia start at zero. It scans all fixtures (shapes on all colliders) attached to the body (ignoring triggers) adding up mass/COM and calculating the rotational-inerta. The only change at the end of this loop is that if the inertia is zero then it’s set to a default of 1.

Normally I’d direct anyone to the Box2D source as in "void b2Body::ResetMassData()" here. The difference in Unity comes from early-on when users complained that triggers participated in these calculations so there’s two parts of the loop that skip a collider shape (fixture):

  • If the density is zero
  • If the fixture is a trigger (Box2D sensor)

I hear you and we do have a feature planned for this but it’s tricky. We cannot just provide a script callback for each “pre-solve” as we are unable to stop you from making any modifications you like during such a callback (apart from stopping you deleting a GO/Component). This means you can modify objects participating in the simulation therefore it’d be easy to crash and burn. Providing that callback after the fact doesn’t help either. Also, doing this for every single pre-solve callback is expensive too. There are various ways around this which we’re looking at. ECS physics solves this by exposing everything but we’re not there yet.

For now, this would seem like the best option if the Rigidbody2D has to keep moving around. If it doesn’t then you can obviously just use Rigidbody2D.simulated or have the Collider on a separate child GameObject and change its layer so it won’t collider with anything which will remove existing contacts without changing its state in any way.

Feel free to message me directly if you need to, I’ll give you a direct email address if it’d help.

5

Thanks for the detailed response. I have the work-around in-place and it works fine. I just make note of the center of mass and intertia at start-up, then set it explicitly whenever I put the collider into trigger-mode.

-Jeff

1 Like
6

It does seem though that having the collider on a the child to which you simply change the layer to a layer which isn’t set to contact anything would work too effectively turning off contacts for that collider.

Feel free to contact me if you need anything else.

7

I’ll try that our as well and use whichever feels “cleaner”. --Thanks

1 Like