Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Goal

Itemize list of low-hanging fruits, tasks and operations to lower the cost of maintaining the USD WebAssembly prototype, and to eventually merge back components into the main USD branch.

Intent:

  • Prevent WebAssembly prototype from lagging too far behind most recent USD version
  • Automate builds, publishing to NPM, Wasmer or other repositories to facilitate integrations and adoption by other parties.
  • Facilitate contributions and collaboration with other parties not necessarily intricately familiar with USD (web community, ThreeJS, etc.)

Itemized list

Items in this list are ordered by ascending order of priority for the WebAssembly project (i.e. from "mandatory" to "optional").

Prerequisite work

Target a recent, stable version of the USD main branch. At the time of writing, USD 22.11 is the latest known public stable version.

High-level prioritized item list

0. Legal requirements

Clarify ASWF vs. USD contribution guidelines regarding attributions.

1. Build system changes

  1. Add Dockerfile to standardize Emscripten build (using an Ubunutu 22.04 LTS base image)
    • Using known good Emscripten version (2.0.24)
  2. Update build_usd.py build script to support:
    1. Adding an --emscripten build option to specify a WebAssembly target
    2. Using emcmake/emmake as a drop-in replacement for cmake when targeting WebAssembly build
    3. Replacing TBB with WasmTBB
    4. Listing USD components incompatible with WebAssembly build to warn Users that Python, usdview, imaging have been disabled
  3. Add CMakeLists.txt for JavaScript/WebAssembly bindings in order to:
    • List USD binding dependencies (usd, usdLux, usdGeom, usdUtils, sdf, tf)
    • Specify location of WebAssembly build artifacts (WASM bundle, WebWorker, JavaScript bindings)
  4. Include tests to validate WebAssembly build, using a NodeJS dependency in order to enable tests from headless environments. Test examples include (but are not limited to):
    1. Loading a USDA stage
    2. Exporting USDA stage to string
    3. Traversing the USDA stage
    4. Running WebWorkers
    5. etc.

2. Core USD changes

arch library

  • Add #if defined(__EMSCRIPTEN__) guards to integrate Emscripten as an alternative to Linux platform:
    • ArchDebuggerTrap(), ArchAbort(), ARCH_BITS_32
    • ArchStatIsWritable(), ArchGetModificationTime(), ArchGetAccessTime(), ArchGetStatusChangeTime(), ArchGetFileLength()
    • ArchLibraryOpen(), ArchLibraryError(), ArchLibraryClose(), ArchLibraryGetSymbolAddress()
    • ArchGetStartTickTime(), ArchGetStopTickTime()

tf library

  • Add type registration for USD symbols to be exposed to/from C++/JavaScript
    • Used to wrap TfToken, double, int, etc.
  • Add TfPointerAndBits to specify operations on 32-bit architectures (as USD only specifies 64-bit operations by default)

vt library

  • Add type registration for USD symbols to be exposed to/from C++/JavaScript
    • Add getJsObj to VtValue (similar to the existing getPyObj for Python)

sdf library

  • Add type registration for USD symbols to be exposed to/from C++/JavaScript
    • Used to wrap SdfPath objects

usd library

  • Add type registration for USD symbols to be exposed to/from C++/JavaScript
    • Used to wrap UsdPrim, UsdStage objects to expose CreateNew(), ExportToString() and other API bindings.

3. ThreeJS Hydra renderer

TBD: Separate project/branch? Engage with ThreeJS/web community for collaboration opportunity on this aspect?

  • No labels