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.
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.
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.
Call it from anywhere you simulate.
Terminal, REST, right inside Isaac Sim or MuJoCo. One API for all.
The latest from Rigyd.
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: Prop-Robotics-Neutral for any OpenUSD physics runtime, Prop-Robotics-Physx for PhysX with SDF colliders, and Prop-Robotics-Isaac for the Isaac Sim payload layout. A rigid prop and an articulated one both pass all three.
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.