LightUSD reads and writes USD without the USD SDK

A USD library without the SDK dependency tree

LightUSD is a full-featured, dependency-free, lightweight USD library written in C++17. It reads and writes USDA, USDC, and USDZ, and it includes MaterialX and USD Physics support. The project was previously known as TinyUSDz, which is a useful clue about the intent: the point was to have a USD implementation small enough to embed.

The positioning in the README is specific about the audience. LightUSD is designed for applications that need USD to be compact, portable, and fast: high-performance 3D interchange and DCC tools, render and asset pipelines, generative AI, and Physical AI systems that connect scene understanding with simulation and robotics.

That list explains the two design decisions that matter. The same core runs across desktop, mobile, WebAssembly, and sandboxed environments, and there are explicit resource limits for untrusted assets. A library used to load a scene into a robot or a browser has to survive input it did not produce, and the word dependency-free is doing real work in that sentence.

The repository topics are ar, dependency-free, universal-scene-description, usd, usdc and usdz. The homepage is lighttransport.github.io/LightUSD, and the package is published on PyPI as lightusd and on npm as lightusd.

The author is Syoyo Fujita, and Light Transport Entertainment, Inc. is listed alongside him in the Python package metadata.

The Python package and its zero-copy promise

The Python binding is the fastest way to try the library, and it installs like any other package.

python -m pip install lightusd

The usage is short enough to read as an example of the API shape:

import lightusd

stage = lightusd.load("scene.usdz")
for prim in lightusd.traverse(stage):
    print(prim.type_name, prim.name)

Loading a stage and traversing it are the two operations, and the traversal exposes type_name and name per prim. The WebAssembly and JavaScript packages live under the web directory, and the Python usage notes are in python/README.md.

The package description is where the engineering claim becomes specific: a lightweight, dependency-free USD/USDA/USDC/USDZ loader plus Tydra render-scene access, with NumPy-friendly zero-copy arrays, on CPython abi3 plus free-threaded wheels.

Zero-copy is the part to pay attention to. If the arrays handed to NumPy are views into the loaded buffers rather than copies, a pipeline that processes a large scene does not pay to duplicate the geometry in memory, and the memory limit becomes the real bound on what you can load. If they are copies, the same pipeline quietly doubles its footprint.

The build driver in setup.py explains how the wheels are produced, and the interesting detail is the two flavours from one source. The regular CPython build is a stable-ABI extension with Py_LIMITED_API=0x030A0000, tagged cp310-abi3 and covering CPython 3.10 and later. On free-threaded CPython the limited API is unavailable, so a version-specific extension is built instead, and the module declares Py_mod_gil=Py_MOD_GIL_NOT_USED.

Building the C++ core with CMake and Ninja

The core is C++17 and the build normally uses CMake, and the README gives a full configure, build and test cycle.

cmake -S . -B build_ninja -G Ninja \
  -DLIGHTUSD_BUILD_TESTS=ON -DLIGHTUSD_BUILD_EXAMPLES=ON
cmake --build build_ninja
ctest --test-dir build_ninja --output-on-failure

The two options turn on the test suite and the examples. The test invocation goes through ctest with output on failure, so a failing test prints its output rather than just its name.

The repository layout explains the scope better than a feature list would. There is a src directory, a schema directory, a tests directory, a benchmark directory and a separate benchmarks directory, an examples directory with around two dozen named examples, and a doc directory with a per-topic documentation set. The examples cover the API tutorial, asset resolution, the C API, file formats, a large scene load, a command line tool named lusdcat, a quick look viewer, an MCP server, progressive composition, URDF to USD, USD texture compilation, USD to glTF, USDA and USDC parsing, and variant analysis and listing.

That list is a reasonable proxy for the library's coverage. Support for reading a URDF, converting to glTF and exposing an MCP server are the three entries that go beyond round tripping USD, and they are the ones that say something about the intended users.

A .clusterfuzzlite directory is present, and there is a sandbox directory. Both belong to the same theme as the security notes further down.

Resource limits and the untrusted asset question

The Security section is three sentences and it is the part of the README that distinguishes this library from a general purpose USD reader.

