Hi3D v1.0 is open source: wat de 3D-printbewering eigenlijk vereist

Hi3D v1.0 verscheen op 23 oktober 2026 op GitHub en Hugging Face, met één getal eraan gekoppeld: 90% succes bij slicen. Dat getal is de hele reden waarom een 3D-printbedrijf zich voor deze release zou moeten interesseren, en het is tegelijk het enige getal dat de repository niet kan reproduceren. Er zit geen slicer in, geen testmeshes, geen baseline en geen definitie van wat als mislukking telt. Wat wel in de repo zit, is substantieel: inferencecode, acht weightbestanden en een pipeline die een referentiefoto plus een ruw mesh neemt en een veel dichter mesh teruggeeft, tot een effectief sparse-extraction-grid van 1536³. De nuttige vraag is dus niet of Hi3D v1.0 werkt. Het is wat eromheen waar moet zijn voordat er aan de andere kant een printbaar onderdeel uitkomt.

Wat er precies is uitgebracht

De release betreft het open source maken van Sparc3D — het Python-pakket en de openbare API dragen nog steeds de namen sparc3d en Sparc3DPipeline omwille van compatibiliteit, en de onderliggende paper dateert van mei 2025. De GitHub-repository opende met zes commits en één tag; de Hugging Face-kaart vermeldt dat het model op 23 oktober 2026 is uitgebracht en, in hetzelfde paneel, dat het “door geen enkele Inference Provider wordt gedeployed.” Er is geen gehost endpoint voor v1.0. Het commerciële product is een afzonderlijke, propriëtaire v3.0 met 2048³-geometrie en tot 8K-textures.

• Wat de repo bevat — inferentiecode, een demo, Docker- en afhankelijkheidsbeperkingen, en documentatie. Trainingscode, de evaluatieharnas uit het paper, benchmarksplitsingen en de vergelijkingsmeshes achter de hoofdtabel ontbreken allemaal, en de README zegt dat ronduit.

• Wat de gewichten zijn — acht runtime-bestanden: een modelindex, een schedulerconfiguratie, een VAE-configuratie en safetensors, en twee transformerconfiguraties en safetensors. De afbeeldingsencoders, facebook/dinov2-large en openai/clip-vit-large-patch14, worden afzonderlijk geladen bij het eerste gebruik en maken geen deel uit van de modelmap.

• Hoe je het installeert — Python 3.10, PyTorch 2.5.0 met CUDA 12.4, flash-attn==2.7.4.post1, spconv-cu120==2.3.6, geïnstalleerd vanaf de bron. Er is geen PyPI-wheel en geen voorgebouwde release.

• Welke licentie van toepassing is — de Hi3D Open License Agreement 1.0. Het is geen OSI-licentie. Commercieel gebruik is toegestaan, maar een product of dienst die 200.000 maandelijkse actieve gebruikers of USD 1.000.000 aan maandelijkse omzet overschrijdt, moet Hi3D binnen 60 dagen op de hoogte stellen en een aparte schriftelijke licentie aanvragen, en integraties moeten "Powered by Hi3D 1.0" weergeven met een link waar het medium dat ondersteunt.

De framing in de berichtgeving over de release is dat dit een image-to-3D-model van "industriële productiekwaliteit" is. De eigen aankondigingspagina van de leverancier beweert wel dat het model "gevalideerd is in echte productieworkflows" en dat de evaluatie meerbeeldige verschijning, lokale detail en geometrische bruikbaarheid omvatte. Er wordt geen enkele klant, workflow of gemeten output genoemd. Dat is een bewering over productie, geen bewijs ervan.

De printclaim, opgesplitst in vier vereisten

Een onderdeel dat uit een printer komt, moet aan vier dingen voldoen die niets te maken hebben met hoe indrukwekkend een render eruitziet. Hi3D v1.0 pakt er één goed aan, één gedeeltelijk en twee helemaal niet.

