Hi3D v1.0 Is Open Source: What the 3D-Printing Claim Actually Requires

Hi3D v1.0 went up on GitHub and Hugging Face on 23 October 2026 with one number attached to it: 90% slicing success. That number is the entire reason a 3D-printing shop should care about the release, and it is also the one number the repository cannot reproduce. There is no slicer in it, no test meshes, no baseline, and no definition of what counts as a failure. What is actually in the repo is substantial: inference code, eight weight files, and a pipeline that takes a reference photograph plus a rough mesh and returns a much denser one, up to an effective sparse extraction grid of 1536³. So the useful question is not whether Hi3D v1.0 works. It is what has to be true around it before a printable part comes out the other end.

What shipped, precisely

The release is the open-sourcing of Sparc3D — the Python package and public API still carry the sparc3d and Sparc3DPipeline names for compatibility, and the underlying paper dates to May 2025. The GitHub repository opened with six commits and a single tag; the Hugging Face card states the model was released on 23 October 2026 and, in the same panel, that it "isn't deployed by any Inference Provider." There is no hosted endpoint for v1.0. The commercial product is a separate, proprietary v3.0 with 2048³ geometry and up to 8K textures.

• What the repo contains — inference code, a demo, Docker and dependency constraints, and documentation. Training code, the paper's evaluation harness, benchmark splits and the comparison meshes behind the headline table are all absent, and the README says so plainly.

• What the weights are — eight runtime files: a model index, a scheduler config, a VAE config and safetensors, and two transformer configs and safetensors. The image encoders, facebook/dinov2-large and openai/clip-vit-large-patch14, load separately on first use and are not part of the model directory.

• How you install it — Python 3.10, PyTorch 2.5.0 with CUDA 12.4, flash-attn==2.7.4.post1, spconv-cu120==2.3.6, installed from source. There is no PyPI wheel and no prebuilt release.

• What licence applies — the Hi3D Open License Agreement 1.0. It is not an OSI licence. Commercial use is permitted, but a product or service that passes 200,000 monthly active users or USD 1,000,000 in monthly revenue must notify Hi3D and apply for a separate written licence within 60 days, and integrations must display "Powered by Hi3D 1.0" with a link where the medium supports one.

The framing in the release coverage is that this is an "industrial production grade" image-to-3D model. The vendor's own announcement page does claim it has been "validated in real production workflows" and that evaluation covered multi-view appearance, local detail and geometric usability. It does not name a single customer, workflow, or measured output. That is an assertion about production, not evidence of it.

The printing claim, broken into four requirements

A part that comes off a printer has to satisfy four things that have nothing to do with how impressive a render looks. Hi3D v1.0 addresses one of them well, one partially, and two not at all.

• Scale — gone by design. The output is recentered and normalized to a unit maximum radius. Absolute size and world coordinates are not preserved, so every model has to be rescaled to millimetres before it means anything. If your reference photo came from a real object and you needed its true dimensions, Hi3D does not carry them through. The repo is explicit about this rather than silent, which is worth credit, but it means scale is a step you own.

• Topology — inherited from the input, not repaired. Hi3D takes a coarse mesh and adds detail to it. If that coarse mesh has non-manifold edges, self-intersections, or inverted normals, the refinement makes them finer, not correct. The README's own limitation section says "coarse structure matters" and that severe coarse-mesh errors can persist. A slicer will still choke on the same defects, only at higher resolution. This is the single most important sentence in the release for anyone pointing it at a printer.

• Surface — absent. The output is a geometry-only trimesh.Trimesh: no textures, no materials, no vertex colours. For single-material printing that is mostly a non-issue, because you print material rather than UV maps. For anything that needs a painted or multi-colour result, or for a client preview that has to look like the product, it is disqualifying and pushes you to v3.0.

• Printability — unevaluated. Nothing in the repo measures wall thickness, minimum feature size, overhangs, or whether the mesh is watertight after refinement. The 90% slicing figure lives in the press release, not the code, and no slicer is named. A sliced file is also not a printed part: slicing success does not tell you the print will adhere, survive supports, or hold tolerance.

The numbers, sorted by what actually backs them

