Scaling of Collision Shapes

Troubleshooting physics
1

As reported by @JhonKkk: The SDK doesn’t scale CollisionShapes at all when scaling the node.

https://hub.jmonkeyengine.org/uploads/default/original/4X/1/6/0/1600edf1fc21a5d8430f1220867734207f1b1c4a.png

(Note that in the first picture this is the mesh and in the second picture that’s the collission shape).

Now this is trivial to fix, but the question is about the scalability of CollisionShapes, especially with non-uniform scale that could happen.

@RiccardoBlb wrote on Discord:

it is ok to scale some
i think gimpact and mesh shape can’t be scaled, but everything else should be ok

Any other opinions? I am also wondering whether the sdk should just iterate over all controls below the scaled node to find any physics control and scale it’s shape (and/or if it’s even possible to scale already attached shapes, like if there is a getter for that?)

2

Wow. Thank you for your answers. In the future, I will submit the error report in the right way. Thank you again.
:+1:

3

During the development of Minie, I did some experiments. I concluded that, in modern versions of Bullet, all collision shapes except SimplexCollisionShape may be scaled uniformly, ie by (0.2,0.2,0.2) or (9,9,9). So it’s fine to scale GImpact and mesh shapes.

The following collision shapes should only be scaled uniformly:

  • CapsuleCollisionShape
  • ConeCollisionShape
  • SphereCollisionShape

A CylinderCollisionShape may be scaled arbitrarily on its principal axis, but the other 2 axes must have the same scale factors. In other words, its cross section must be a circle, not an ellipse.

Minie includes a CollisionShape.canScale() method that implements these rules.

1 Like
4

And the same doesn’t also apply to the Capsule?
Thanks for your precious work, that’s more than enough to get the SDK going.

1 Like
5

Like I said, capsules should only be scaled uniformly, which means they are stricter about scaling than cylinders.

1 Like
6

JME does not support non-uniform scaling… so even if you did try to support it in bullet it would be incompatible.

JME pretends to support non-uniform scaling but it’s only sensible to do it on Geometry (ie: leaves of the graph). This is because scale is rolled up into one value for the whole path to the parent… so non-uniform scaling does not pay attention to rotation/translaction/etc. as it should.

So just keep that in mind when supporting non-uniform scaling. (I personally think that JME should disallow non-uniform scaling on Nodes… something to consider for JME4, maybe.)

4 Likes
7

A couple afterthoughts:

  1. My experiments were entirely with native Bullet. No telling if they apply to JBullet.
  2. Prior to JME 3.2.4 there was a bug (1120) affecting scaled GImpact shapes.
8

In the SDK editor，
Rigid body scaling is correct for quad geometry.

Other geometry, rigid body scaling is not correct.