Abnormal bounce effect with container physical body in Havok

see line 57 ~ 79

Expectations:

Current :

After setting the physical body of the ground to Container, the strength of the bounce doesn’t seem to change no matter how I change the restitution parameter.

And as long as the physical body type of the ground is not a container, everything works normally. Is this a bug or have I made a mistake somewhere?

cc @Cedric

Interesting, I see that the only difference between both PG’s is Line 65: BABYLON.PhysicsShapeType.BOX vs. BABYLON.PhysicsShapeType.CONTAINER

Have you tried creating a BABYLON.PhysicsShapeContainer like in the example: https://doc.babylonjs.com/features/featuresDeepDive/physics/compounds

Yes, I’ve tried, here’s an example.

I also tested modifying the restitutionCombine property (which determines how the restitutions of two PhysicsShapes are mixed together), with no luck. This is because I noticed that the default value of containerShape’s restitutionCombine is different from the others.

But to keep things simple, I’ve commented out the relevant section

Also, I logged the material of all the shapes in the scene to check if I’m missing something.

I tried to modify the restitution in the documentation example, and he seems to have the same problem.

see line 65

In the Babylon.js havokPlugin.ts source: setMaterial() function: (which sets restitution and friction):

this._hknp.HP_Shape_SetMaterial(shape._pluginData, hpMaterial);

the Result returned by HP_Shape_SetMaterial() is not checked. My hunch is that this function is silently failing for BABYLON.PhysicsShapeType.CONTAINER

I just tried implementing a container shape in my project where I check Result for every Havok function call. HP_Shape_SetMaterial() is succeeding for individual shapes, but failing for container shapes

Let me look further into this tomorrow

Indeed, it works in my project if HP_Shape_SetMaterial() is run for each child shape instead of the container shape

@eoin @Cedric Is it possible to expose a Havok function to return the children shape IDs (Array<HP_ShapeId>) of a container shape? Currently, we only have a function that returns the number of children:

HavokPhysics.d.ts

/** Get the number of children of the container. */
HP_Shape_GetNumChildren(container : HP_ShapeId): [Result, number];

If we have a function that returns the children shape IDs, it would be much easier to implement a fix for this in the Babylon.js source. Otherwise, we may have to keep track of a container and all of its children in havokPlugin.ts. Thank you for your help!

Hi,

I’m currently on the road, so can’t give a super detailed answer right now, but it’s expected that you can’t set a material on a compound shape - the compoudn doesn’t have any geometry of it’s own, so there’s nothing to set a material on; we decided that the alternative behaviour where a compound would set the materials of the child shapes could be confusing, since those shapes might be used in multiple different places, so we wanted to avoid implicit side-effects like this.

Totally agree that we should have an interface to access the child shapes of a compound. If you want to log a bug in GitHub - BabylonJS/havok: The Havok Physics plugin runtime files (wasm and js), I’ll look into it once I’m back in the office :slight_smile:

You need to set the material on the child shapes; so if you change line 65 to read:

cubeShape.material = {restitution: 1};

it should have the effect you’re after.

I’ve tried setting the material for each childShape before, but it looks like there’s something wrong with the way I set it up.

  // ❌ The material will not be updated.
  childShape.material.restitution = 1

  // 👍 The material will be refreshed
  childShape.material = { restitution: 1 };

  // 👍 or Manually trigger the set function
  childShape.material.restitution = 1
  childShape.material = childShape.material

perhaps we should clarify in the documentation that ContainerShape is not affected by materials, and also provide more details about the small considerations when setting materials.

Thank you so much, @eoin :slight_smile: I’ve submitted an enhancement request as you recommended

I really like your and the team’s approach of not using the alternative behaviour. It seems to give us more flexibility in that we can have a container with children each with different friction, restitution, and collision filter masks

Interesting find. It looks like this is because of the setter:

public set material(material: PhysicsMaterial) {
    this._physicsPlugin.setMaterial(this, material);
    this._material = material;
}

There’s a similar issue (where the setter triggers an important side effect) in assigning shape to a physicsBody. The .shape setter recalculates mass properties whereas assigning .density directly to shape does not trigger the recalculation.