The release mixes claims with very different levels of support. Lumping them together is how a vendor number becomes a fact in a buying decision.

• About two million curated 3D assets — stated in the press release and on the model card, and consistent with the Sparc3D lineage, which the earlier paper described at roughly 500,000 assets. You cannot audit the curation from the repo, because neither the dataset nor the training code ships. Treat it as a credible vendor figure, not a verified one.

• 1536³ effective resolution — this one is real as a configuration. The pipeline runs one pass for 512³, two for 1024³ and three for 1536³, at 25 scheduler updates per pass by default. The word "effective" matters: these are nominal sparse coordinate and extraction grids, not a dense 1536³ latent tensor. The README also notes that the 1536³ setting has only been validated on a 96 GB H20 and that feasibility and peak memory on smaller cards are unstated.

• 90% slicing success — vendor-reported, unreproduced, and unmethodised. No slicer, no failure definition, no baseline, no test set. It is the most quotable number in the release and the least checkable.

• Highest multi-view fidelity and detail richness — presented as the result of "the reported evaluation," which is not in the repository. There is no comparison table, no competitor list, and no per-category breakdown.

• "Validated in real production workflows" — a sentence on the announcement page, with no named partner, no case study and no described workflow. It may well be true. It is not yet evidence.

The hardware wall

The measured stack is a 96 GB NVIDIA H20, and the repo is honest that this is the machine the top setting was validated on. The surrounding requirements are equally specific: Linux, compute capability 8.0 or newer, CUDA 12.0 through 12.5, and no CPU inference path at all. flash-attn has no fallback attention implementation, so a build failure there is fatal rather than degraded. Batch size is one.

Sequential CPU offload is supported and reduces GPU residency, but the README is careful to say it does not establish a minimum GPU-memory requirement and does not remove the cost of decoded features. In practice that means the 512³ one-pass path may fit on a 24 GB card, but nobody has published a memory table, and the vendor has not claimed it. If your plan depends on a 4090, you are running an unverified configuration and should time and measure it yourself before committing.

What a working print pipeline looks like

Hi3D v1.0 is one stage. The repo ships an optional adapter that uses Tencent's Hunyuan3D-2 mini to produce the coarse mesh from a single image; Hunyuan is third-party and not a dependency of the core library, but without something like it you have no input.

So the real sequence is: generate or obtain a coarse mesh, refine it with Hi3D at 512³, 1024³ or 1536³, export the geometry, rescale it to real dimensions, repair whatever topology the coarse stage got wrong, verify watertightness, then slice. Three of those steps — repair, watertightness, slicing — have no equivalent anywhere in the release, and the first one is where most failures will actually happen.

OrcaRouter does not host Hi3D v1.0 or any other 3D model, and it is not going to return a printable mesh from an API call. What it does host is the text and vision work around the pipeline: writing the object brief, captioning the reference photo, and judging multi-view renders for defects before you spend GPU time on a 1536³ pass. That is one endpoint for more than 200 models with automatic failover, which is useful when the surrounding checks are the part you do not want to build yourself. The 3D step stays on your own hardware.

Who should download it this week

If you already have a coarse-mesh generator in production — Hunyuan3D-2 mini, TripoSR, or an in-house stage — and your bottleneck is that the meshes look soft, Hi3D v1.0 is worth a day of GPU time. The 512³ path is the place to start; the 1536³ path needs the H20-class card the vendor used.

If your requirement is "one photograph in, printable part out," this release does not do that, and neither does the marketing around it. You still need the first stage, the repair stage and the slicer, and the 90% number does not transfer to your objects, your material, or your printer.

If you need texture, colour, or a client-facing render, wait for v3.0 or use something else. Geometry-only is a hard boundary, not a temporary gap.

What would change the verdict is narrow and specific: a named slicer, a published test set, a failure taxonomy and a baseline — ideally the unrefined coarse mesh, so a reader can see what the refinement actually bought. A memory and latency table at all three resolutions on more than one GPU would settle the hardware question. Until one of those exists, the honest description of Hi3D v1.0 is a strong, genuinely open geometry refiner with a production claim bolted on ahead of its evidence.