Hi3D V1.0 vs CARI4D: The Same Backbone, Two Different Questions

The most clarifying fact about Hi3D V1.0 and CARI4D is that both can call Tencent's Hunyuan3D-2. Hi3D V1.0, released on 23 October 2026 as the open-source successor to Sparc3D, uses a Hunyuan3D-2 mini adapter in its demo to produce the coarse mesh it then refines. CARI4D, NVIDIA's category-agnostic 4D reconstruction of human-object interaction, uses Hunyuan3D-2 to reconstruct the object's mesh from the first frame of a video before it tracks how that object moves. Same upstream geometry model, two entirely different jobs: Hi3D asks what the object's surface should look like at high resolution, and CARI4D asks what the person and the object did over time.

Where Hunyuan3D-2 actually sits

It is worth being precise, because "both use Hunyuan3D" can imply a closer relationship than exists.

Hi3D's core library does not require Hunyuan at all. The refinement pipeline takes a reference image and a coarse mesh, and demo/refine_mesh.py imports nothing from Tencent. The Hunyuan3D-2 mini adapter lives in demo/coarse_stage.py, is optional, and exists so that someone with only an image can produce the coarse mesh the refiner needs. Tencent's code, weights and outputs keep their own licence and must be obtained separately. In a production pipeline, Hunyuan is one possible upstream among many.

CARI4D's dependency is structural. Its object reconstruction stage takes the first frame, segments the manipulated object, and reconstructs its geometry with Hunyuan3D-2. That mesh is then placed at metric scale using UniDepth and a coarse-to-fine search through FoundationPose. The rest of the pipeline — NLF for the human, a pose-hypothesis selection step, CoCoNet for render-and-compare correction, and a contact-aware joint optimisation — depends on that object mesh being good enough to track against.

The consequence is the useful frame for this comparison. Hi3D's entire purpose is to correct the kind of geometry Hunyuan3D-2 produces. CARI4D's purpose is to recover motion, and it treats the mesh as an input it inherits. One model is aimed at the other's weak point without either project saying so.

What each learned model is for

Hi3D's learned component is a sparse flow conditioned on image features, defined on coordinates taken from the coarse mesh. It samples sparse latents, decodes them with a self-pruning sparse VAE, extracts a surface, revoxelises and repeats. Three passes take the structural grid from 64³ to 128³ to 192³ and the sparse extraction grid from 512³ to 1024³ to 1536³, at 25 scheduler updates per pass. The model is learning local geometric detail: edges, thin structures, surface continuity, the parts a coarse generator smooths away.

CARI4D's learned component is CoCoNet, a render-and-compare network. It renders the current estimate of the object and the human into RGB, depth and masks, encodes that render with a DINOv2 ViT-B/14 and a ViT-S/14 six-channel XYZ-and-mask encoder, runs spatio-temporal attention, and regresses per-frame pose corrections plus two hand-contact logits. The research checkpoint is 194M parameters; the commercially licensed MHR variant released on 30 August 2026 is 231M. What it learns is not shape detail but the relationship between a rendered hypothesis and an observed frame.

Those are different training signals and different failure modes. Hi3D can make a wrong silhouette sharper. CARI4D can track a badly shaped object accurately through a video and still give you a poor mesh, because its metrics are about pose and contact, not surface fidelity.

What comes out, line by line

• Input — Hi3D V1.0 a reference image plus a coarse mesh vs CARI4D a monocular RGB video

• Output — Hi3D V1.0 a geometry-only trimesh mesh vs CARI4D per-frame human pose and shape, object rotation and translation, and two hand-contact logits

• Scale — Hi3D V1.0 recentred and normalised to unit maximum radius vs CARI4D metric scale recovered through UniDepth and FoundationPose

• Texture — Hi3D V1.0 none vs CARI4D none; it returns poses and contact, not a textured asset

• Compute — Hi3D V1.0 a 96 GB NVIDIA H20 measured, no CPU path, batch size one vs CARI4D PyTorch on NVIDIA Ampere, validated on A100, with a Docker image

• Licence — Hi3D V1.0 the Hi3D Open License 1.0, commercial use with a 200,000-MAU or USD 1M-monthly-revenue trigger vs CARI4D the NVIDIA Open Model Agreement for the 231M commercial checkpoint, research-only for the 194M release

• Evidence — Hi3D V1.0 no numeric benchmark published vs CARI4D a CVPR 2026 paper with ablations and BEHAVE results, vendor-reported and not independently reproduced

The experiment nobody has published

Here is the composition the shared backbone makes obvious, stated as an experiment rather than a feature.

CARI4D reconstructs its object mesh from a single first frame through Hunyuan3D-2. Hi3D refines exactly that kind of coarse mesh, conditioned on a reference image of the same object — and CARI4D has one, because the first frame is the reference. In principle, a pipeline could take CARI4D's first-frame image and Hunyuan mesh, run Hi3D at 1024³ or 1536³, and hand the refined surface back to the stage that places and tracks it.

