OpenSCAD vs CadQuery vs Build123d: kateri CAD pogon zna AI zares napisati?

GrandpaCAD spremeni klepetalno sporočilo v 3D-natisljiv model. AI napiše CAD kodo, mi jo prevedemo, ti dobiš mrežo. Zato je največji vzvod, ki ga imam, izbira, v katerem CAD jeziku AI piše. Izberi napačnega in model porabi svoj proračun za boj s sintakso namesto za gradnjo tvojega dela.

Vsakič, ko objavim o tem, mi nekaj ljudi na Hacker News pove isto: OpenSCAD je igrača, ne zmore prave CAD, in raje bi moral uporabljati pravo parametrično jedro, kot je CadQuery ali Build123d. Deloma imajo prav, jedra so res zmogljivejša. Zato sem namesto prepiranja izvedel eksperiment. Če si pristal tukaj, ker si mi rekel, naj zamenjam, tole je moj odgovor.

Prej sem pisal o tem, zakaj smo se odločili za OpenSCAD, potem ko sem začel s shemo JSON, nato JSCAD, nato Blender. To je nadaljevanje. Vrnil sem se in preizkusil dva "resna" parametrična CAD pogona, ki sem ju preskočil, CadQuery in Build123d, enega za drugim, na isti zbirki evalvacij. Tole so povedale številke.

Če želiš metodologijo za temi izvajanji (kako ocenjujem, uteževam in arhiviram), je to ločena objava: kako testiramo agenta za modeliranje.

Dve družini CAD kode

Sta res dva tabora.

OpenSCAD je deklarativen in zgrajen na konstruktivni geometriji trdnin (CSG). Opišeš oblike in jih združuješ z unijo, razliko in presekom. Jezik je majhen, zato ni veliko površine, na kateri bi se model lahko zmotil.

CadQuery in Build123d sta knjižnici Python, ki ovijata OpenCASCADE, isto jedro B-rep (predstavitev z robovi), ki je pod FreeCAD in veliko komercialne CAD. B-rep je "pravi" CAD pristop: natančne ukrivljene površine ter pravi zaobljitve in posnetja, ki prelomijo rob namesto da bi napihnili celoten del. Na papirju sta zmogljivejša od OpenSCAD, in to je Python, ki ga vsak model piše tekoče.

Moje pričakovanje ob vstopu je bilo torej, da bosta zmagala pogona B-rep Python. Nista.

Kaj sem meril

Vsak pogon je pognal isti nabor promptov skozi isti harness na istem sloju modela (gemini-3.5-flash, poceni delovni konj, ki sem ga takrat primerjal), tako da je edina spremenljivka CAD jezik. Skrbijo me tri stvari:

• Napake v kodi na generacijo: kako pogosto AI napiše kodo, ki se ne prevede ali med izvajanjem sproži napako.
• Neuspeli modeli: generacije, ki nikoli niso ustvarile uporabne mreže.
• Strošek in dejanski čas, kot razsodba ob izenačenju.

Napake v kodi so pošten signal. Moj harness jih samodejno popravi, tako da uporabnik redko vidi neuspeh, a vsak popravek je še en klic modela, kar pomeni več latence in več stroška. Visoka stopnja napak v kodi je AI, ki ti tiho pove, da jezika v resnici ne pozna.

Na istem modelu in istih scenarijih se je OpenSCAD ustavil pri okoli 0,4 napake v kodi na generacijo (10 v izvajanju s 23 modeli). Build123d, ki piše Python, ki naj bi bil za model lažji, je na istem izvajanju brez pomoči prišel do 40 napak v kodi, in 33 s pomočjo, kar je približno tri- do štirikrat več od OpenSCAD. To je tri- do štirikrat več popravljalnih zank za isto delo.

CadQuery je bilo že samo za meritev bolj zapleteno. Moja prva izvajanja niso padla na sintaksi, padla so na izvozu. Vgrajeni pisalnik 3MF v CadQuery obvlada samo mrežo in izgubi barve delov, zato sem moral ročno napisati izvoznik barvnega 3MF, preden so večdelni modeli prišli ven celi. Pred tem popravkom je do polovice scenarijev v izvajanju povsem odpovedalo. Ko je vodovod deloval, so neuspehi upadli, a osnovni vzorec se je ujemal z Build123d: model je še naprej segal po metodah, ki ne obstajajo.

Zakaj je AI slabši pri "boljših" pogonih

To me je sprva presenetilo, potem je postalo smiselno. Prav tisto, kar dela CadQuery in Build123d zmogljiva, je tudi tisto, ob čemer se model spotakne: obsežen, tekoč, veriženja zmožen API s stotinami metod in strogimi pričakovanji o tem, kaj vrne ploskev proti robu proti žici. Trenutni modeli ga niso videli dovolj. Samozavestno kličejo metodo z napačnim imenom, napačnim vrstnim redom argumentov ali na napačnem tipu objekta. Bere se kot verjeten Python in se potem ne požene.

OpenSCAD ima nasprotni profil. Jezik je majhen in stabilen, in modeli veliko pogosteje pravilno zadenejo njegovo deklarativno obliko. Ko že spodrsne, ena sama sintaksna popravljalna prehod običajno popravi.

Sem pa poskusil zapreti vrzel. Za Build123d sem generiral referenco API z natančnimi podpisi neposredno iz knjižnice (introspekcijsko, ne ročno) in jo dal modelu. Merljivo je pomagalo: napake v kodi na celotnem izvajanju so padle s 40 na 33. A 33 je še vedno precej nad tem, kjer je OpenSCAD. Referenčni list vrzel zoži, ne izbriše je.

Načrt: OpenSCAD zdaj, B-rep pozneje

Nič od tega ne pomeni, da sta CadQuery ali Build123d slaba. Sta boljša pogona. Jedro je zmogljivejše in geometrija natančnejša, in tisti dan, ko jih bo model pisal tako zanesljivo kot piše OpenSCAD, bo GrandpaCAD preklopil. Prav to, da jih poganjam kot evalvacije, mi omogoča, da zamenjam pogon v trenutku, ko tabla rezultatov reče, da je čas.

Za zdaj je odgovor dolgočasen in pravilen: OpenSCAD je tisto, kar trenutni modeli pišejo dovolj dobro, da gre v izdajo. CadQuery in Build123d ohranjam priklopljena in izbirljiva v harnessu, da lahko ta pregled ponovim vsakič, ko pride močnejši model, in pustim, da odločajo številke namesto hrupa.

Torej vsem, ki mi pravite, naj uporabim pravo CAD jedro: prav imate, zmogljivejše je, in res sem ga preizkusil. Ozko grlo danes ni jedro, ampak to, kar model lahko napiše brez lomljenja. Ko se to spremeni, se bo spremenila tudi privzeta izbira.

Bi rad videl, kaj pogon proizvede? Preizkusi pogon OpenSCAD.