kmammou/v-hacd

JavaScript/WebAssembly API support

Glavin001 opened this issue · 12 comments

Glavin001 commented

Would this be something you're interested in maintaining to enable support for websites?

Update: I've actually built a working proof of concept using V-HACD v4.0 and Emscripten which performs great for Node.js/server-side and in web browsers (e.g. raw JavaScript, React, Next.js)! Let me know if this is something I should prepare a Pull Request for or if I should maintain it separately 😃 .

Thank you so much for building this incredible library! 🎉 🚀

Glavin001 commented

Is there a way to compile this without using pthreads? It's been many years (school) since I've used worked with C/C++ so compiling this and using https://emscripten.org/ has been an interesting journey recently 😂 .
Why? When using pthreads it requires a browser feature SharedArrayBuffer which is only supported on certain web-browsers. I'd like to have 2 versions: 1) using pthreads and requiring most modern browsers and 2) without pthreads for better support for all browsers.

jratcliff63367 commented

Because this library uses standard c++ 11 threads, I believe on Linux, it requires pthreads in the linker line. I do not personally know of any way around that; other than getting rid of all multi-threading from the code and that would be a bad idea. Maybe someone else who's a better Linux person than I am has an idea. Regarding a pull request. Yeah I'm open to pull requests. I wouldn't have any way to test it or anything, but if you want to offer it and it doesn't affect the build significantly, I'm okay with that.

Glavin001 commented

getting rid of all multi-threading from the code and that would be a bad idea

Would it work if I added a #ifndef block around code related to CreateVHACD_ASYNC and left only CreateVHACD for the synchronous (blocking) implementation of V-HACD?
Something like:

#define DISABLE_ASYNC_VHACD_IMPLEMENTATION 1

Around the following sections:

Performance would take a hit, as is shown in the v4 overview video at 5:20 with -a false, however, it would at least be usable in all browsers without the pthreads/SharedArrayBuffer dependency. Encourage using the pthread version while having a fallback version for more compatibility.

@jratcliff63367 : Any other issues I'm not thinking of?

I'll experiment a bit more this week and get back to you with a Pull Request. It may make sense to keep as a lightweight separate repository with this repo as a submodule, so the JavaScript consumers can make issues there without cluttering this repo.

📣 For anyone else interested in contributing to make V-HACD v4 run on the web, please let me know in this issue. 🎉

jratcliff63367 commented

I could make a version that is single threaded only with a #define. It would be a bit of an ugly hack, but it's doable. I'm still confused why you can't just add pthreads to your linker line. I mean std::thread is pretty standard at this point isn't it?

Glavin001 commented

I'm still confused why you can't just add pthreads to your linker line

pthreads works 💯%, however, Emscripten adds a dependency on SharedArrayBuffer browser feature to implement pthreads. Unfortunately, SharedArrayBuffer is not supported on all browsers and those which do support it require a special server configuration with custom headers for security reasons (see 1, 2, 3). Furthermore, online web app editors like CodeSandbox, which are extremely useful for providing demos for documentation and examples of reproduced bugs, would not support these custom headers making it impossible for a large audience of JavaScript/web developers to use this library.

tl;dr: My goal is to recommend the full pthreads version, which uses SharedArrayBuffer, and for those who cannot satisfy the browser/headers constraints they have a workaround, until browser support becomes easier.

I could make a version that is single threaded only with a #define. It would be a bit of an ugly hack, but it's doable.

If you're interested in creating this version it would be really helpful! Thanks to my lack of C++ & Emscripten knowledge, it already took me about a week (weekends + after work) to get this proof of concept working 😂 . If you don't have time, I'd be happy to try creating a pthreads version myself, which hopefully doesn't take me as long.

My concern was it would become an ugly hack so wanted to align with you first and determine best practice for achieving this.

Thank you!

Edit: I also plan to put both versions of library in a WebWorker so it does not block the main thread (even in -a false mode) and implement it by hand without SharedArrayBuffer, instead of how Emscripten automatically uses SharedArrayBuffer.

jratcliff63367 commented

I'm out of town until this Friday, so that is the soonest I can make this change.

  • 👍1
jratcliff63367 commented

Ok, I have made this change.

Just get the latest from master. Before you include 'VHACD.h' add this to your code:

#define VHACD_DISABLE_THREADING 1

If you do this, then all threading code will be compiled away and you will no longer get a linker dependency on pthreads.

I tested that this works.

Instead of calling:

'VHACD::IVHACD *iface = VHACD::CreateVHACD_ASYNC();'

you will call:

VHACD::IVHACD *iface = VHACD::CreateVHACD();

  • 🎉1
  • ❤️1
  • 🚀1
Glavin001 commented

Wow, thank you very much! Will try out tonight.

Glavin001 commented

✅ Confirmed, with VHACD_DISABLE_THREADING enabled I'm able to build a version without SharedArrayBuffer dependency, such that it is compatible with online code editors (e.g. https://codesandbox.io) and without changing server response headers 🎉

Thanks again!

Still more work to do before I'll have a polished JavaScript wrapper library ready. For people interested in a sneak peak see these:

  • 🎉1
  • ❤️1
pmconne commented

@Glavin001 are you still working on your wrapper library?

@jratcliff63367 @kmammou I am putting together a simple JavaScript API that uses V-HACD compiled to WebAssembly. I intend to publish it as an npm package shortly. Do you have any objections, concerns, or requests about that?

Glavin001 commented

@pmconne : Yes I am, although these past months have been 🔥 at work and my other commitments so I haven't finished the version I've been working on yet 👎.
Your wrapper looks great! 🎉

pmconne commented

I've published the npm package.

  • 🎉1
  • 🚀2