1 पॉइंट द्वारा GN⁺ 6 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • OpenSCAD Pantheon बेंचमार्क यह परखता है कि क्या AI coding tools सिर्फ 2 reference images और एक छोटे prompt के आधार पर किसी वास्तु संरचना को parametric CAD code के रूप में बना सकते हैं
  • Google Antigravity 2.0 / Gemini 3.5 Flash High ने 4.5/5 quality score के साथ सर्वोच्च स्थान हासिल किया, और Pantheon के वास्तविक dimensions, inscription, यहां तक कि अंदरूनी coffered ceiling pattern तक को लागू किया
  • Codex 5.5 High में detail density काफी अधिक थी, लेकिन PNG preview और final STL के mismatch के कारण अंक कटे, जबकि Sonnet ने मौजूदा autonomous runs में सबसे साफ-सुथरा मॉडल दिया
  • Cursor सबसे तेज़ था, लेकिन quality सबसे कम रही; ModelRift/Gemini Flash 3.0 ने visual feedback जोड़ने वाले human-in-the-loop तरीके से 3.8/5 तक पहुंच बनाई
  • सभी systems ने OpenSCAD CLI rendering तक किया, लेकिन bottleneck tool access नहीं बल्कि geometry judgment और final mesh verification था

बेंचमार्क का उद्देश्य और कार्य

  • ModelRift हर 3D model के लिए OpenSCAD code जनरेट करता है, इसलिए LLM की spatial geometry संभालने की क्षमता सीधे वास्तविक model quality से जुड़ती है
  • इस test में कई AI coding tools को एक ही task दिया गया, जिसमें reference images और छोटे prompt के आधार पर Pantheon को OpenSCAD में बनाना था; यह एक छोटा लेकिन व्यावहारिक benchmark था
  • लक्ष्य यह जांचना था कि क्या वे architectural reference material को parametric CAD code में बदल सकते हैं, OpenSCAD CLI से PNG preview render कर सकते हैं, और iteration के जरिए सुधार कर सकते हैं
  • Prompt में Pantheon की rotunda, dome, portico, columns, pediment और front detail शामिल करने की मांग थी
    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.
    

Pantheon और OpenSCAD को चुनने का कारण

  • Pantheon ऐसा task है जो सिर्फ difference(), cube(), cylinder() syntax test से आगे जाता है, लेकिन OpenSCAD के लिए कठिन organic sculptures या character-type geometry जैसा भी नहीं है
  • इसकी मुख्य संरचना गोल rotunda और dome, बीच का oculus, सीधा portico, columns, stepped plinth और triangular pediment से मिलकर बनती है, इसलिए अलग-अलग परिणामों की तुलना करना आसान है
  • कमजोर परिणाम भी dome वाली इमारत जैसे लग सकते हैं, लेकिन अच्छे परिणामों में गोल drum, rectangular portico, dome ring और front facade के रिश्ते अधिक सटीक होने चाहिए
  • OpenSCAD में model plain-text code होता है और इसकी vocabulary छोटी है, इसलिए यह LLM-generated geometry के लिए उपयुक्त है
  • “radius के चारों ओर 28 columns दोहराना” या “dome से oculus subtract करना” जैसी बातें source code में सीधे व्यक्त की जा सकती हैं
  • Output inspect करने योग्य, reproducible और आसानी से editable होता है; इसलिए column spacing जैसी गलती hidden scene state के बजाय parameter या loop बदलकर ठीक की जा सकती है
  • ModelRift ने OpenSCAD पर क्यों बनाया, यह Why we built ModelRift on OpenSCAD में समझाया गया है
  • इसकी कमी यह है कि OpenSCAD कोई sculpting tool नहीं है; यह compositional, parametric और hard-surface objects के लिए सबसे उपयुक्त है

