Add Newton Importer Support for USD Deformable Physics Schemas

[jcarius-nv]

Problem and Motivation

Newton needs a concrete USD schema path for deformable assets. Users should be able to author deformable objects in USD and load them into Newton without relying on ad hoc asset conventions or solver-specific side channels.

USD is the common interchange format for Newton assets, so deformable bodies should follow the same pattern as rigid bodies: shared schema data should describe the asset, and solver-specific data should be layered on only where needed. This avoids fragmenting deformable content across incompatible formats and gives asset authors a stable target.

The deformable physics schema work is still evolving, but Newton can start by importing the current shared/base schema subset and tracking schema changes as they settle. The importer should avoid creating a Newton-specific fork of the base schema unless a true incompatible requirement appears.

Proposal

Implement Newton importer support for USD deformable physics schemas, starting with the shared/base deformable schema subset. The importer should focus on consuming the shared schema cleanly and should not decide any Newton-specific schema extensions as part of this work.

The implementation should:

• Parse the base deformable schema first, not solver-specific extensions.
• Support compatible namespaced variants where they map cleanly to the base schema.
• Avoid creating a Newton-specific replacement for shared schema concepts.
• Keep the implementation flexible enough that separately defined Newton-specific schemas or attributes can be added later if needed.
• Clearly document the supported schema version/source and supported subset.

Proposed Shape

• Add a Newton USD importer path for deformable bodies/assets.
• Support a minimal initial subset needed to construct Newton deformable model data.
• Include namespace handling for compatible schema variants.
• Warn or fail clearly for unsupported fields or schema features that Newton cannot consume yet.
• Add parser tests and one or more small USD fixtures that exercise the supported subset.
• Update importer documentation as the canonical public schema proposal evolves.

Acceptance Criteria

• Newton can load at least one USD deformable asset authored against the supported schema subset into Newton model data.
• The importer handles the agreed initial namespace compatibility path for equivalent base-schema content.
• Unsupported or non-equivalent fields produce clear warnings or errors.
• Parser tests cover the supported subset and namespace mapping behavior.
• Documentation states the supported schema subset, the schema source/version, and what users should author against.

Scope

In scope:

• Newton-side parsing/import of USD deformable physics schema data.
• Compatibility parsing for equivalent namespaced schema variants.
• Minimal USD fixtures and importer tests.
• Documentation of supported subset, namespace handling, and schema reference.

Out of scope:

• Publishing or standardizing the schema proposal itself.
• Designing a Newton-incompatible replacement schema.
• Designing Newton-specific deformable schemas or attributes.
• Full authoring/export support.
• Solver-specific extension support beyond safe compatibility parsing.
• Other schema families or solver features beyond what is needed to parse the
  initial deformable assets

[mzamoramora-nvidia]

Linking #3037, #3036, and #3038 as relevant requests with useful desired interfaces.

[andrewkaufman]

I'd propose we parse the AOUSD UsdPhysics Deformables proposal as written (it's about to be posted publicly), which covers all three body types:

• Volume → TetMesh + PhysicsVolumeDeformableSimAPI + PhysicsVolumeDeformableMaterialAPI
• Surface (cloth) → Mesh + PhysicsSurfaceDeformableSimAPI + PhysicsSurfaceDeformableMaterialAPI
• Curve (rod/cable) → linear BasisCurves + PhysicsCurvesDeformableSimAPI + PhysicsCurvesDeformableMaterialAPI

That gives us a public target (instead of an interim newton: namespace), and the namespace-compat path for existing assets (eg omniphysics:*) can hopefully be handled by the SchemaResolvers, like we do for rigids.

Mass distribution precedence (per-point masses → body mass → body density → material density, with the per-element volume formulas) is one of the most error-prone parts; worth dedicated fixtures.

One thing to flag for scope clarity: we know a rod/cable extension is coming. Per the discussion on newton-usd-schemas#70 we're hopeful it can extend PhysicsCurvesDeformable{Sim,Material}API with NewtonCurvesDeformable{Sim,Material}API for the genuinely-Newton-specific bits (e.g. damping, articulation wrapping). I'd keep that extension out of this issue's deliverable, but just calling it out so the base parser is designed to accommodate it.

[devshahofficial]

Hey @mzamoramora-nvidia, can I work on a first slice here?

I’d keep it narrow: one minimal USD deformable fixture, parser support for the base schema fields, and clear warnings for unsupported pieces.