Cookware
Pots, pans, saucepans, baking trays. Mass varies with contents; handle geometry matters for grip.
SimReady Assets for Kitchen and Cooking
Cookware, utensils, dishware, fresh produce, and small appliances — calibrated for the variable mass, wet surfaces, and deformable contact a cooking robot actually has to deal with.
Updated 2026-06-06
Cooking robotics is the hardest manipulation domain in service robotics: every object's mass changes as you pour from it, surfaces get wet and oily, half the targets are deformable, and contact with food is destructive. Generic 3D libraries skip the whole category. Rigyd generates physics-enabled OpenUSD and MJCF from 3D models, reference images, or text descriptions, with calibration tuned for the variable-mass and slippery-surface physics that cooking robots actually have to deal with.
Objects
What's in this category.
Utensils and knives
Chef's knives, spatulas, whisks, ladles, tongs. Long-lever physics, edge geometry, slip risk.
Dishware
Plates, bowls, cups, mugs. Glazed ceramic surfaces, fragile, stackable for storage tasks.
Fresh produce
Fruits, vegetables, herbs. Variable density, sometimes deformable, irregular shapes for grasp planning.
Packaged goods
Jars, bottles, cans, sealed bags. Rigid containers with variable fill levels driving mass changes.
Small appliances
Blenders, kettles, toasters, food processors. Mixed-material surfaces, articulated lids.
Cleaning supplies
Sponges (deformable), brushes, cloths, dish soap bottles. Mostly soft-body but rigid-body approximations work.
Cutting boards and surfaces
Wood, plastic, composite. Friction varies materially; common manipulation working surface.
Storage containers
Tupperware, glass jars, metal tins. Stackable, often closed (no fluid simulation needed).
Raw proteins
Meat, fish, poultry. Slippery, soft, hard to grasp — common edge case for grippers.
Physics
Physics characteristics.
Variable mass from contents
A pot full of water has 10× the mass of an empty pot. Rigyd generates assets with the empty mass baked in; for content-aware tasks, scripts can scale inertial mass at runtime based on a fill-level parameter. Domain randomisation over fill state is the standard training pattern for cooking robots.
Slippery wet and oily surfaces
Friction in a working kitchen drops to 0.05–0.15 on wet steel, 0.02–0.08 on oily ceramic. Rigyd keys per-material friction to surface classification, and the MJCF output supports per-geom friction tuning so wet/dry/oily variants of the same asset can be generated as DR samples.
Mixed rigid + deformable behaviour
Most kitchen tasks involve at least one deformable target (bread, vegetables, dough, sponges). Rigyd outputs rigid-body approximations that work for grasp planning and contact detection; full soft-body simulation lives in the downstream simulator (MuJoCo flex, Genesis soft-body, PhysX FleX) using Rigyd's geometry as the rest-state mesh.
Materials
Common materials.
Stainless steel · cookware, utensilsCeramic / porcelain · dishwareGlass · containers, ovenwarePlastic (HDPE, PP, ABS)Wood · cutting boards, utensilsSilicone / rubber · grips, matsOrganic (produce, dough, proteins)
Robot tasks
What these assets enable.
Cooking and food prep
Chopping, stirring, pouring, plating. Tasks need correct cookware mass and handle geometry, plus realistic produce/proteins for slip-aware grasping.
Dishwashing and clean-up
Picking dishware off a table, loading a dishwasher, scrubbing surfaces. Wet-surface friction and fragile-collision behaviour drive whether the policy transfers to the real kitchen.
Inventory and pantry tasks
Restocking shelves, retrieving items, recognising fill levels. Rigid-body physics is enough — but the asset library has to cover the long tail of packaged goods most generic libraries skip.
~5 min
per asset, including variable-fill mass setups
per-geom
friction tuning for wet / oily / dry variants in MJCF
8 simulators
consume the same OpenUSD + MJCF output
FAQ
Frequently asked questions
How does Rigyd handle variable-mass objects like half-full pots?
Rigyd bakes the empty-asset mass into the output and exposes inertial parameters as settable runtime properties in the MJCF and OpenUSD output. Most cooking-robot training pipelines wrap a fill-level parameter into domain randomisation, scaling inertial mass and centre-of-mass position per episode. The asset stays the same; the physics state varies. This is the same pattern used for fuel-level randomisation in autonomous-vehicle simulation.
Can the assets handle deformable food like dough or vegetables?
Rigyd outputs rigid-body approximations sufficient for grasp planning, contact detection, and tactile-feedback training. Full soft-body simulation — dough kneading, vegetable cutting, sponge compression — happens in the downstream simulator using soft-body extensions (MuJoCo flex, Genesis soft-body, PhysX FleX). Rigyd-emitted geometry serves as the rest-state mesh those extensions wrap around. For most cooking-robot policies, rigid-body is sufficient; soft-body is reserved for narrow validation tasks.
How do I simulate wet vs dry surfaces for slip-aware grasping?
MJCF output supports per-geom friction parameters, so you can emit two friction variants of the same asset (dry: μ=0.45, wet: μ=0.10) and switch at training time. OpenUSD assets carry a default friction value with material classification metadata; the downstream simulator picks the appropriate friction per scenario. Domain randomisation over the wet-dry-oily axis is standard for any policy expected to operate in a working kitchen.
Does Rigyd produce recognisable consumer-product geometry?
Rigyd does not generate brand-specific replicas of consumer products (a "Cuisinart blender" or "Le Creuset pot"). The pipeline produces generic but physically plausible appliances and cookware from images, text descriptions, or your own CAD. If you need brand-specific assets, bring the CAD exports the manufacturer publishes for VR / AR / training purposes and Rigyd adds the physics layer on top. The text-to-asset and image-to-asset paths are calibrated for "a coffee machine" not "a specific Breville coffee machine".
Which simulators does the output work with for cooking-robot training?
OpenUSD output drops into NVIDIA Isaac Sim, Isaac Lab, Omniverse, Unreal Engine, and Unity directly, plus Gazebo Sim via USD imports. MJCF output drops into MuJoCo, MJX, and Genesis. The same source asset works across all of these without re-authoring. For training pipelines that combine Isaac Lab (GPU-parallel rollout) with MuJoCo (precise contact-rich tasks), this means one asset library covers both stages.
Train cooking robots on a kitchen that matches a real kitchen
Drop in 3D models, images, or text descriptions and get SimReady assets in minutes per object.