कुल परिणाम

  • Scores इस benchmark के भीतर relative evaluation हैं, general model ranking नहीं
  • Time score project के public release time नहीं, बल्कि देखे गए implementation time को दर्शाता है
  • Quality scores को conservative ढंग से दिया गया, और सर्वोत्तम परिणाम भी एक परफेक्ट Pantheon model के करीब नहीं थे
  • Tools और models के परिणाम:
    • Cursor 3.5 / Composer 2.5: समय 5/5, quality 1.4/5. सबसे तेज़, लेकिन सबसे कमजोर; dome और portico की बड़ी आकृति के अलावा proportion, color control और architectural detail की कमी थी
    • Codex 5.5 High: समय 4/5, quality 3.0/5. Entablature inscription तक जोड़ने लायक detail density थी, लेकिन final STL, PNG preview से अलग निकला, इसलिए अंक कटे
    • Claude Code 2.1 / Opus 4.7: समय 2/5, quality 3.0/5. Cursor की तुलना में structure, portico और stepped plinth ज्यादा स्पष्ट थे, लेकिन रंग बहुत uniform थे और मजबूत परिणामों जितना प्रभावशाली नहीं था
    • Claude Code 2.1 / Sonnet 4.6: समय 1/5, quality 3.4/5. मौजूदा autonomous runs में सबसे विश्वसनीय overall impression और balanced proportions दिखे, लेकिन implementation time सबसे लंबा था
    • Google Antigravity 2.0 / Gemini 3.5 Flash High: समय 1/5, quality 4.5/5. इसने Pantheon के वास्तविक dimensions और inscription का उपयोग किया, और autonomous agents में अकेले इसी ने अंदरूनी coffered ceiling pattern लागू किया
    • ModelRift / Gemini Flash 3.0: समय 1/5, quality 3.8/5. ModelRift के iterative annotation workflow का उपयोग करने वाले non-autonomous परिणामों में यह सर्वश्रेष्ठ था, और Claude Code की तुलना में लगभग 2 गुना अधिक समय लगा

Workflow observations

  • Client workflow, model जितना ही महत्वपूर्ण था
  • Codex Desktop ने conversation में LLM द्वारा context में लाई गई images सीधे दिखाईं, जिससे visual CAD work में reference material के उपयोग की पुष्टि करना आसान था
  • Cursor Agent और Claude Code CLI भी images का उपयोग कर सकते थे, लेकिन processing के दौरान visual context कम स्पष्ट दिखता था
  • Test किए गए सभी systems local OpenSCAD toolchain चला सकते थे, और macOS PATH में मौजूद OpenSCAD को call करके PNG preview render करते थे
  • Bottleneck tool access नहीं, बल्कि geometry judgment, camera setup और preview model को साफ final mesh के रूप में export कर पाने की क्षमता थी
  • Codex में reference images, OpenSCAD file editing और generated previews एक ही thread में दिखाई देते थे, इसलिए iterative process को follow करना आसान था
  • Public benchmark के बाद Codex ने roof और entablature export issues को ठीक करने की कोशिश की, लेकिन final comparison मूल submitted model के आधार पर ही किया गया
  • Cursor ने सबसे तेज़ interaction loop और उपयोगी planning/OpenSCAD code parallel UI दिया, लेकिन output quality धीमे runs से पीछे रही
  • Claude Code ने terminal-centric तरीके से images पढ़ीं और OpenSCAD commands दोहराए, लेकिन model बनने की प्रक्रिया कम visual थी

