Hi3D V1.0 vs ABot-Earth 0.7: Den ena skärper ett objekt, den andra genererar en stad

Fråga vad som kommer ut i andra änden, så försvinner förvirringen. Hi3D V1.0 returnerar ett enda mesh: ett objekt, omcentrerat till enhetsradie, endast geometri, ingen textur. ABot-Earth 0.7 returnerar en kilometer stad som en 3D Gaussian-splatting-scen, med vägar, kvarter och landmärken i en konsekvent rumslig referensram. Båda släpptes av kinesiska leverantörer under de senaste sex veckorna. Båda hamnar under "3D-modell" i samma nyhetscykel. Ingen av dem är en ersättning för den andra, och den användbara jämförelsen är inte vilken som är bättre — utan vilken leverans din pipeline faktiskt kan ta emot.

Två artefakter, inte två konkurrenter

Hi3D V1.0 är en förfiningsmodell från Hi3D, släppt den 23 oktober 2026 som öppen källkods-efterföljare till Sparc3D. Den tar en referensbild och ett grovt mesh av samma objekt och lägger till geometrisk detalj, i upp till tre pass, vid efterfrågade upplösningar på 512³, 1024³ eller 1536³. Koden och vikterna går att ladda ner; licensen tillåter kommersiell användning med en skala-utlösare; den uppmätta konfigurationen är en 96 GB H20; och det finns ingen hostad inferensslutpunkt.

ABot-Earth 0.7 är en 3D-native urban världsmodell från Amap, Alibabas kart- och navigationsarm, som avtäcktes den 10 september 2026 vid evenemanget Street Stars i Hangzhou. Den tar emot en georefererad satellitbild eller en textprompt och genererar en utforskningsbar stadsscen i 3D Gaussian Splatting-format. Amap uppger att en scen på kilometerskala tar cirka tio minuter på en konsumentklassad GPU, att täckningen omfattar fler än 196 länder och regioner och att resultatet kan exporteras till Unreal Engine och Unity. Det är leverantörens siffror. Inga vikter, modellkort, publika API:er eller priser har publicerats, och genereringen på upplevelsewebbplatsen beskrivs som endast på inbjudan.

Ställ de två styckena sida vid sida och jämförelsen gör redan något mer användbart än ett specifikationsblad: den skiljer ett verktyg från en produktdemonstration.

Indata är den första asymmetrin

{{1}}ABot-Earth 0.7{{/1}} är end-to-end på ingångssidan. {{2}}En satellitbild eller en textprompt matas in; en scen kommer ut.{{/2}} Du anger ingen geometri, och {{3}}Amap{{/3}} ber dig inte göra det.

Hi3D V1.0 är ett andra steg. Det behöver ett grovt mesh innan det kan göra någonting. Repositoriet levereras med en valfri demoadapter som genererar ett med Tencent's Hunyuan3D-2 mini, men kärnraffinemangsskriptet importerar inte Hunyuan och accepterar vilket grovt mesh som helst som du redan har. Den designen är avsiktlig – den låter modellen placeras bakom vilken generator du än använder – men det innebär att den ärliga beskrivningen av Hi3D är "en upscaler för geometri", inte "en bild-till-3D-modell", även om Hugging Face-taggarna inkluderar image-to-3D.

Det här är det första stället en köpare bör stanna vid. Om ditt arbetsflöde är "en bild in, en tillgång ut" ger Hi3D ensamt inte det. Om ditt arbetsflöde redan har ett grovt mesh och en referensrendering — vilket de flesta asset-pipelines har — är Hi3D inriktat exakt på gapet mellan de två.

Sex dimensioner som avgör köpet

• Utdataenhet — Hi3D V1.0 ett objekt vs ABot-Earth 0.7 en stadsscen i kilometerskala

• Format — Hi3D V1.0 enbart geometri, ett trimeshnät, exporterbart som GLB jämfört med ABot-Earth 0.7 3D Gaussian Splatting, med påstådd export till Unreal Engine och Unity

• Ytutseende — Hi3D V1.0 utan textur, material eller vertexfärg jämfört med ABot-Earth 0.7 texturerad scenutdata, enligt Amap

• Indata — Hi3D V1.0 en referensbild plus ett grovt mesh kontra ABot-Earth 0.7 en satellitbild eller en textprompt

• Beräkning — Hi3D V1.0 uppmätt på en NVIDIA H20 med 96 GB, ingen CPU-väg, jämfört med ABot-Earth 0.7 cirka tio minuter per kvadratkilometer på en konsumentklassad GPU, enligt leverantören

• Åtkomst — Hi3D V1.0-kod och -vikter nedladdningsbara idag under en anpassad kommersiell licens jämfört med ABot-Earth 0.7: inga vikter, inget API, ingen prissättning, beta endast på inbjudan

En splat är inte ett mesh

Det här är den del som de flesta jämförelser missar, och det är inte en teknisk detalj. En Gaussian-splat-scen är en samling orienterade, färgade blobbar som renderas vackert och inte har någon explicit yta. Ett mesh är en sammanhängande uppsättning trianglar med en gräns. De två är bra på olika saker.

Splats renderas. De kan betraktas från nya vinklar, streamas med detaljnivå och läggas in i en realtidsmotor. De är ett dåligt underlag för en slicer, en CAD-kärna, ett kollisionsnät eller en riggningspipeline, eftersom dessa verktyg vill ha en yta och en vattentät volym. ABot-Earths utdata ligger på renderingssidan av den gränsen. Amaps påstående om kompatibilitet med Unreal och Unity anger inte om exporten är en splat-resurs, ett mesh eller båda, och det finns ingen offentlig formatdokumentation att kontrollera mot. Det är inte en brist i modellen; det är en fråga en köpare måste ställa innan den bygger en pipeline kring den.

