Huang, Chao, Mousavian, Liu, Fox, Mo, Fei-Fei (Stanford / NVIDIA), 2026

PointWorld: Scaling 3D World Models

A robot glances once at a scene, imagines its own hand reaching in, and predicts how every 3D point of the world will move — pushing, deforming, articulating — all in 0.1 seconds, with no demos and no fine-tuning.

Prerequisites: Basic ML + 3D geometry intuition + RL/control basics
11
Chapters
6+
Simulations

Chapter 0: The Problem

You walk into a kitchen you have never seen. On the counter sits a half-full mug. Without touching it, you already know: if you push it, it slides; if you nudge it past the edge, it falls; if you bump the cloth next to it, the cloth crumples but the mug barely moves. You ran a physics simulation in your head — from a single glance — and you did it for the whole scene at once.

A robot cannot do this. Give a robot one camera image and ask "what happens if I push here?" and most systems either (a) have no answer, or (b) require a hand-built physics simulator tuned for that exact object, or (c) generate a blurry video that violates gravity.

The core question: Can we pre-train one model that, from a single RGB-D image of any scene and a description of any robot action, predicts how the entire 3D world will move — rigid pushes, deformable cloth, articulated drawers, tool use — in real time, with zero demonstrations of that task?

Why this is hard: three failed families

World modeling — predicting future states from current state and action — has been attacked from three angles, and each hits a wall:

ApproachHow it predicts the futureWhere it breaks
Physics simulators (MuJoCo, FleX)Solve Newtonian equations on hand-specified meshes + materialsYou must MODEL every object first. Sim-to-real gap. No "glance and know."
Learned dynamics (graph nets, particle models)Learn forward dynamics from interaction dataNeed full observability, object segmentation, or material labels baked in
Video generators (Sora-style)Predict future pixelsNo explicit action conditioning; physically inconsistent; seconds-long inference

Notice the pattern: each method buys predictive power by buying inductive bias — a mesh, a segmentation, a material model. That bias is exactly what stops them from generalizing to a kitchen they've never seen. PointWorld's bet is that you can drop almost all of that bias and recover it from scale.

The bar PointWorld must clear

Figure 3 of the paper lists what a single forward pass must implicitly do, with no explicit module for any of it:

And it must do all six together, in 0.1 seconds, from one image. That single-forward-pass-does-everything claim is the whole paper.

Why do physics simulators and classical learned-dynamics models fail to "glance and predict" in a new kitchen?

Chapter 1: The Key Insight

PointWorld's insight is a single design decision that everything else follows from: represent both the world's state AND the robot's action in the exact same modality — 3D point flows in a shared physical space.

Unification for scaling. State = the scene as a cloud of 3D points. Action = the robot's own surface, also as 3D points, moving over time. Both live in the same coordinate frame. World modeling then collapses to one question: given the static scene points and the moving robot points, predict where every scene point goes next.

Why "same modality" is the unlock

Think about what an action is in most robot systems: a vector of joint angles, or an end-effector pose. That representation is embodiment-specific — a Franka arm's joint vector means nothing to a humanoid. So a model trained on one robot can't learn from the other.

Now represent the action as the 3D points on the gripper surface, moving through space. Suddenly a Franka gripper closing and a humanoid hand closing are the same kind of object: a set of 3D points that approach the scene and make contact. The model never sees "joint 4 = 0.3 rad." It sees geometry touching geometry. That is why one model can ingest single-arm, bimanual, whole-body, and mobile data all at once.

The analogy the authors lean on: this is "next-token prediction, but for interaction over 3D space and time." Just as an LLM learns grammar, facts, and reasoning all from one objective (predict the next token), PointWorld learns segmentation, materials, articulation, and gravity all from one objective (predict the next 3D displacement). No labels for any of those concepts — they emerge because predicting motion correctly requires them.

The formulation in one line

Classical world models do a single step: st+1 = Fθ(st, at). PointWorld predicts a whole chunk at once:

FθH : (st,  at:t+H−1) → st+1:t+H

Here st is the scene point cloud at time t, at:t+H−1 is the robot's point-flow trajectory over the next H steps, and the output is the scene's state at every one of those H future steps. The paper uses H = 10 steps at 0.1s each — so one forward pass imagines a full second of physics. Chunking (instead of step-by-step) improves temporal consistency and amortizes compute, which is what makes real-time MPC possible.

What is the single design decision that lets PointWorld learn from many different robot embodiments at once?

Chapter 2: World Models, Briefly

