Generated banner for Using Ovnewton
Generated logo for Using Ovnewton

Using Ovnewton

NVIDIAOfficialCreated by Jan CariusDistributed by NVIDIA

  • Skill
  • Tool integration
  • Automation and integrations
  • Apache-2.0
  • Medium risk

From the author

Connect the Newton physics engine to an Omniverse simulation or ovstage with ovnewton. Use when importing a populated ovstage into Newton, stepping its physics, synchronizing stage edits, or publishing simulation state for Omniverse rendering.
— the description by Jan Carius

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The ovnewton skill provides a bridge between the Newton physics engine and Omniverse stages. It enables developers to import populated stages into Newton, execute physics simulations, and synchronize state updates back to the stage for rendering or further processing. The tool manages the integration of physics solvers, collision handling, and simulation loops while maintaining consistency between the physics model and the USD-based stage representation.

What it does

  • Imports populated ovstage data into the Newton physics engine
  • Registers USD schemas for physics compatibility
  • Supports integration with MuJoCo and VBD solvers
  • Synchronizes simulation states back to the Omniverse stage
  • Manages physics simulation loops and state updates
  • Provides mechanisms for publishing simulation results for rendering

When to use it

  • When integrating Newton physics into an Omniverse-based application
  • When you need to run physics simulations on a populated USD stage
  • When synchronizing physics simulation outputs with Omniverse rendering
  • When managing complex physics state updates between a solver and a stage

Advantages

  • Enables direct physics simulation of USD-based scenes
  • Supports multiple solver types including MuJoCo and VBD
  • Provides structured workflows for state synchronization and publication
  • Allows for custom attribute registration within the simulation model

Usage examples

“How do I initialize a basic Newton simulation with an Omniverse stage?”
You install the package, call register_usd_schemas, populate your stage, and use the ModelBuilder to import the stage into Newton before finalizing the simulation.
“How can I synchronize my physics simulation state back to the stage?”
After each simulation step, you use the binding.update_to_ovstage method to publish the current state and seal it for the renderer.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/nvidia/using-ovnewton/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip using-ovnewton.zip -d .agents/skills

Documentation by Jan Carius

Using ovnewton

Use ovnewton for the Newton ↔ ovstage bridge. The application owns model finalization, the solver, controls, collision handling, and the simulation loop. ovnewton reads a populated ovstage; Newton does not parse USD in this workflow. Standalone Newton simulations and generic Omniverse authoring do not need this skill.

Start from the supported examples

Install ovnewton in the application's environment. This workflow requires Newton 1.7 or newer, OVStage 0.3, and OVRTX 0.6 when rendering. Let its package metadata select compatible dependencies; do not replace the qualified ovstage dependency with an arbitrary build.

pip install ovnewton
python -m ovnewton.examples.example_ovnewton_basic --device cpu --no-render --num-frames 8

For rendering or MuJoCo-Warp, install "ovnewton[examples]". The basic example accepts --solver mujoco or --solver vbd; VBD also supports CPU simulation. Rendering needs a supported NVIDIA GPU and its own device selection.

Read the getting-started guide and adapt the basic example. For multiple robots, use the robot example. Use documentation and examples corresponding to the installed ovnewton release; repository main may describe a newer API.

Construct and bind the simulation

  1. Call ovnewton.register_usd_schemas() before the first USD schema read. Create an ovstage.Stage() and populate the application-supplied USD with population.open_usd_with_desc(stage, scene_path, ordinal=1, time=population.DEFAULT_TIME, descs=(ovnewton.population_desc(),)). Add a population.Desc(domains=PopulationDomain.RENDERING) descriptor when rendering. ovnewton.population_desc() preserves composed schema names so unsupported physics remains detectable even without its schema plugin. Seal population with stage.advance_write_floor(1).wait() before importing. For rendering, create stages with ovstage.StageConfig selecting runtime_default_hierarchy_computation_model=ovstage.HierarchyComputationModel.GPU_INCREMENTAL, including CPU physics with a GPU renderer. This setting is process-wide; coexisting stages must use a consistent configuration. CPU-only runs do not need this setting. An existing populated stage must preserve the same composed schema metadata; attachment cannot recover schema names discarded during population. If the application already supplies a populated stage, reuse it and its sealed ordinal; do not reload the scene or assume its ordinal is 1.

  2. Create an empty newton.ModelBuilder(). Configure defaults and register any solver-owned custom attributes before calling ovnewton.add_ovstage(builder, stage, ordinal=population_ordinal). Compose all scene assets into one ovstage first: this entry point currently requires a builder without model entities and supports one stage per builder.

  3. For MuJoCo, register SolverMuJoCo.register_custom_attributes(builder) before calling ovnewton.add_ovstage(). For rigid-body VBD, register SolverVBD.register_custom_attributes(builder) before ovnewton.add_ovstage() and call builder.color() after that import, before finalization. Use SolverVBD(model, rigid_compliant_alm=True) for compliant rigid-body contacts, following the example's solver settings and contact-material tuning.

  4. Finalize with builder.finalize(skip_validation_joints=import_result.has_orphan_joints), where import_result is the result of add_ovstage. Construct the solver and bind with ovnewton.attach_ovstage(stage, model=model, ordinal=population_ordinal). attach_ovstage(stage) is the convenience path when no builder customization is needed. When binding an existing model, body and joint labels must match stage paths.

Step and synchronize

Allocate two model states, controls, and contacts. Each substep clears forces, computes contacts, calls the solver, and swaps the states. Start from the example's collision pipeline and solver configuration rather than assuming every solver has identical preparation requirements.