Use USDLoadOptions::max_memory_limit_in_mb for unknown inputs. For hostile or internet-sourced assets, also isolate loading in a sandboxed process or WASI environment.

Two separate defences, and the second one is the more honest. A memory limit caps what a single malformed file can do to your process, but it does not protect against a parser bug that is not about memory, so the README's advice is to run the load somewhere it cannot hurt you. A sandbox directory in the repository, a WASI environment and the WebAssembly build are all the same idea applied at different levels.

For a robotics or simulation pipeline that reads USD from a marketplace, a web upload or a model zoo, this is the difference between a library you can accept untrusted input with and one you cannot. The MAX memory limit is an option on the load options object, so it is set per call rather than being a global process setting.

The MCP server in the examples directory is worth noting in the same context. An MCP interface is a way for a model or an agent to call into your tooling, and the fact that the project provides one alongside its sandboxing story suggests the authors are thinking about the two together.

MaterialX, USD Physics and the documentation set

Two of the README's most significant claims are the extra format support, and each has its own document.

The feature line says the library reads and writes USDA, USDC and USDZ, and includes MaterialX and USD Physics support. MaterialX is the shading description format that USD embeds for material networks, and the doc directory carries a dedicated doc/materialx.md. USD Physics is a separate specification built on top of USD for physics scene description, and it has doc/usd-physics.md.

The documentation index lists the topics one by one, and the list is more useful than it looks: a documentation index at doc/README.md, an API and schema status document at doc/api-status.md, then MaterialX, USD Physics, composition at doc/composition.md, Python bindings at doc/python_binding.md, testing for the C++ side at doc/testing-cpp.md, and release and CI at doc/ci.md. There is also doc/build-and-examples.md for integration, build options and examples.

The API and schema status document is the one to read first if you are evaluating this. A USD implementation that reads and writes the three main file formats can still be missing schema coverage, and a document whose name is API and schema status is the place that would say so. The composition document matters for a different reason: composition is the layer where a USD scene is assembled from layers, references and payloads, and it is where a partial implementation shows up first.

The composition and progressive composition examples in the repository, plus a variant-analyzer and a variant-lister, suggest composition is being worked on rather than deferred.

Release state, licensing and the 1.0 boundary

Two things to check before you depend on this: the release state and the licence.

On releases, the README has a Releases section that lists v1.0.0 RC (main) with the note that it will be 26.09 or 26.10, and the GitHub tags show v0.9.1 from 2025-11-04, v0.9.0 from 2025-06-27 and v0.8.0rc8 from 2024-07-08. The last push was on 2026-10-19, so the work is current, but the version you can count on is still below 1.0 and the 1.0 release candidate had not shipped under the version numbers listed.

Note the tension with the Python metadata, which classifies the package as Development Status :: 5 - Production/Stable. The library may be stable in the sense that it works, while the versioning says the interface is not yet frozen. For a C++ library that other code links against, that distinction matters.

On licensing, LightUSD is primarily licensed under Apache 2.0. Some helper code uses MIT or similarly permissive licenses. See LICENSE.3rdparty for third-party notices. The GitHub licence field shows as a custom licence that GitHub cannot classify, which is why the LICENSE and LICENSE.3rdparty files are the authoritative statement. Apache 2.0 for the main body is about as practical as it gets for a library you intend to vendor into a commercial product.

The project also carries AGENTS.md and CLAUDE.md at the top level, which is the convention for instructions aimed at coding agents working in the repository, alongside a .serena directory.

Editorial conclusion

LightUSD suits a team that needs to read and write USD in a C++ codebase without pulling in the USD SDK and its dependency tree, particularly for asset pipelines, generative AI tooling and simulation or robotics work, since the same core runs on desktop, mobile and WebAssembly. It is the wrong tool if you need the full USD feature set today, because the API and schema status is tracked in a document of that name and the library is still pre 1.0, and the wrong tool if you want the Apple USD Python bindings you already know. Before adopting it, read doc/api-status.md to see which parts of the schema are covered, and set USDLoadOptions::max_memory_limit_in_mb before loading any file you did not create.

Frequently asked questions

Official sources

1. Issues
2. lighttransport/LightUSD on GitHub
3. Project website
4. README
5. Releases