Before the method, let's pin down the vocabulary, because "world model" means different things to different communities.

A world model is a predictive model: given the current state and an action, it simulates the future state. The interesting design axis is what is the state-action representation? — and that choice determines everything else.

The representation zoo (side by side)

RepresentationState is...StrengthWeakness
Video modelspixelsphotorealistic, easy datano explicit action, physically loose, slow
Radiance fields / Gaussiansa learned 3D fieldgreat appearanceper-scene fitting, appearance > physics
Meshes / surfacesexplicit geometryphysically preciseneed reconstruction first
Point flows (PointWorld)a cloud of moving 3D pointsphysics-first, no priors, RGB-D-readyno appearance/texture modeling

PointWorld deliberately picks the representation that emphasizes contact and geometry over appearance — "the role of a physics simulator rather than a renderer." It does not try to predict what the future looks like (color, texture, shading). It only predicts where matter goes. That is a much narrower, much more learnable target.

Think of it this way: a video model is a movie director — it must get lighting, texture, and motion all right. PointWorld is a choreographer — it only cares where the dancers move. Dropping the appearance burden is half the reason it can run in 0.1s while diffusion video models need seconds.

Why "particles" are an old idea done at new scale

Representing a scene as particles (points with state) and learning their dynamics is not new — graph-based neural dynamics (GBND) models did this years ago. The catch: they worked on small, fully-observed, single-object scenes. PointWorld's contribution is not the representation itself; it's the recipe to scale it — modern backbone, pre-trained features, a loss that survives noisy real data, and 2M trajectories. Chapter 9 walks the exact roadmap.

What does PointWorld deliberately NOT model, and why is that a feature?

Chapter 3: Point Flows — the data structure

Everything in PointWorld is a point flow. Let's build the two kinds — scene flows and robot flows — from the ground up, with their actual tensor shapes, because the shapes are the understanding.

Scene state: where matter is

The scene state at time t is a set of points:

st = { (pt,i, fiS) }i=1..NS,   pt,i ∈ ℝ3,  fiS ∈ ℝDS

How do you get these points? From a calibrated RGB-D image: each pixel has a color and a depth, so you back-project it into 3D. You first mask out the robot's own pixels using forward kinematics (you know exactly where the robot is from the URDF + joint angles), so the scene cloud is just the environment.

The subtle bit that makes inference cheap: the model receives a static snapshot of scene points and predicts their future positions itself. Correspondence ("which point is which over time") is maintained inside the forward pass — its imagination. So at deployment you need no point tracker, and the point count can change between calls. Tracking is only needed offline to build training labels.

Action: the robot as a moving cloud

The action is the robot's own surface, forecast forward in time by forward kinematics — not measured, computed. Given a sequence of joint configs {qt+k}, you sample surface points on the robot once, attach each to its link, and propagate:

at+k = { (rt+k,j, ft+k,jR) }j=1..NR,   rt+k,j ∈ ℝ3

In practice most robot surface points never touch anything, so for efficiency they sample flows only from the grippers — a few hundred points per gripper. The grippers are where contact happens; the elbow is irrelevant to the dishes.

Why FK instead of sensing the robot? Two reasons. (1) Full observability: the imagined action must be complete even in occluded contact (holding a big box egocentrically). (2) Embodiment-agnostic: FK turns any robot's joint commands into the same point-cloud language, so a single model trains across single-arm, bimanual, and whole-body data without per-robot heads.

Why does PointWorld generate robot action points via forward kinematics rather than from the depth camera?

Chapter 4: The Rollout Simulator (Showcase)

This is the heart of the paper made interactive. The robot's gripper (orange points) sweeps along an action trajectory you control. Where it makes contact, scene points (teal) get pushed; the rest stay put. Watch how the model's job — propagate displacement from action geometry to scene geometry — plays out.

Action-Conditioned 3D Point-Flow Rollout

Drag the push direction and push strength. Pick a material — it changes how points respond to the gripper. Press Roll out to imagine the H-step future. The "single forward pass" predicts all 10 frames at once; the animation just replays them.

Material:
Static scene + action trajectory. Press Roll out.
What you just watched the model do: it had to (1) decide which scene points the gripper touches (implicit segmentation), (2) decide how they respond — a rigid block moves as one, cloth deforms locally, a hinged door rotates about a pivot (material + articulation), and (3) leave the untouched points alone (most of the scene is static). No object labels, no physics equations — just learned displacement.

The data-flow trace, frame by frame

