Cube WASM demo doesn't run

[GoJermangoGo]

I tried out this demo in Chrome and I can only see the floor plane.

Console log:

[shawn0326]

same to me

[GoJermangoGo]

It seems like it's actually an emscripten bug. Someone had an almost identical error while trying to compile OpenCV. (emscripten-core/emscripten#7562, see most recent comment)

I was able to get it working by compiling with emscripten 1.38.12. Any version after that either fails to compile or gives the above error in Chrome.
(I had to undo the DebugDrawer commit d144e11 to avoid emscripten-core/emscripten#7234, which hadn't been merged yet in the older version of emscripten)

[InfiniteLee]

I've spent the entire day trying to figure out what's happening here, but the only way I can get a working wasm build is if I do what @luisfonsivevo did with the exception that I was able to compile with 1.38.13.
Also I discovered that if you just comment out

[JSImplementation="btIDebugDraw"]
interface DebugDrawer {
...
}

you can avoid the error in the wasm build. This led me to believe that it was an issue with JSImplementation and wasm, but the same trick doesn't work for emscripten > 1.38.13 so not sure).

All my googling makes me think there is some memory related wasm configuration that is not correct for ammo.js, but I'm not sure.

Whatever it is, it seems like the wasm builds have just been broken for the past couple of months, starting around when the DebugDrawer stuff was added. However, even if I go to an ammo.js version prior to that and try to build with emscripten > 1.38.13, the wasm build has the same errors. This leads me to believe that something in 1.38.14 broke wasm for ammo.js. Any ideas @kripken?

[InfiniteLee]

Well I just had revelation: That specific example is using an ammo.wasm.wasm build that is a year old. If you copy the new ammo.wasm.wasm build from the builds directory over it, it works fine. That old one is just obviously not compatible with the new wasm builds that have been made in the past few months.

I think there's a separate issue where the .wasm file doesn't get loaded correctly depending on browser/how your web server is setup, which is probably why this example has it sitting right next to the example's html file.

[kripken]

I think there's a separate issue where the .wasm file doesn't get loaded correctly depending on browser/how your web server is setup, which is probably why this example has it sitting right next to the example's html file.

Might have been an issue with older emscripten versions. Perhaps now we can just make it point to the build dir and get the wasm and js there.

[GoJermangoGo]

Looks like the January 15 build did indeed fix it. Previously, the demo, the October 25 build, and anything I tried to build on my own web server were all giving the same error. I'm able to compile it now with emscripten 1.38.24. Just have to update the demo website now.

[InfiniteLee]

Might have been an issue with older emscripten versions. Perhaps now we can just make it point to the build dir and get the wasm and js there.

Sorry this should probably be in a new issue for emscripten, but I think the larger issue is that it is difficult to use wasm binaries with webpack right now unless you use some workarounds. E.g. this seems to work (taken from https://gist.github.com/surma/b2705b6cca29357ebea1c9e6e15684cc):

const OriginalAmmo = require("ammo.js/builds/ammo.wasm.js");
//uses webpack file loader to get the relative path of the wasm binary
const WasmBinaryPath = require("ammo.js/builds/ammo.wasm.wasm");
const Ammo = OriginalAmmo .bind(undefined, {
  locateFile(path) {
    if (path.endsWith(".wasm")) {
      return WasmBinaryPath ;
    }
    return path;
  }
});

This is not an issue for simple projects like the ammo examples which can use script tags, but for projects that try to use ammo as an npm dependency (or for that matter, a dependency of a dependency).

That said, I believe the long term solution is to have a real ES module target for Ammo.js, which would require updating emscripten, specifically preamble.js, such that webpack is responsible for creating the wasm module given the url to the wasm binary in an import statement like what is proposed here: webpack/webpack#7352 (comment)

When https://github.com/WebAssembly/esm-integration lands, the preamble.js will likely be able to go away and the wasm binary will be able to be imported via the same ESM syntax.

[kripken]

Emscripten does has ES6 module support, with EXPORT_ES6. It's not tested much yet, though, because it was waiting on VM support, but maybe that's present now? Worth experimenting if someone has time.

[kripken]

There is also .mjs suffix support which auto-enables that option, emscripten-core/emscripten#7876

[GoJermangoGo]

Works now