Hi3D V1.0 Went Open Source Today. What the Repo Proves, and What It Doesn't

On 23 October 2026, a GitHub repository called hi3d-official/Hi3Dv1.0 appeared with six commits, one tag, and a release note reading "Release Hi3D v1.0 inference code and documentation." The same day, eight runtime files landed on Hugging Face, and Hi3D V1.0 — the model formerly known as Sparc3D — became downloadable and commercially usable. The announcement, such as it was, came as a wire release under the headline "Hi3D V1.0 Goes Open Source: The First Production-Validated Open-Source AI 3D Model." What did not go out was a benchmark table. There is no number in the repository that tells you how much better this model is than the coarse mesh it refines, and no third party has published one yet. That gap is the story.

Six commits and eight files

The repository is small enough to read in an afternoon, which is the first useful fact about it. It contains inference code, a demo, Docker constraints, documentation and the sparc3d Python package. It does not contain training code, the evaluation harness, benchmark splits or the comparison meshes behind the press release's charts. The authors say so directly in the README: this is an inference release, not a reproduction package.

The weights are eight files: a model index, a scheduler config, a VAE config and model.safetensors, plus transformer_512 and transformer_1024 configs and weights. The loader reads JSON and safetensors and does not execute model-repository Python or unpickle checkpoints, which is the safer pattern and worth noting for anyone who has to clear a supply chain. Two conditioning encoders — facebook/dinov2-large and openai/clip-vit-large-patch14 — are separate downloads and carry their own licences.

No parameter count is published. Not in the README, not on the model card, not in the press release. You can infer the scale from the file sizes if you download them, but the vendor has not put a number on it, and this article will not invent one.

What the pipeline does with your image

Hi3D V1.0 is not an image-to-3D generator in the sense most people mean. It is a refinement stage. You give it a reference image of an object and a coarse mesh of the same object, and it returns a higher-resolution mesh. The image conditions a sparse flow defined on coordinates taken from the coarse mesh; the pipeline samples sparse latents, decodes them through a self-pruning sparse VAE, extracts a surface, then revoxelises that surface to support the next pass.

There are three passes, and the resolution you ask for decides how many run:

• 512³ — one pass, 64³ structural grid, 512³ sparse extraction, transformer_512

• 1024³ — two passes, adding a 128³ structural grid, 1024³ extraction, transformer_1024

• 1536³ — three passes, adding a 192³ structural grid, 1536³ extraction, transformer_1024

Each pass runs 25 scheduler updates by default. The README is careful about what "1536³" means: it is a nominal sparse coordinate and extraction grid, not a dense 1536³ latent tensor and not a fixed triangle count. That distinction matters because the press release says "effective sparse-grid resolution of up to 1536³," which is accurate but easy to read as something denser than it is.

The output is a trimesh.Trimesh and the achieved resolution. It is recentred and normalised to unit maximum radius, so the original world coordinates and absolute scale are gone. Batch size is one. There are no textures, materials or vertex colours. If your next step needs a real-world dimension — a print bed, a CAD assembly, a collision hull — you are re-scaling and re-orienting by hand.

The 90% number has no denominator

The press release makes four quantitative claims. Training data grew from roughly 500,000 to two million curated 3D assets. Geometry reaches an effective 1536³ sparse grid. The model reports a 90% slicing success rate. And it claims "the highest multi-view fidelity and detail richness scores in the reported evaluation."

Only the first two are visible in the repository. The two million figure appears on the model card as a project-report claim; the 1536³ figure is real in the sense that the pipeline accepts the request and the configs exist. The 90% slicing number appears nowhere in the repo. There is no definition of what was sliced, which slicer was used, what the failure modes were, or what the baseline was. "Highest multi-view fidelity" comes with no scores, no comparison set and no methodology in the public material. Those are vendor-reported figures, and the honest reading is that they are unverified, not that they are wrong.

The absence of an evaluation harness is the reason this matters. A reader cannot take the repository, run the reported comparison, and check the result. Independent replication would have to start by rebuilding the benchmark, which is a different project. That is not unusual for an inference-only release, but it does mean the first serious review of this model will come from someone with a print farm or an asset pipeline, not from a leaderboard.

The repo is more honest than the release

Read the limitations section and a more useful picture emerges than the headline gives. These are the vendor's own words, paraphrased:

• Geometry only. No textures, materials or vertex colours, and batch size is one.

• A coarse mesh is mandatory. The model refines structure; it does not invent a first surface from an image.

• Coarse-mesh errors persist. If the input silhouette is wrong, the refinement can make a wrong shape sharper.

• Geometry hidden from the reference image is completed plausibly, not reconstructed exactly. That is fine for a hero asset and bad for a measurement.

• Absolute scale and world coordinates are discarded by the normalisation step.

• Seeds are not mesh hashes. GPU sparse convolution and attention are not bitwise deterministic, so the same seed can produce a different mesh.

