PAN 2 vs Hi3D v1.0: Two Models That Both Refuse to Tell You How Big Anything Is

Ask either of these models for a world and the first thing you lose is the ruler. PAN 2 is the Institute of Foundation Models' 29-billion-parameter open-weight world model, on Hugging Face as an Apache-2.0 checkpoint since 7 October 2026 with code on 5 November and Day-0 vLLM-Omni support on 10 November: give it a starting frame and a described action and it renders up to twenty seconds of 704×1248 video at 24 frames per second showing the consequence. Hi3D v1.0, formerly Sparc3D, is an open-weights geometry refiner announced on 23 October 2026 that takes one image plus a coarse mesh and returns a denser one, in geometry only, with every result re-centred and normalised to unit radius. One outputs a moving picture with no metric claim; the other outputs a static shape with its absolute scale deliberately deleted. Neither will tell you whether the thing in front of you is a metre across, and both are more useful once you stop expecting them to.

That shared omission is the honest basis for a comparison. The usual framing — 3D versus video, or geometry versus dynamics — is true and unhelpful, because it makes the choice sound like a preference. The framing that decides anything is what each model hands you, what it throws away to get there, and what you are allowed to do with the result afterwards.

What each one hands you, item by item

Name the output object before naming any capability, because the two objects are not the same kind of thing.

• Input — PAN 2 takes an optional first frame plus a structured action caption refined by a prompt-rewriter skill; Hi3D v1.0 takes one image and a coarse mesh of the same object.

• Output — PAN 2 returns an MP4 of up to twenty seconds; Hi3D returns vertex geometry and nothing else, with no colour, no texture, no material and no vertex colour.

• Time — PAN 2 exists to be run forward, and every clip is a prediction of a consequence; Hi3D has no time axis at all and would return the same mesh for the same two inputs forever.

• Scale — PAN 2 makes no metric claim about anything it renders; Hi3D normalises every result to unit radius, discarding absolute size on purpose.

• Batch shape — PAN 2 renders one clip per call; Hi3D runs batch size one.

• Resolution of the output — PAN 2 renders 704×1248 at 24 frames per second for up to twenty seconds; Hi3D refines to an effective sparse extraction-grid resolution of up to 1536°, which is a density of vertices rather than a pixel count.

• Access — PAN 2 is 86.17 gigabytes across sixty files, ungated, Apache-2.0; Hi3D is downloadable under its own Hi3D Open License, royalty-free for commercial use with a "Powered by Hi3D 1.0" attribution.

• Hardware — PAN 2's documented default is eight H200s in BF16, with a recipe putting thirteen seconds of video at roughly 119 seconds on four B300s; Hi3D was validated on a single 96GB H20 with no CPU inference path.

• What you can check yourself — PAN 2's card describes its harness in enough detail to argue with: 300 single-action cases across six capability categories, 100 multi-step tasks scored on step and full-plan completion over three seeds, and a blind pairwise study with thirteen reviewers; Hi3D's card states that training code and the paper's evaluation harness are not included in the release, so its quality claims cannot be re-run from the download.

Those nine rows are the whole purchase decision, and eight of them are descriptions of what each tool accepts and returns rather than claims about how good it is.

The number both models delete, and why

Hi3D's normalisation is documented and easy to miss: each refined mesh is re-centred and normalised to unit radius. That is standard practice in geometry learning, because a network that has to regress absolute coordinates wastes capacity on a scale it could be told, and because training sets assembled from scans and assets rarely agree on units. It also means a mesh that comes out of Hi3D cannot be dropped into a scene at real-world size without you re-applying a scale factor you have to know from somewhere else. The refined geometry is metric-free by construction.

PAN 2's omission is subtler and gets less attention than it deserves. The model renders a physically coherent consequence — the strawberry demo, where swapping the fruit or the liquid changes the splash, is the clearest statement of the idea anyone has produced — and it does so without ever asserting a distance. The training signal is video, the output is video, and video has no intrinsic scale: a close-up of a thimble and a wide shot of a bucket are the same tensor. The model card's own list of shortcuts points at the same gap from the other side, with pasta appearing in the colander before it is drained — a scene that progressed without the physics that would have had to happen.

This is the reason a driving simulator cannot be built out of PAN 2 no matter how good it gets at splashes. A road network needs lane widths in metres and lidar returns in centimetres, and a model whose entire representation of the world is latent video has nowhere to put either. It is also the reason Hi3D cannot supply those metres: it refines the shape of one object, at a scale it normalised away, from an image that had no depth in it.

If your pipeline needs metric output, the metric has to enter somewhere before either model — from a depth sensor, a known-size marker in the frame, a CAD file — and both models sit downstream of that decision rather than making it. That is worth saying plainly because the alternative is a team discovering it after a week of integration.

Editability is the difference that survives contact with a project

Generated video is a dead end for revision. If PAN 2 renders a plan in which a drawer opens and a cup is knocked over, and you want the drawer to open more slowly, you do not edit the clip; you rewrite the caption and pay for another hundred forward passes through a 29B transformer. The caption is the only editable surface, and it is a genuinely good one — structured, time-grounded, with actions bound to actors and camera motion spelled out — but it operates at the level of "what happens", not "where this vertex goes".

