Add WebAssembly / Emscripten as new compilation target

[kaischroeder]

Description of Change(s)

This Draft PR adds support for compiling USD to WebAssembly/Emscripten, which allows us to run the library in a browser or in node.js. It comes with a JavaScript binding for the UsdStage.

The purpose of this PR is to gather early feedback from interested parties before making a real PR to the main USD repository. Please use Github's review functionality to share comments.

Known limitations:

• No asset-resolving across multiple files yet - textures and multiple usd files contained in a usdz file can be loaded.
• USD pre-allocates several hundred Megabytes on start-up - on web this is not always desired
• Javascript bindings have to be implemented manually - similar to how the Python bindings are being implemented. We have thought about auto-generating the bindings from the Python bindings but this seems to be difficult.
• No large scenes have been tested yet
• Compilation of the emscripten build has only been tested on Ubuntu (can be run via Docker on other platforms)

To try this out, install emscripten https://emscripten.org/docs/getting_started/downloads.html and build

python build_scripts/build_usd.py --build-variant=release  --emscripten ../USD_build

The build folder will contain a bin subfolder with a sample (test.html), which creates a USD Stage and prints its content to the console.

The SharedArrayBuffer feature that is used requires cross-origin isolation: https://web.dev/cross-origin-isolation-guide/

For debugging purposes you can run Chrome with a parameter to always enable SharedArrayBuffer so that you don't need to worry about this: --enable-features=SharedArrayBuffer
The better solution is of course to add the proper headers on the server.

Note: This build depends on a version of TBB (Threading Building Blocks) for WebAssembly. https://github.com/hpcwasm/wasmtbb - unfortunately, the corresponding Github project seems to be unmaintained. Luckily it mostly contains changes to build files, so hopefully this situation can be improved in the future. We have also fixed a small problem in this branch: https://github.com/sdunkel/wasmtbb/

In follow-up PRs to be published soon, we intend to open-source:

• More JavaScript bindings. How these can be completed and maintained going forward is an open question.
• Hydra-related code to implement JavaScript based RenderDelegates
• an experimental version of a THREE.js based RenderDelegate

We have already deployed a few samples using the above mentioned RenderDelegate:
https://autodesk-forks.github.io/USD/

Support for materials in this RenderDelegate is still minimal. Some of the examples use animations, which are directly handled by the USD runtime.

[meshula]

I tried a build under CentOS, using the command line noted in the instructions above, but got hung up right away:

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - no
CMake Error at /trees/nporcino/usd-wasm/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
  /trees/nporcino/usd-wasm/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  /trees/nporcino/usd-wasm/share/cmake-3.22/Modules/FindThreads.cmake:238 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  cmake/defaults/Packages.cmake:37 (find_package)
  CMakeLists.txt:23 (include)

I wonder if there's a little more set up required for emsc.

[kaischroeder]

I tried a build under CentOS, using the command line noted in the instructions above, but got hung up right away:
I wonder if there's a little more set up required for emsc.

Hm, good question. So far I have only tried compiling on Ubuntu - someone else successfully built it on Mac though. Maybe the Dockerfile contains something useful?

It looks like cmake cannot find pthread for some reason. Does a standard compile of USD work on this machine?

[mikelyndon]

Minor thing. I successfully build the docker container on my M1 Mac. But the package.json file binding path is "bindings/RelWithDebInfo/jsBindings." but the docker container path is "bindings/Release/jsBindings."

[mikelyndon]

Took some time this weekend to get this up and running with React-Three-Fiber. This is very exciting!
A couple of thoughts.

1. If the render delegate is specific to threejs, I'd love to see a USDLoader. Similar to the FBX and GLTF loaders. That's more cleanup than anything else.
2. I'm a little out of touch with the USD side of things, so not sure what's happening in the driver.Draw() function. Is this modifying the scene in anyway? Or is that all still happening through the render delegate?
3. It feels like the js bindings would create allow us greater control over the stage but also move us further away from some of the threejs functions for manipulating the scene. Does this double up on work?

[marklundin]

Just started following this PR. Fantastic work @kaischroeder + team really awesome to see this progress. A few thoughts/questions;

1. Has there been any more active work on this PR?
2. Would a URI resolver need to cross the JS/Wasm boundary so that asset loading would happen externally to the Wasm? If so could this be a bottleneck?
3. If the Memory64 proposal gets fully supported and implemented, will this mean some of the changes in this PR are no longer needed?

[kaischroeder]

Has there been any more active work on this PR?

yes, but I'll refer to the team working on this currently. :-)

Would a URI resolver need to cross the JS/Wasm b oundary so that asset loading would happen externally to the Wasm? If so could this be a bottleneck?

I don't think so. You can fetch assets directly from within WASM (https://emscripten.org/docs/api_reference/fetch.html)

If the Memory64 proposal gets fully supported and implemented, will this mean some of the changes in this PR are no longer needed?

Yes, then we would not need support for a 32bit architecture anymore, which this PR adds. But this can still take a while until all browsers and especially web views support this.