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));
};
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
@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.
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.
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
If you want to give it a try, please do. I can’t wait to review this PR!
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.
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 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.
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.
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.