Hi3D:s utdata ligger på ytsidan. Ett trimesh-nät kan exporteras, skivas, bearbetas med booleska operationer och mätas. Men förvaret normaliserar det till en maximal radie på 1, kastar bort världskoordinater och lägger inte till någon textur. För 3D-utskrift är det en användbar utgångspunkt efter en omskalning. För e-handel eller en spelresurs är det en halv leverabel: den andra halvan är ett textureringssteg som Hi3D inte utför.

Så formatraden är inte "mesh kontra splat, och mesh vinner". Det är "artefakten du kan efterbehandla kontra artefakten du kan titta på". Välj den som ditt nästa verktyg accepterar.

Beräkning och åtkomst, vilket är där jämförelsen blir ojämn.

Hi3D är dyrt per objekt och billigt per experiment. Den uppmätta konfigurationen är en 96 GB H20, och README säger att hela 1536³-stegen bara har validerats där. Batchstorleken är ett. Det finns ingen CPU-väg, och flash-attn har ingen fallback. En begäran på 512³ körs i ett pass med 25 scheduleruppdateringar; 1536³ körs i tre. Repositoriet publicerar inga mätningar av väggklockstid, så du kan inte budgetera en produktionslinje utifrån kortet. Det du kan göra är att ladda ner det i dag, köra det på hårdvara du redan har och mäta.

ABot-Earth 0.7 är billigt per scen på papperet och otillgängligt i praktiken. Tio minuter per kvadratkilometer på en konsument-GPU är ett slående påstående – Amap säger också upp till 1 000× snabbare och ungefär en hundradel av kostnaden för traditionell rekonstruktion – men vart och ett av dessa siffror kommer från Amap och ingen av dem har oberoende reproducerats. Än mer relevant: det finns inget sätt för ett utomstående team att reproducera dem: inga vikter, inget modellkort, inget API, ingen prissättning, ingen utvecklardokumentation. Upplevelsesajten är live, gränssnittet är endast på förenklad kinesiska och genereringen är vitlistad. Du jämför en nedladdningsbar modell med en presscykel.

Den asymmetrin avgör kvartalet även om ABots tekniska påståenden är helt sanna. Ett team som behöver urban 3D den här månaden kan inte anskaffa ABot-Earth 0.7. Ett team som behöver objektgeometri den här månaden kan installera Hi3D V1.0 och ta reda på vad den gör.

Vad ett team faktiskt skulle göra med båda

Det finns en verklig komposition, och den är värd att formuleras exakt eftersom det är lätt att överdriva. En stadsseen behöver en miljö och den behöver rekvisita. ABot-Earth 0.7 skulle, om det vore tillgängligt, tillhandahålla miljön: terräng, kvarter, byggnadsvolymer och gatunät. Hi3D V1.0 tillhandahåller en bättre version av en enskild rekvisita, givet ett grovt mesh och en referensbild. Sätt samman de två i en motor och du har en scen med detaljerade tillgångar i en genererad stad.

Skarven är inte gratis. ABots scen är en splat-representation med ett eget koordinatsystem; Hi3D:s mesh är normaliserad till enhetsradie och har ingen absolut skala. Att placera en förfinad prop på rätt plats, i rätt storlek, i en splat-scen kräver en transform och en skalkonvention som ingen av leverantörerna publicerar. Ingen har skrivit ner den integrationen. Det är sådant arbete som en studio gör på en vecka och behåller för sig själv.

För de flesta team är den mer realistiska uppdelningen enklare: använd ABot-Earth 0.7 som bevis på vad Amaps rumsliga och tidsmässiga data kan åstadkomma, inte som ett beroende, och använd Hi3D V1.0 där ni redan äger grovmaskstadiet.

Ingen av sidorna visar räkningen.

Ingen av modellerna tillhandahålls av OrcaRouter. Katalogen omfattar text-, bild-, video-, inbäddnings- och talmodeller, inte 3D-geometri, och den här artikeln tänker inte låtsas något annat. Det båda pipelinearna däremot använder är anrop till språk- och bildmodeller: att expandera en textprompt till en användbar scenbeskrivning, skriva bildtexter till referensrenderingar, kontrollera om en utdata matchar briefen och skriva metadata som gör en tillgång hittbar.

Det är det lager som OrcaRouter täcker. Fler än 200 modeller ligger bakom ett enda API, leverantörens listpris förs vidare med 0 % påslag, och automatisk redundansväxling hindrar en försämrad leverantör från att stoppa en batch mitt i. För en studio som kör hundratals tillgångsjobb handlar skillnaden mellan en nyckel och fem inte om elegans; den handlar om hur många ställen ett jobb kan misslyckas på.

Beslutet, utan förbehållen

Om det du behöver överlämna till någon är ett utskrivbart eller redigerbart objekt är Hi3D V1.0 det enda av dessa två som du kan installera, och det enda med en licens som omfattar kommersiell användning. Räkna med den grova mesh som kommer uppströms, 96 GB-kortet och ett textureringssteg. Om det du behöver är en stad att promenera i är ABot-Earth 0.7 det mer intressanta systemet och det mindre tillgängliga; behandla det som ett riktmärke för vad ett kartföretag med goda resurser kan generera, inte som en komponent du kan planera in.

Jämförelsen ser bara konstig ut om du antar att "3D-modell" är en kategori. Den är åtminstone två: geometri du kan tillverka, och miljöer du kan befinna dig i. Hi3D och ABot-Earth befinner sig på motsatta sidor av den gränsen, vilket är anledningen till att det ärliga svaret på "vilken är bättre" är en annan fråga — vad accepterar ditt nästa verktyg?