Weird issue with virtual character controller not hitting the ground in Firefox Emscripten
Closed this issue · 5 comments
Hi Jorrit,
This bug only happens in Emscripten (WASM), on Firefox, and not in Debug configuration :)
Basically the character is never supported by the ground, e.g. jolt_character->IsSupported() remains false, even after 'falling' for minutes.
Any ideas?
Unfortunately I don't think I can step through the Jolt code to see what's happening due to WASM usage.
My player physics code: https://github.com/glaretechnologies/substrata/blob/25d3df8e49c95ee31da7c3780a0c3517a779717c/gui_client/PlayerPhysics.cpp#L217
Hmmm, I can't repro this in Firefox 124.0 on Win 11 in the character_virtual test level by adding console.log("Is supported: " + character.IsSupported()); after the call to ExtendedUpdate:
Debugging WASM is very hard in my experience and especially if it only happens on a single browser and not in debug mode... The code is pretty simple, if you call CharacterVirtual::Update then it has to go through the code path that sets the ground state, and if there is any kind of contact (which you could check by calling GetActiveContacts() and checking that at least one has mHadCollision == true) then there's no way that the state could be InAir.
Ok I'll get in there and and some print statements and see what the problem is :)
Well, this one is being a bit of a heisenbug. While adding print statements, suddenly the problem fixed itself. Weird.
Before it fixed itself:
Some matrices were being computed incorrectly:
03:27:39.835 ConvexShape::sCollideConvexVsConvex gui_client.js:4427:8
03:27:39.835 inCenterOfMassTransform1 col 0: -1.0000002, 1.0000001, 1.0000001, 0 gui_client.js:4427:8
03:27:39.835 inCenterOfMassTransform1 col 1: 1.0000001, -1.0000002, 1.0000001, 0 gui_client.js:4427:8
03:27:39.836 inCenterOfMassTransform1 col 2: 1.0000001, 1.0000001, -1.0000002, 0 gui_client.js:4427:8
Maybe some SSE code was being miscompiled by firefox. Or possibly some uninitialised memory is being used.
The only possible suspect I can see is Vec3::sFixW, where JPH_USE_SSE is enabled and JPH_FLOATING_POINT_EXCEPTIONS_ENABLED is disabled, so the w coord is left as-is. Maybe the w coord is used somewhere?
More likely Firefox messing up though.
JPH_FLOATING_POINT_EXCEPTIONS_ENABLED is only ever set if you compile with MSVC (it doesn't work on other platforms because clang is much better at auto vectorization which causes float exceptions too):
Lines 497 to 501 in e8a99bf
Will close, can reopen if it comes up again. Is probably a WASM/emscripten bug anyway.