Robot simulation has a boring bottleneck: finding 3D models that behave like the real thing. A CAD file of a robot arm is not enough to train a policy; the simulator also needs mass, collision shapes, friction and joint limits. NVIDIA's answer, announced October 21, 2026 in a Hugging Face blog post, is SimReady Central: a free, ungated library of more than 2,000 simulation-ready OpenUSD assets. This article explains what is in the library, what "SimReady" means, who contributed, and how developers and agents can use it.
TL;DR: SimReady Central at a glance
| Item | Detail |
|---|---|
| Size | More than 2,000 OpenUSD assets |
| Access | Hugging Face, free and ungated |
| Contents | Robot arms and grippers, warehouse equipment, racks, cooling infrastructure, household appliances |
| Contributors | Vertiv, Comau, FANUC, Franka Robotics, Robotiq, Standard Bots, Universal Robots, Palatial, LG Electronics, ForgeCAD |
| Search | Natural language via NVIDIA USD Search; integrated into Hugging Face search |
| Targets | Isaac Sim and Isaac Lab workflows, AI factory digital twins |
| Roadmap | More OEM partners and a growing library |
What does "simulation-ready" actually mean?
NVIDIA defines SimReady assets as OpenUSD models prepared with the properties required for simulation. OpenUSD is an open framework for describing and composing 3D scenes. A detailed CAD model is a start, but simulation needs more: for a manipulation task, the object's mass, collision geometry and friction; for an AI factory, equipment geometry plus electrical or thermal metadata.
The SimReady Foundation supplies specifications, profiles and validation tools. A profile is a logical grouping of features an asset needs for a use case. NVIDIA's table of structural elements lists collision geometry and physical properties for contact and physics simulation, joint structure and limits for articulated movement, semantic labels for object identification and annotated synthetic data, and materials and sensor attributes for rendering and sensor simulation. Developers are meant to pick assets whose profiles match their workflow and compose them into a scene.
A robot arm placing a green box onto a shelf, illustrating robot assets in a simulation-ready library
Image: NVIDIA
Who contributed, and why would they?
The incentive for equipment makers is distribution. An OEM can turn its CAD models into SimReady assets and publish them where teams building simulations will find them, so that customers can test and simulate scenarios with the OEM's product before buying. NVIDIA names:
- Vertiv for AI factory equipment such as server racks, cooling and supporting infrastructure.
- Comau, FANUC, Franka Robotics, Robotiq, Standard Bots and Universal Robots for robot arms and grippers.
- Palatial, with the NVIDIA Robotics 1K Dataset and complex articulated assets generated from text, images, scans, datasheets and CAD.
- LG Electronics for home appliances like refrigerators and dishwashers, aimed at household robot training and synthetic data.
- ForgeCAD, an AI-assisted CAD provider, for articulated robotics props with high-quality textures.
OEMs contribute using a SimReady Central submission skill that validates assets against profiles, packages them and submits them, while managing their own Hugging Face datasets. That design keeps ownership with the manufacturer, but it also means quality will vary by contributor, and anyone using an asset for training should check its license and its profile rather than assume uniform fidelity.
How do developers find and use the assets?
NVIDIA USD Search powers natural-language search across participating datasets, and Hugging Face has integrated it into platform search with indexed USD properties and simulation metadata, so agents can find assets suited to a physical AI task. There is also a search endpoint hosted as a Hugging Face Space, and GitHub skills for building your own asset browser.
NVIDIA's examples pair the library with an AI model. In one, a developer prompts a frontier model, such as OpenAI's GPT-6 Astra, to find a FANUC arm, a compatible Robotiq gripper and warehouse assets, then generate Python to assemble a pick-and-place scene in Isaac Sim with PhysX, render a preview movie, and include scripts and asset versions so the run is reproducible. In another, the same approach builds two AI factory layouts from racks and cooling equipment, checks overlaps and aisle clearances, and saves each layout as an OpenUSD scene. NVIDIA writes that it "expects" the model to query the search API, reference assets into a stage, generate code, configure the task and render a preview, so read these as intended workflows, not benchmarks. For Astra itself, see our launch coverage of GPT-6 Astra.
A cream robotic gripper mirroring an outlined hand, illustrating assets moving from design into robot simulation
Image: NVIDIA
To extend a scene, NVIDIA suggests keeping layout and task changes in separate OpenUSD layers so one set of source assets supports many experiments; varying placements and equipment configurations; configuring training and evaluation tasks in Isaac Lab for robotics; and, for AI factories, connecting scenes to equipment data, power and cooling analysis tools, and live building-management and IT telemetry to keep a digital twin in sync. NVIDIA also mentions Microduck, the open-source robot from Hugging Face and Pollen Robotics, as a project that can use such environments.
Why does this matter for robotics and AI infrastructure?
Physical-AI teams spend a surprising share of time on content: building objects that behave. If a shared library with a validated spec reduces that, more groups can run simulation-based training and evaluation, and agents can assemble scenes programmatically. That sits alongside NVIDIA's push on open physical-AI stacks, which we covered in NVIDIA's long-context world action model for robots, the Cosmos 3 surgical simulator, and the keynote-wide picture in our GTC Berlin 2026 recap.
The AI-factory side is a quiet but important thread. Digital twins of data centers let operators compare layouts, clearances and cooling before building, and our coverage of NVIDIA's DSX POD shows why vendors want standardized, simulation-ready models of racks and chillers: the faster a design can be validated, the better the case for a 14-day deployment claim. Vertiv's presence in the library fits that.
How does it fit NVIDIA's wider physical-AI push?
SimReady Central was published during GTC Berlin week, when NVIDIA's keynote live blog described an open physical-AI stack: Isaac Capture for data collection, GR00T models for robot intelligence, Isaac Lab for simulation training, and Isaac OS for runtime. Assets are the missing input for the simulation layer, because policies trained in simulation are only as good as the worlds they practice in. A shared, validated library lowers the cost of building those worlds and makes results easier to compare between groups, since two labs using the same FANUC arm asset are at least starting from the same geometry and physics.
There is a second effect on the sharing side. Hugging Face already hosts models and datasets, and putting simulation content in the same place lets the same search, versioning and access controls apply. For a team that stores checkpoints and datasets there, adding an asset library is a small step. For equipment makers, it is a new channel: a robot arm that appears in thousands of simulated warehouses is marketing that also gives customers a way to check fit before purchase.
One practical question for adopters is reproducibility. NVIDIA's example prompts ask the agent to include scripts, asset versions and runtime versions, which is the right habit. Pin the asset version you used, store the generated scene alongside your training configuration, and record the simulator and physics engine versions. Without that, a result that depends on one friction coefficient in one asset revision cannot be reproduced when the library updates.
What are the limits?
- Fidelity varies by contributor. A SimReady profile says what properties exist; it does not certify that a friction value matches a real part. Validate against hardware before trusting transfer to the real robot.
- Licensing needs checking. The post says the library is free and ungated, but individual asset licenses and terms are set by contributors; read them before commercial use.
- Tooling lean. The workflows are built around NVIDIA's stack, Isaac Sim, PhysX and Isaac Lab. OpenUSD is open, but other simulators may need conversion work.
- Agent claims are expectations. The Astra-driven examples are described as what NVIDIA expects the model to do; no success rate, cost or failure analysis is published.
- Library size in context. About 2,000 assets is a useful start, but a full factory or home contains far more object types, so expect gaps.
What to do next
If you work on robot learning, browse the library for the arm and gripper you actually own, drop them into an Isaac Sim scene, and check whether the physical properties produce the same behavior as your real setup; any mismatch is data for the contributor and for the SimReady profile. If you make equipment, the submission guide and CAD-to-SimReady skills are the path in. NVIDIA invites comments on which assets, runtimes and integration gaps matter most, and says the roadmap includes more OEM partners.
Related reading
- GTC Berlin 2026 keynote recap
- NVIDIA DSX POD and the 14-day claim
- NVIDIA long-context world action model
- NVIDIA Cosmos 3 surgical simulator
- GPT-6 Astra launch
- Figure and Nscale 100,000-GPU deal
Details reflect NVIDIA's October 21, 2026 Hugging Face post; library contents and terms may change.