Tools: make C/Wasm library for data processing (compression, clusterization etc.)

[aras-p]

Currently all of data encoding, SH clusterization, quantization code is in C#/Burst within Unity. That's fine for "within Unity" use cases, but e.g. if #45 is done then it would be easier for "web" use case to have all that code usable outside of Unity. Like a native code library, possibly compiled to WebAssembly too.

[andybak]

I might be misunderstanding but how would that work for "running inside Unity" use-cases?

I've generally found C dependencies a pain for anything cross-platform (x86 Windows, x86, Mac, ARM Mac, ARM Android, whatever Unity on Linux supports)

WASM is plausible but there's not a mature, free (beer or speech) WASM host for Unity that I'm aware of.

https://github.com/extism/extism looks pretty close but nobody has a non-trivial Unity demo working yet.

[andybak]

Also - is WASM multithreaded? If you're giving up on multithreading, is there any guarantee it won't have a performance penalty on all other platforms compared to Burst/Jobs code? I might be misinformed here so please correct me if so.

[aras-p]

@andybak oh no, I'm definitely not thinking of using Wasm library in Unity itself, somehow. What I'm thinking is:

1. Make a C/C++ library that does all the data processing. That is normally compiled into native code dynamic lib. Native code use cases use this one.
2. It also happens to be compiled into WebAssembly, as just another "platform". Web use cases use that one.

Now, whether this would replace the data processing part that's currently in Unity C#/Burst, or be in addition to that, is still up in the air. A good thing is that said data processing is Editor-only code right now, which drastically cuts down on number of platforms the 1. above would need to be compiled four (just windows, mac, linux).

And if wasm can't be multithreaded (I think it can these days though?), then that's just wasm specific side; any other platforms can still be multithreaded.

[andybak]

I guess my only other concern is that this means runtime conversion of splats is permanently off the table. I was a little dismayed to see functionality being moved to the editor namespace as I've always been interested in the full pipeline being possible at runtime.

However - I've got no concrete plans at the moment, no idea how feasible this is realistically and I guess I can always maintain my own fork!

[aras-p]

Nothing is permanently off the table, I just moved it to editor assembly since I did not have a clear idea for runtime use case. Everything can be moved anywhere, at any point.

That said, even before the editor namespace move, the code as-is would not have worked at runtime since it uses Editor-only API to compress the texture at low quality levels. So if runtime would be needed, code to do that would need to materialize at runtime too.