- Der OpenSCAD-Pantheon-Benchmark prüft, ob AI-Coding-Tools allein mit zwei Referenzbildern und einem kurzen Prompt ein Bauwerk als parametrischen CAD-Code umsetzen können
- Google Antigravity 2.0 / Gemini 3.5 Flash High erhielt mit 4,5/5 die höchste Qualitätswertung und setzte sogar reale Pantheon-Maße, die Inschrift und das innere Kassettendeckenmuster um
- Codex 5.5 High hatte die höchste Detaildichte, verlor aber Punkte wegen einer Abweichung zwischen PNG-Vorschau und finalem STL; Sonnet erzeugte das sauberste Modell unter den bisherigen autonomen Läufen
- Cursor war am schnellsten, lieferte aber die schwächste Qualität; ModelRift/Gemini Flash 3.0 erreichte mit einem Human-in-the-Loop-Ansatz inklusive visuellen Feedbacks 3,8/5
- Alle Systeme führten das Rendern über die OpenSCAD-CLI aus, aber der Engpass war nicht der Tool-Zugriff, sondern die geometrische Beurteilung und die Validierung des finalen Meshes
Ziel und Aufgabenstellung des Benchmarks
- ModelRift erzeugt für alle 3D-Modelle OpenSCAD-Code, daher ist die Fähigkeit eines LLM zur Verarbeitung räumlicher Geometrie direkt mit der tatsächlichen Modellqualität verknüpft
- Dieser Test war ein kleiner praxisnaher Benchmark, bei dem mehrere AI-Coding-Tools dieselbe Aufgabe bekamen: das Pantheon anhand von Referenzbildern und einem kurzen Prompt in OpenSCAD umzusetzen
- Ziel war es, die Fähigkeit zu prüfen, architektonische Referenzen in parametrischen CAD-Code zu überführen, PNG-Vorschauen per OpenSCAD-CLI zu rendern und das Ergebnis iterativ zu verbessern
- Der Prompt verlangte, Rotunde, Kuppel, Portikus, Säulen, gestuftes Podium, Dreiecksgiebel und Frontdetails des Pantheon einzubeziehen
see two ref images and build .scad file with openscad implementation of pantheon. use openscad CLI (available) to preview your work (by rendering openscad model to .png) and iterate until you are happy with the result.
Warum Pantheon und OpenSCAD gewählt wurden
- Das Pantheon ist eine Aufgabe, die über einen simplen Test von
difference(),cube()undcylinder()hinausgeht, zugleich aber keine organische Skulptur oder charakterartige Geometrie ist, mit der sich OpenSCAD schwertut - Die Hauptstruktur besteht aus kreisförmiger Rotunde und Kuppel, zentralem Oculus, linearem Portikus, Säulen, gestuftem Sockel und Dreiecksgiebel, was den Vergleich der Ergebnisse erleichtert
- Selbst schwächere Resultate können wie ein Gebäude mit Kuppel aussehen, doch gute Resultate müssen die Beziehung zwischen runder Trommel, rechteckigem Portikus, Kuppelringen und Frontfassade genauer treffen
- OpenSCAD eignet sich, weil Modelle dort Plaintext-Code sind und der Sprachumfang klein ist, was es zu einem guten Ziel für LLM-generierte Geometrie macht
- Anweisungen wie „28 Säulen um einen Radius herum wiederholen“ oder „den Oculus aus der Kuppel subtrahieren“ lassen sich direkt im Quellcode ausdrücken
- Ergebnisse sind prüfbar, reproduzierbar und leicht zu ändern; selbst Fehler bei den Säulenabständen lassen sich durch Anpassung von Parametern oder Schleifen beheben statt durch verborgene Szenenzustände
- Der Hintergrund, warum ModelRift auf OpenSCAD aufbaut, wird in Why we built ModelRift on OpenSCAD erläutert
- Nachteilig ist, dass OpenSCAD kein Sculpting-Tool ist, sondern am besten für konstruierte, parametrische und Hard-Surface-Objekte passt
Gesamtergebnisse
- Die Punktzahlen sind relative Bewertungen innerhalb dieses Benchmarks und keine allgemeine Modellrangliste
- Die Zeitbewertung spiegelt nicht den Veröffentlichungszeitpunkt eines Projekts wider, sondern die beobachtete Umsetzungszeit
- Die Qualitätsbewertungen wurden konservativ vergeben; selbst das beste Ergebnis kommt keinem perfekten Pantheon-Modell nahe
- Ergebnisse nach Tool und Modell:
- Cursor 3.5 / Composer 2.5: Zeit 5/5, Qualität 1,4/5. Am schnellsten, aber auch am schwächsten; außer den großen Formen von Kuppel und Portikus fehlten Proportionen, Materialsteuerung und architektonische Details
- Codex 5.5 High: Zeit 4/5, Qualität 3,0/5. Hohe Detaildichte bis hin zur Inschrift im Entablature, aber Punktabzug, weil das finale STL von der PNG-Vorschau abwich
- Claude Code 2.1 / Opus 4.7: Zeit 2/5, Qualität 3,0/5. Klarere Struktur, Portikus und gestufter Sockel als bei Cursor, aber farblich zu einheitlich und weniger überzeugend als die stärkeren Resultate
- Claude Code 2.1 / Sonnet 4.6: Zeit 1/5, Qualität 3,4/5. Der plausibelste Gesamteindruck und ausgewogene Proportionen unter den bisherigen autonomen Läufen, aber die längste Umsetzungszeit
- Google Antigravity 2.0 / Gemini 3.5 Flash High: Zeit 1/5, Qualität 4,5/5. Verwendete reale Pantheon-Maße und die Inschrift und setzte als einziger autonomer Agent sogar das innere Kassettendeckenmuster um
- ModelRift / Gemini Flash 3.0: Zeit 1/5, Qualität 3,8/5. Bestes nichtautonomes Ergebnis mit dem iterativen Annotations-Workflow von ModelRift und etwa doppelt so langsam wie Claude Code
Beobachtungen zum Workflow
- Der Client-Workflow war fast so wichtig wie das Modell selbst
- Codex Desktop zeigte dem LLM die in den Kontext geladenen Bilder direkt in der Unterhaltung, wodurch sich leicht prüfen ließ, ob Referenzen bei visueller CAD-Arbeit tatsächlich verwendet wurden
- Cursor Agent und Claude Code CLI konnten ebenfalls Bilder verwenden, aber der visuelle Kontext war im Ablauf weniger explizit sichtbar
- Alle getesteten Systeme konnten mit der lokalen OpenSCAD-Toolchain umgehen und OpenSCAD aus dem macOS-
PATHaufrufen, um PNG-Vorschauen zu rendern - Der Engpass war nicht der Tool-Zugriff, sondern die geometrische Beurteilung, Kameraeinstellungen und die Frage, ob sich ein Vorschau-Modell als sauberes finales Mesh exportieren ließ
- Codex machte den Iterationsprozess leicht nachvollziehbar, weil Referenzbilder, Bearbeitung der OpenSCAD-Datei und generierte Vorschauen im selben Thread sichtbar waren
- Nach dem öffentlichen Benchmark versuchte Codex, Probleme beim Export von Dach und Entablature zu beheben, doch der finale Vergleich basiert auf dem ursprünglich eingereichten Modell
- Cursor bot die schnellste Interaktionsschleife und eine nützliche parallele UI für Planung und OpenSCAD-Code, blieb bei der Ausgabequalität aber hinter langsameren Läufen zurück
- Claude Code arbeitete terminalzentriert, las Bilder ein und wiederholte OpenSCAD-Befehle, doch der Modellierungsprozess selbst war weniger visuell
Google Antigravity 2.0 / Gemini 3.5 Flash High
- 3D-Ergebnis ansehen
- Dieser Lauf wurde am 22. Mai 2026 hinzugefügt, kurz nachdem Google auf der I/O 2026 Antigravity 2.0 veröffentlicht hatte und Gemini 3.5 Flash am 19. Mai 2026 vorgestellt wurde
- Das Ergebnis war das beste vollautonome Modell in diesem Benchmark und ein frühes positives Signal für Flash 3.5
- Antigravity 2.0 wirkte eher wie eine agent-first Desktop-App mit Planung, Task-Ausführung und Vorschau; Nutzer, die die frühere IDE-Erfahrung wollten, hatten außer Downgrade oder dem Festhalten an der alten App keinen reibungslosen Rückweg, was in der Release-Woche viel Kritik auslöste
- Flash 3.5 High betrachtete die Referenzbilder nicht nur grob, sondern recherchierte reale Pantheon-Parameter
- Planung und Code verwendeten explizite Maße für Rotunde, Kuppel, Portikus und Oculus und übersetzten diese in parametrische OpenSCAD-Werte
Implement a detailed, visually stunning, and dimensionally accurate 3D model of the Pantheon in Rome using OpenSCAD. - Um auch die innere Struktur des Pantheon abzubilden, wurde ein Cutaway-Modus vorgeschlagen
To showcase both the exterior (stepped rings, portico) and the interior (coffers, niches, perfect spherical proportion), I will include a toggle in the code `show_cutaway = false;`. - Das stärkste Detail war die Decke
The Pantheon dome interior has 5 rings of 28 coffers. Subtracting these mathematically in OpenSCAD is highly detailed and looks amazing. - Antigravity setzte als einziger autonomer Agent das wiederholte quadratische Kassettendeckenmuster um, das durch den Oculus sichtbar ist
- Das äußere Ergebnis enthielt zudem Elemente, die bei schnellen OpenSCAD-Ausgaben oft fehlen
- Säulenmaterial mit gemischten grauen und rötlichen Tönen
- lesbare Inschrift
- gestufte Dachringe
- stimmige Großbeziehungen zwischen Rotunde, Mittelblock, Portikus und Kuppel
- Qualitätswertung 4,5/5, Geschwindigkeitswertung 1/5
- Es war nicht schnell, hob aber die Obergrenze autonomer Generierung in diesem Benchmark an und lässt Flash 3.5 vielversprechend für räumliche Codegenerierung erscheinen, wenn es mit Werkzeugen für Planung, Rendering, Prüfung und Korrektur kombiniert wird
ModelRift / Gemini Flash 3.0
- 3D-Ergebnis ansehen
- Dieses Ergebnis entstand in einem Human-in-the-Loop-Prozess mit ModelRift und Gemini Flash 3.0 und war anders als die ersten vier Läufe kein autonomer Single-Pass-Benchmark
- Der Workflow dauerte etwa 10 Minuten und damit ungefähr doppelt so lange wie Claude Code, weshalb ebenfalls die Geschwindigkeitswertung 1/5 vergeben wurde
- Der Benchmark-Lauf fand am 21. Mai 2026 statt, direkt nach der Veröffentlichung von Gemini 3.5 Flash
- Das Antigravity-Ergebnis zeigte zwar die Stärke von 3.5 Flash, doch bei der Standard-Modellwahl von ModelRift müssen Qualität, Kosten und Latenz gemeinsam berücksichtigt werden
- Googles Gemini-API-Preise nennen für Gemini 3.5 Flash Standardpreise von 1,50 US-Dollar pro 1 Million Input-Token und 9,00 US-Dollar pro 1 Million Output-Token; für Gemini 3 Flash werden 0,50 US-Dollar Input und 3,00 US-Dollar Output angegeben
- Gemini 3.5 Flash bedeutet damit dreifach höhere Kosten gegenüber der vorherigen Flash-Generation und liegt deutlich über den früheren Kostenniveaus aus der Gemini-1.5-Flash-Zeit
- Die Qualität lag bei 3,8/5 und damit über den bisherigen autonomen Läufen
- Das Modell war nicht perfekt, aber Portikus, Säulenanordnung, Dach, Kuppelrippen und Gesamtmasse waren konsistenter
- Der entscheidende Unterschied war, dass sich visuelles Feedback direkt auf dem aktuellen Render anbringen ließ
- Der ModelRift-Workflow ist darauf ausgelegt, Modellerzeugung, Browser-Inspektion, visuelle Notizen auf dem Render und Anfragen an die AI zur OpenSCAD-Anpassung zu wiederholen
- Für räumliche CAD-Aufgaben ist diese Schleife deutlich präziser als ein Vorgehen mit rein textlichen Anweisungen
Wichtige Resultate autonomer Läufe
-
Codex 5.5 High
- 3D-Ergebnis ansehen
- Codex 5.5 High erzeugte das dichteste Modell
- Enthalten waren Rotunde, Kuppelrippen, Oculus, gestapelte Steinbänder, Frontportikus, Säulen, umliegende Sockeldetails und Text im Entablature
- Im Entablature stand
M AGRIPPA L F COS TERTIVM FECIT - Text in OpenSCAD ist aus Modellierungssicht anspruchsvoll, weil Platzierung, Extrusion, Ausrichtung und geringe Dicke kontrolliert werden müssen
- Während der Iteration wirkte die Render-Vorschau besser als das final exportierte STL
- Im finalen Ergebnis entstand im Bereich von Entablature und Portikusdach eine deckenartige Problemfläche, die den Eindruck der Frontmontage veränderte
- Codex zeigte starke räumliche Schlussfolgerung und hohen Detailanspruch, machte aber auch das Exportrisiko sichtbar, dass Vorschaugenauigkeit nicht automatisch finale Mesh-Genauigkeit bedeutet
- Wäre statt des veröffentlichten STL die beste PNG-Vorschau bewertet worden, hätte es strukturell und in den Details knapp hinter Antigravity 2.0 gelegen
- Die Wertung 3,0/5 ist stark durch die Diskrepanz zwischen Entwurfsabsicht und finalem Export/Rendering geprägt
-
Claude Sonnet
- 3D-Ergebnis ansehen
- Claude Sonnet erzeugte das sauberste Modell unter den bisherigen autonomen Läufen
- Es versuchte nicht so viele feine Details wie Codex, hatte aber eine sauberere Silhouette und natürlicher ineinandergreifende architektonische Hauptkomponenten
- Kuppel, Trommel, Portikus und Säulenanordnung lasen sich als ein Gebäude statt als Bündel benachbarter Primitive
- Auch die Proportionen waren zurückhaltender; vor dem Antigravity-Lauf war dies das stärkste vollautonome Ergebnis
- Claude Code war in diesem Benchmark etwa 2- bis 3-mal langsamer als Codex, und Sonnet erhielt trotz guter Qualität die niedrigste Zeitwertung
- Die Qualitätswertung lag bei 3,4/5; es blieb also weiterhin ein Näherungsmodell und keine architektonische Rekonstruktion in Produktionsqualität
-
Cursor Composer
- 3D-Ergebnis ansehen
- Die Kombination aus Cursor und Composer 2.5 war am schnellsten, lieferte aber das schwächste Ergebnis
- Die großen Gesten von Rotunde, Kuppel, Portikus und Säulen wurden getroffen
- Es fehlten aber die zurückhaltende Materialität und die architektonische Nuancierung, die das Pantheon erkennbar machen
- Die Ausgabe wirkte eher wie ein vereinfachter Platzhalter als wie ein fertiges Modell und hätte vor einer Veröffentlichung umfangreiche Nacharbeit gebraucht
-
Claude Opus
- 3D-Ergebnis ansehen
- Claude Opus lag zwischen Cursor und Sonnet
- Es erzeugte ein vollständigeres Gebäude als Cursor, mit klarerem Portikus und deutlicherem gestuftem Sockel
- Die Ausgabe war jedoch zu gleichförmig und weniger überzeugend als Sonnet
- Struktur war vorhanden, aber das Urteilsvermögen für visuelle Hierarchie fehlte
- Farbe und Gewicht fast aller Elemente waren gleich, sodass Details eher miteinander konkurrierten, statt den Blick zu führen
- Die aktualisierte Wertung lag bei 3,0/5; das war höher als in der ersten Tabellenversion gerechtfertigt erschien, blieb aber hinter Sonnet und Antigravity zurück
Zentrale Erkenntnisse
- OpenSCAD hat sich als Zielsprache gut behauptet
- Die Syntax ist klein, die Ausgabe deterministisch, und die CLI rendert prüfbare Vorschauen für die Iterationsschleife
- Die LLMs brauchten keinen besonderen Kniff, um OpenSCAD zu verwenden
- Tool-Nutzung war nicht der Engpass
- Alle Agenten riefen OpenSCAD aus dem macOS-
PATHauf und renderten PNG-Vorschauen - Der schwierige Teil war nicht das Plumbing, sondern die geometrische Beurteilung
- Alle Agenten riefen OpenSCAD aus dem macOS-
- Geschwindigkeit war kein verlässlicher Prädiktor für Qualität
- Cursor war am schnellsten und zugleich am schwächsten
- Sonnet brauchte unter den bisherigen autonomen Läufen am längsten, erzeugte aber das sauberste Modell
- Auch Antigravity war langsam, doch Gemini 3.5 Flash High lieferte nach Zeit für Planung und Iteration das beste autonome Ergebnis
- ModelRift/Gemini Flash 3.0 brauchte länger, erreichte dank visuellem Feedback aber höhere Qualität als die bisherigen autonomen Läufe
- Vorschau und Export sind nicht dasselbe
- Codex wirkte in der Render-Schleife stark, zeigte im finalen STL aber Geometrieprobleme rund um das Portikusdach
- Bei Modellen für den Druck muss nicht nur die Vorschau, sondern auch das exportierte Mesh separat geprüft werden
- Keine Ausgabe war auf dem Niveau eines wirklich originalgetreuen Architekturmodells
- Die Inschrift bei Codex war ein gutes Detail
- Die Proportionen bei Sonnet waren konsistent
- Die Kassettendecke bei Antigravity war das überraschendste Detail
- Das Ergebnis von ModelRift/Gemini Flash 3.0 zeigte, wie stark die Qualität steigt, wenn ein Mensch visuell nachsteuert
- Mit nur zwei Referenzbildern und einem kurzen Prompt erreichten alle Systeme gültiges und renderbares OpenSCAD, ohne den CAD-Code manuell schreiben zu müssen
- Die Qualitätsunterschiede zwischen den Tools waren groß, aber das Ausgangsniveau selbst lag höher als erwartet
- Vollautonome Generierung ist für diese Art von Aufgabe noch nicht der richtige Workflow
- Bei ModelRift wird für Iterationen weiterhin der Annotation Mode verwendet
- Dabei werden Pfeile und Notizen direkt auf 3D-Modell-Screenshots gezeichnet und an die AI zurückgegeben
- Für räumliche Geometrie bleibt ein Human-in-the-Loop-Schritt wichtig, selbst mit Spitzenmodellen
- Ein Modell kann die große Masse korrekt treffen und dennoch Säulenpositionen oder Kuppelproportionen falsch setzen
- Probleme direkt auf dem Render zu markieren ist schneller und präziser, als sie nur textlich zu beschreiben
1 Kommentare
Hacker-News-Kommentare
Letzte Woche habe ich auf dem Marketplace das Fahrrad meiner Frau gekauft; der Zustand war gut, aber ein Gummistopfen für die interne Kabelführung fehlte.
Ich habe Claude nur ein Foto der pillenförmigen Öffnung gegeben und zusätzlich ein Foto, auf dem ich mit einer digitalen Schieblehre die lange und die kurze Achse messe, und mit einem kurzen Prompt hat es mir ein OpenSCAD-Modell erstellt, bei dem alle Maße parametrisiert waren.
Ich habe es ohne Änderungen in TPU gedruckt, und schon der erste Versuch war fast perfekt. Nachdem ich den von Claude für die x/y-Maße abgezogenen Wert von 0,3 mm auf 0,1 mm reduziert hatte, passte es exakt. Viel einfacher als antike römische Architektur, aber trotzdem beeindruckend, dass es so leicht funktioniert
Ich hatte eine ähnliche Erfahrung damit, mit OpenSCAD und LLMs einfache funktionale Teile für den 3D-Druck zu erstellen, und ich weiß auch, dass die Modelle darin nicht so gut sind wie bei der Erzeugung von React-Code, und ich bin das genaue Gegenteil eines geübten Operators. Trotzdem ist es großartig, dass mich das überhaupt dazu gebracht hat, als Hobby eine neue Technik zu lernen
Die echte Magie wäre erreicht, wenn man nur ein Maß oder ein Foto mit Lineal geben müsste und die AI den Rest erschließt, aber zumindest aktuell ist Claude ziemlich schlecht im Raten
Dass „Antigravity der einzige autonome Agent war, der das markante innere Deckenmuster des Pantheon umsetzte, also die sich wiederholende quadratische Kassettendecke, die durch den Oculus sichtbar ist“, ist wirklich beeindruckend.
Ich habe mir sogar das 3D-Modell angesehen, aber bis ich diesen Satz gelesen habe, bin ich nicht einmal auf die Idee gekommen, ins Innere zu schauen.
Das 3D-Modell mit aktiviertem
show_cutawayist hier: https://modelrift.com/models/pantheon-benchmark-antigravity-...Wenn man „Pantheon“ verlangt, ist das natürlich irgendwie richtig, aber als technischer Zeichner oder Ingenieur fände ich es schwer, so ein Ergebnis zu akzeptieren
In welchem Benchmark Antigravity auch immer Platz 1 gemacht haben soll: Mein Antigravity, das mir zwangsweise Gemini CLI ersetzt hat, verlangt bei jeder Nutzung einen Browser-Login, und die Antigravity IDE wird überhaupt nicht aktualisiert.
Wenn möglich, hätte ich gern zuerst einmal grundsätzlich akzeptable Deployment-Qualität, bevor man sich darum kümmert, irgendwo Erster zu sein.
Der eigentliche Titel lautet „OpenSCAD LLM Benchmark: Building the Pantheon“
Die LLM-Modelle selbst sind trotzdem gut, und auch Antigravity 2.0 ist nicht so schlecht. Wenn man allerdings wie viele andere seine Antigravity-1.0-Konfiguration und Projekte verloren hat, sieht die Sache anders aus
Gemini 3.5 Flash ist seltsam. Der Cutoff ist alt, in mancher Hinsicht ist es besser als 3.1 Pro, in anderer schlechter, und manchmal ist es günstiger, manchmal teurer als 3.1 Pro.
Antigravity wirkte wie aufgegeben, und die Leute spekulierten über ein Ende; faktisch ist das durch die Migration aller Nutzer auf das neue Antigravity auch teilweise so gekommen.
Bei Google hat man das Gefühl, als würde das Organigramm direkt als Produkt ausgeliefert, es gibt zu viele AI-Produkte, und keines davon wirkt wie Best-in-Class. Zum Beispiel ist die Gemini-Integration in Google Docs schlechter als Claude.
Ich hatte auf ein Modell mit „Opus-Niveau zum Haiku-Preis“ oder „Sonnet-Leistung zum Preis von Gemini 3.0“ gehofft. Wenn auch nur eines davon gekommen wäre, wäre es ein Standardmodell und ein echter Claude-/Codex-Konkurrent geworden, aber bekommen haben wir weder das eine noch das andere
Mich würde interessieren, was Antigravity CLI + VS Code oder eine andere IDE-Kombination nicht abdeckt
Aber die E-Mail vom Mittwoch nach dem Motto „Danke für dein Google-One-AI-Pro-Abo, ab jetzt fügen wir deinem Konto Einschränkungen hinzu, Pech gehabt“ fand ich wirklich unerquicklich. Zuvor hatte ich das AI-Pro-Abo noch als gutes Preis-Leistungs-Verhältnis gelobt
Ich finde es gut, dass Google investiert, aber je älter ich werde, desto stärker schütze ich meinen Workflow
Ich habe für OpenSCAD viele Benchmarks mit allen möglichen Modellen und Einstellungen laufen lassen, und das ist meine Erkenntnis:
Die Modelle sind inkonsistent; bei bestimmten 3D-Modelltypen sind sie hervorragend, bei anderen nicht.
Meiner Erfahrung nach sind die Gemini-Modelle am wenigsten inkonsistent und beim Bildverständnis am stärksten.
Gleichzeitig sind Gemini-Modelle auch am kreativsten, was aber eher unerwünscht sein kann, wenn man präzise CAD-Teile haben möchte.
Insgesamt beweist dieser Benchmark nicht besonders viel. Ein einziges 3D-Modell und ein einziger Versuch reichen einfach nicht aus. Normalerweise teste ich mindestens 12 Modelle, jeweils mit 3 Generierungen, aber eigentlich müsste man noch deutlich mehr machen. Für Einzelentwickler ist das allerdings zu teuer.
Trotzdem danke fürs Veröffentlichen; ich werde bald einmal ausprobieren, wie Flash 3.5 abschneidet
Es ist ein interessanter Benchmark, LLMs danach zu bewerten, ob sie valide 3D-CAD-Modelle erzeugen können.
OpenSCAD eignet sich dafür besonders gut, weil dort alles vollständig codebasiert ist
Als ich es selbst ausprobiert habe, war es eine ziemlich schlechte Erfahrung. Beim ersten Versuch kann noch ein halbwegs brauchbarer Entwurf herauskommen, aber sobald man anfängt, ihn zu „debuggen“, merkt man nach einer sehr frustrierenden Session, dass das Modell das Ergebnis gar nicht richtig „sehen“ kann.
Das heißt: Es gibt überhaupt keine iterative Verbesserung.
Die meisten Ausführungstools oder Harnesses skalieren Bilder herunter, bevor sie verarbeitet werden, und dabei gehen offenbar so viele Details verloren, dass insbesondere bei Wireframe-Bildern kaum noch sinnvoll darauf geschlossen werden kann.
Vielleicht benutze ich es falsch, aber dieser Test hat genau diesen Punkt eben nicht wirklich geprüft. Es war nur ein einmaliger Versuch, und dieser Ansatz bricht ziemlich schnell zusammen, besonders wenn man kein Referenzfoto von dem hat, was man erstellen will
Ein einziges reales Objekt zu bauen und das dann zum Benchmark zu erklären, ist keine robuste Art, Tools zu bewerten.
Man sollte eher wie bei Iron Chef ein Thema wie griechische Architektur vorgeben und dann eine Jury den Sieger bestimmen lassen. Im Moment schaut man im Grunde nur, welches Tool subjektiv das plausibelste Pantheon gebaut hat
Hier wird ein einzelnes, nicht sauber definiertes Beispiel ohne echten Endanwendungsfall anhand völlig subjektiver Bewertungskriterien beurteilt
Für einen Short auf Autodesk ist es noch zu früh.
Zur Einordnung: Autodesk hat im Dezember einen agentischen Assistenten für Fusion herausgebracht, und selbst sechs Monate später ist der noch ziemlich schlecht
Ich musste in den letzten Wochen ein paar einfache Teile für den 3D-Druck entwerfen und habe es dafür ausprobiert. Jedes davon entsprach vielleicht vier Schritten in der Timeline, aber selbst mit einer detaillierten Schritt-für-Schritt-Beschreibung in Fusion-Terminologie kam es nicht einmal in die Nähe von dem, was ich wollte.
Im Moment bin ich mir nicht einmal sicher, ob es simple Grundkörper zuverlässig korrekt hinbekommt
Ich finde das schwer überzeugend. Das Pantheon ist eines der ikonischsten historischen Bauwerke überhaupt, es gibt viele Bücher dazu, und es wurden sicher schon zahllose Fotos und frei verfügbare Modelle zum Training verwendet.
Ein Benchmark, bei dem man allein auf Basis der bereitgestellten Referenz ein anonymes Bauwerk modellieren muss, wäre viel interessanter. Das wirkt auf mich wie diese oberflächliche Magie, wenn ein LLM in einem Durchgang eine To-do-App ausspuckt
Ich entwickle gerade ein Technikgerät für Eltern, und dessen Gehäuse wurde vollständig von AI generiert.
Ich hatte überhaupt keine Ahnung, wo ich bei 3D-Modellierung anfangen sollte, und das LLM hat mir gezeigt, dass auch das wie vieles andere einfach Code ist.
Seltsamerweise hat Opus 4.5 es in einem Durchgang perfekt hinbekommen; das war noch vor der Kontroverse um die Leistungsverschlechterung, und seitdem ist es selbst extrem schwer geworden, das Gehäuse nur minimal zu verändern.
Es fühlt sich an, als wäre Opus von einem Modell, das Formen professionell im Kopf rotieren konnte, zu einem Modell geworden, das gar nicht mehr versteht, womit es arbeitet
4.7 war bei Änderungsarbeiten allerdings okay