• Schaal — bewust weggelaten. De uitvoer wordt opnieuw gecentreerd en genormaliseerd naar een maximale straal van één eenheid. Absolute afmetingen en wereldcoördinaten blijven niet behouden, dus elk model moet naar millimeters worden herschaald voordat het iets betekent. Als je referentiefoto van een echt object kwam en je de werkelijke afmetingen nodig had, geeft Hi3D die niet door. De repo is hier expliciet over in plaats van stilzwijgend, wat lof verdient, maar het betekent dat schaal een stap is die je zelf moet doen.

• Topologie — overgenomen uit de invoer, niet gerepareerd. Hi3D neemt een grof mesh en voegt er detail aan toe. Als dat grove mesh niet-manifold randen, zelfdoorsnijdingen of geïnverteerde normalen heeft, maakt de verfijning ze fijner, niet correct. De eigen beperkingensectie van de README zegt "de grove structuur is van belang" en dat ernstige fouten in het grove mesh kunnen blijven bestaan. Een slicer loopt nog steeds vast op dezelfde defecten, alleen bij een hogere resolutie. Dit is de belangrijkste zin in de release voor iedereen die het op een printer richt.

• Oppervlak — afwezig. De output is een trimesh.Trimesh met alleen geometrie: geen texturen, geen materialen, geen vertexkleuren. Voor printen met één materiaal is dat meestal geen probleem, omdat je materiaal print in plaats van UV-maps. Voor alles wat een geschilderd of meerkleurig resultaat nodig heeft, of voor een klantpreview die er als het product uit moet zien, is het diskwalificerend en dwingt het je naar v3.0.

• Printbaarheid — niet beoordeeld. Niets in de repo meet wanddikte, minimale detailgrootte, overhangen, of het mesh na verfijning waterdicht is. Het cijfer van 90% slicing staat in het persbericht, niet in de code, en er wordt geen enkele slicer genoemd. Een gesliced bestand is bovendien nog geen geprint onderdeel: succesvol slicen zegt niets over of de print zal hechten, supports zal overleven of binnen tolerantie zal blijven.

De cijfers, gesorteerd op wat er daadwerkelijk achter zit

Het persbericht mengt beweringen met zeer verschillende niveaus van onderbouwing. Die op één hoop gooien is hoe een leverancierscijfer een feit wordt in een aankoopbeslissing.

• Ongeveer twee miljoen zorgvuldig geselecteerde 3D-assets — vermeld in het persbericht en op de modelkaart, en consistent met de Sparc3D-lijn, die in het eerdere artikel op ongeveer 500.000 assets werd beschreven. Je kunt de curatie niet controleren vanuit de repo, omdat zowel de dataset als de trainingscode niet wordt meegeleverd. Beschouw het als een geloofwaardig cijfer van de leverancier, niet als een geverifieerd cijfer.

• 1536³ effectieve resolutie — deze bestaat daadwerkelijk als configuratie. De pipeline voert één pass uit voor 512³, twee voor 1024³ en drie voor 1536³, standaard met 25 scheduler-updates per pass. Het woord "effectief" is belangrijk: dit zijn nominale sparse coördinaten- en extractieroosters, geen dichte 1536³ latente tensor. De README vermeldt ook dat de 1536³-instelling alleen is gevalideerd op een 96 GB H20 en dat haalbaarheid en piekgeheugen op kleinere kaarten niet worden vermeld.

• 90% slicing-succes — door de leverancier gerapporteerd, niet gereproduceerd en zonder methodologie. Geen slicer, geen definitie van falen, geen baseline, geen testset. Het is het meest citeerbare getal in de release en het minst controleerbare.

• Hoogste getrouwheid en rijkdom aan details bij meerdere weergaven — gepresenteerd als het resultaat van "de gerapporteerde evaluatie", die niet in de repository staat. Er is geen vergelijkingstabel, geen lijst met concurrenten en geen uitsplitsing per categorie.

• "Gevalideerd in echte productieworkflows" — een zin op de aankondigingspagina, zonder genoemde partner, zonder case study en zonder beschreven workflow. Het kan best waar zijn. Het is nog geen bewijs.

De hardwaremuur

