Creating USD files from JavaScript

I was interested in creating USD files (USDA initially, USDC a bonus) from a website. I was pointed at HdJavaScript and JavaScript API wrappers by kaischroeder · Pull Request #2 · autodesk-forks/USD · GitHub from the Omniverse forums, but I do not need to parse USD files, only create them.

I am not sure I want to go full WASM (although I am using three.js for loading and previewing GLB files in a browser). Basically I am exploring building tools to speed up scene assembly as a web app, then exporting to USD.

My default was going to be writing out lots of USDA strings (I don’t need arbitrary USD constructs), but I thought I would check to see if there are any projects around that would give me USDC as a bonus, or if anyone thought there were good reasons to go full blown USD APIs (via WASM I assume). But I am after a solution that works today (not in 6 months time).

An alternative is to create a library that can create output files, but not sure that is useful. Once you start down that path it feels like you may as well do the full USD API and be done with it.

(I noticed Looking for usda and usdc file format specifications from just yesterday, and yes, having a formal USDA grammar would be nice.)


Hi @alankent , welcome to the forum and thanks for a great topic

Unfortunately right now there’s nothing that can claim to be truly “to spec” other than USD as wasm since there’s no spec yet (as you of course noted)

Now, in the “I void all warranties of correctness” set of things you could do:

  1. TinyUSDZ is a smaller subset of usd that is geared towards reading/writing single files without any of the schema APIs. . It might be smaller and easier to get into wasm. However, again, no guarantees of being completely compliant though I believe syoyo does good testing.

  2. Three.js has a usda/usdz exporter since you’re already using it. It has several issues since it’s really just writing out strings but it would save you from adding any extra dependencies and might fit your needs.


Anyway, any non-OpenUSD solution is at your own risk of error introductions but those are the options I think you have if you can’t use the wasm build of OpenUSD.

Thanks @dhruvgovil for the quick response. I sat down and tried to write out my own USDA grammar - there are some interesting edge cases! (layer offsets use ‘;’ instead of ‘,’??)

But then realized my problem is much easier. I am just creating an AST for a USDA file out of JavaScript objects, then converting to text. I don’t have to check for correct syntax or semantics, just make it possible to serialize to text. So far that is looking like a few hundred lines of JavaScript, less if I skip variant sets for now. (I am not using USD as my internal data model.)

I recommend that if you are going down that path, to routinely test your output files with usdchecker that is part of the usd distribution, just to test for validity.

1 Like