Fidget: बड़े पैमाने के गणितीय expression evaluation की library

 (mattkeeter.com)
3 पॉइंट द्वारा GN⁺ 2025-01-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Fidget सैकड़ों से लेकर हजारों arithmetic clauses से बने mathematical expressions को represent, compile और evaluate करने वाली Rust library है; इसका मुख्य उपयोग implicit surfaces के backend के रूप में है
  • implicit surfaces, $f(x,y,z) \rightarrow d$ रूप की distance function से अंदर और बाहर को अलग करती हैं, और CSG operations व parallel evaluation के लिए अच्छी तरह फिट बैठती हैं
  • frontend Rhai scripts से mathematical tree, DAG, SSA tape और reusable register-आधारित bytecode तक जाने वाली pipeline देता है
  • backend interpreter और JIT compiler देता है, और single point, SIMD arrays, forward automatic differentiation और interval arithmetic evaluation को support करता है
  • 7867 expressions के 1024² brute force evaluation में JIT ने 5.8 सेकंड को घटाकर 182ms कर दिया, लेकिन optimized rendering में अंतर 6ms और 4.6ms के साथ करीब 25% तक सिमट गया

Fidget के लक्ष्य और implicit surfaces

  • Fidget बड़े पैमाने के mathematical expressions को represent, compile, evaluate करने के लिए एक library है
    • यह सैकड़ों से हजारों arithmetic clauses संभालने वाले expressions को target करती है
    • मुख्य उपयोग implicit surfaces के backend के रूप में है, लेकिन इसे अन्य कामों में भी इस्तेमाल किया जा सकता है
  • implicit surface $f(x, y, z) \rightarrow d$ रूप का expression होती है, जो एक single distance value $d$ लौटाती है
    • अगर $d$ positive है, तो point $(x,y,z)$ model के बाहर है
    • अगर $d$ negative है, तो point model के अंदर है
    • radius 1 वाला sphere $\sqrt{x^2 + y^2 + z^2} - 1$ से represent किया जा सकता है
  • Fidget basic arithmetic operations से expressions बनाने वाली closed-form implicit surfaces पर focus करता है
    • यह pixel shader के GLSL की तरह Turing-complete program से distance value calculate करने के तरीके के विपरीत है
    • ऐसी functions हाथ से सीधे लिखने की बजाय, higher-level representations के लिए target करना आसान “shape की assembly language” जैसी होती हैं

implicit surfaces कहाँ फायदेमंद हैं

  • implicit surfaces compact और parallel evaluation के लिए उपयुक्त होती हैं
    • SIMD instructions या GPU का उपयोग करने वाले बड़े पैमाने के parallel evaluation के लिए फिट होती हैं
  • CSG operations सरल हो जाते हैं
    • mesh या NURBS में कठिन union, intersection जैसे operations को आसानी से express किया जा सकता है
    • ठीक-ठीक overlap कर रहे दो cylinders का union min(a, b) से represent होता है
  • closed-form equations optimization के मौके बनाती हैं
    • Fidget evaluation के दौरान कौन-सी branch चुनी गई, यह दिखाने वाला execution trace capture कर सकता है
    • इस trace का उपयोग expression को simplify करने और बाद के evaluation cost को घटाने में होता है

libfive के बाद नया बनाने की वजह

  • Fidget, मौजूदा libfive kernel को replace करने के लिए बनाई गई नई library है
    • libfive लगभग 40K lines के ज्यादातर C++ code से बना है
    • मूल लेखक के लिए भी इसमें बदलाव करना मुश्किल था, और कुछ महीनों बाद दोबारा compile करने पर build टूट जाता था, इसलिए CMake में छेड़छाड़ करनी पड़ती थी
  • नया implementation अभी दिलचस्प सवालों पर प्रयोग करने का base है
    • implicit kernel के लिए सही API खोजना, और compatibility तोड़ने की संभावना भी खुली रखना
    • GPU पर ले जाए बिना performance बढ़ाने के लिए native JIT compilation पर प्रयोग करना
    • WebAssembly में cross-compile करके आसानी से access होने वाले web demos बनाना
  • Fidget Rust में लिखा गया है
    • सिर्फ cargo build से compile हो जाता है
    • WebAssembly में स्वाभाविक रूप से cross-compile होता है
    • Rust के मजबूत type system और memory safety के कारण refactoring में भरोसा अधिक रहता है

