The simulation data layer for physical AI
Simulation-ready assets with validated physics
Turn an image or text prompt into millions of simulated kitchen, warehouse, and factory objects, instead of spending weeks modeling and tuning them by hand.
Prompt or image in, simulation-ready asset out, in minutes. Generated for your use case, not pulled from a library.
Physics derived, never guessed. Drop and settle tested, auto-corrected, every SimReady check before export.
OpenUSD and MJCF with physics intact. Loads directly into Isaac Sim, Isaac Lab, and MuJoCo.
Collision detail where the robot makes contact, simplified everywhere else. Triangle and primitive counts included.
The parts of a training scene that usually get built by hand.
Every run below is on Rigyd-generated assets. Each one replaces weeks of modeling, joint tuning and collision cleanup.
Whole scenes, articulated, with telemetry per step
A Unitree G1 with five-finger hands opens a microwave, fridge and oven in a generated kitchen. Every appliance is an articulated asset with joint limits and collision geometry already set, and door angle, hand contact force and arm torque are logged each step: the signals you need to shape rewards and confirm contacts behave.
Fine manipulation inside an articulated chassis
An arm pulls a memory module from a Dell PowerEdge R730 and places it in a tray. Slots, latches and lid are separate articulated parts, with collision geometry tight enough for the grasp to register and simple enough to keep the solver stable at RL step rates.
Variation in geometry, not just textures
One prompt, nine microwaves: different finishes, form factors and door geometry, each with a working hinge. A policy trained on the set has seen real spread in handle position and door swing, which is where texture-only randomization tends to fail at transfer.
Deformables: cable routing and insertion
An arm picks up an Ethernet cable and seats the plug in a router port. The cable is a deformable body with its own stiffness and damping, so it bends, drapes and springs back, which is the behaviour rigid-link approximations get wrong and insertion policies fail on.
See real SimReady outputs.
Assets our users produced with the fully-automated pipeline — textured, with collision hulls, physics properties, and a validation report baked in.
An agent that reasons from your use case, then builds from the ground up.
It researches the object and picks the right method for every part: visual fidelity where it shows, physics accuracy where it touches. Scope, research, iteration, your approval, validation, export.
Call it from anywhere you simulate.
Terminal, REST, right inside Isaac Sim or MuJoCo. One API for all.
The latest from Rigyd.
Rigyd assets at training scale: 8,192 environments on one GPU
“When you can measure what you are speaking about, and express it in numbers, you know something about it.”William Thomson, Lord Kelvin
A question robotics teams ask before trusting a third-party asset: how does it behave when a training run copies its scene thousands of times onto one GPU? This post answers with numbers instead of a claim.
Why we rebuilt Rigyd around an agent that reasons first
“Nobody ever figures out what life is all about, and it doesn’t matter. Explore the world. Nearly everything is really interesting if you go into it deeply enough.”Richard P. Feynman
We are robot learning and spatial computing engineers who spent seven years building 3D products together. We trained pipelines for AI-based asset creation, fine-tuning large models on proprietary data to cut hallucinations and produce the most realistic results for specific use cases.
Built by a team with a robot learning and spatial computing background.
Previously built a 3D platform that delivered experiences to 10M users last year, and produced 30K+ high-fidelity assets for Fortune 500 brands.
Questions engineers ask first.
What can I give it as input?
A text description, a photograph or reference image, or an existing 3D file — .glb, .gltf, .fbx, .obj, .stl, .ply, or USD. Multi-file bundles go in as a .zip.
Today, part-by-part articulated builds run from text prompts. Image-to-articulation is shipping shortly.
Which simulators can I export to?
OpenUSD with USD Physics for Isaac Sim and Isaac Lab, and MJCF for MuJoCo. URDF is coming.
The values are written into the file itself — you are not applying a physics schema by hand after import.
How do you make them SimReady?
An agent researches the object before it builds anything: real dimensions, material, and mechanism. Density and friction come from engineering handbooks for the identified material; mass is built from the geometry rather than assumed solid — a thin-walled shell is its surface area times its wall thickness times its density, a solid part is its volume, and any interior filling is added from what the object is; the centre of mass and inertia tensor are derived from the geometry; collision hulls come from convex decomposition rather than a bounding box. Articulated objects get their joints authored per part — type, axis, limits, damping.
Everything is normalized to Z-up and metric, drop-and-settle tested in headless MuJoCo, then scored against the SimReady foundation spec — NVIDIA's published requirements, read from their own spec metadata rather than a list we keep by hand. Assets are scored per profile, and the report names the spec release it was scored against. SimReady 2026.08.0 puts every prop, rigid or articulated, under one profile, Robotics-Prop, with Isaac, PhysX, MuJoCo and Newton as optional features inside it; earlier releases split the same ground into Prop-Robotics-Neutral, Prop-Robotics-Physx and Prop-Robotics-Isaac. A rigid prop and an articulated one both pass the profile they target, and the report lists which optional features each one meets.
What happens when an asset fails validation?
It depends on what failed. Correctness stops the build: the USD and the MJCF have to describe one asset, and the export invariants — a baked scale so joint frames compose, the authored pose inside its joint limits, the centre of mass in the frame USD means — have to hold. Those are not reported, they fail the job.
Conformance is different. A hull that penetrates the floor is corrected automatically and re-run; a requirement an asset does not meet is reported rather than quietly patched, because a non-conformant asset is still a usable asset and you should get it with a red report rather than get nothing. Status is per profile, and anything not applicable to your asset says so with a reason.
The validation report travels with the asset, so you can see exactly what passed, what did not, and against which release of the spec.
What does validation prove, and what does it not?
Our checks prove an asset behaves the way its numbers claim, in simulation: mass and inertia derived from geometry, friction and restitution from material data, drop and settle tested and corrected.
They do not prove your policy will transfer. Your robot is the reference for that, and closing the loop against it is what we are building next.
Do you handle articulated and deformable objects?
Articulated objects are live: hinges, sliders, and their real limits and damping are authored per part and written into every export. Deformables — cloth, cable, and soft bodies with per-layer stiffness — are in early access.
Can I generate variants for domain randomization?
Yes — and we randomize inside physics, not around it. One prompt produces thousands of physically distinct variants. Mass, friction, scale, and material vary together, inside ranges a real material can actually occupy, so your policy trains on variety instead of on worlds that cannot exist.
Is there an API or MCP?
The API, yes — a REST endpoint plus a CLI and Python SDK, an Isaac Sim extension, and a MuJoCo loader. Keys are scoped per project and every surface is agent-callable. Start with the quickstart or the authentication guide.
An MCP server is coming soon, so an agent can call Rigyd directly as a tool rather than through the REST surface.