Child in physics compound body not rotated properly under Ammo.js and Oimo

Bugs
1

When the parent of a physics compound body is rotated, the child physics body does not appear to be correctly when Ammo or Oimo is used.

This PG demonstrates the problem. https://playground.babylonjs.com/#PRHF00#22

  • The compound body hits the static body when it should be missing it.
  • If the parent of the compound body is not rotated, then the physics body is correct. No collision occurs.
  • If using cannon, everything works fine.
  • If using ammo, the mesh is rotated correctly, but the physics body is not.
  • If using oimo, both the mesh and physics body are not rotated correctly.

It’s quite hard to debug this, as the inspector does not show the physics body of the child, and I don’t know of any ways to determine the dimensions/rotation/position of the child physics body except by interaction with other objects.

1 Like
2

Adding @RaananW

3

So! This is an interesting issue.

It seems like the parent’s rotation is not taken into account when initializing it with rotation.

If you rotate the parent AFTER the init it does work correctly - https://playground.babylonjs.com/#PRHF00#23 .

I am not saying this is the solution, I am just suggesting a solution until we investigate further why this happens.

1 Like
4

I think I know the cause. In ammoJSPlugin.ts…

878 var extendSize = impostor.getObjectExtendSize();

…the extendSize takes into consideration the parent’s rotation. This is incorrect, as parent’s rotation are ignored when adding the child into the compound shape.

I’m afraid I’m not sufficiently familiar with the physics code to know how best to fix this. Modifying getObjectExtendSize to ignore parent’s rotation would likely break other things. Perhaps reversing the parent’s rotation in _tmpAmmoTransform would work.

2 Likes
5

Did a bit most digging…

Reversing the child’s rotation in _tmpAmmoTransform will not work if the parent’s rotation is not a multiple of 90 degrees, as the extend size will remain incorrect.

Changing…

physicsImposter.ts, line 613:
let size = boundingInfo.boundingBox.extendSizeWorld.scale(2);

…into…

let size = boundingInfo.boundingBox.extendSize.scale(2);

…should fix things for ammo, and probably improve the situation for oimo. Not sure how that will affect cannon which is already working correctly.

1 Like
6

Pretty sure now that changing extendSizeWorld to extendSize is the way to go. In this PG with a 45 degrees rotation, even cannon is behaving incorrectly. https://playground.babylonjs.com/#PRHF00#24

7

A possible workaround is setting the rotationQuaternions after setting the PhysicsImpostors: https://playground.babylonjs.com/#PRHF00#28

There may still be a bug as @Cort mentioned

Also found this quoted in the Babylon doc https://doc.babylonjs.com/features/position,_rotation,_scaling:

1. You must set and use rotationQuaternion when creating physics objects because physics engines rely only on them.
2. Setting a rotationQuaternion overwrites the use of rotation see warning

8

This is there to explain that the physics engines convert your rotation to quaternions so don’t use .rotation after setting a physics impostor. I do agree however that you can understand this sentence a bit differently :slight_smile:

This is certainly a bug, and it seems like the extent size change is the way to go. There was a reason why we decided to use extendSizeWorld, so I will have to see when what should be used. The logic is clear thou :wink:

Want to report an issue on github so we can follow this? Link this thread as well when filing it.

1 Like
9

Sure! I can file this bug, though I don’t think I understand it as well as you and @Cort. Is the bug that setting mesh.rotation before assigning its physicsImpostor results in incorrect collisions?

10

Posted an issue on github. I’ve also tested the extendSizeWorld to extendSize fix on a local copy, and it fixed things for both cannon and ammo. Oimo remains broken, …but less so.

1 Like