Havok Cylinder Physics Broken


It seems that Havok’s implementation of PhysicsShapeCylinder is broken; depending on the ratio between cylinder length and diameter, the actual collision shape used becomes an infinitely-thin planar circle. See this playground: https://playground.babylonjs.com/#0VS3BE#3

Turn on the Physics Helper in the Inspector pane to see the circular collision meshes. I included a couple of other Physics Shape instantiation methods which give the same result. The result is that the cylinders clip though faces easily etc.


You probably need to increase the diameter and height of the cylinder.
I have tried similar samples before.

I tried scaling everything up by 10 times, same result. Hence my comment about the ratio. I’ll add a scale variable to the playground.

Playground updated to add a scale variable.

It looks like the issue as actually a combination of cylinder diameter and thickness. The resulting collision shape seems to have some padding, i.e. is smaller than the passed cylinder mesh. This results in the collision mesh being two planar circles below certain sizes. I’ve dug but can’t find any parameters regarding the apparent padding.

Either way, a physics engine being unable to simulate e.g. a coin seems like a bug to me.

cc @carolhmj and @Cedric

What if you tried 100x instead of 10x?
I don’t know about Havok, but many of the physics engines use MKS units.

I don’t think it’s a ratio problem. I think it’s related to this issue:

points A and B are not computed correctly so the cylinder is flat.

Nop, not the same issue. It looks like when dimensions are not in the good ranges, there is some jittering.
Do you confirm @eoin ?

So, I think there’s two separate problems here; one is the debug display geometry; internally, physics doesn’t store the “real” input vertices, so we reconstruct the debug geometry from the physics shape; we chose to use a “fast-but-slightly-inaccurate” algorithm here, which ends up with slightly smaller debug geometry than are really used by the shape. It’s not noticeable at larger scales, but does show up artifacts when shapes are this small. Maybe we should revisit this decision, to avoid user confusion, Cedric?

As far as the accuracy is concerned, this is unfortunately due to the small scale. Physics solvers aren’t perfect; there’s always some error. In this case, the error comes from the huge difference between the gravity (10m/s) and the size of the coin (0.001m) – four orders of magnitude. That error is enough to let the objects rotate and tunnel through the landscape, but it’ll also have some negative effects on the engines’ ability to stack objects and when objects are detected as “sleeping.” I’d recommend keeping the minimum object scale at a few centimeters, if you want to have “real world” gravity. You can also scale the inertia of the bodies, which helps with the rotation effect that the bodies experience.