Atlas World Model for robotics: real-to-sim workflows and examples

Real-to-sim is the robotics use case World Labs chose to headline the Atlas launch, and it is the one where a world model’s reconstruction ability matters most. This guide, from an independent site not affiliated with World Labs, explains what was demonstrated, how to capture spaces so they reconstruct well, how the outputs reach a simulator, and where the open questions are.

What real-to-sim means

Robot policies are trained and tested in simulation because real trials are slow, expensive and occasionally destructive. The catch is the gap between the simulator and the real world: a policy that works in a hand-built simulated kitchen may fail in a real one. Real-to-sim narrows that gap by starting from a capture of the actual deployment environment, so the simulator contains the real floor plan, furniture and lighting.

Traditionally that meant photogrammetry rigs, laser scanners and days of cleanup. The promise of a world model is that a phone walk-through is enough.

What World Labs demonstrated with Atlas

In the launch material World Labs captured two large environments using ordinary phone video, with 24 frames per environment, reconstructed them with Atlas, and then simulated different robots navigating the spaces while rendering what each robot’s onboard camera would see (Spatial Insider). They also varied lighting, backgrounds, object placement and robot behaviour to generate additional training samples from the same capture.

Three properties of Atlas make that possible, per World Labs’ description (The Decoder):

• Few-view reconstruction. Atlas accepts from one to more than 100 images and claims faithful results from two or three; 24 frames from a video is a generous input.
• Explicit 3D output. Point clouds and Gaussian splats, so the reconstruction is a scene, not a video.
• Camera-controlled rendering. A robot’s planned trajectory is a camera path, and Atlas renders frames along it.

The obvious caveat: this is a demonstration by the model’s maker. Coverage of the launch notes that the robotics simulation results “remain unproven” outside World Labs’ own material (XenoSpectrum), and no sim-to-real transfer study has been published as of September 3, 2026. Background on the model is in what the Atlas world model is.

Capture guidelines

Whether the reconstructor is Atlas or Marble, capture quality decides the result.

• Move slowly and overlap. Each frame should share most of its content with the previous one. A slow lap of the room with the phone at chest height is the baseline.
• Cover the workspace from multiple heights. Robots see the world from their sensor height, often lower than a human’s. Add a pass at the robot’s camera height.
• Keep the scene static. People, pets and moving chairs produce ghosting. Capture when the space is empty.
• Even lighting. Avoid strong backlight and mixed colour temperatures; turn on the lights the robot will operate under.
• Avoid mirrors and glass where possible. They confuse every reconstruction method.
• Record what you cannot see. Note dimensions of a few reference objects so you can verify scale later.

The same rules apply to the video to 3D world tool on this site, which tracks Atlas video input, and to the image to 3D world tool that runs on Marble today.

From capture to simulator

A Gaussian splat is a rendering representation, not a physics one. Getting a reconstructed world into Isaac Sim, MuJoCo or Gazebo takes three layers:

1. Visual layer. The splat, for rendering realistic camera observations. Isaac Sim can render splats through extensions; MuJoCo and Gazebo generally cannot, so the visual layer there is the mesh.
2. Collision layer. A mesh. Use the mesh export from the World API (Radiance Fields), decimate it, and convex-decompose it for the physics engine, or hand-model collision proxies for the surfaces that matter: floor, walls, tables.
3. Semantic layer. Labels for objects and regions, added in the simulator, so tasks can reference them.

Verify scale with the reference objects from capture before anything else. A world that is five percent too large produces a policy that under-reaches.

Domain randomisation with generated variations

The most interesting part of the Atlas demo is not the reconstruction but the variations: the same space re-rendered with different lighting, backgrounds and object layouts (Spatial Insider). That is domain randomisation, the standard technique for making policies robust, produced by the world model instead of by a simulator’s random-material shader.

If the variations are photorealistic and geometrically consistent, they are worth more than shader noise, because they resemble real distribution shift: a lamp switched off, a box moved, a different time of day. Whether they are consistent enough to train on is exactly what independent evaluation should establish.

What you can do today with Marble

Atlas is early-access only. The World API for Marble accepts video and multi-image input and exports splats and meshes (World Labs), which is enough to build and test the pipeline:

• Capture with the guidelines above.
• Generate a world at about $1.20 per attempt as of September 3, 2026 (pricing).
• Open the splat in the viewer and check geometry against your reference measurements.
• Export the mesh, build collision, and load it into your simulator.
• Script the swap so that when Atlas access arrives you only change the generation step. The Atlas API page tracks that.

Marble generates rather than strictly reconstructs, so treat today’s results as a pipeline rehearsal, not a digital twin.

A minimal evaluation before you trust a reconstruction

Before training anything on a reconstructed world, run a short acceptance test.

1. Scale. Measure three known distances in the world, such as a doorway width and a table length, against your capture notes. Accept within two percent.
2. Geometry. Export the mesh, load it into the simulator, and drive a simulated robot along a known real path. Compare where it collides with where the real robot did.
3. Appearance. Render the onboard camera view at the robot’s height and compare with a real photo from the same spot. Check for missing regions and floating artefacts.
4. Variation sanity. If you use generated variations for domain randomisation, confirm that walls and fixed furniture stay put across variations and only the intended elements change.

A world that fails the first two tests is not a twin; use it for perception pretraining, not for planning.

Limitations and open questions

• No published accuracy. Nobody outside World Labs has measured how metrically accurate an Atlas reconstruction is.
• Dynamic scenes. The demos are static rooms; deformable objects, doors and drawers are not shown.
• Physics properties. Friction, mass and articulation still come from you.
• Sensor realism. Rendered RGB is not the same as a real depth camera’s noise profile.
• Access. Select partners only, no timeline (Implicator).

Who this is for today

Labs with a capture-to-simulator pipeline already in place gain the most from Atlas, because the reconstruction step is their bottleneck and everything downstream is built. Teams starting from scratch should build the simulator side first on Marble worlds, where the cost of a bad reconstruction is $1.20 and an afternoon, and apply for Atlas once the pipeline can consume a better twin without changes.

Next steps

Read how to get Atlas early access if your lab qualifies, rehearse the pipeline on Marble, and join the waitlist below to be told when video-to-world generation goes live on this site.