frontend: script से bytecode तक

  • Fidget frontend input script से bytecode तक जाने वाली pipeline देता है
    • user को यह पूरा flow अनिवार्य रूप से follow करने की जरूरत नहीं है; library को किसी भी intermediate stage पर इस्तेमाल किया जा सकता है

  • Rhai scripting

    • Fidget में Rust के लिए embedded scripting language Rhai bindings शामिल हैं
    • operator overloading के जरिए scripts में mathematical expressions बनाए जा सकते हैं
    • draw को दी जाने वाली value, script द्वारा बनाए गए expression को दर्शाने वाला mathematical tree है

  • tree, graph, SSA tape

    • mathematical tree duplicate removal के बाद directed acyclic graph (DAG) में convert होता है
    • topological sorting के जरिए graph को straight-line code में flatten किया जाता है
    • यह code SSA(single static assignment) form में होता है
    • arbitrary संख्या में pseudo-registers rX होते हैं, और हर register में सिर्फ एक बार लिखा जाता है
    • SSA tape को भी evaluate किया जा सकता है, लेकिन हर operation के लिए memory location चाहिए, इसलिए scalability कम होती है
    • वजह यह है कि pseudo-registers reuse नहीं होते

  • bytecode और register allocation

    • evaluation efficiency बढ़ाने के लिए pseudo-registers को reusable physical registers पर map किया जाता है
    • example SSA tape को 6 reusable registers में compress किया जा सकता है
    • register allocation पहले पेश किए गए simple algorithm का उपयोग करता है
    • यह single-pass algorithm है, जो efficiency से ज्यादा speed और determinism को प्राथमिकता देता है
    • bytecode interpreter 256 registers का उपयोग करता है
    • register index u8 में store होता है
    • registers कम पड़ने पर allocator LOAD और STORE insert करके u32 index वाली auxiliary memory में लिखता है

