EXT_meshopt_compression location (ES6)

Questions
1

Hello, and I have been using the EXT_meshopt_compression extension via gltfpack to create compressed glb files. These files load without error into the playground, but the extension is not enabled by default in the gltf loader. I would like to load the extension (using LoadExtensionAsync), but have not been able to locate it within node.

Is this an issue of the extension silently falling back to another loader in the playground? Or how can I import and load the extension in Babylon 4.2?

Thanks for any help you might lend,
Robert

2

Pardon me if this partially answers my own question, as it looks like I need to switch branches to an alpha release which includes the extension (sometime after the cleanup done on Nov 24 (link.

Is there a preferred (stable) version higher than 5.0.0-alpha.2?

Thanks,
Robert

3

Yes we have alpha.19 now :wink:

4

Hey @Deltakosh ,

I have updated to alpha.19 and am debugging the changes now.

(a meme)

r

1 Like
5

Can I ask for some clarification on what’s happening in the playground with the EXT_meshopt_compression extension? It does not show in the list of enabled instructions and creates a warning in validating the file, but loads correctly.

In my own code the extension is failing at the decode (decodeGltfBuffer) call randomly on firefox, and somewhat less in chrome. I get the impression that the extension is falling out of scope after loading and unloading scenes containing gltfs, as it reports the following error on fail:

(console)
Uncaught (in promise) TypeError: instance is undefined
decodeGltfBuffer https://preview.babylonjs.com/meshopt_decoder.js:108

(meshopt_decoder.js:108)
var promise =
WebAssembly.instantiate(unpack(wasm), {})
.then(function(result) {
instance = result.instance;
instance.exports.__wasm_call_ctors();
});

Do I need to handle reloading extensions if I am going to create and dispose of scenes which use them?

Thanks,
Robert

7

This should work, a repro would be really helpful adding @bghgary in case he has a better idea ?

8

Hey, and thanks for taking a look at this. I spent some time debugging last night and have a case which shows the problem I am having. Please hit play a few times to see the different number of objects which get loaded.

https://playground.babylonjs.com/#ZDCHQE#1

I downloaded the Playground code base, and tried to emulate the workflow of copying the meshopt_decoder.js file locally (which allowed me to edit the file). The issue seems to be coming from loading multiple glb files asynchronously, although allowing the code to continue shows that some of the models will load correctly.

The promise being returned by meshopt_decoder always resolves, but the wasm instance seems to be missing in some calls. I am going to look at the call to ‘unpack(wasm)’ (line 34), to see if I can understand better where the failure is happening, but I am wading deep into unfamiliar territory and would appreciate any guidance.

Thanks again, and let me know if you see anything obviously wrong with the approach,
Robert

10

I can repro, but I have no idea what is wrong yet. :frowning:

11

I’ve fixed it in this PR: Fix race condition in EXT_meshopt_compression by bghgary · Pull Request #10274 · BabylonJS/Babylon.js (github.com)

1 Like
12

Thanks!

So… The decoder is a shared binary object which is being called by each of the gltf loader instances?

r

13

The decoder is a WebAssembly library. We don’t want to load it multiple times. That will cause issues.

14

Thanks. Is it advisable to copy the wasm files locally, as in Playground? I would like for my content to run offline, if that will ensure the availability of the libraries.

r

15

Yes, for running locally or for production scenarios, you should copy the wasm and change the configuration (EXT_meshopt_compression.DecoderPath) to point to the copied file.

1 Like
17

https://playground.babylonjs.com/#ZDCHQE#2 has updated urls for the example. There are not many meshopt examples around.

1 Like