In practice there are four obstacles, and none of them is small.

• Scale. Hi3D recentres its output and normalises it to unit maximum radius. CARI4D needs a metric-scale mesh to initialise FoundationPose. The transform back is not published, and getting it wrong changes the object's apparent size in every frame.

• Structure. Hi3D refines the coarse structure it is given; it does not correct it. If Hunyuan3D-2 misread the object's topology from one frame, Hi3D makes that misreading more detailed. CARI4D's pose-hypothesis selection can absorb some object error — the paper reports cutting object Chamfer distance from roughly 1,565 cm to 16.85 cm at initialisation — but it is not a shape-repair stage.

• Runtime. Hi3D runs one object at a time, up to three passes, 25 steps each, with no published latency. CARI4D's pipeline already chains Hunyuan3D, UniDepth, NLF, FoundationPose, CoCoNet and a joint optimisation. Adding a 96 GB refinement stage in front of a per-clip loop may be defensible offline and impossible interactively.

• Validation. Nobody has published this integration. The numbers in CARI4D's paper measure pose and contact accuracy, not the effect of a better object mesh on those numbers. It is entirely possible that the refinement improves the mesh and barely moves the reconstruction metrics, because the tracking is robust to surface detail. It is also possible that a sharper mesh improves FoundationPose's correspondences. Until someone runs the ablation, both are guesses.

The honest value of this observation is not "use them together." It is that the two releases are complementary at a specific seam, and the seam has a measurable question attached to it that neither vendor has answered.

Two kinds of evidence, neither independent

CARI4D looks better evidenced than Hi3D, and it is, but the difference is smaller than it first appears. CARI4D has a peer-reviewed CVPR 2026 paper, a named benchmark, ablations and a reported 38% lower reconstruction error in-distribution and 36% on unseen data. Those are NVIDIA's numbers from NVIDIA's evaluation. No neutral lab has reproduced them. The code and the evaluation scripts are public, which makes reproduction possible, not done.

Hi3D has no numeric benchmark at all. The repository publishes visual comparisons across nine methods for local geometry, a training-scale claim of roughly two million curated assets, and a resolution claim of 1536³ sparse extraction. The press release adds a 90% slicing success rate and a claim of the highest multi-view fidelity and detail scores in the reported evaluation, with no scores, no baseline and no slicer named. Training code and the evaluation harness are absent, so the paper's tables cannot be rebuilt from the release.

Both, in other words, are vendor-reported. One has a paper attached and the other has a press release. A buyer should treat the CVPR badge as a reason to take the methodology seriously and not as a substitute for an independent test.

Which question you actually have

If you have a video of a person handling an object and you need to know how the hand, the object and the body moved — metric-scale poses, contact points, frame by frame — CARI4D is the system built for that, and the commercial checkpoint makes it deployable. Hi3D cannot answer that question at all. It has no temporal model, no pose output and no contact reasoning.

If you have a reference image and a rough mesh and you need a sharper static asset, Hi3D is the direct tool. CARI4D cannot answer that question either: its object mesh is a by-product of a tracking pipeline, produced at whatever fidelity Hunyuan3D-2 gives from one frame, and it exposes poses rather than a refined surface.

If you are building the composite — a reconstruction pipeline where object geometry is the weak link — the interesting move is to test whether Hi3D's refinement improves CARI4D's downstream metrics. That is a research question with a clear experiment and no published answer. Budget for the scale transform and the GPU before you budget for the paper.

The layer that surrounds both

Neither model is served by OrcaRouter, and neither is a language model. The catalogue is text, vision, video, embedding and speech; 3D reconstruction is done on your own hardware. The calls around the reconstruction, though, are model calls: captioning the first frame, describing the object for an asset record, or judging whether a refined render still matches the reference from three angles.

That last one is a good fit for model fusion. Instead of trusting a single vision model's opinion that a refined mesh is faithful, send the same multi-view comparison to a panel of models and let their answers aggregate. OrcaRouter exposes fusion and more than 200 individual models behind one API, with the provider's list price passed through at 0% markup and automatic failover if one provider degrades. The geometry stays on your GPU; the judgement around it can be redundant without being expensive to wire.

What would settle it

A single ablation would do more than any amount of spec comparison: take one BEHAVE sequence, refine the object mesh with Hi3D at 1024³, undo the normalisation, and report the pose and contact metrics against the unrefined baseline. If the numbers move, the shared backbone becomes a pipeline. If they do not, Hi3D's value stays where it is strongest — as a standalone geometry tool for people who already own the coarse mesh.

Until that experiment exists, the defensible split is simple. Hi3D V1.0 is a geometry refiner with open weights and no benchmark. CARI4D is a motion reconstructor with a paper and a commercial checkpoint. They meet at Hunyuan3D-2, and neither one is a substitute for the other.