OpenUSD Physics Plugins

Backend-neutral physics runtime components for OpenUSD-based applications.

Status (2026-09-27): core/backend extraction complete; Box USD foundation in progress. The repository builds and installs physicsCore and physicsJolt; the neutral core contract and a Jolt-backed world with fixed stepping, changed state, segment queries, and ground queries are implemented. The Jolt-required OpenStrata intent passes locally and in hosted CI. An optional physicsUsd package now reads standard Box declarations; wider bridge support and artifact rollout remain. The capability matrix is the only page that states what exists, and the current roadmap states what comes next.

The repository is intended to extract the reusable physics boundary proven in usd-stage-runner, then validate it with usd-mmd-plugins and usd-vrm-plugins.

The central rule

The optional Box adapter builds with -DUSDPHYSICS_BUILD_USD=ON and an OpenUSD 26.08 install on CMAKE_PREFIX_PATH. It installs physicsUsd::physicsUsd and usd_physics/usd/box_scene.h. The core/backend-only root build remains the default. See the bounded Box contract for supported declarations and explicit rejection behavior.

ost build --intent usd-jolt and ost test --intent usd-jolt validate the reader and Jolt together, including the clean-prefix USD consumer. Source CI uses that intent on Windows and Linux and retains isolated library archives for physicsCore, physicsJolt, and physicsUsd. Public USD artifact pins and hosted evidence for this new gate remain pending; see the local artifact report.

OpenUSD describes the physical world; usd-physics-plugins makes that world executable without exposing a backend SDK to its consumers.

source-format semantics
        |
        v
standard UsdPhysics or solver-neutral descriptors
        |
        v
usd-physics-plugins
        |
        v
replaceable solver backend

The initial rigid-body path is:

UsdPhysics stage -> physicsUsd -> physicsCore -> physicsJolt -> body states

Secondary skeletal motion is related but distinct:

format-owned semantics -> generic spring-chain descriptors
                       -> secondaryMotion -> solver implementation

MMD, VRM, gameplay, camera, character, and vehicle policy remain in their owning repositories. Backend-native identifiers and types remain private to their backend.

Planned components

Component	Kind	Role	State
physicsCore	plain C++ library	Handles, descriptors, world lifecycle, state, and optional query contracts; no OpenUSD and no backend SDK	Phase 1 contract implemented and installed
physicsJolt	plain C++ library	First rigid-body backend implementing physicsCore	Phase 2 implementation present; hosted evidence pending
physicsUsd	OpenUSD-facing C++ library	Translate standard UsdPhysics declarations to runtime descriptors and maintain transient prim/resource mappings	planned
secondaryMotion	plain C++ library	Solver-neutral spring-chain and collider contracts	deferred until the rigid-body boundary is extracted
secondaryMotionVerlet	plain C++ library	First deterministic CPU secondary-motion solver	deferred until a real VRM integration slice requires it
physicsSchema	OpenUSD schema bundle	Semantic extensions that pass the schema admission test	not admitted

Component identities, directories, and allowed dependency edges are owned by the workspace contract. Planned names do not mean empty targets should be created ahead of their phase.

Scope boundaries

This repository owns reusable simulation mechanics:

• shapes, bodies, constraints, forces, velocities, and changed-body state;
• optional collision, ground, ray, segment, and shape-cast capabilities;
• standard UsdPhysics interpretation and transient runtime mappings;
• backend adapters, beginning with Jolt;
• generic secondary-motion contracts when validated by a real consumer.

It does not own source-format parsing, MMD or VRM semantics, application update loops, player input, character policy, camera behavior, rendering, or editor UI. See the design policy for the full boundary.

Documentation

docs/design/	Intended behavior and rationale; start with DESIGN_POLICY.md
docs/architecture/	Binding component identities, dependency directions, external dependencies, and package surfaces
docs/reference/	Facts about the current tree; start with CAPABILITY_MATRIX.md
docs/roadmap/	Incomplete work and phase status
docs/contributing/	How these documents are maintained

Build and usage guides will be added only when commands can be run against an implementation. Release records and dated reports will likewise be created only when a release or real evidence exists.