ModelRift가 여러 AI 코딩 도구를 대상으로 텍스트 기반의 파라미터 3D 모델링 도구인 OpenSCAD를 사용해 판테온을 설계하는 벤치마크를 진행했습니다. 그 결과, 안티그래비티 2.0(Antigravity 2.0) 모델이 가장 뛰어난 공간 기하학 처리 및 건축적 디테일 구현 능력을 보여주며 1위를 차지했습니다. 이 벤치마크는 LLM이 복잡한 3D 형상을 얼마나 잘 코드로 변환하는지 평가하여, AI가 실제 CAD 및 3D 프린팅 워크플로우에 적용될 수 있는지를 보여준다는 점에서 중요합니다.
번역된 본문
우리는 소규모 실용 벤치마크를 실행했습니다. 여러 AI 코딩 도구에 동일한 유형의 작업을 주고 OpenSCAD로 판테온(Pantheon)을 만들도록 요청했습니다. ModelRift는 플랫폼의 모든 3D 모델에 대해 OpenSCAD 코드를 생성합니다. 대규모 언어 모델(LLM)의 공간 기하학 처리 능력은 우리가 제공할 수 있는 결과물에 직접적인 영향을 미치므로, 우리는 이러한 작업에서 모델들이 어떻게 발전하는지 추적합니다. 목표는 각 시스템이 건축 참고 자료를 파라미터 CAD 코드로 얼마나 잘 변환할 수 있는지 확인하는 것이었으며, 이를 위해 OpenSCAD CLI(Command Line Interface)를 사용해 미리보기를 렌더링하고 반복 작업을 수행했습니다. 프롬프트는 의도적으로 시각적이고 건축적인 내용으로 구성했습니다. 원형 돔(rotunda), 돔(dome), 현관(portico), 기둥(columns), 박공(pediment) 및 인식 가능한 정면 디테일을 포함하여 참고 이미지를 바탕으로 판테온을 구축하도록 요청했습니다. 다음은 현재 6개 벤치마크 결과에 대한 개요입니다. 각 썸네일에는 해당 실행에 사용된 클라이언트와 모델이 표시되어 있습니다.
왜 판테온인가? 이것은 기본적인 OpenSCAD 구문 테스트가 아니었습니다. 현재의 모든 코딩 LLM은 OpenSCAD에서 '구멍이 뚫린 큐브'와 같은 단순한 모델을 완벽하게 생성할 수 있습니다. 그러한 종류의 프롬프트는 주로 모델이 difference(), cube(), cylinder()와 같은 함수를 아는지 테스트할 뿐입니다. 판테온은 중간 지점에 위치해 있기 때문에 벤치마크로서 더 유용합니다. OpenSCAD는 자연스럽게 조각된 모델, 유기적인 표면 또는 캐릭터 같은 형상에는 적합하지 않습니다. 대신 부울 연산(Boolean operations), 방사형 대칭(radial symmetry), 돌출(extrusions) 및 깔끔한 구조적 형태를 다루는 데 훨씬 뛰어납니다. 판테온은 큰 원형 돔과 돔, 중앙의 오큘러스(oculus, 천창), 직선 현관, 기둥, 계단형 기단 및 삼각형 박공을 가지고 있습니다. 이러한 혼합은 불가능하지 않으면서도 특징을 잘 보여줍니다. 또한 매우 인지하기 쉽습니다. 약한 결과물은 여전히 돔이 있는 건물처럼 보이지만, 더 나은 결과물은 원형 드럼, 직사각형 현관, 돔 링 및 정면 외관 사이의 관계를 대략적으로라도 정확히 파악해야 합니다.
왜 OpenSCAD인가? OpenSCAD는 모델이 압축된 어휘를 가진 순수 텍스트 코드이기 때문에 LLM이 생성하는 기하학의 훌륭한 타겟입니다. AI 에이전트는 건물을 중첩된 변환, 부울 연산, 원통, 돌출, 루프 및 명명된 모듈로 설명할 수 있습니다. 이는 언어 모델이 구조에 대해 이미 추론하는 방식과 훨씬 더 가깝습니다. 즉, UI 동작을 통해 3D 애플리케이션을 구동하도록 요청하는 것보다 훨씬 자연스럽습니다. 이것이 우리가 애초에 ModelRift를 OpenSCAD 기반으로 구축한 주요 이유이며, '우리가 OpenSCAD 위에 ModelRift를 구축한 이유(Why we built ModelRift on OpenSCAD)'에서 다룬 바 있습니다. 이는 복잡한 기하학에서 특히 중요합니다. OpenSCAD를 사용하면 LLM이 소스 코드에서 직접 '특정 반경 주위로 28개의 기둥을 반복 생성'하거나 '돔에서 오큘러스를 뺀다'고 말할 수 있습니다. 그 결과물은 검사 및 재현 가능하며 수정하기 쉽습니다. 기둥 간격이 잘못된 경우, 수정은 숨겨진 장면 상태 변이가 아니라 단순히 파라미터나 루프를 변경하는 것입니다. 이와 같은 텍스트 우선 구조는 OpenSCAD가 '더 나은 OpenSCAD 커스터마이저 구축(Building a better OpenSCAD customizer)'에서 논의된 것과 같은 파라미터 UI 레이어와 잘 작동하게 만듭니다.
Blender MCP 및 유사한 도구 제어 방식은 일부 워크플로우에 유용하지만, 이 벤치마크에서는 덜 자연스러운 인코딩 방식입니다. 에이전트는 건축적 의도를 일련의 애플리케이션 작업으로 번역한 다음, 이러한 작업이 누적됨에 따라 장면 상태에 대한 멘탈 모델(mental model)을 유지해야 합니다. CAD와 같은 작업의 경우 이는 상당히 돌아가는 방식(간접적 접근)입니다. OpenSCAD는 기하학 자체를 결과물로 유지합니다. 단점은 OpenSCAD가 조각 도구가 아니라는 것입니다. 구성적이고 파라미터적이며 대부분 하드 서페이스 객체에 가장 적합합니다. 판테온은 방사형 대칭, 반복되는 기둥, 링, 컷아웃 및 단순한 건축 솔리드를 필요로 하므로 이 영역에 정확히 들어맞습니다. 또한 3D 프린팅의 실제 파일 출력 측면과도 깔끔하게 연결됩니다. '3D 파일 형식 설명(3D file formats explained)' 및 'ModelRift에 다중 색상 3MF 내보내기를 추가한 방법(How we added multicolor 3MF export to ModelRift)'에서 설명한 것처럼 STL은 기본 메시 형식으로 남아 있는 반면, 3MF는 더 풍부한 어셈블리 및 색상 정보를 전달할 수 있습니다. 이것이 바로 ModelRift가 LLM에서 생성하기를 원하는 기하학의 종류에 유용한 벤치마크인 이유입니다.
프롬프트: 벤치마크에 사용된 프롬프트는 다음과 같았습니다. "두 장의 참고 이미지를 보고 판테온을 구현한 OpenSCAD 코드(.scad 파일)를 작성하세요. 작업물을 미리보기 위해 사용 가능한 OpenSCAD CLI를 사용하여 결과를 확인하고 반복하세요."
We ran a small practical benchmark: give several AI coding tools the same kind of task and ask them to build the Pantheon in OpenSCAD. ModelRift generates OpenSCAD for every 3D model on the platform. The LLM’s ability to handle spatial geometry directly affects what we can ship, so we track how models improve on this kind of task. The goal was to see how well each system could turn architectural reference material into parametric CAD code, using the OpenSCAD CLI to render previews and iterate. The prompt was intentionally visual and architectural: build the Pantheon from reference images, including the rotunda, dome, portico, columns, pediment, and recognizable front details. Overview of the six current benchmark results. Each thumbnail is labeled with the client and model used for that run. Why Pantheon? This was not a basic OpenSCAD syntax test. All of the current coding LLMs can produce a simple “cube with a hole” model in OpenSCAD perfectly well. That kind of prompt mostly tests whether the model knows difference() , cube() , and cylinder() . The Pantheon is more useful as a benchmark because it sits in a middle ground. OpenSCAD is not a good fit for natural sculpted models, organic surfaces, or character-like geometry. It is much better at Boolean operations, radial symmetry, extrusions, and clean constructive shapes. The Pantheon has a large radial rotunda and dome, a central oculus, straight portico faces, columns, stepped bases, and a triangular pediment. That mix makes it illustrative without being impossible. It is also recognizable. A weak result still looks vaguely like a domed building, but a better result has to get the relationship between the round drum, the rectangular portico, the dome rings, and the front facade roughly right. Why OpenSCAD? OpenSCAD is a strong target for LLM-generated geometry because the model is plain text code with a compact vocabulary. An agent can describe a building as nested transformations, Boolean operations, cylinders, extrusions, loops, and named modules. That is much closer to how language models already reason about structure than asking them to drive a 3D application through UI actions. This is the main reason we built ModelRift around OpenSCAD in the first place, as covered in Why we built ModelRift on OpenSCAD . That matters for complex geometry. With OpenSCAD, the LLM can say “make 28 repeated columns around a radius” or “subtract an oculus from a dome” directly in the source. The result is inspectable, reproducible, and easy to revise. If a column spacing is wrong, the fix is usually a parameter or loop change, not a hidden scene-state mutation. That same text-first structure is what makes OpenSCAD work well with parametric UI layers like the ones discussed in Building a better OpenSCAD customizer . Blender MCPs and similar tool-control approaches are useful for some workflows, but they are a less natural encoding for this benchmark. The agent has to translate architectural intent into a sequence of application operations, then keep a mental model of the scene state as those operations accumulate. For CAD-like tasks, that is a lot of indirection. OpenSCAD keeps the geometry itself as the artifact. The tradeoff is that OpenSCAD is not a sculpting tool. It is best at constructive, parametric, and mostly hard-surface objects. The Pantheon sits right in that zone: radial symmetry, repeated columns, rings, cutouts, and simple architectural solids. It also maps cleanly to the practical file-output side of 3D printing: STL remains the baseline mesh format, while 3MF can carry richer assembly and color information, as described in 3D file formats explained and How we added multicolor 3MF export to ModelRift . That is why it is a useful benchmark for the kind of geometry ModelRift wants LLMs to generate. Prompt The prompt used for the benchmark was: 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. Reference Images Reference #1 is the front facade view on the left. Reference #2 is the aerial/top view on the right. The combined image was generated with ffmpeg from the two source images used in the benchmark. Results The six current benchmark outputs, labeled by client and model. Tool and model Time Quality Summary Link Cursor 3.5 / Composer 2.5 ●●●●● 5/5, fastest ●○○○○ 1.4/5 Quickest run, but the weakest output. It captured a dome and portico, but the proportions, color discipline, and architectural details were the poorest. Explore 3D result Codex 5.5 High ●●●●○ 4/5, baseline ●●●○○ 3.0/5 Strong detail density, including the inscription on the entablature. If the final STL had matched the PNG preview, this would likely score just below Antigravity; the published score is held down by the export mismatch. Explore 3D result Claude Code 2.1 / Opus 4.7 ●●○○○ 2/5, slower ●●●○○ 3.0/5 Better structure than Cursor, with a clearer portico and stepped base, but too monochrome and less convincing than the stronger runs. Explore 3D result Claude Code 2.1 / Sonnet 4.6 ●○○○○ 1/5, slowest ●●●◐○ 3.4/5 The model had clean massing, balanced proportions, and the most plausible overall read among the original autonomous batch, but took the longest to implement. Explore 3D result Google Antigravity 2.0 / Gemini 3.5 Flash High Best autonomous result ●○○○○ 1/5, around 12 min ●●●●◐ 4.5/5 Strongest autonomous output. It used real Pantheon dimensions, included the inscription, and was the only agent to implement the signature interior coffered ceiling pattern. Explore 3D result ModelRift / Gemini Flash 3.0 Human-in-the-loop winner ●○○○○ 1/5, about 10 min ●●●◐○ 3.8/5 Best non-autonomous result. It used ModelRift’s iterative annotation workflow with Gemini Flash 3.0 and took about 2x the Claude Code time. Explore 3D result The scores are relative to this benchmark only. They are not general model rankings, and the time score reflects observed implementation time, not project publication timestamps. The quality scores are intentionally conservative: even the best result is not close to a perfect Pantheon model. Workflow Notes The client workflow mattered almost as much as the model. Codex Desktop shows the images that the LLM has loaded into context directly inside the conversation. For visual CAD work, that is very convenient: you can see whether the agent is actually using the same references you intended. Cursor Agent and Claude Code CLI were workable, but their process views made visual context less explicit. All tested systems handled the local OpenSCAD toolchain well. OpenSCAD was installed on the test Mac and available on PATH , and every agent used it successfully to render PNG previews during iteration. The limiting factor was not tool access. It was geometric judgment, camera setup, and whether a previewed model exported into a clean final mesh. Codex also made the preview iteration easier to follow. It exposed the reference images, the OpenSCAD file edits, and generated preview images in the same thread. After the public benchmark result, Codex attempted to investigate and fix the problematic roof and entablature export issue. That follow-up was not included in the final benchmark results, because the published comparison uses the original submitted models. Cursor had the fastest interaction loop, and its UI showed a useful plan plus generated OpenSCAD code side by side. The output quality still lagged behind the slower runs. Claude Code was more terminal-centric. It did read the images and iterate with OpenSCAD commands, but the process was less visual while the model was being built. Google Antigravity 2.0 / Gemini 3.5 Flash High Explore 3D result Short demo clip of the Antigravity result and workflow. We added this run on May 22, 2026, immediately after Google launched Antigravity 2.0 at I/O 2026 and published Gemini 3.5 Flash on May 19, 2026 . It is a