A refined mesh is the opposite kind of artefact. Hi3D's output opens in a modeller, gets retopologised, gets textured elsewhere, gets placed. The refinement is one irreversible step in a pipeline that is otherwise full of reversible ones, and that is exactly what a content team wants: a tool that improves a blockout and then gets out of the way.

Here is the composition that does exist, stated without overreach. A coarse blockout refined by Hi3D becomes a detailed prop; a scene builder places the prop; a PAN 2-style world model renders what happens when something acts on it. The two are adjacent stages, not competitors. What does not exist is a loop: Hi3D cannot take a PAN 2 frame and give you back geometry, because a single video frame with no depth and unknown scale is not a mesh problem Hi3D was built to solve.

The place a routing layer earns its keep in that pipeline is the connective language work rather than either model. Captioning a render so a simulator can condition on it, writing the structured world-state description that PAN 2's text encoder consumes at a budget of 1,480 tokens soft and 1,536 hard, judging whether a generated frame matches the brief — those are ordinary metered model calls, and they surround both tools. OrcaRouter carries more than 200 models behind one API at 0% markup on provider list price, with automatic failover between providers, so a caption writer and a render critic can share a key and a fallback path. Neither PAN 2 nor Hi3D v1.0 is in that catalogue and nothing here suggests otherwise: the renderer is your node, the refiner is your GPU, and what we route is the glue.

Two licences that tell you who the customer is meant to be

Both models are open enough to download, and the terms diverge in a way that is more informative than the weights.

PAN 2 is Apache-2.0: no attribution requirement beyond the licence text, no user threshold, no revenue tripwire, no field-of-use restriction. You can fine-tune it, quantise it, ship it inside a product and say nothing about it. For a 29-billion-parameter diffusion transformer trained from scratch on hundreds of millions of videos by a university-affiliated lab, that is an unusually permissive choice, and it is the biggest practical difference between PAN 2 and the closed world models it is usually compared with.

Hi3D v1.0 is royalty-free for commercial use with a "Powered by Hi3D 1.0" attribution, and a separate agreement kicks in above 200,000 monthly active users or $1 million in monthly revenue. That threshold is a fingerprint: it says the intended customer is a studio, a platform or a tool vendor, and it says the authors expect the model to be embedded rather than studied. Below the line it costs nothing; above it, you are negotiating.

Neither licence is a trap. They are different bets about what openness is for: PAN 2's is a bid for adoption as infrastructure, Hi3D's is a bid for adoption with a commercial conversation attached once you are big enough to have one.

The hardware bill, which is not close

Hi3D's requirements are strict and cheap to satisfy if you already own the machine: Linux, Python 3.10, an NVIDIA GPU at compute capability 8.0 or above, CUDA between 12.0 and 12.5, flash-attn with no fallback path, no CPU inference, validated on a single 96GB H20. A studio workstation clears that. The failure mode is the CUDA pin and the missing fallback, not the memory.

PAN 2's requirements are a different category. Eight H200s in BF16 is the documented default, with VAE patch parallelism across four tiles on top, because decoding a twenty-second 704×1248 clip is its own memory problem. The 119-seconds-for-thirteen-seconds figure on four B300s comes from the vLLM recipe, and it is the number that turns every design question into an arithmetic one: fifty sampler steps at a flow shift of 9 with guidance of 2.5 on every step is a hundred forward passes through the 29B transformer per clip, and a planner that evaluates five candidate actions per step of a ten-step task wants fifty clips.

So the cost comparison is not "which is cheaper". It is that one of these is a workstation tool and the other is a cluster workload, and a team that can afford the first may not be able to run the second at all. That asymmetry does not make PAN 2 worse. It makes the decision easy for anyone whose GPU budget is a single card.

Which question you are actually asking

If your problem is that a blockout is too coarse, or that a scanned prop has no fine detail, Hi3D v1.0 is the tool and PAN 2 is irrelevant — there is nothing in a video generator that will give you vertices. Budget the CUDA stack, check the flash-attn dependency before you promise a delivery date, and remember the mesh arrives at unit radius.

If your problem is that you need to see what an action does before you commit to it — plan evaluation, counterfactual data, a robot or an agent that previews its choices — PAN 2 is the only one of the two that answers, and it answers in pixels with a dropped step in about two in three plans according to its own card. Design a checker into the loop, keep your prompts inside the token budget, and treat every clip as a hypothesis rather than a measurement.

If you need both, build the pipeline in the order the artefacts actually flow: metric input first, geometry second, consequence third, and a language model at each seam where one representation has to become another. That is more engineering than either model's announcement implies, and it is the shape every serious 2026 world-model stack has ended up with.

What would change this page is a model that emits geometry with metric scale and a time axis — a 4D output with units. Nothing in either release points at it. Until something does, the accurate summary is that PAN 2 shows you what happens and Hi3D sharpens what is there, that neither will say how large it is, and that the second limitation is the one that quietly decides which of your projects can use either.