backend: evaluation methods और simplification

  • Fidget backend Function, TracingEvaluator, BulkEvaluator traits के जरिए frontend से अलग किया गया है
    • algorithms mathematical tree implementation से tightly coupled नहीं रहते और generic Function को target कर सकते हैं
    • फिलहाल Function trait का कोई non-mathematical-tree implementation नहीं है
  • अभी mathematical tree evaluation के दो तरीके हैं
    • bytecode interpreter
    • JIT-compiled function

  • evaluation modes

    • Fidget चार evaluation modes देता है
      • single point evaluation
      • array-based SIMD evaluation
      • forward automatic differentiation
      • interval arithmetic
    • bulk evaluation में user input values की array देता है और output array पाता है
    • JIT backend SIMD code generate करता है, जो AArch64 पर एक बार में 4 elements और x86-64 पर 8 elements process करता है

  • forward automatic differentiation

    • differentiation evaluator value और अधिकतम 3 partial derivatives calculate करता है
    • implicit surfaces में आम तौर पर $(f, \partial f/\partial x, \partial f/\partial y, \partial f/\partial z)(x,y,z)$ calculate किया जाता है
    • surface पर जब $f(x,y,z)=0$ हो, तो partial derivatives surface normal का अच्छा approximation होते हैं
    • इस value को shading में इस्तेमाल किया जा सकता है
    • evaluation forward automatic differentiation से होती है
    • register values के साथ derivative values जोड़ी जाती हैं और हर step पर chain rule apply होता है
    • JIT evaluator value और 3 derivatives को एक 4 x f32 register में रखता है

  • interval arithmetic

    • interval arithmetic single input value की जगह input values की range evaluate करता है
    • उदाहरण के लिए $x=1$ की जगह $1 \le x \le 5$ इस्तेमाल किया जा सकता है
    • output भी $2 \le f(x,y,z) \le 20$ जैसा interval बनता है
    • interval arithmetic के results conservative होते हैं
      • वे actual function range को बहुत tight तरीके से cover न कर पाएं
      • लेकिन दिए गए input interval के भीतर सभी possible outputs को शामिल करते हैं
    • implicit surface evaluation में interval arithmetic एक core building block है
    • अगर किसी spatial region को $x,y,z$ intervals के रूप में evaluate करने पर output interval साफ तौर पर 0 से बड़ा है, तो वह पूरा region shape के बाहर है, इसलिए आगे देखने की जरूरत नहीं

  • trace-based simplification

    • interval arithmetic evaluator execution trace भी capture करता है
    • min(a,b) में अगर $0 \le a \le 1$, $4 \le b \le 5$ हो, तो a हमेशा छोटा है, इसलिए expression को a में simplify किया जा सकता है
    • हर min और max operation result को प्रभावित करने वाले argument को record करता है
    • left, right, या both में से किसी एक को selection के रूप में record किया जाता है
    • इस selection का उपयोग original function simplification में किया जाता है
    • Fidget CSG में इस्तेमाल होने वाले min·max और logical operations and·or simplification को support करता है
    • जिन shapes में CSG या logic नहीं है, उन्हें simplification का फायदा नहीं मिलता
    • फिर भी interval arithmetic के आधार पर empty regions या fully filled regions को skip करने का फायदा बना रहता है

