Failed to initialize basis worker: Error: WebAssembly.Module doesnt parse at byte 4572: invalid opcode 192, in function at index 73

Help & Support
21

pinging @slimbuck in case he has some ideas here

1 Like
22

Maybe there is an example project with basis that works and I could test with that projects basis file? possibly.

As in use that basis file in my project.

Maybe I should check the memory for my project aswell incase that is causing it somehow?

23

Possibly some Wasm extension that Webkit added support for in the later versions, so the older ones are meeting an opcode that they can’t resolve. You could probably try an older version of Basis from their repo. Maybe v1.15 or something before Safari 14.1.

1 Like
24

good idea, will give that a go. The repo for playcanvas?

25

I was referring to Basis repo:

Maybe engine repo has some of those as well in the history, as @slimbuck updates it periodically.

1 Like
26

oh sorry yes that makes sense. I will have a look, thanks

27

@mvaligursky @LeXXik

So I switched to an older version of basis and that seems to resolve it for now (testing through browserstack). But I came across a new issue in which none of the assets using draco mesh compression seem to show. I wonder if there is a way to disable it in code depending on device? probably not as I think the mesh is compressed when its imported right? so the only way would be to disable draco and re-import all the assets? No errors it seems, they just dont show

Maybe the device is too old for draco mesh compression. Maybe I should make a new post for this though?

28

Each wasm module comes wiith a fallback JS implementation (that is slower, and intended for devices without wasm support). You could perhaps try and use those fallbacks on those devices.

I’m not entirely sure how we load those wasm’s currently, likely using this internal loader: engine/src/core/wasm-module.js at main · playcanvas/engine · GitHub

The loading would need to change to detect the device that has problems with wasm, and using the JS path instead.

@slimbuck - would you be able to add some details on this? Or this possible?

1 Like
29

This is tricky. The Basis worker can accommodate fallbackUrl, but Draco worker doesn’t.

1 Like
30

ah I see ok, so the draco worker does not load the fallback if needed?

31

yes correct.

1 Like
32

ok thanks. Do you think there is any workarounds if I still wanted to use draco or not?

33

I’m so sorry, but I can’t think of anything rn

1 Like
34

It would require a relatively big change to the engine, basically

1 Like
35

no worries! thanks for the help with this