• The full 1536³ ladder has only been validated on a 96 GB NVIDIA H20. Memory use and feasibility on smaller cards are explicitly not established.

• There is no CPU inference path, and flash-attn has no fallback attention implementation.

• If the requested resolution cannot be reached, the pipeline raises an error rather than silently returning something lower.

• The README says nominal resolution and geometric detail do not guarantee suitability for a downstream application. That is the most important line in the document.

Open source, with a growth clause

The licence is called the Hi3D Open License Agreement Version 1.0. It is not MIT, Apache-2.0 or any OSI-approved text, and the official page does not name a licence at all, so the repository is the authoritative source. Commercial use is permitted. The conditions are the interesting part.

If a related product or service exceeds 200,000 monthly active users or USD 1,000,000 in monthly revenue, the licensee must notify Hi3D and apply for a separate written licence within 60 days. Commercial integrations must display "Powered by Hi3D 1.0" and link to the official site where supported. Standalone outputs that contain no Hi3D materials or derivatives do not by themselves trigger the branding, distribution or scale-licence obligations. Existing Apache-2.0 and MIT terms remain in force for the original and third-party portions they cover, and DINOv2, CLIP, Hunyuan and other components keep their own terms.

For a hobbyist or an agency making assets, that is close to unrestricted. For a SaaS that puts refinement behind an endpoint, it is a licence with a tripwire at a specific size, plus an attribution requirement. The 200,000-MAU line is not enormous for a consumer design tool. Anyone planning to build one should read the agreement before the integration, not after the growth curve.

What it takes to run

This is a Linux-only, source-install release. Python 3.10, an NVIDIA GPU with compute capability 8.0 or newer, and a CUDA toolkit between 12.0 and 12.5 that matches the installed PyTorch. The measured configuration in the README is Python 3.10.12, PyTorch 2.5.0 with CUDA 12.4, and a 96 GB H20. Installation pulls flash-attn 2.7.4.post1 with build isolation disabled, spconv-cu120 and a pinned constraints file. There is no PyPI wheel and no prebuilt project package.

Offline use needs local copies of the refinement weights, DINOv2 and CLIP. The optional demo adapter for generating a coarse mesh uses Tencent's Hunyuan3D-2 mini, which must be obtained separately and keeps its own licence. The core refinement script does not import Hunyuan and will accept any coarse mesh you supply, which is the more useful mode for a production pipeline that already has a generator.

Two practical warnings sit inside the install instructions. flash-attn must be built after PyTorch, and there is no fallback if it fails. Memory offload is available but does not guarantee a minimum GPU footprint, and it cannot be combined with a plain .to("cuda"). If you were hoping to run this on a 24 GB workstation card, the repository does not claim you can, and the one measured configuration is four times that.

What is not in the box

There is no hosted API for Hi3D V1.0. The Hugging Face card says the model "isn't deployed by any Inference Provider," and the official site's download button points at local deployment. The free demo Space linked from the vendor page is a trial, not an endpoint with a rate card. The company's commercial product is a different model: Hi3D v3.0, which the site describes as 2048³ voxel-level geometry with up to 8K textures and access through the online workspace. v1.0 is the open one; v3.0 is the one the company sells.

The absence of a hosted endpoint is not a criticism. It is a deployment fact that changes who can use the model this month: a team with a 96 GB GPU and a Linux box can; a team that wants to send an image to an API cannot, unless it builds the service itself or waits for someone else to.

Where a router fits, and where it does not

OrcaRouter does not serve Hi3D V1.0, and it does not serve 3D models at all. The catalogue is text, vision, video, embedding and speech models. Nothing in this article should be read as a claim that you can call a mesh generator through our endpoint.

The layer around a refinement pipeline is a different matter. The obvious quality check for an image-conditioned mesh is visual: render the result from three or four angles and ask a vision model whether the silhouette, the local detail and the multi-view consistency match the reference. That is an LLM-shaped call, and it is the kind of call that benefits from being able to try several models without three contracts. OrcaRouter puts more than 200 models behind one API at 0% markup, with automatic failover when a provider degrades, and its model-fusion mode lets a panel of models answer the same inspection together rather than betting the QA gate on one. The 3D work stays local; the judgement around it does not have to be bespoke.

What would change this assessment

Three things, in order of usefulness. A print test with a named slicer, a stated failure criterion and a baseline would turn the 90% claim into a number a buyer can use. A latency and memory table at 512³, 1024³ and 1536³ on more than one GPU would tell teams whether the 96 GB requirement is a validation artefact or a hard floor. And an independent comparison against the coarse mesh it started from would answer the only question that matters for a refinement model: how much detail does the second stage actually add, and at what cost in artefacts?

Until then, the defensible summary is narrow and useful. Hi3D V1.0 is a real, downloadable, commercially usable refinement model with an unusually candid limitations section, a licence that scales with your business, and no published evidence beyond its authors' own. For a team that already generates coarse meshes and owns the GPU, that is enough to run an experiment this week. For everyone else, it is a promising release with the receipts still to come.