Havok memory access out of bounds

Morning folks,

Havok is causing me Havok! :wink: See what I did there:

I’m seeing a memory access out of bounds error the moment I add a Physics6DoFConstraint constraint to an aggregate body

Which I was hoping would replace the old ammo setAngularFactor call to keep a imposter locked upright on the Y axis.

No dice though, I’m wondering if there are any known gotchas or bugs, the setup for this is a parent transform that I ran calculateBoundingBox over, the aggregate is applied that transform, the actual player mesh is a child of the parent transform.

  calculateBoundingBox = () => {
    let cm = this.mesh.getChildMeshes();
    let min = cm[0].getBoundingInfo().boundingBox.minimumWorld;
    let max = cm[0].getBoundingInfo().boundingBox.maximumWorld;
    for (let i = 0; i < cm.length; i++) {
      let meshMin = cm[i].getBoundingInfo().boundingBox.minimumWorld;
      let meshMax = cm[i].getBoundingInfo().boundingBox.maximumWorld;

      min = Vector3.Minimize(min, meshMin);
      max = Vector3.Maximize(max, meshMax);
    }
    this.mesh.setBoundingInfo(new BoundingInfo(min, max));
  };

I’m going add things as I try and figure out what’s up here.

Chrome Win x64, Version 112.0.5615.138 (Official Build) (64-bit)

I don’t think it’s the calculate bounding box and assign info, and the root transform is actually a mesh, my bad.

Also spotted this in the logs:

Info: redacted.cpp:2049: [0x4C873B15] Warning: Attempted to constrain body 0x08000000001000000 to itself. Skipping creation of the constraint.
HavokPhysics.wasm:0x1e3cf0  [common.baseSystem]

I’m wondering if I injured myself trying to use the aggregate helper :wink:

CC @Cedric .
Is it possible to reproduce that on the playground?

Copy that, already working on it :slight_smile:

2 Likes

@RaananW & @Cedric Not that i’m trying to break things, but I feel a great sense of achivement being able to pull together a playground that does really break.

1 Like

True story and side note, trying to load that playground on the iPhone just moans about the web assembly not being valid.

1 Like

Thanks! I’ll wait for @Cedric to fully debugging this, but will probably go over the code today to try and understand what’s going on.

1 Like

Thanks @RaananW , side question, I saw you did some work getting rapier working in babylon, is there any interest in packaging that up into a V2 plugin, I’m not saying I’m the right person but determnistic physics would be really useful for me, so I could give it a shot. I haven’t looked at compatability or if anything is missing, but I see constraints exist at a high level.

1 Like

Apart of preliminary testing of the engine we haven’t done too much with rapier. Once Havok was approved, there was no need to work on any other engine!
Having said that - the new physics architecture is ready for any other engine to be integrated! Rapier is a great physics engine with great benefits, and I can promise we will never say no to any new plugin implemented :slight_smile:
If you want to give it a try, please do. I can’t wait to review this PR! :slight_smile:

1 Like

I am the least qualified to do this, but It’s on the roadmap, so I’ll see if its just case of wrapping it and getting an MVP going. For single player stuff Havok makes a ton of sense, for anything over the wire with physics, it feels like a deterministic solution would be better, depending on how how imporant the outcome of physcs simulation is, multiplayer football for example.

Do you mean to add a constraint to the same object? child and object should not be the same

With ammo we used to do setAngularFactor to lock off an axis, for example if you didn’t want something to fall over, you would lock off the Y axis, In my case, I don’t want avatars falling over :wink: but it wasn’t clear what the replacement was in V2 API, seems like the 6DOF constraint would be the way.

In short if you have capsule imposter and you move forward, it will fall over, but we could setAngularFactor (0,1,0) to lock off the y axis before to stop the capsule falling over.

i’ll wait for @Cedric on this one, he knows the ins and outs better

1 Like

The best way to stop a body from rotating is to modify it’s inertia and set some of the axes to zero. This will allow a body to only rotate around the Y axis:

let body : PhysicsBody = …
body.setMassProperties( {inertia: new Vector3(0, 1, 0) } ); // Can set all the axes to zero if you want to prevent all rotations

There’s a couple of reasons this is the best way:

#1 It’s slightly less math for the constraint solver to work through.
#2 Constraint solvers aren’t perfect, it’s possible to see errors when using joints – especially if a body is being squeezed between two real heavy bodies. Changing the inertia prevents interactions from ever having an effect on the rotation.

3 Likes

Totally forgot to ask, but do you have a playground which reproduces the memory access issue? The plugin should ideally handle errors more gracefully than that, so I’d like to get that bug fixed.

1 Like

Hey @eoin, did you try the playground futher up the thread, that does reproduce the issue.

1 Like

Oh, sorry, I missed that. That’s brilliant, thank you!

2 Likes