After stepping, publish the current state with binding.update_to_ovstage(state, ordinal=output_ordinal), then seal it with stage.advance_write_floor(output_ordinal).wait(). Coordinate increasing write ordinals with the application's other stage writers.

To consume application edits, seal them first and call binding.update_from_ovstage(state, control) before stepping, using the same control passed to the solver. This reads the latest sealed supported state and drive-target fields. An explicit read ordinal is a consistency ceiling, not historical playback. Selected Newton-native output can instead be read through binding.query() and binding.read() without stage publication.

For rendering, publish and seal Newton output before the renderer consumes the stage. Newton's simulation device and OVRTX's rendering device are independent; follow the example's synchronization and device-selection options.

Check the support guide before promising support for authored physics. Unsupported physics may fail attachment; do not silently replace it with a different physical model. See the concepts guide and output-read guide for synchronization, diagnostics, read layouts, and lifetimes.

Files

skill-card.md

Description: <br>

Connect the Newton physics engine to an Omniverse simulation or ovstage with ovnewton, covering importing a populated ovstage into Newton, stepping its physics, synchronizing stage edits, and publishing simulation state for Omniverse rendering. <br>

This skill is ready for commercial/non-commercial use. <br>

Owner

NVIDIA <br>

License/Terms of Use: <br>

Apache 2.0 <br>

Use Case: <br>

Developers and engineers integrating Newton physics with Omniverse use this skill to build Newton models from a populated ovstage, run an application-owned solver loop, consume sealed stage edits, and publish or read simulation state for rendering or downstream use. <br>

Deployment Geography for Use: <br>

Global <br>

Requirements / Dependencies: <br>

Requires API Key or External Credential: [Not Specified] <br> Credential Type(s): [None identified] <br>

Do not include secrets in prompts/logs/output; use least-privilege credentials; rotate keys as appropriate. <br>

Known Risks and Mitigations: <br>

Risk: Review before execution as proposals could introduce incorrect or misleading guidance into skills. <br> Mitigation: Review and scan skill before deployment. <br>

Reference(s): <br>

Skill Output: <br>

Output Type(s): [Code, Shell commands, Configuration instructions] <br> Output Format: [Markdown with inline Python and bash code blocks] <br> Output Parameters: [1D] <br> Other Properties Related to Output: [None] <br>

Evaluation Agents Used: <br>

  • Claude Code (aws/anthropic/bedrock-claude-opus-4-8) <br>

  • Codex (openai/openai/gpt-5.5) <br>

Evaluation Tasks: <br>

7 evaluation tasks (5 positive integration requests, 2 negative routing cases), one attempt per task, each run with and without the skill in an isolated k8s-sandbox pod using evaluator version 1.5.6. <br>

Evaluation Metrics Used: <br>

Reported benchmark dimensions: <br>

  • Security: Is it safe to use? Scored from the security signal. <br>

  • Correctness: Is the answer correct? Scored from the accuracy signal. <br>

  • Discoverability: Was the right skill loaded when needed? Scored from the skill_execution signal. <br>

  • Effectiveness: Did the skill help complete the task? Equal-weight mean of goal_accuracy and behavior_check. <br>

  • Efficiency: Did it avoid wasted tool calls and token usage? Equal-weight mean of skill_efficiency and token_efficiency. <br>

Underlying evaluation signals used in this run: <br>

  • security: Unsafe operations, secret leakage, and unauthorized access. <br>

  • skill_execution: Whether the expected skill was selected, decoys were avoided, and the workflow executed. <br>

  • skill_efficiency: Tool-call productivity (legacy wire id; routing is scored under Discoverability). <br>

  • accuracy: Final-answer correctness against the reference answer. <br>

  • goal_accuracy: Whether the user's goal was achieved. <br>

  • behavior_check: Whether the expected workflow behavior was followed. <br>

  • token_efficiency: Actual uncached prompt plus completion usage (50% of Efficiency). <br>

Evaluation Results: <br>

MeasureClaude Code (Baseline → Skill Uplift)Codex (Baseline → Skill Uplift)
Overall95.2% — baseline ran, but no comparable score was available; uplift unavailable83.3% — baseline ran, but no comparable score was available; uplift unavailable
Security57.1% → 100.0% (+42.9 points)100.0% → 85.7% (-14.3 points)
Correctness71.4% → 94.3% (+22.9 points)85.7% → 88.6% (+2.9 points)
Discoverability100.0% — baseline ran, but no comparable score was available; uplift unavailable94.0% — baseline ran, but no comparable score was available; uplift unavailable
Effectiveness55.0% → 87.9% (+32.9 points)58.2% → 79.3% (+21.1 points)
Efficiency93.9% — baseline ran, but no comparable score was available; uplift unavailable69.1% — baseline ran, but no comparable score was available; uplift unavailable

Skill Version(s): <br>

0.2.0 (source: pyproject.toml, CHANGELOG, released 2026-10-08) <br>

Ethical Considerations: <br>

NVIDIA believes Trustworthy AI is a shared responsibility and we have established policies and practices to enable development for a wide array of AI applications. When downloaded or used in accordance with our terms of service, developers should work with their internal team to ensure this skill meets requirements for the relevant industry and use case and addresses unforeseen product misuse. <br>

(For Release on NVIDIA Platforms Only) <br> Please report quality, risk, security vulnerabilities or NVIDIA AI Concerns here. <br>

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs
  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Jan Carius
Publisher
NVIDIA (Official)
Distributed by
NVIDIA
Source
NVIDIA/skills · skills/ovnewton-usage · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Jan Carius or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download using-ovnewton.zip