The exception below is triggered when I blow up a wall with v2 physics. The exception started to occur after I added the new rigid-body-gltf-extension (glTF + Physics + Babylon) and loaded in a rigid body mesh (created in Blender).
Uncaught RuntimeError: memory access out of bounds
at HavokPhysics.wasm:0x2bb47
at HavokPhysics.wasm:0x2c403
at HavokPhysics.wasm:0x1f1b3
at HavokPhysics.wasm:0x12a461
at HavokPhysics.wasm:0x128ebf
at HavokPhysics.wasm:0x181c71
at HavokPhysics.wasm:0x1c697
at HavokPhysics.wasm:0x23c04
at Object.HP_World_Step (eval at new_ (HavokPhysics_umd.js:9:22462), <anonymous>:9:10)
at e.executeStep (Babylon.min.js:1:4167677)
$func447 @ HavokPhysics.wasm:0x2bb47
$func457 @ HavokPhysics.wasm:0x2c403
$func157 @ HavokPhysics.wasm:0x1f1b3
$func1811 @ HavokPhysics.wasm:0x12a461
$func1805 @ HavokPhysics.wasm:0x128ebf
$func1978 @ HavokPhysics.wasm:0x181c71
$HP_World_Step @ HavokPhysics.wasm:0x1c697
$func278 @ HavokPhysics.wasm:0x23c04
HP_World_Step @ VM2879:9
e.executeStep @ Babylon.min.js:1
e._step @ Babylon.min.js:1
xr._advancePhysicsEngineStep @ Babylon.min.js:1
t.animate @ Babylon.min.js:1
t.render @ Babylon.min.js:1
update @ TacticalGame.js:1001 <--render loop
I can reproduce the exception - but not very reliably! That means I go to the same tile, shoot at the ragdoll and in maybe 70% of trials the exception occurs. I cannot trigger the exception when not loading the ragdoll mesh; just gave it 10 more trials. Also there was no such exception in the weeks before.
Anyway, huge problem is if I disable a subsystem I do not know whether it was the disabling or whether the exception did just not occur So, to be fair, the exception may not be caused by the rigid-body-gltf-extension at all!
Unfortuntely, so far I failed to reproduce the exception in a playground. I guess I now have to assemble a playground bit by bit and hope for the exception to occur.
But maybe someone can make sense of the call stack above? Any hint would be very welcome.
What version of @babylonjs/havok are you using? That’ll help me get some extra info from your callstack.
Obviously, a repro would be great, but (making a guess) I wonder if the objects you’re exploding have PhysicsShapeType.MESH shape types? Your description of the scenario makes me think that in the plugin, we’re trying to allocate a lot of memory, which fast moving, complex meshes using continuous collision detection can do. It might be that we’re asking for more memory than the browser is willing to give us…
@eoin Upgraded to latest version. Same callstack (lines, addresses).
Some progress. Found a significant crash influencer. A gltf root node slipped through and ended up in the array of the cell fracture meshes. (The ones that get blown to pieces.)
Since I have filtered out the root node, no crashes during the automatic reproduction steps. That means under “normal” crash condition, I was able to reproduce the crash in about <2 game starts on average. I am at 10 game starts w/o crash. The reproduction steps are automated and the only source of variability, I think, should be the ragdoll which wiggles around a bit.
Unfortunately, if I then start shooting at other walls, the crash still occurs.
edit: After 30 trials, the automated crash script trigger the crash. After the crash there is no mesh of class ‘Mesh’ with empty geometry and set physicsBody. Oh dear