Make the WASM location configurable

[agviegas]

So far we have been working on the assumption that the WASM file is in the root directory of the project. However, this may not always be the case, and it would be interesting if the user could define where their WASM file is. I've had to set this up by hand for the Three.js IFC Loader, and I think it would be interesting to incorporate it into web-ifc.

The path to the WASM file resides in the wasmBinaryFile variable generated by Emscripten.

The solution provided for Three.js was to add a global variable containing the relative path of the WASM that could be set through a function of the API. Something like:

var WasmPath = "";

//...

var wasmBinaryFile = WasmPath + "web-ifc.wasm";

//...

var IfcAPI = class {
   //...
   SetWasmPath(path){
     WasmPath = path;
   }
};

export {
  IfcAPI,
  ms
};

This setter function will be also present in web-ifc-three. This way, we will be able to use the Loader like this:

   const IfcLoader = new IfcLoader();
   ifcLoader.SetWasmPath("./whatever/path/");
   ifcLoader.load();

A minimal example of how this looks can be found here.

I suppose that the SetWasmPath can be added to web-ifc-api.ts. As for the global variable and the wasmBinaryFile initialization, we can probably write a JS file with a script to add these two lines to the bundled file.

[xeolabs]

I wonder if there is a way to actually bundle/encapsulate web-ifc.wasm inside web-ifc-api.js and web-ifc-api-node.js?

[agviegas]

I wish there was a way, it would be definitely cleaner 🤔 But as far as I know, the WASM file is not interpreted the same way as JS (they are precompiled), so I suspect that for that we need to do a couple of reverse-engineering hacks (e. g. generate the WASM file in runtime). Would this runtime-generation be worth for eliminating the wasm file? Honestly, I have no idea.

[vegarringdal]

have a look at this:

https://github.com/mrdoob/three.js/blob/dev/examples/jsm/libs/meshopt_decoder.module.js#L8-L15

isnt the wasm code here ?

[agviegas]

Hum, might be. Feel free to dig into this, could be nice if it removes the WASM file handling!

[tomvandig]

Would vote against this, the WASM file as a standalone web resource enables browsers to cache the compiled code, reducing subsequent startup times by skipping compilation. More info here: https://v8.dev/blog/wasm-code-caching

I am by no means a chrome expert, but I expect this caching to break if we somehow bundle the wasm inside the js resource, they specifically mention:

Cached compiled code is associated with the URL of the .wasm resource, which makes it easy to look up without having to scan the actual resource. This means that changing the URL of a resource (including any query parameters!) creates a new entry in our resource cache, which also requires a complete recompile and creates a new code cache entry.

Could be this info is out of date though, no idea.