Interval arithmetic और tape simplification का संयोजन

  • Interval arithmetic और tape simplification का संयोजन बड़े expressions को संभालना आसान बनाने वाली मुख्य तकनीक है
    • निष्क्रिय space regions को skip करता है, और बचे हुए सक्रिय regions की evaluation को भी सस्ता बनाता है
  • Tape simplification किसी खास space region में ही मान्य simplified expression को compute करने की विधि है
    • सामान्य ray tracing acceleration structures के विपरीत, यह evaluation के दौरान dynamically acceleration structure बनाने जैसा है
  • Rasterization में interval evaluation की लागत कई pixels में बंट जाती है
    • $N \times N$ pixel region की interval evaluation tape length $T$ के proportional $O(T)$ होती है
    • यह pixels की संख्या पर निर्भर नहीं करती
  • छोटे regions तक उतरने के बाद per-pixel evaluation करते समय काफी छोटी हो चुकी tape का उपयोग होता है
    • $M \times M$ region में लागत $O(T' \times M \times M)$ होती है
    • यहां $T' < T$ है
  • 256×256 2D hello, world rendering example की original tape 254 clauses की है
    • 32×32 pixel tiles के 64 tiles को interval-evaluate किया जाता है
      • खाली regions को skip करके 47 active tiles बचते हैं
      • active tiles की average tape length घटकर 73 clauses हो जाती है
    • हर tile को 16 8×8 pixel tiles में subdivide किया जाता है
    • 8×8 pixel tiles के 752 tiles को interval-evaluate किया जाता है
      • खाली regions को skip करके 351 active tiles बचते हैं
      • active tiles की average tape length घटकर 20 clauses हो जाती है
    • बचे हुए 351 8×8 tiles पर per-pixel evaluation की जाती है
  • Per-pixel evaluation के समय तक tape अपनी original length से 10 गुना से ज्यादा छोटी हो जाती है

JIT compilation

  • Bytecode interpreter tight loop है, लेकिन इसमें unavoidable overhead होता है
    • Instruction dispatch एक single branch है जिसका prediction मुश्किल है
    • हर instruction VM evaluator के register slots के जरिए memory पढ़ता और लिखता है
  • Fidget maximum performance के लिए bytecode को machine code में lower करने वाला JIT compiler शामिल करता है
    • Machine instructions dispatch-रहित straight-line code होते हैं
    • Physical registers का सीधे उपयोग होने से memory read/write घटता है
  • JIT input वही पुरानी bytecode tape है
    • VM के default 255 registers के बजाय x86-64 में 12 और AArch64 में 24 physical registers के हिसाब से plan किया जाता है
    • AArch64 में v8-31, और x86-64 में xmm4-15 पर map किया जाता है
  • हर opcode × data type × architecture combination के लिए assembly snippets हाथ से लिखे जाते हैं
    • इच्छित physical registers को snippet में patch करके mmap की गई memory region में copy किया जाता है
  • Rust level पर generated memory को function pointer में cast करके call किया जाता है
    • Input और output Rust slices को raw pointer में cast करके pass किए जाते हैं

  • Performance numbers

    • 7867 expressions से बने complex example में 1024² pixels की brute force evaluation पर JIT का असर बड़ा है
    • Bytecode interpreter: 5.8 seconds
    • JIT backend: 182ms
    • Speedup: 31×
    • brute force interval arithmetic या tape simplification का उपयोग नहीं करता
    • ज्यादा smart algorithm इस्तेमाल करने पर अंतर घट जाता है
    • Fidget का optimized rendering implementation उसी image को bytecode interpreter से 6ms और JIT backend से 4.6ms में draw करता है
    • इस case में improvement लगभग 25% है

Rendering और mesh generation

  • Rendering

    • सभी model rendering fidget::render के algorithms का उपयोग करती है
    • Rendering SIGGRAPH paper के core algorithm का उपयोग करती है
    • बड़े space regions को interval arithmetic से render किया जाता है
    • Tracing-based तरीके से छोटी हुई tapes बनाई जाती हैं
    • Ambiguous regions को subdivide करके recursively process किया जाता है
    • 3D rendering में partial derivatives से normals compute किए जाते हैं
    • Model को rendering process के दौरान 4×4 homogeneous matrix से transform किया जाता है
    • Perspective transform support है
    • Rendering result आम तौर पर दो images होते हैं: heightmap और per-pixel normals
    • Result को SSAO जैसी standard deferred rendering techniques से draw किया जा सकता है

  • Mesh generation

    • Fidget mesh generation के लिए Manifold Dual Contouring implement करता है
    • इस implementation को हमेशा निम्न properties वाला mesh बनाना चाहिए
      • watertight
      • manifold
      • sharp edges और corners का preservation
      • अधिकतर flat regions में triangle density कम करने वाली adaptive property
    • कुछ ज्ञात कमियां भी हैं
      • पतली features को जरूरी नहीं कि preserve करे
      • result mesh में self-intersections हो सकते हैं
      • vertex placement adversarial cases के प्रति vulnerable है
    • Arbitrary implicit surfaces की अच्छी mesh generation अभी भी unsolved problem है
    • Manifold Dual Contouring perfect नहीं है, लेकिन simplicity और performance के बीच balance point पर है

Demos और web GUI

  • Fidget repository में कई demos शामिल हैं
    • Web GUI को सबसे interesting demo के रूप में पेश किया गया है
    • Simple CLI fidget-cli और native script viewer fidget-viewer भी हैं
  • Web demo कई web technologies को combine करता है
    • GUI TypeScript में लिखा गया है
    • Fidget crate event loop को drive नहीं करता, बल्कि library के रूप में use होता है
    • Text editor CodeMirror का उपयोग करता है
    • Node modules इस्तेमाल करने के लिए bundler की जरूरत थी, और webpack चुना गया
    • Script evaluation और rendering main event loop को block न करें, इसलिए वे web worker में किए जाते हैं
    • Browser में std::thread की अनुपस्थिति को bypass करने के लिए wasm-bindgen-rayon से rendering parallelize की जाती है
    • worker और main event loop memory share करते हैं
    • जब user नया input देता है, तो worker के साथ shared Arc<AtomicBool> flag से लंबी चल रही rendering cancel की जा सकती है
  • कई components को साथ काम करवाने की प्रक्रिया मुश्किल थी
    • हर component के working examples थे, लेकिन bundler, settings, server वगैरह अलग-अलग थे
    • wasm-bindgen के recent bug fix ने wasm-bindgen-rayon के लिए जरूरी behavior बदल दिया था, इसलिए पुराना version pin करना पड़ा
  • Web demo phones पर भी काम करता है
    • यह mouse events का उपयोग कर रहा है, इसलिए camera controls supported नहीं हैं

Demo और library के बीच तनाव

  • Fidget सबसे पहले library है
    • Intended use यह है कि users demo को असली CAD tool की तरह इस्तेमाल करने के बजाय इसे अपने projects में infrastructure के रूप में embed करें
  • लेकिन demo आजमाने वाले लोग library से tools बनाने वालों से कहीं ज्यादा हैं
    • कुछ लोग demo को design work के लिए इस्तेमाल करने तक लगते हैं
    • बड़े demo user base के लिए demo improve किया जाए या छोटे tool-maker base के लिए library improve की जाए—इस बीच तनाव है
  • Kernel और complete CAD UI को साथ में maintain करना मुश्किल था, और demo scope धीरे-धीरे घटा
    • Web editor जैसा “minimal” demo भी काफी बड़ा project है
  • Plan तीन दिशाओं में है
    • Motivation और focus बनाए रखने के लिए interests को follow करते रहना
    • Tool users के suggestions लेना, लेकिन expectations reasonable रखना
    • Ideally, demo burden कम करने में मदद देने वाले tool makers के feedback को प्राथमिकता देना

आगे की संभावनाएँ

  • GPU backend

    • GPU backend एक स्वाभाविक विस्तार है
    • इससे संबंधित SIGGRAPH paper पहले से मौजूद है
    • wgpu-bytecode branch में यह पहले से implement किया जा चुका है
    • Apple M1 Max laptop के आधार पर performance खास आकर्षक नहीं है
    • bytecode interpreter loop बहुत inefficient दिखता है
    • मूल कारण की जाँच अभी जारी है

  • बेहतर mesh generation

    • गंभीर library users के लिए mesh generation एक बड़ा मुद्दा है
    • Fidget libfive जैसी ही mesh generation strategy इस्तेमाल करता है, लेकिन इसमें libfive के अधिक robust behavior बनाने वाली कई बारीक tunings नहीं हैं
    • अभी उपलब्ध विकल्पों से संतुष्ट न होने के कारण इस हिस्से पर ज़्यादा समय नहीं लगाया गया
    • dual contouring पर परत चढ़ाने के बजाय वे bulletproof mesh algorithm implement करना चाहते हैं
    • requirements पूरी करने वाली literature में कोई method या अपना alternative अभी नहीं है
    • user demand के आधार पर कुछ tuning की जा सकती है, लेकिन बेहतर विकल्पों की तलाश भी जारी रखने की योजना है

  • standard shape और transform library

    • कई generations के software में Fab Modules की standard shape library को नए tools में port किया जाता रहा है
    • यह काम उबाऊ है, लेकिन high-level modeling के लिए कुछ हद तक standard foundation देता है
    • libfive में हर shape C++ में लिखा गया था, और header file से C, Python, Scheme bindings अपने-आप generate किए गए थे
    • README बताता है कि libfive_stdlib.h एक C header भी है और helper script द्वारा parse किया जाने वाला structured document भी
    • Fidget का approach अभी चर्चा में है
    • चल रही चर्चा fidget#145 में है
    • Fab shapes library को Rust में लाने का तरीका संभव है
    • Inigo Quilez की primitives library की तरह GLSL vector का लाभ उठाने वाला अधिक elegant code भी एक reference point है

  • high-level language bindings

    • Fidget फिलहाल केवल Rhai binding देता है
    • Rhai को इसलिए चुना गया क्योंकि यह mature Rust-first scripting languages में से एक है
    • integration आसान था और WebAssembly में compile होने का फायदा है
    • कई users Python या Node bindings पसंद कर सकते हैं
    • binding का तरीका भी एक खुला सवाल है
    • C API हर language की FFI libraries का उपयोग करने देता है, लेकिन Rust-first design में यह एक level नीचे जाने जैसा लगता है
    • standard library बन जाए तो अच्छा होगा कि वह हर binding में docstring, default arguments आदि जैसी उचित usability के साथ अपने-आप expose हो

सार्वजनिक स्थिति और इस्तेमाल का तरीका

  • Fidget का README शुरुआती public release के बाद से इसे “quietly public” स्थिति में बताता रहा है
    • crates.io पर 19 versions publish किए गए हैं
    • कुछ users ने पहले ही Fidget के ऊपर कुछ बनाना शुरू कर दिया है
  • अब Fidget “loudly public” चरण में जा रहा है
  • source code Github पर है
    • Rust project में इसे cargo add fidget से जोड़ा जा सकता है
    • license कमजोर copyleft वाला MPL 2.0 है
    • इसे OSS और commercial use, दोनों के लिए friendly license के रूप में पेश किया गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-01-09
Hacker News की टिप्पणियाँ

  • नमस्ते, यह मेरा प्रोजेक्ट है :)
    CS का यह क्षेत्र मुझे खास तौर पर इसलिए पसंद है क्योंकि इसमें हर किसी के लिए कुछ न कुछ है। इसमें data structures और algorithms, low-level performance work, compilers, rendering/computer graphics, design tools के लिए UI/UX, GPGPU programming — सब शामिल हैं
    मैं thread में दिख रहे सवालों का जवाब दूँगा, लेकिन आगे के अपडेट social media(https://mattkeeter.com/links/) या ब्लॉग के RSS feed(https://mattkeeter.com/atom.xml) से भी follow किए जा सकते हैं

    • ब्लॉग देखते समय मुझे यह मिला, और यह वाकई बहुत अच्छा लगा: https://www.mattkeeter.com/projects/machined-pen/the_plan.jp...
      यह उस विचार को अच्छी तरह दिखाता है जो लंबे समय से मेरे दिमाग में है। क्या हो अगर इस manufacturing plan को design करने की प्रक्रिया ही user-facing CAD API बन जाए? woodworking, plumbing, metal fabrication, machining जैसी “बनाने” वाली समस्याओं में हम स्वाभाविक रूप से raw materials, उपलब्ध tools, और मनचाहा परिणाम पाने के लिए कामों के क्रम के बारे में सोचते हैं
      लेकिन मौजूदा CAD API — चाहे वह code-based CAD tool हो या mouse-based traditional interface — इस तरह काम नहीं करते, और वे इस बात पर ध्यान केंद्रित कराते हैं कि अंतिम shape को कैसे व्यक्त किया जाए, बजाय इसके कि उसे वास्तव में कैसे बनाया जाएगा। आखिरकार महत्वपूर्ण चीज़ वस्तु बनाना है, और modeling तो बस उसमें मदद करने का एक tool है, लेकिन वही tool जरूरत से ज्यादा सामने आ जाता है
      ज़्यादा reality-based modeling workflow के कई फायदे लगते हैं। CAD में आप मुझसे कहीं अधिक अनुभवी हैं, तो क्या आपको लगता है कि इस विचार में आगे बढ़ने की संभावना है, या यह एक dead end है?
      पेन पर एक और feedback जोड़ूँ तो, 3-jaw chuck में bar stock पकड़कर उसे collet के अनुकूल size तक turn किया जा सकता है, फिर उस sized bar से एक cap और दो body parts के लिए blanks काटे जा सकते हैं, और बाकी काम collet में पकड़कर किया जाए तो concentricity बनी रहती है। बस अगर final dimension collet size से अलग हो, तो थोड़ा material waste होता है
    • Matt, एक छोटा-सा सवाल है। मैंने शायद पर्याप्त खोजबीन नहीं की, इसलिए अगर यह बहुत सामान्य या मूर्खतापूर्ण सवाल हो तो क्षमा करें
      functionality के लिहाज़ से Fidget libfive या Ao से कैसे अलग है?
    • बहुत बढ़िया! मुझे याद है कि मैंने SIGGRAPH paper में उद्धृत Knoll et al. 2009 के काम के expression parser code में योगदान दिया था
      वह code बस एक user-friendly single expression को GLSL में IA library के nested function calls में बदल देता था, उसमें कोई optimization नहीं था। यह उससे कहीं आगे जाता दिख रहा है

  • संयोग से मैं अभी लेखक की एक और शानदार पोस्ट पढ़ ही रहा था: https://www.mattkeeter.com/projects/constraints/

  • वाह, काश मुझे इसके बारे में तब पता होता जब मैं अपना खुद का implicit surface renderer बना रहा था
    मेरा approach भी कुछ मायनों में ऐसा ही था (interval arithmetic), और कुछ मायनों में अलग। optimization कम था, और मैंने fragment shader के लिए सीधे GLSL generate किया था
    सच कहूँ तो सब कुछ फेंककर इसे फिर से implement करके उसकी जगह लगाने का मन होता है। समझ नहीं आ रहा कि खुश होऊँ या दुखी

    • आप खुश हो सकते हैं! आखिर आप ऐसे क्षेत्र में काम कर रहे हैं जहाँ आप खुद tools बना सकते हैं और दूसरों के बनाए tools भी इस्तेमाल कर सकते हैं
      आप ideas लेकर उनका उपयोग कर सकते हैं, या इसे इस्तेमाल करते हुए project में योगदान भी दे सकते हैं। दोनों ही शानदार हैं

  • एक नया open source CAD kernel आना कमाल की बात है! सिर्फ लेख पढ़कर यह स्पष्ट नहीं हुआ कि क्या यह STEP जैसे सामान्य formats में export को support करता है
    अगर करता है, या भविष्य में करने लगे, तो यह कई open source CAD libraries के लिए शानदार foundation बन सकता है

    • अफसोस, STEP export supported नहीं है। STEP files पूरी तरह अलग internal representation का उपयोग करती हैं
      ज़्यादातर STEP files shape को surfaces के एक set के रूप में व्यक्त करती हैं। उदाहरण के लिए trimmed NURBS वगैरह। इन surfaces को watertight manifold बनाना होता है, तभी उन्हें solid volume की तरह माना जा सकता है
      इसे वास्तव में काम कराने के लिए Fidget की function representations (f-reps) नहीं, बल्कि एक boundary representation (b-reps) kernel चाहिए। ऐसा kernel लिखना कहीं अधिक कठिन समस्या है। उदाहरण के लिए, दो NURBS surfaces का intersection हमेशा closed-form representation नहीं रखता
      जब मैंने industry के लोगों से बात की, तो उनका अनुमान था कि एक ठीक-ठाक b-rep kernel बनाने में, भले ही टीम ने यह पहले किया हो, लगभग 6 engineers को 1 साल लगेगा
      अगर आप और जानना चाहें, तो संयोग से मैंने एक STEP file viewer भी लिखा है, जिसमें industrial-grade से काफी दूर एक b-rep kernel शामिल है: https://www.mattkeeter.com/projects/foxtrot/

  • “1024² पिक्सेल के लिए brute-force evaluation करने पर bytecode interpreter को 5.8 सेकंड लगते हैं, जबकि JIT backend को 182ms लगते हैं, यानी 31 गुना तेज़”
    “ज़्यादा समझदार algorithm इस्तेमाल करने पर speedup इतना नाटकीय नहीं रहता। brute-force तरीका interval arithmetic या tape simplification का उपयोग नहीं करता। Fidget की optimized rendering implementation इस image को bytecode interpreter से 6ms में और JIT backend से 4.6ms में render करती है, इसलिए सुधार केवल लगभग 25% है”
    मुझे यह पसंद है कि यहाँ फोकस इस बात पर है कि algorithm optimization के बाद JIT backend कम महत्वपूर्ण हो जाता है, न कि इस पर कि algorithm optimization bytecode में 1000 गुना और JIT में 40 गुना सुधार देता है

  • कुछ साल पहले विश्वविद्यालय में मैंने nuclear physics simulator, यानी reactor modeling जैसी चीज़ों पर थोड़ा काम किया था
    उसका geometric model implicit surfaces पर, खासकर R-functions पर आधारित था। min(x,y) भी उसका एक उदाहरण है, और इसमें हर जगह differentiable होने जैसी दिलचस्प properties हैं
    शुरुआत के लिए अच्छा material यह है। शायद अंग्रेज़ी में उपलब्ध इकलौता material भी यही हो सकता है: https://ecommons.cornell.edu/items/35ae0f68-1af5-4f28-8b8b-7...
    nuclear physics क्षेत्र छोड़े हुए काफ़ी समय हो गया है, लेकिन modeling में अब भी बहुत सा पुराना Fortran code इस्तेमाल होता होगा। Fidget किसी नए simulation package के kernel के रूप में दिलचस्प संभावनाएँ रखता है

  • बात थोड़ी अलग है, लेकिन मैं code-based CAD software में सबसे अच्छा विकल्प खोज रहा हूँ
    मैंने CadQuery आज़माया था, लेकिन कुछ समस्याएँ आईं। 3D printing के लिए क्या कोई ऐसा है जिसकी आप सिफारिश करेंगे?

    • code-based CAD पर एक प्रस्तुति देते समय मैंने काफ़ी सारे विकल्पों को कवर किया था
      https://youtu.be/0wn7vUmWQgg?si=9Rc1tvbiQgQDgQzd&t=2766
      मैं Rust में एक विकल्प विकसित भी कर रहा हूँ, लेकिन अभी यह कहने की स्थिति में नहीं हूँ कि वह तैयार है
    • build123d भी है
      https://github.com/gumyr/build123d
    • जो लोग वीडियो खोलना नहीं चाहते, उनके लिए दूसरे comment/video में दी गई सूची यह है
      OpenSCAD, DSLCAD, CadQuery, Build123d, Cascade Studio, Declaracad, Replicad
    • replicad

  • दिलचस्प है। मैंने पहले भी ऐसे implicit surfaces पर papers और demos देखे हैं। शायद वह इसी लेखक का काम रहा हो
    कल्पना का इस्तेमाल करके किस तरह के models बनाए जा सकते हैं, यह प्रभावशाली है, लेकिन मैं toy examples से बड़े कुछ देखना चाहूँगा
    उदाहरण के लिए, क्या b-rep kernel की तरह surfaces को extrude करना, या SVG/fonts import करके उन्हें solid में बदलना संभव है?
    मैं सच में ऐसा तेज़ open source kernel देखना चाहूँगा जो ऐसी सुविधाएँ दे और parallelization भी अच्छी तरह संभाले

  • Ian Henry का https://bauble.studio/ काफ़ी याद दिलाता है

  • मैं भी SDF का उपयोग करके surface generation के लिए abstract tree जैसी किसी चीज़ पर काम करना चाहता था
    विचार यह है कि कोई target mesh या point cloud हो, और hill climbing/annealing से ऐसा tree खोजा जाए जो इच्छित shape से अच्छी तरह मेल खाए

    • “A Unified Differentiable Boolean Operator with Fuzzy Logic” दिलचस्प लग सकता है
      https://arxiv.org/abs/2407.10954
      यह differentiable leafs (quadrics) को differentiable Boolean-जैसे operations से जोड़कर CSG tree बनाता है, जिससे पूरे shape पर hill climbing किया जा सकता है