Concretely, in one forward pass the model maps:

in
Scene points s0 ∈ ℝN×3 + DINOv3 features + robot flows a0:9 ∈ ℝ10×NR×3
↓ concatenate into one cloud, run PTv3 backbone
mid
Per-point features for all points (scene + robot)
↓ shared MLP head, per scene point, per step
out
Displacements ΔP ∈ ℝ10×N×3 → future positions P̂1:10

Crucially the output is a displacement per scene point per future step, all 10 steps emitted simultaneously. Compare to a diffusion video model that needs dozens of denoising iterations per frame. That architectural choice is the entire latency story.

In the showcase, switching from "rigid" to "deformable" changes how scene points respond to the same gripper push. What real PointWorld capability does that represent?

Chapter 5: The Architecture

PointWorld deliberately avoids inventing a custom network. Instead it builds on a state-of-the-art point-cloud backbone and asks: what's the recipe to make it a scalable world model? Here is the pipeline (Figure 2).

PointWorld Pipeline

Walking the boxes left to right

Why is DINOv3 frozen? Two reasons the paper makes explicit. (1) High-quality 3D pre-trained features are scarce, but high-quality 2D features (DINOv3) are abundant and excellent — so borrow them. (2) Freezing preserves the objectness priors learned from internet-scale images; fine-tuning on a smaller robot dataset would erode them. The backbone learns dynamics; DINOv3 supplies "what is this thing." This is the single biggest accuracy lever in the scaling roadmap (Chapter 9).

Why a point-cloud transformer and not a graph net?

The old GBND models built an explicit graph (nearest-neighbor edges) and did message passing. That bakes in a locality prior and scales poorly. PTv3 uses serialized attention over points — it can route information between any points, scales to billions of parameters, and runs fast on GPUs. The ablation (Chapter 9) shows swapping GBND→PTv3 is the foundation everything else is built on.

Data-flow shapes, end to end

StageTensorMeaning
Scene in[NS, 3]back-projected pixel positions
Scene feat[NS, DS]frozen DINOv3, multi-layer
Robot in[H, NR, 3]FK-forecast gripper points
Concatenated cloud[NS + H·NR, D]one cloud into PTv3
Output displacements[H, NS, 3]per point, per future step
Why is the DINOv3 encoder frozen rather than fine-tuned?

Chapter 6: The Loss — making regression survive reality

The output is continuous 3D positions, so the obvious loss is L2 on displacement. But two facts about the real world break naive L2. The paper's loss is L2 plus two surgical fixes. Let's manufacture the need for each.

Problem 1: almost everything is static

In a full-scene prediction, the robot touches maybe 2% of the points. The other 98% don't move. If you average L2 over all points, the gradient is dominated by "predict zero displacement" — the model learns to output nothing and scores great. The moving points, which are the entire point of the task, are drowned out.

Fix 1 — movement weighting. Up-weight points that actually move. Let δk,i be the ground-truth displacement norm of point i at step k. Define a soft "is it moving?" likelihood:

mk,i = σ( κ·(δk,i − τ) )

Then normalize across all points/steps to get weights wk,i = mk,i / Σ m. Now the loss budget is spent on the points that move.

Problem 2: the labels are noisy

The real-world ground truth comes from an imperfect offline pipeline (depth + tracking). Some "ground-truth" displacements are simply wrong. Forcing the model to match them exactly teaches it noise.

Fix 2 — aleatoric uncertainty. Let the model predict, per point per step, a scalar log-variance sk,i — "how much should you trust my prediction here?" High predicted uncertainty down-weights that point's residual, so the model can say "this label looks unreliable, I won't overfit it." This is learned with no uncertainty labels — it's self-supervised through the loss shape.

The full objective, term by term

L = Σk,i [ wk,i · ρδ(P̂ − P) · e−sk,i + ½ sk,i ]
TermSymbolJob
movement weightwk,ifocus loss on moving points
Huber loss on 3D residualρδ(P̂−P)robust regression (L2 near zero, L1 far out → outlier-tolerant)
uncertainty weighte−sdown-weight points the model flags as unreliable
uncertainty regularizer½ sk,istops the model from declaring everything uncertain to dodge the loss

Read it as a tug-of-war on s: the e−s term wants s large (to shrink the residual penalty), the +½s term wants s small. The balance point is exactly where predicted uncertainty matches real label noise. Visible points only — anything the 2D tracker marks occluded is dropped from supervision.