De gemeten stack is een NVIDIA H20 van 96 GB, en de repo geeft eerlijk toe dat dit de machine is waarop de hoogste instelling is gevalideerd. De omliggende vereisten zijn even specifiek: Linux, compute capability 8.0 of nieuwer, CUDA 12.0 tot en met 12.5, en helemaal geen CPU-inferentiepad. flash-attn heeft geen fallback-implementatie voor attention, dus een buildfout daar is fataal in plaats van een verslechterde werking. De batchgrootte is één.

Sequentiële CPU-offload wordt ondersteund en vermindert de GPU-residentie, maar de README zegt zorgvuldig dat er daarmee geen minimale GPU-geheugenvereiste wordt vastgesteld en dat de kosten van gedecodeerde features niet verdwijnen. In de praktijk betekent dat dat het 512³ one-pass-pad misschien op een kaart met 24 GB past, maar dat niemand een geheugentabel heeft gepubliceerd en de leverancier dit niet heeft beweerd. Als je plan afhangt van een 4090, draai je een niet-geverifieerde configuratie en moet je zelf timen en meten voordat je je vastlegt.

Hoe een werkende printpipeline eruitziet

Hi3D v1.0 is één fase. De repo wordt geleverd met een optionele adapter die Tencent's Hunyuan3D-2 mini gebruikt om de grove mesh uit één enkele afbeelding te produceren; Hunyuan is van derden en geen afhankelijkheid van de kernbibliotheek, maar zonder zoiets heb je geen invoer.

De werkelijke volgorde is dus: een grof mesh genereren of verkrijgen, dit verfijnen met Hi3D op 512³, 1024³ of 1536³, de geometrie exporteren, deze terugschalen naar werkelijke afmetingen, herstellen wat er in de grove fase aan topologie mis is gegaan, de waterdichtheid verifiëren en vervolgens slicen. Drie van die stappen — reparatie, waterdichtheid en slicen — hebben nergens in de release een equivalent, en juist bij de eerste zullen de meeste fouten zich in de praktijk voordoen.

OrcaRouter host geen Hi3D v1.0 of enig ander 3D-model, en zal geen printbaar mesh retourneren uit een API-aanroep. Wat het wel biedt, is het tekst- en visionwerk rond de pipeline: het opstellen van de objectbrief, het genereren van een bijschrift voor de referentiefoto, en het beoordelen van multi-view renders op defecten voordat je GPU-tijd besteedt aan een 1536³-pass. Dat is één endpoint voor meer dan 200 modellen met automatische failover, wat handig is wanneer de omringende controles het onderdeel zijn dat je liever niet zelf bouwt. De 3D-stap blijft op je eigen hardware.

Wie zou het deze week moeten downloaden?

Als je al een generator voor grove meshes in productie hebt — Hunyuan3D-2 mini, TripoSR of een eigen stage — en je knelpunt is dat de meshes zacht ogen, dan is Hi3D v1.0 een dag GPU-tijd waard. Het 512³-pad is de plek om te beginnen; het 1536³-pad vereist de kaart uit de H20-klasse die de leverancier gebruikte.

Als je eis is "één foto erin, printbaar onderdeel eruit", dan doet deze release dat niet, en de marketing eromheen ook niet. Je hebt nog steeds de eerste fase, de reparatiefase en de slicer nodig, en dat getal van 90% geldt niet voor jouw objecten, jouw materiaal of jouw printer.

Als je textuur, kleur of een render voor de klant nodig hebt, wacht dan op v3.0 of gebruik iets anders. Alleen geometrie is een harde grens, geen tijdelijke lacune.

Wat het oordeel zou veranderen, is smal en specifiek: een bij naam genoemde slicer, een gepubliceerde testset, een taxonomie van fouten en een baseline — idealiter het onbewerkte grove mesh, zodat een lezer kan zien wat de verfijning daadwerkelijk heeft opgeleverd. Een tabel met geheugengebruik en latency bij alle drie de resoluties op meer dan één GPU zou de hardwarekwestie beslechten. Totdat een van die dingen bestaat, is de eerlijke beschrijving van Hi3D v1.0 een sterke, oprecht open geometrische refiner met een productieclaim die erop is vastgeschroefd voordat het bewijs ervoor bestaat.