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 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.
Good news! yes it does
Did you share your reproduction?
Please, see edit of first post for the time being.
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…
Still working on the repro I am bouncing between playground, project code and in-game testing.
@eoin I am using the wasm from https://cdn.babylonjs.com/havok/HavokPhysics.wasm last update from 9-Sep-2023. I could not find a version number so I uploaded a copy here: GitHub - Joe-Kerr/tempBabylonHavok
During the entire destruction process I only use PhysicsShapeType.BOX for level geometry and PhysicsShapeType.SPHERE for the projectile collider.
@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.
I still cannot reproduce the error in a playground: https://playground.babylonjs.com/#88CB6A#134
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