An emergent surprise: the uncertainty head was added just to fight label noise, but it also learns action-conditioned physical uncertainty. Drop a cloth and the model reports high uncertainty along the cloth's free edge — exactly where physics is genuinely unpredictable. Nobody told it to; it fell out of the objective.

Worked numerical example

Say a moving point has true displacement δ = 0.04m, with τ = 0.01m and κ = 100. Then m = σ(100·(0.04−0.01)) = σ(3) ≈ 0.95 — strongly weighted. A static point with δ = 0.002m gives m = σ(100·(0.002−0.01)) = σ(−0.8) ≈ 0.31 — heavily discounted. The 3:1 ratio is what rescues the moving-point signal. Use the slider below to feel it.

Movement-Weighting Curve
Why does naive L2 over all points fail for full-scene world modeling?

The core loss as runnable code

# PointWorld weighted, uncertainty-regularized Huber loss import torch, torch.nn.functional as F def pointworld_loss(pred, gt, log_var, visible, tau=0.01, kappa=100., beta=0.02): # pred,gt: [H, N, 3] positions log_var: [H, N] visible: [H, N] bool delta = gt.diff(dim=0, prepend=gt[:1]).norm(dim=-1) # [H, N] gt motion norm m = torch.sigmoid(kappa * (delta - tau)) # soft "is moving" m = m * visible # occluded -> no supervision w = m / (m.sum() + 1e-8) # normalize to weights res = F.huber_loss(pred, gt, beta=beta, reduction='none').sum(-1) # [H,N] # aleatoric: down-weight by exp(-s), regularize with +s/2 loss = w * (res * torch.exp(-log_var) + 0.5 * log_var) return loss.sum()

Chapter 7: The Dataset — 2M trajectories from imperfect cameras

A world model is only as good as its supervision. PointWorld needed accurate 3D labels at scale — and the existing manipulation datasets don't have them. The dataset-curation pipeline is half the paper's contribution.

The key observation: three lines of 3D-vision research — metric depth estimation, camera-pose estimation, and dense point tracking — have all matured enough that you can run a markerless, offline pipeline on already-recorded video and recover high-quality 3D point flows. No re-collection, no markers. Mine the labels from existing data.

The three-stage real-world annotation pipeline (DROID)

DROID gives RGB video + (poor) sensor depth + (inaccurate) extrinsics. The pipeline fixes each:

1
Depth: replace noisy sensor depth with FoundationStereo — sharp at the close working distances of manipulation
2
Extrinsics: refine VGGT-initialized camera poses by an optimization that aligns observed robot depth to the known robot mesh
3
Tracking: CoTracker3 gives 2D tracks + visibility; lift to 3D with the refined depth+pose; carry visibility labels so occluded points are excluded from supervision

Why optimize extrinsics against the robot mesh? Because the robot is the one object whose 3D geometry you know exactly (URDF + joints). If your camera pose is right, the observed robot depth should land precisely on the analytical robot surface. Minimizing that "depth reprojection loss" is a free, ground-truth-free calibration signal. This is the same trick used to evaluate calibration in the wild (the best 1% of scenes by this metric serve as a pseudo-ground-truth reference).

Result of the pipeline: reliable 3D point flows for over 60% of DROID — nearly 200 hours of human teleop — beating both the original dataset releases and naive use of frontier models (VGGT alone gives over-smoothed depth and poses off by tens of centimeters). Simulation (BEHAVIOR-1K) adds ~1100 hours with perfect ground-truth state, filtered to trajectories with actual robot-object contact. Combined: ~2M trajectories, ~500 hours — the largest 3D dynamics dataset to date.

The evaluation metric, and a warning about it

Models are scored by per-point, per-timestep L2 distance on moving points (the static 98% would otherwise dominate and hide all differences — same logic as the training loss). The paper flags an honest subtlety: because horizons are one second, even big motions move points only a few centimeters, so absolute metric gaps look tiny (0.0312 vs 0.0386). Yet they say small numerical gaps map to large qualitative differences in rollout fidelity, and task success rate is too coarse to expose them. The eval set is denoised by a held-out expert model that flags unreliable flows, keeping the top 80% by confidence.

How does PointWorld refine the (inaccurate) camera extrinsics without ground-truth poses?

Chapter 8: From prediction to action — MPC with MPPI

A world model predicts. It does not act. To make a robot move, PointWorld is dropped into a sampling-based model-predictive controller — and its real-time, chunked prediction is what makes this practical.

The idea: imagine many futures, pick the best, repeat

