DracoUnity: Build fails for WebGL on Unity 2022.2 (new Emscripten)

Hi folks,

TL;DR: I can give you an immediate workaround right now and we’re working on a convenient long-term solution.

Problem

Native Draco libraries are compiled into WebAssembly via Emscripten. Different versions of Unity use different versions of Emscripten. Not all of them are compatible, so one has to compile the libs with the exact version Unity uses. The lack of Unity version settings on native libraries makes it impossible to provide one package that works across a large range of Unity versions.

What I did so far

In the past I just bumped the major release number, so we ended up with:

• DracoUnity 3.x, which works for Unity (2019-) 2020
• DracoUnity 4.x, which works for Unity 2021

I could make 5.x support 2022 and 6.x the upcoming 2023.2, but that has downsides:

• Supporting 4 releases in parallel is much more work
• Breaks the concept of semantic versioning. Imagine there’s a new API breaking feature. How do you bump versions now?

Solution

As said, unfortunately Unity does not offer a solution here. What we’ll do is split the WebAssembly binaries into sub-packages. One for each Emscripten version. The main package will contain code, that automatically configures your project, so that you’ll end up with a working built with one click.

This is in the making, but releasing a package properly involves some work and multiple parties. Your patience is appreciated.

Workaround for Unity 2022 and newer

1. Download a copy of the most recent DracoUnity 4.1.0 and unzip it.
2. Download the Draco binaries 1.1.0 I’ve built via GitHub Actions and unzip it.
3. Copy the library files in WebGL/2022/*.a over into the package subfolder Runtime/Plugins/WebGL
4. Open your project with Unity 2022 or newer and install DracoUnity from the local copy you just altered
5. Try to make a WebGL build

Again, sorry for the delay and thanks for your patience.

https://github.com/atteneder/draco/releases/ You can install the latest version which is 2.0.0

@der-hugo I thought about this as well, but we’ve opted for another solution that puts WebGL binaries in a sub-package.

@omidhedayati Most of the times this is related to incorrect use of GIT LFS and thus incorrect binaries. Check if the binary files are actually correct (in size and content).

@RyuuyaS Technically this is done, but formal and legal issues need to be resolved before we release the fixed version. I’m not promises, but I expect it to take 1-2 months.

@atteneder Thanks for the workaround,it works on webgl builds now but after using this solution i face this error on editor,it was ok before workaround. version: 2022.3.4f1

After installing git’s Draco in the package manager, copy the Runtime/Plugins/x86_64 folder, delete the x86_64 folder of Draco in the local copy, and replace it Sorry, maybe my english is strange.

@atteneder Can confirm your solution works.

The issues I encountered were not caused by DracoUnity, but just manifested there. I was finally able to pin down a threading issue that we reported to Unity.

Great! Good to hear you are working on it, and the temporary fix works for us; we can now build (using 2022.2.21), and the glb’s load up nicely.

@PTC-sradlwimmer Did you try increasing the Initial Memory Size in ‘Player / Publishing Settings’? If it is a large GLTF you are loading it might be due to the heap memory that is unable to expand (on time). We use gltFast and also removed a lot of properties from the shadergraphs used by our dataset models. All the different options in the gltf shaders causes a lot of shader variants to be compiled, and they take up a lot of memory in the webgl build.

Hi Stefan,

Thanks for reporting!

Indeed emscripten seems to have upgraded from 2.0.19 to 3.1.8-git. I’ll try an updated build and if that fixes the problem, I’m going to have to make a new major release with updated binaries.