Google Antigravity 2.0 / Gemini 3.5 Flash High

  • Explore 3D result
  • यह run 22 मई 2026 को जोड़ा गया, ठीक Google ने I/O 2026 में Antigravity 2.0 लॉन्च किया और Gemini 3.5 Flash को 19 मई 2026 को जारी किया उसके तुरंत बाद
  • परिणाम इस benchmark का सबसे अच्छा fully autonomous model था, और Flash 3.5 के लिए शुरुआती संकेत भी सकारात्मक थे
  • Antigravity 2.0 एक agent-first desktop app जैसा था, जिसमें planning, task execution और preview शामिल थे; जो उपयोगकर्ता पुराना IDE अनुभव चाहते थे, उनके लिए downgrade या पुराने app पर टिके रहने के अलावा सहज वापसी का रास्ता नहीं था, इसलिए launch week में काफी आलोचना हुई
  • Flash 3.5 High ने reference images को सिर्फ आंखों से नहीं देखा, बल्कि वास्तविक Pantheon parameters भी खोजे
  • Planning और code में rotunda, dome, portico और oculus के लिए explicit dimensions का उपयोग हुआ और उन्हें parametric OpenSCAD values में बदला गया
    Implement a detailed, visually stunning, and dimensionally accurate 3D model of the Pantheon in Rome using OpenSCAD.
    
  • Pantheon की आंतरिक संरचना दिखाने के लिए इसने cutaway mode का सुझाव दिया
    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;`.
    
  • सबसे मजबूत detail ceiling में थी
    The Pantheon dome interior has 5 rings of 28 coffers. Subtracting these mathematically in OpenSCAD is highly detailed and looks amazing.
    
  • Antigravity autonomous agents में अकेला था जिसने oculus के जरिए दिखने वाला दोहराया गया चौकोर coffered ceiling pattern लागू किया
  • बाहरी परिणाम में वे तत्व भी शामिल थे जो तेज़ OpenSCAD outputs में अक्सर छूट जाते हैं
    • धूसर और लाल रंग का मिला-जुला column material
    • पढ़ी जा सकने वाली inscription
    • stepped roof rings
    • rotunda, middle block, portico और dome के बीच का व्यापक संबंध
  • Quality score 4.5/5 और speed score 1/5 था
  • यह तेज़ नहीं था, लेकिन इस benchmark में autonomous generation की upper bound को ऊपर ले गया, और Flash 3.5 planning, rendering, inspection और fixing tools के साथ मिलकर spatial code generation के लिए आशाजनक दिखा

ModelRift / Gemini Flash 3.0

  • Explore 3D result
  • यह परिणाम ModelRift और Gemini Flash 3.0 का उपयोग करने वाली human-in-the-loop प्रक्रिया से बना, इसलिए यह शुरुआती चार runs की तरह autonomous single-pass benchmark नहीं था
  • Workflow में लगभग 10 मिनट लगे, जो Claude Code के समय का लगभग 2 गुना था, इसलिए इसे भी 1/5 speed score मिला
  • यह benchmark 21 मई 2026 को, Gemini 3.5 Flash के सार्वजनिक होने के तुरंत बाद चलाया गया
  • Antigravity का परिणाम दिखाता है कि 3.5 Flash मजबूत है, लेकिन ModelRift की default model selection में quality के साथ cost और latency भी देखनी पड़ती है
  • Google के Gemini API pricing में Gemini 3.5 Flash की standard pricing input के लिए 1 million tokens पर $1.50 और output के लिए 1 million tokens पर $9.00 दी गई है, जबकि Gemini 3 Flash के लिए input $0.50 और output $3.00 है
  • Gemini 3.5 Flash, पिछले Flash generation की तुलना में 3x cost increase है, और पुराने Gemini 1.5 Flash दौर की लागत से भी काफी अधिक है
  • Quality 3.8/5 रही, जो पहले के autonomous batch runs से बेहतर थी
  • Model परफेक्ट नहीं था, लेकिन portico, column placement, roof, dome ribs और overall massing अधिक consistent थे
  • मुख्य अंतर यह था कि मौजूदा render पर सीधे visual feedback जोड़ा जा सकता था
  • ModelRift workflow इस तरह बनाया गया है कि model generation, browser inspection, render पर visual notes लिखना, और AI से OpenSCAD changes मांगना—इन सबको दोहराया जा सके
  • Spatial CAD work में यह loop सिर्फ text instructions देने की तुलना में कहीं अधिक सटीक है

प्रमुख autonomous run परिणाम

  • Codex 5.5 High

    • Explore 3D result
    • Codex 5.5 High ने सबसे dense model बनाया
    • इसमें rotunda, dome ribs, oculus, layered masonry bands, front portico, columns, surrounding plinth detail और entablature text शामिल थे
    • Entablature में M AGRIPPA L F COS TERTIVM FECIT शामिल था
    • OpenSCAD में text modeling के लिहाज़ से कठिन तत्व है, क्योंकि इसके लिए placement, extrusion, orientation और पतली thickness बनाए रखना पड़ता है
    • Iteration के दौरान render preview, final exported STL से बेहतर दिख रहा था
    • Final result में entablature और portico roof area में problematic ceiling-like surface बन गई, जिससे front assembly का impression बदल गया
    • Codex ने मजबूत spatial reasoning और high-detail ambition दिखाई, लेकिन इससे यह export risk भी सामने आया कि preview accuracy हमेशा final mesh accuracy जैसी नहीं होती
    • अगर सार्वजनिक STL के बजाय सबसे अच्छे PNG preview के आधार पर मूल्यांकन होता, तो इसकी structure और detail इसे Antigravity 2.0 के ठीक नीचे रखती
    • 3.0/5 score में model की design intent से ज्यादा final export/render mismatch की penalty का असर था
  • Claude Sonnet

    • Explore 3D result
    • Claude Sonnet ने मौजूदा autonomous batch runs में सबसे साफ-सुथरा मॉडल बनाया
    • इसने Codex जितनी fine detail की कोशिश नहीं की, लेकिन silhouette ज्यादा साफ था और मुख्य architectural parts अधिक स्वाभाविक रूप से जुड़ते थे
    • Dome, drum, portico और column layout अलग-अलग primitives के समूह की तरह नहीं, बल्कि एक इमारत की तरह पढ़े जाते थे
    • Proportions भी अधिक नियंत्रित थे, और Antigravity run से पहले यह सबसे मजबूत fully autonomous result था
    • Claude Code इस benchmark में Codex से लगभग 2–3 गुना धीमा था, और Sonnet ने अच्छी quality के बावजूद सबसे कम time score पाया
    • Quality score 3.4/5 था, लेकिन यह अभी भी production-quality architectural reconstruction नहीं, बल्कि एक approximate model ही था
  • Cursor Composer

    • Explore 3D result
    • Cursor और Composer 2.5 का संयोजन सबसे तेज़ run था, लेकिन परिणाम सबसे कमजोर रहा
    • इसने rotunda, dome, portico और columns जैसे बड़े gestures सही पकड़े
    • लेकिन Pantheon को पहचानने योग्य बनाने वाली material restraint और architectural nuance छूट गए
    • Output एक finished model से अधिक simplified placeholder जैसा था, और public release से पहले काफी rework की जरूरत थी
  • Claude Opus

    • Explore 3D result
    • Claude Opus, Cursor और Sonnet के बीच में रहा
    • इसने Cursor से अधिक complete building बनाई और portico व stepped plinth को ज्यादा स्पष्ट किया
    • लेकिन output बहुत uniform था और Sonnet जितना convincing नहीं लगा
    • Structure मौजूद थी, लेकिन visual hierarchy का आकलन कमजोर था
    • लगभग सभी elements का color और weight एक जैसा था, इसलिए details नजर को दिशा देने के बजाय एक-दूसरे से प्रतिस्पर्धा कर रही थीं
    • Updated score 3.0/5 था; यह शुरुआती table version से बेहतर माना गया, लेकिन Sonnet और Antigravity से पीछे रहा

मुख्य सीख

  • OpenSCAD target language के रूप में अच्छी तरह टिका रहा
    • इसका syntax छोटा है, output deterministic है, और CLI iteration loop में inspect करने योग्य preview render करता है
    • LLMs को OpenSCAD इस्तेमाल करने के लिए किसी विशेष सहारे की जरूरत नहीं पड़ी
  • Tool usage bottleneck नहीं था
    • सभी agents ने macOS PATH में OpenSCAD को call किया और PNG previews render किए
    • मुश्किल हिस्सा plumbing नहीं, बल्कि geometry judgment था
  • Speed, quality की भविष्यवाणी नहीं कर सकी
    • Cursor सबसे तेज़ था, लेकिन सबसे कमजोर परिणाम दिया
    • Sonnet मौजूदा autonomous runs में सबसे धीमा था, लेकिन सबसे साफ मॉडल लेकर आया
    • Antigravity भी धीमा था, लेकिन Gemini 3.5 Flash High ने planning और iteration time मिलने के बाद सर्वोत्तम autonomous result दिया
    • ModelRift/Gemini Flash 3.0 ने अधिक समय लिया, लेकिन visual feedback की वजह से पहले के autonomous batch से बेहतर quality हासिल की
  • Preview और export एक जैसी चीज़ें नहीं हैं
    • Codex render loop में मजबूत दिखा, लेकिन final STL में portico roof के आसपास geometry issues आ गए
    • Print-targeted models के लिए सिर्फ preview नहीं, exported mesh की अलग से जांच जरूरी है
  • कोई भी output faithful architectural model की कसौटी पर पास नहीं हुआ
    • Codex की inscription एक अच्छी detail थी
    • Sonnet के proportions consistent थे
    • Antigravity की coffered ceiling सबसे चौंकाने वाली detail थी
    • ModelRift/Gemini Flash 3.0 का परिणाम दिखाता है कि जब इंसान visual tuning करता है तो quality कैसे ऊपर जाती है
  • सिर्फ दो reference images और छोटे prompt के साथ, सभी systems बिना हाथ से सीधे CAD code लिखे valid, renderable OpenSCAD तक पहुंच गए
  • Tools के बीच quality gap बड़ा था, लेकिन शुरुआती baseline खुद अपेक्षा से अधिक ऊंची थी
  • पूर्ण autonomous generation अभी इस तरह के काम के लिए सही workflow नहीं है
    • ModelRift अब भी iteration के लिए Annotation Mode का उपयोग करता है
    • इसमें 3D model screenshots पर सीधे arrows और notes बनाकर AI को वापस भेजा जाता है
    • Spatial geometry में, top-tier model इस्तेमाल करने पर भी human-in-the-loop चरण महत्वपूर्ण रहता है
    • Model बड़े massing को सही पकड़ सकता है, लेकिन column positions या dome proportions गलत कर सकता है
    • Render पर सीधे समस्या दिखाना, उसे text में समझाने की तुलना में तेज़ और अधिक सटीक है

1 टिप्पणियां

 
GN⁺ 6 시간 전
Hacker News की राय
  • पिछले हफ़्ते मैंने Marketplace से अपनी पत्नी की साइकिल खरीदी। हालत अच्छी थी, लेकिन internal cable routing rubber grommet में से एक गायब था
    मैंने Claude को गोली-जैसे आकार वाले छेद की एक फोटो, और digital calipers से उसकी लंबाई व चौड़ाई नापी हुई एक और फोटो दी। सिर्फ़ एक छोटे prompt से उसने ऐसा OpenSCAD मॉडल बना दिया जिसमें सारे dimensions parameterized थे
    मैंने उसे TPU में बिना किसी बदलाव के प्रिंट किया, और पहली कोशिश में ही वह लगभग परफ़ेक्ट था। Claude ने x/y dimensions में 0.3mm घटाने का प्रावधान रखा था, जिसे मैंने 0.1mm किया और वह बिल्कुल फ़िट हो गया। यह प्राचीन रोमन वास्तुकला से काफ़ी आसान आकार है, लेकिन फिर भी इसका इतना आसान होना काफ़ी शानदार लगा

    • CAD मेरे लिए निजी तौर पर entry barrier बहुत ऊँचा होने की वजह से न अपनाई गई तकनीक का उदाहरण था, लेकिन अब ऐसा लगता है कि कम-से-कम साधारण काम तो किसी तरह किए जा सकते हैं
      OpenSCAD और LLM के साथ 3D printer के लिए simple functional parts बनाने का मेरा अनुभव भी ऐसा ही रहा। मुझे पता है कि मॉडल React code generation जितने अच्छे नहीं हैं, और मैं भी किसी skilled operator के बिल्कुल उलट हूँ। फिर भी, शौकिया स्तर पर नई तकनीक सीखना शुरू करवा देना अपने आप में काफ़ी बढ़िया है
    • Claude सारे dimensions दिए जाएँ तो अच्छा काम करता है, लेकिन अनुमान लगाने में कमज़ोर है
      असली जादू तो तब होगा जब आप सिर्फ़ एक dimension या scale वाली एक फोटो दें और AI बाक़ी खुद निकाल ले, लेकिन कम-से-कम अभी का Claude अनुमान लगाने में काफ़ी कमज़ोर है
    • हाल ही में मैंने मॉडलों से 3D fortune cookie बनवाने की कोशिश की। Claude ने three.js में और Gemini ने OpenSCAD में कोशिश की, लेकिन दोनों ही concept ठीक से नहीं पकड़ पाए और पास भी नहीं पहुँचे। लगता है यह उम्मीद से ज़्यादा जटिल shape है
    • ऐसे छोटे functional prints ही वह क्षेत्र हैं जहाँ OpenSCAD और LLM generation सच में चमकते हैं
    • क्या यह support की ज़रूरत न पड़े, इस तरह optimize भी करता है?
  • यह बात सच में प्रभावशाली है कि “Antigravity ही एकमात्र autonomous agent था जिसने Pantheon के प्रतिष्ठित अंदरूनी ceiling pattern — यानी oculus से दिखाई देने वाली दोहराई जाने वाली square coffered ceiling — को लागू किया”
    3D मॉडल देखने के बाद भी, यह वाक्य पढ़ने तक मैंने इमारत के अंदर देखने का सोचा तक नहीं था
    show_cutaway चालू किया हुआ 3D मॉडल यहाँ है: https://modelrift.com/models/pantheon-benchmark-antigravity-...

    • मॉडल बनाने के लिए prompt में साफ़ तौर पर न दी गई बाहरी जानकारी का उपयोग करना अच्छा है या बुरा, इस पर मैं निर्णय नहीं कर पा रहा हूँ
      अगर आपको “Pantheon” चाहिए, तो यह स्पष्ट रूप से सही व्यवहार है, लेकिन किसी drafter या engineer के लिए ऐसी output स्वीकार करना मुश्किल हो सकता है
    • संयोग से अंदर देखा, और बाहर की तुलना में वहाँ बुद्धिमत्ता और मेहनत ज़्यादा साफ़ दिखी
  • Antigravity ने चाहे जिस benchmark में पहला स्थान पाया हो, मेरे यहाँ Gemini CLI को ज़बरदस्ती replace करने वाला Antigravity हर बार इस्तेमाल पर browser login माँगता है, और Antigravity IDE तो अपडेट ही नहीं होता
    अगर संभव हो, तो किसी चीज़ में पहला स्थान पाने की चिंता करने से पहले कम-से-कम स्वीकार्य deployment quality तो ठीक कर देनी चाहिए
    असली शीर्षक है “OpenSCAD LLM Benchmark: Building the Pantheon”

    • सहमत। Google AI products को लेकर मेरी सबसे बड़ी चिंता login, billing, upgrade और product shutdown के आसपास का लगातार चलने वाला user-experience दर्द है
      फिर भी LLM model ख़ुद अच्छे हैं और Antigravity 2.0 भी इतना बुरा नहीं है। लेकिन अगर बहुतों की तरह आपने Antigravity 1.0 की settings और projects खो दिए हों, तो बात अलग है
    • Google I/O देखने के बाद Google की execution क्षमता पर मेरा भरोसा और कम हो गया
      Gemini 3.5 Flash अजीब है। उसका cutoff पुराना है, कुछ मामलों में वह 3.1 Pro से बेहतर है लेकिन कुछ में कमज़ोर, और कभी सस्ता है तो कभी 3.1 Pro से महँगा
      Antigravity छोड़ा हुआ-सा लग रहा था और लोग उसके बंद होने की अटकलें लगा रहे थे, और फिर सभी को नए Antigravity पर ले जाकर कुछ हद तक वही हुआ भी
      Google ऐसा लगता है जैसे उसने अपना org chart ही product के रूप में ship कर दिया हो, और AI products इतने ज़्यादा हैं कि उनमें से कोई भी best-in-class नहीं लगता। उदाहरण के लिए, Google Docs में Gemini integration, Claude से कमज़ोर है
      उम्मीद यह थी कि “Haiku cost पर Opus-स्तर की intelligence” या “Gemini 3.0 price पर Sonnet-स्तर का performance” मिलेगा। इनमें से एक भी आ जाता, तो वह flagship model और Claude/Codex competitor बन सकता था, लेकिन दोनों में से कुछ नहीं मिला
    • मैं Claude Code और IntelliJ इस्तेमाल करता हूँ, इसलिए मुझे ठीक से समझ नहीं आता कि Antigravity के VS Code छोड़ने पर इतने लोग क्यों शिकायत कर रहे हैं
      मैं जानना चाहता हूँ कि Antigravity CLI + VS Code या किसी दूसरे IDE के साथ कौन-सी ज़रूरत पूरी नहीं होती
    • Gemini CLI, जो मुझे पसंद था और कुछ मामलों में Claude Code से बेहतर भी लगा, उससे forced upgrade किया जाना भी बुरा था
      लेकिन बुधवार को आया ईमेल — “Google One AI Pro subscription के लिए धन्यवाद, लेकिन अब से हम आपके account पर limits जोड़ रहे हैं, कुछ नहीं किया जा सकता” — सच में बहुत बुरा लगा। पहले मैं AI Pro subscription को अच्छी value कहकर सराह चुका था
    • workflow टूटना ही वह मुख्य कारण है जिसकी वजह से Antigravity पसंद होने के बावजूद मैंने उसे नहीं अपनाया
      अच्छा है कि Google निवेश कर रहा है, लेकिन उम्र बढ़ने के साथ मैं अपने workflow को और ज़्यादा बचाकर रखना चाहता हूँ
  • मैंने OpenSCAD के लिए हर तरह के models और settings पर बहुत benchmarks चलाए हैं, और मेरी सीख यह है
    मॉडल असंगत होते हैं, इसलिए किसी एक तरह के 3D model में वे शानदार हो सकते हैं, लेकिन दूसरे प्रकार में नहीं
    मेरे अनुभव में Gemini models सबसे कम असंगत थे और उनकी image understanding सबसे अच्छी थी
    Gemini models सबसे creative भी हैं, लेकिन अगर आपको precise CAD parts चाहिए, तो यह उल्टा नुकसान भी हो सकता है
    कुल मिलाकर यह benchmark बहुत कुछ साबित नहीं करता। एक 3D model और सिर्फ़ एक कोशिश काफ़ी नहीं है। मैं आम तौर पर कम-से-कम 12 models को 3-3 बार generate करके test करता हूँ, लेकिन सच कहूँ तो इससे भी ज़्यादा करना चाहिए। बस individual developer के लिए इसकी लागत बहुत अधिक हो जाती है
    फिर भी इसे प्रकाशित करने के लिए धन्यवाद, और मैं जल्द ही Flash 3.5 को चलाकर देखूँगा कि वह कैसा perform करता है

    • मेरे हिसाब से OpenSCAD curves संभाल नहीं पाता, इसलिए वह बेकार है। समझ नहीं आता कि उसे बार-बार इतना ध्यान क्यों मिलता है
  • LLM की वैध 3D CAD models generate करने की क्षमता के आधार पर उसका मूल्यांकन करना काफ़ी दिलचस्प benchmark है
    OpenSCAD पूरी तरह code पर निर्भर है, इसलिए इस तरह के मूल्यांकन के लिए यह खास तौर पर उपयुक्त है

  • मैंने ख़ुद आज़माया, और अनुभव काफ़ी खराब था। पहली कोशिश में कोई ठीक-ठाक draft मिल सकता है, लेकिन जैसे ही आप उसे “debug” करना शुरू करते हैं, बहुत निराशाजनक session के बाद समझ आता है कि मॉडल नतीजे को ठीक से “देख” ही नहीं पा रहा
    यानी यह बिल्कुल भी iterative improvement नहीं कर पाता
    ज़्यादातर execution tools या harnesses image process करने से पहले उसका size कम कर देते हैं, और उस प्रक्रिया में, खासकर wireframe images में, इतनी detail खो जाती है कि reasoning करना मुश्किल हो जाता है
    हो सकता है मैं इसे ग़लत इस्तेमाल कर रहा हूँ, लेकिन इस test ने उस हिस्से की वास्तव में जाँच नहीं की। यह बस one-shot कोशिश थी, और ऐसा तरीका बहुत जल्दी टूट जाता है। खासकर तब जब आप जो बनाना चाहते हैं उसकी reference photo भी न हो

  • वास्तविक दुनिया की सिर्फ़ एक वस्तु बनाकर उसे benchmark घोषित कर देना मज़बूत tool evaluation तरीका नहीं है
    इसे Iron Chef की तरह होना चाहिए, जहाँ Greek architecture theme दिया जाए और judges panel विजेता चुने। अभी तो बस यह देखा जा रहा है कि किस tool ने subjectively सबसे विश्वसनीय Pantheon बनाया

    • यह benchmark से ज़्यादा “मुझे यह पसंद आया!” जैसा लगता है
      एक अकेले, ठीक से परिभाषित न किए गए उदाहरण को लेकर, बिना किसी end use case के, पूरी तरह subjective scoring criteria पर मूल्यांकन हो रहा है
  • Autodesk को short करने में अभी देर है
    जानकारी के लिए, Autodesk ने दिसंबर में Fusion के लिए agentic assistant जारी किया था, और 6 महीने बाद भी वह काफ़ी खराब है

    • लगभग हास्यास्पद रूप से खराब है
      पिछले कुछ हफ़्तों में मुझे 3D printing के लिए कुछ साधारण parts design करने थे, इसलिए मैंने इसे आज़माया। हर part timeline में लगभग 4 operations वाला ही था, फिर भी Fusion terminology के अनुसार step-by-step विस्तार से लिखने पर भी यह चाही हुई चीज़ के करीब नहीं पहुँचा
      अब तो मुझे भरोसा नहीं कि यह simple basic solids भी ठीक से बना सकता है
    • क्या आपने पिछले महीने जारी हुआ Fusion MCP आज़माया? https://aps.autodesk.com/blog/bringing-fusion-claude-creativ...
    • अभी काफ़ी दूरी तय करनी है, लेकिन आख़िरकार वहाँ पहुँच जाएगा, ऐसा मुझे लगता है
  • बात पूरी तरह समझ में नहीं आती। Pantheon इतिहास की सबसे प्रतिष्ठित इमारतों में से एक है, उस पर बहुत साहित्य है, और training में इस्तेमाल हुई पुरानी photos व public models भी बहुत होंगे
    सिर्फ़ दिए गए reference के आधार पर किसी अनाम संरचना को model करने वाला benchmark ज़्यादा दिलचस्प होता। यह कुछ वैसा लगता है जैसे LLM को एक ही बार में todo app बनाते देखकर होने वाला सतही जादू

  • मैं parenting के लिए एक tech device बना रहा हूँ, और उसका enclosure पूरी तरह AI-generated था
    मुझे 3D modeling कहाँ से शुरू करनी है, इसका बिल्कुल पता नहीं था, लेकिन LLM ने बताया कि यह भी बाक़ी चीज़ों की तरह code है
    अजीब तरह से Opus 4.5 ने इसे एक ही बार में परफ़ेक्ट बना दिया था। यह performance degradation विवाद से ठीक पहले की बात थी, और उसके बाद enclosure में बहुत छोटा बदलाव करना भी बेहद मुश्किल हो गया
    लगता है Opus एक ऐसे model से बदलकर, जो दिमाग़ में shapes को पेशेवर स्तर पर घुमा-फिरा सकता था, ऐसे model में बदल गया जो यह भी नहीं समझता कि वह किस चीज़ से काम कर रहा है

    • मेरा enclosure भी कुछ ऐसा ही था: https://quill.lorehex.co/feather
      हालाँकि 4.7 edits के लिए ठीक-ठाक था