MPPI (Model Predictive Path Integral) is "guess-and-check" done well. At each control step:

  1. Sample K candidate end-effector trajectories by adding smooth (cubic-spline) noise to a nominal plan.
  2. For each candidate, build its robot point-flows and roll it out through PointWorld to imagine the resulting scene.
  3. Score each imagined future with a cost J — does it move the task points toward their goals?
  4. Update the nominal trajectory as a softmax-weighted average: good trajectories pull harder.
ω ∝ exp(−J(ℓ) / β),   nominal ← Σ ω · trajectory(ℓ)
Why PointWorld is a natural fit for MPPI: MPPI needs to evaluate many candidate futures fast. PointWorld predicts a full H-step chunk in one 0.1s batched forward pass, so you can score hundreds of candidates in real time. A diffusion video model (seconds per rollout) would make MPPI hopeless. The chunked formulation isn't just a quality choice — it's what unlocks closed-loop control.

The cost function: task vs. control

Cost splits into what you want and what's allowed:

ctask(sk) = (1/|Itask|) Σi∈Itask ½·||pk,i − gi||2

Itask is a set of task-relevant scene points (the points on the mug you care about) and gi are their target positions. This single pointwise goal cost works for rigid, deformable, AND articulated objects — you just specify where the relevant points should end up. A control cost cctrl adds path-length and reachability regularization. Task points can be picked by a human in a GUI or proposed by a VLM.

MPPI: sample trajectories, roll out, reweight

Each thin line is a sampled candidate gripper path. The dashed circle is the goal. Press Resample to draw K new candidates; the bold orange line is the softmax-weighted nominal that emerges. Lower β commits to the best sample; higher β hedges.

Press Resample & refine.
What property of PointWorld makes it a good fit for sampling-based MPC?

Chapter 9: The Scaling Roadmap

The paper's most useful contribution for practitioners is Figure 7: a step-by-step "roadmap" showing exactly which design changes move the L2 error, starting from an old GBND baseline and ending at the 1B-parameter final model. Each step isolates one choice.

Roadmap: each lever's effect on L2 error (lower = better)

Toggle each design lever on/off and watch the cumulative L2 error (moving points, DROID test). These are the paper's reported numbers. Notice which levers matter most.

The four levers, in order of leverage

The headline finding: 3D world models scale like LLMs. Doubling data or doubling model size each gives a roughly constant additive improvement in prediction accuracy (log-linear). That means there's no near-term plateau — the recipe is "just add more," exactly the property that made language and vision foundation models work.

Generalization at deployment

The payoff: a single pre-trained checkpoint, integrated with MPC, drives a real Franka to do rigid pushing, deformable + articulated manipulation, and tool use in scenes it never saw — from one in-the-wild RGB-D image, with no demonstrations and no fine-tuning. Reported zero-shot success rates: drawer 90%, scarf 80%, tissue box 70%, duster 60%, pillow 40%, microwave 30%, book 20%. Far from solved — but a single un-finetuned model doing all of it is the result that matters.

According to the scaling study, how does prediction accuracy improve as you scale model size or data?

Chapter 10: Connections & Cheat Sheet

PointWorld sits at the crossroads of world models, point-cloud learning, and model-based control. Here's how it connects, plus a one-screen reference.

Where it fits

The cheat sheet

SymbolMeansPlain analogy
st = {(pt,i, fiS)}scene state: positions + frozen featuresa cloud of dots, each with an ID card
at+k = {(rt+k,j, fR)}action: robot surface points over time (via FK)the robot's hand drawn as moving dots
FθHchunked dynamics: predicts H future steps at onceimagine the next second in one go
m = σ(κ(δ−τ))soft "is this point moving?" likelihooda dimmer switch for "pay attention here"
e−s, +½saleatoric uncertainty weighting + regularizer"trust slider" the model sets on its own labels
ρδHuber loss on 3D residualL2 for small errors, L1 for outliers
ω ∝ exp(−J/β)MPPI softmax reweighting of candidate plansvote weighted by how good each guess was
H = 10, 0.1s/stepone-second horizon, 0.1s inferencereal-time imagination

The one-sentence takeaway

Unify state and action as 3D point flows, predict full-scene displacement with a scalable point transformer trained on mined-at-scale real + sim data, and you get a single pre-trained model that imagines physics in 0.1s — close enough to plug into MPC and drive a real robot through tasks it has never seen.

"Humans anticipate, from a glance and a contemplated action of their bodies, how the 3D world will respond."
— PointWorld, opening line