माँ, matrices के बिना भी काम चल जाएगा

 (enkimute.github.io)
2 पॉइंट द्वारा GN⁺ 2024-02-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 3D graphics में जड़ता से इस्तेमाल होने वाले 4x4 matrix की जगह Euclidean PGA को glTF-compatible forward renderer में शुरू से अंत तक लागू करके देखने का यह एक प्रयोग है
  • rotation और translation को 8 float वाले PGA motor से व्यक्त किया जाता है, और सामान्य motor composition को 4x4 matrix multiplication के 64 multiplication·48 addition की बजाय 48 multiplication·40 addition में किया जा सकता है
  • point transform को सीधे expand करने पर यह matrix से महँगा पड़ता है, लेकिन normalization condition का उपयोग करने वाले sandwich product से इसे 21 multiplication·18 addition तक घटाया जा सकता है, और direction·basis direction transform इससे भी सस्ते हैं
  • tangent space normal mapping में normal और tangent को tangentRotor से बदलकर vertex data को 12 float से 9 float तक घटाया गया, जबकि world-space transform cost भी matrix method के लगभग बराबर 47 multiplication·38 addition स्तर पर रखी गई
  • वास्तविक glTF content के साथ काम करने के लिए load समय पर matrix को motor में बदलना पड़ता है और uniform scale को अलग float के रूप में track करना पड़ता है, जबकि non-uniform scale के लिए restricted handling या 4x4 matrix fallback path की जरूरत होती है

PGA से बना matrix-less forward renderer

  • प्रोजेक्ट Look, Ma, No Matrices है, जिसका लक्ष्य matrix-less forward renderer को implement करना है
  • 2019 SIGGRAPH के बाद Geometric Algebra, खासकर Euclidean PGA, graphics और machine learning community में रुचि का विषय बना, लेकिन पारंपरिक 3D graphics में यह अक्सर dual quaternion को PGA motor कहकर दोबारा नाम देने तक ही सीमित रहा
  • यह implementation glTF-compatible 3D engine में PGA algebra को integrate करती है, यानी सिर्फ algebra का नाम बदलना नहीं बल्कि graphics pipeline के कई हिस्सों को PGA तरीके से फिर से बनाना
  • reference implementation Khronos glTF viewer है, और यह optimal performance implementation से ज्यादा बिना समझौते matrix को बदलने वाला एक प्रयोग है
    • अंततः hybrid solution बेहतर विकल्प हो सकता है

4x4 matrix पर सवाल क्यों

  • 4x4 matrix ने graphics API और GPU fixed-function pipeline में लंबे समय तक केंद्रीय भूमिका निभाई है, और आज भी सामान्य forward rendering का बुनियादी tool है
  • आधुनिक GPU fixed-function pipeline से अधिक programmable scalar processor जैसे हो गए हैं, इसलिए matrix-केंद्रित representation अनिवार्य नहीं रह गया
  • वास्तविक 3D engine में कई matrix सिर्फ rotation और translation रखने वाले orthogonal matrix होते हैं
  • PGA motor manifold पूरे Euclidean motion को कम computation·memory cost में व्यक्त कर सकता है, और quaternion तथा dual quaternion को भी बिना conversion के समाहित कर सकता है

PGA data representation और basic operations

  • PGA algebra चार basis vector e0~e3 से बनती है
    • e1, e2, e3 क्रमशः x=0, y=0, z=0 plane के अनुरूप हैं
    • विशेष degenerate vector e0 अनंत plane को दर्शाता है
  • shader में operator overloading के बिना GLSL built-in type का उपयोग करके addition, subtraction और scalar multiplication का इस्तेमाल किया जाता है
    • motor mat2x4
    • line mat2x3
    • point vec3
    • direction vec3
  • सामान्य PGA motor composition geometric product से किया जाता है
    • 4x4 matrix multiplication: 64 multiplication, 48 addition
    • सामान्य motor composition gp_mm: 48 multiplication, 40 addition
  • कुछ विशेष transform combination में इससे सस्ते operations संभव हैं
    • gp_rr: 16 multiplication, 12 addition
    • gp_tt: 0 multiplication, 3 addition
    • gp_rt / gp_tr: 12 multiplication, 8 addition
    • gp_rm / gp_mr: 32 multiplication, 24 addition
    • gp_tm / gp_mt: 12 multiplication, 12 addition

point·direction transform optimization

  • PGA में motor M से point p को transform करने के लिए sandwich product M p M̃ का उपयोग होता है
  • सीधे expansion में 33 multiplication, 29 addition लगते हैं, जो matrix-vector multiplication के 16 multiplication, 12 addition से अधिक हैं
  • normalized motor के M M̃ = 1 को उपयोग करके expression बदलने पर point transform को 21 multiplication, 18 addition तक घटाया जा सकता है
  • direction, यानी infinity point, में implied e123 coefficient 0 होता है, इसलिए यह और सस्ता है
    • सामान्य direction transform: 18 multiplication, 12 addition
    • basis direction transform में, उदाहरण के लिए x-axis transform को 6 multiplication, 4 addition तक घटाया जा सकता है
  • यही basis direction optimization आगे tangent frame handling में इस धारणा को चुनौती देता है कि matrix हमेशा सबसे तेज होते हैं

normalization, square root, exponential·log maps

  • PGA motor का squared pseudonorm M M̃ = a + b e0123 रूप का Study Number होता है
  • normalization सिर्फ vector normalization नहीं है, बल्कि ऐसा process है जो सुनिश्चित करता है कि result motor एक orthonormal transformation बने
    • सामान्य motor normalization implementation cost: 21 multiplication, 5 addition
    • pure translation या rotation में और अधिक efficient version उपयोग किए जा सकते हैं
  • दो point·दो line·दो plane a, b के बीच rigid transformation को M = sqrt(b / a) के रूप में व्यक्त किया जा सकता है
    • एक ही प्रकार के दो तत्वों के लिए geometric product ba, a से b तक जाने वाले transform का दोगुना motor बनाता है
    • sqrt M = normalize(1 + M) रूप में इसकी गणना संभव है
  • PGA motor का logarithm एक scaled line होता है, और scaled line को exponentiation से rotation motor में बदला जा सकता है
  • सामान्य 4x4 matrix का exponential map संख्यात्मक रूप से महँगा है, लेकिन PGA motor manifold में efficient closed form संभव है

inverse और motor factorization

  • Geometric Algebra normalized object के inverse को efficiently compute कर सकती है
    • plane inverse: स्वयं
    • line inverse: sign inversion
    • point inverse: sign inversion
    • motor inverse: reversion
  • जब सामान्य bivector Plücker condition को satisfy नहीं करता और एक single line का प्रतिनिधित्व नहीं करता, तब Study Number inverse से inverse निकाला जाता है
  • rendering implementation में दो तरह की factorization इस्तेमाल होती हैं
    • Euclidean factorization: motor को origin के आसपास rotation के बाद translation में तोड़ता है
    • Invariant factorization: motor को परस्पर commuting translation और rotation में तोड़ता है, जिसे 3D में Mozzi-Chasles theorem के रूप में जाना जाता है
  • tangent frame और object-to-world motor को compose करते समय, translation के प्रति invariant frame गुण के कारण Euclidean factorization उपयोगी है

glTF matrix और scale handling

  • मौजूदा glTF content के साथ interoperability के लिए load समय पर matrix को PGA motor में convert करना पड़ता है
  • 4x4 orthogonal matrix को quaternion के साथ isomorphism का उपयोग करके motor में बदला जाता है
    • import किए गए सभी matrix और transformation load time पर convert किए जाते हैं
  • PGA motor rigid body transformation संभालता है, इसलिए इसमें scaling शामिल नहीं होती
  • uniform scaling rotation और translation के प्रति invariant होती है, इसलिए हर node पर एक float के रूप में track की जाती है
    • हर element का total scale उसके अपने scale और parent scale के गुणन से निकाला जाता है
    • vertex पर total scale को load time या vertex shader के शुरुआती चरण में लागू किया जाता है
    • translation पर parent scale को load time और animation update के समय लागू किया जाता है
  • लगभग 400 random glTF file sample में scale animation वाले मामले 0.5% से कम थे, जबकि fixed uniform scale काफी आम था
  • non-uniform scaling rotation के प्रति invariant नहीं होती, इसलिए इसे संभालना अधिक कठिन है
    • सामान्य non-uniform scale handling में 4x4 matrix fallback path लगभग अनिवार्य है
    • sample glTF में non-uniform scale सिर्फ leaf node पर लागू मिले, और इस स्थिति में बाकी transform से पहले scale को अलग से लागू किया जाता है, बिना animation key को प्रभावित किए

Model-View-Projection का विकल्प

  • forward renderer object space की mesh geometry को screen space में transform करता है और तय करता है कि हर triangle कौन-से pixel को cover करेगा
  • सामान्य pipeline के model, view, projection matrix में से model और view को PGA motor से बदला जाता है
    • vertex position: sw_mp
    • normal और tangent direction: sw_md
  • projection matrix में सामान्यतः सिर्फ 5 non-zero entry होती हैं, इसलिए इसे ज़बरदस्ती PGA में बदलने के बजाय direct projection expression इस्तेमाल किया जाता है
  • CPU-side scene graph hierarchy update में matrix composition की जगह motor composition उपयोग करने से computation कम होता है
  • GPU-side vertex transform में सीधी तुलना करने पर motor नुकसानदेह लग सकता है, लेकिन tangent frame representation बदलने पर परिणाम बदल जाता है

tangent space normal mapping optimization

  • सामान्य tangent space normal-mapped mesh के vertex shader को position, normal और tangent transform करने होते हैं
  • normal, tangent, bitangent एक orthonormal frame बनाते हैं, इसलिए PGA में इन्हें canonical basis frame से इच्छित tangent frame तक ले जाने वाले tangentRotor के रूप में व्यक्त किया जा सकता है
  • इससे vertex descriptor छोटा हो जाता है
    • पहले: position 3 + normal 3 + tangent 4 + uv 2 = 12 floats
    • PGA तरीका: position 3 + tangentRotor 4 + uv 2 = 9 floats
    • प्रति vertex float संख्या 25% घटती है
  • tangentRotor में double cover होता है, और scalar coefficient का sign classical handedness flag से मिलाकर even/odd k-reflection को अलग किया जाता है
    • यह signed zero पर निर्भर करता है, और vertex shader में sign(1/tangentRotor.x) से handedness निकाली जाती है
  • position, normal, tangent को 4x4 matrix से transform करने पर कुल 48 multiplication, 36 addition लगते हैं
  • PGA तरीका पूरे tangent frame को एक बार में transform करके उससे normal और tangent निकालता है
    • tangent frame composition: 16 multiplication, 12 addition
    • normal/tangent extraction: 9 multiplication, 8 addition
    • position transform: 21 multiplication, 18 addition
    • handedness extraction के लिए 1 multiplication
    • कुल 47 multiplication, 38 addition
  • vertex transform cost matrix method के लगभग बराबर रहती है, जबकि transform storage 32 floats से घटकर 8 floats हो जाता है

fragment shader और baked texture की सीमाएँ

  • मौजूदा content लोड करने के लिए fragment shader चरण में फिर TBN matrix की जरूरत पड़ती है
  • baking tool high-detail mesh को low-detail mesh पर bake करते समय vertex normal और tangent को triangle face पर interpolate करता है और हर fragment में orthogonal TBN matrix बनाकर tangent space normal texture तैयार करता है
  • basis vector interpolation matrix method की विशिष्ट error पैदा करता है, और वह error texture में पहले से baked होती है
  • इसलिए यह implementation tangentRotor से normal और tangent vector को स्पष्ट रूप से extract करती है
  • अगर baking tool तक नियंत्रण हो, तो tangentRotor को सीधे fragment shader तक भेजकर normalize करने के बाद sampled normal transform में इस्तेमाल किया जा सकता है
    • TBN matrix बनाने की जरूरत नहीं
    • vertex shader में normal/tangent extraction की जरूरत नहीं
    • एक varying parameter कम किया जा सकता है
    • fragment shader की expensive orthogonalization भी हटाई जा सकती है

motor skinning और animation blending

  • PGA motor dual quaternion के साथ isomorphic है, इसलिए skinning में इसका उपयोग स्वाभाविक है
  • inverse bind matrix को motor में बदलने के बाद, dual quaternion skinning जैसे pattern में bone motor को blend किया जाता है
  • blend होने वाले transformation के sign इस तरह मिलाए जाते हैं कि shortest arc का पालन हो, और फिर result transformation को दोबारा normalize किया जाता है
  • animation blending भी इसी तरह CPU पर सीधे PGA motor को blend करके फिर normalize करती है

matrix replacement experiment का नतीजा

  • glTF-compatible forward renderer में सिर्फ PGA से matrix को replace करने वाली implementation संभव है
  • यह अनुमान कि transform cost अधिक होगी, tangent frame representation और sandwich product optimization लागू करने पर सीधा नहीं रह जाता
  • tangent space normal mapping के सामान्य मामले में, PGA motor तरीका vertex shader cost को matrix method के लगभग बराबर रखते हुए vertex memory footprint को काफी घटा देता है
  • समान storage में लगभग 33% अधिक vertices समाहित किए जा सकते हैं, और यही memory improvement खास तौर पर महत्वपूर्ण है
  • इस तकनीक को vertex shader cost लगभग बढ़ाए बिना और pipeline के बाकी हिस्सों में बदलाव किए बिना existing 3D engine में drop-in replacement की तरह लागू किया जा सकता है

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

1 टिप्पणियां

 
GN⁺ 2024-02-29
Hacker News की राय

  • मेरे पसंदीदा math/graphics YouTube creators में से एक Freya Holmér ने कुछ समय पहले geometric algebra का बहुत अच्छा introductory वीडियो बनाया था: https://www.youtube.com/watch?v=htYh-Tq7ZBI&ab_channel=Freya...
    अगर आपको 3D graphics, खासकर splines/Bezier curves में दिलचस्पी है, तो इनके सारे वीडियो देखने लायक हैं
    व्यक्तिगत रूप से मुझे linear algebra हमेशा कठिन लगी, लेकिन Clifford algebra वाला यह approach कहीं ज़्यादा intuitive लगता है

    • यह सच में बहुत अच्छा presentation था, और इससे https://enkimute.github.io/ganja.js/ याद आ गया
      यह library मूल पोस्ट के लेखक enkimute ने बनाई है, और यह एक single-file, no-build script होते हुए भी N-dimensional algebra और rendering support देती है, जो काफ़ी हैरान करने वाली बात है
    • मुझे लगा यह पोस्ट उसी व्यक्ति के बारे में होगी। मैंने splines और Bezier वाले वीडियो भी मज़े से देखे, और presentation बिना ज़रा भी जल्दबाज़ी लगे सीधे सार तक पहुँचती है
    • YouTube comments में भी हैरानी की बात है कि अच्छे supplementary explanations और सवाल हैं
      उदाहरण के लिए product की non-commutativity जैसी चीज़ों पर, जिन्हें Freya ने थोड़ा जल्दी पार किया या छोड़ दिया, वहाँ अच्छी व्याख्याएँ मिलती हैं

  • geometric algebra कुछ समय तक मेरे लिए पूरी तरह एक पहेली थी, लेकिन आख़िरकार मैंने इसे ऐसे समझा: यह बस polynomial multiplication है, बस इसमें कुछ quantities ऐसी हैं जिनमें multiply करने का order मायने रखता है और multiplication table थोड़ी अजीब है। उदाहरण के लिए i*i = 1, i*j = -j*i
    ज़्यादातर introductory material दो vectors के geometric product (x1*i + y1*j) * (x2*i + y2*j) को बहुत गहरा और रहस्यमय दिखाता है, लेकिन असल में यह freshman algebra में सीखी FOIL expansion जैसा ही है:
    (x1*i + y1*i)(x2*i+y2*j) = x1*x2*i*i + x1*y2*i*j + y1*x2*j*i + y1*y2*j*j = (x1*x2 + y1*y2) + (x1*y2 - y2*x1)*i*j
    पहली bracket के अंदर की value परिचित dot product है, और दूसरी bracket के अंदर की value परिचित cross product के बराबर है, बस इसे i*j नाम के एक नए dimension के basis में व्यक्त किया गया है। और cross product के विपरीत, इसे किसी भी dimension में generalize किया जा सकता है; geometric algebra में इसे wedge product कहा जाता है
    इसे समझ लेने के बाद rotation formula की derivation जैसी चीज़ें भी आसान हो जाती हैं, क्योंकि algebra में सीखी तकनीकों को geometry problems पर सीधे लागू किया जा सकता है

    • दूसरे comment में दिए गए https://youtu.be/htYh-Tq7ZBI?si=lOmsCL2DoqUCQgh1&t=1540 पर Freya ने axioms को एक में समेटने की शानदार व्याख्या की है
      अगर vector को खुद से multiply करने की value को उसकी length के square के रूप में define कर दें, तो बाकी सब साधारण polynomial multiplication से अपने-आप निकल आता है। काफ़ी सुंदर है
    • यह व्याख्या एक दिलचस्प contrast दिखाती है। कुछ दिन पहले किसी ने पूछा था कि math classes केवल formulas देकर calculation क्यों करवाती हैं, operations के तरीके और वजह क्यों नहीं सिखातीं; लेकिन यहाँ ज़ोर इस पर है कि operation क्या करता है, न कि यह क्यों सही है
      “यह कैसे काम करता है?” और “यह क्यों काम करता है?” वे दो सवाल हैं जिनके बीच math teachers को संतुलन रखना पड़ता है, और एक ही course में दोनों का हमेशा अच्छे से जवाब देना कठिन होता है
    • दूसरा term cross product नहीं बल्कि exterior product, या bivector है। cross product केवल 3 dimensions में काम करता है, लेकिन exterior product इससे ऊँचे किसी भी dimension में संभव है
      3D में दो vectors का cross product एक और vector होता है जो उन दोनों vectors द्वारा बनाए गए plane पर perpendicular होता है। दूसरी ओर exterior product दो vectors के बीच के parallelogram को sweep करने वाला 2-vector, यानी bivector होता है, और वह उन्हीं vectors के plane पर मौजूद होता है। 3D में cross-product vector इस bivector plane पर perpendicular होता है
    • math में सीखने में सबसे ज़्यादा समय लेने वाली बातों में से एक यह है कि ज़्यादातर चीज़ें यथासंभव सबसे सरल तरीके से define की जाती हैं
      खासकर vector space V पर अगर आप bilinear product m:V x V -> V define करना चाहते हैं, तो यह ठीक उसी के बराबर है कि आप केवल basis vectors की जोड़ियों पर m तय कर दें। अगर इसे “tensor product की universal property” कह दें, तो शायद प्रतिक्रिया बस “अच्छा, ठीक है” ही होगी

  • rotation interpolation के लिए geometric algebra, quaternions, और यहाँ तक कि full matrix interpolation तक, कई approaches मौजूद हैं, जो दिलचस्प है: https://www.gamedev.net/tutorials/programming/math-and-physi...
    लेकिन कोड को हाथ से optimize करने के बाद, ज़्यादातर approaches में अंतिम code लगभग एक जैसा हो जाता है। फर्क इस बात में है कि आप rules और possibilities को कैसे समझते हैं
    जितना मुझे थोड़ा-बहुत पता है, geometric algebra सबसे consistent और सक्षम approach लगती है। यह अनजानी है, और शुरुआत में अपनाना काफ़ी भारी लगता है, लेकिन जो लोग यह दीवार पार कर लेते हैं, उन्हें यह पसंद आती है
    दूसरी तरफ़, सब लोग quaternions का इस्तेमाल तो करते हैं लेकिन यह शिकायत भी करते हैं कि वे उन्हें समझते नहीं, और उन्हें visualize करने के लिए एक पूरी किताब चाहिए। जैसे Andrew J. Hanson और Steve Cunningham की 『Visualizing Quaternions』

    • मैं mathematician नहीं हूँ और काम में भी geometry का बहुत उपयोग नहीं करता, लेकिन मज़े के लिए geometric algebra सीख रहा था, और पहले कभी quaternions भी सीखने की कोशिश की थी
      geometric algebra मज़ेदार है, quaternions मज़ेदार नहीं हैं। geometric algebra मुझे लगा कि समझ में आ रही है, लेकिन quaternions में lectures और problems follow करने के बाद भी मुझे बस यही पक्का लगा कि मैं इसे समझ नहीं पाया। अब geometric algebra थोड़ा जानने के बाद, आख़िरकार quaternions भी कुछ हद तक समझ आने लगे हैं
    • 『Naive Lie Theory』 एक बेहतरीन किताब है, और उसके पहले chapter में quaternions सिखाए जाते हैं
      https://www.goodreads.com/en/book/show/4419538

  • अगर इस विषय में रुचि है, तो Grassman/Clifford/geometric algebra के concepts पर नज़र डालने के लिए एक अच्छा slideset है: http://www.terathon.com/gdc12_lengyel.pdf
    एक और अच्छी साइट भी है: https://mattferraro.dev/posts/geometric-algebra

  • Sudgy का शानदार “A swift introduction to projective geometric algebra” भी नहीं छोड़ना चाहिए: https://www.youtube.com/watch?v=0i3ocLhbxJ4
    और प्रमुख संदर्भ साइट है https://bivector.net
    1000 से अधिक प्रोफेसरों, शोधकर्ताओं और उत्साही लोगों वाले bivector Discord में भी शामिल हो सकते हैं: https://discord.gg/vGY6pPk

    • उस प्रस्तुति के लेखक Eric Lengyel ने 『Foundations of Game Engine Development, Volume 1: Mathematics』 भी लिखी है, और अध्याय 4 में यही विषय आता है

  • सच कहूँ तो geometric algebra का वह तरीका मुझे खास पसंद नहीं आया जिसमें अगर यह ध्यान न रखा जाए कि किस चीज़ को किससे गुणा कर रहे हैं, तो तरह-तरह के mixed elements बन जाते हैं
    जो चीज़ n-आयामी स्पेस थी, उसके लिए अधिकतम 2^n पदों की ज़रूरत पड़ना भी संभालने में कठिन लगता है
    लगता है कि geometry, यानी inner product, को इससे बेहतर ढंग से संभाल पाना चाहिए, लेकिन केवल wedge product और Hodge star operator या musical isomorphism का उपयोग क्यों पर्याप्त नहीं है, इसका कोई संतोषजनक स्पष्टीकरण मैंने नहीं देखा
    bivector u^v को उस समतल में rotation e^(u^v)t में बदलने वाला जो “जादू” है, वह भी मूल रूप से musical isomorphism से 2-form u^v को linear automorphism में बदलकर e^(u^v)t को matrix exponential की तरह समझने जैसा ही है
    एक और आम उदाहरण यह दिया जाता है कि Maxwell समीकरणों को एक ही समीकरण में बदला जा सकता है, लेकिन differential forms का उपयोग करें तो वे पहले से ही दो समीकरणों में सिमट जाते हैं, जो अलग-अलग कारणों से सही हैं, इसलिए उन्हें एक में मिलाने का लाभ मुझे समझ नहीं आया

    • “जो चीज़ n-आयामी स्पेस थी, उसके लिए अधिकतम 2^n पदों की ज़रूरत पड़ती है” वाला बचाव कभी-कभी भ्रम होता है
      उदाहरण के लिए, normal vector, position vector से अलग तरह से transform होता है। दोनों को एक ही data structure में रखा जा सकता है, लेकिन तब यह ट्रैक करना पड़ता है कि उसमें किस प्रकार का vector है, और कोड के अलग-अलग हिस्सों में उन्हें अलग तरह से संभालने के special case डालने पड़ते हैं
      geometric algebra इसे सीधे स्वीकार करता है, इसलिए vectors के लिए (i,j,k) basis का उपयोग करता है, और दूसरे प्रकारों के लिए (j*k, k*i, i*j) जैसा अलग basis
      इस अर्थ में कि एक समीकरण दो या चार से बेहतर है, यह एक अच्छा उदाहरण है जहाँ higher-dimensional space, lower-dimensional space की तुलना में storage के लिहाज़ से उल्टा ज़्यादा किफायती हो सकता है
      electric field, magnetic field से कुछ वैसे ही अलग है जैसे vector, bivector से अलग होता है। आप electric field और magnetic field को अलग-अलग समीकरणों के special case की तरह संभाल सकते हैं, या उन्हें एक ही तरीके से एकरूपता से संभाल सकते हैं
    • mixed elements ही असल में महत्वपूर्ण हिस्सा हैं
      w=1, x,y,z=0 वाला quaternion identity है, और w=0, x=1 या w=0, x=y=0.7 जैसे quaternion केवल 180 डिग्री rotation के अनुरूप होते हैं
      मनमाना rotation चाहिए तो दोनों का संयोजन चाहिए। यानी “इस रेखा के चारों ओर 180 डिग्री rotation थोड़ा-सा, और 0 डिग्री rotation/identity थोड़ा-सा” मिलाना पड़ता है। scalar और bivector दोनों साथ होने का मतलब यही है
      अगर आप wedge product और inner product के साथ “सावधानी से” मिलावट से बचने की कोशिश कर रहे हैं, तो आप इसे गलत तरह से इस्तेमाल कर रहे हैं। geometric product ही मुख्य पात्र है, और यह बेहद शानदार मिश्रण बनाता है
    • मैं इस बात से सहमत हूँ कि भ्रम पहले से मौजूद है। पारंपरिक तरीका बस उस भ्रम को कालीन के नीचे सरका देता है
      उदाहरण के लिए, यदि आप normals को संभाल रहे हैं, तो कम-से-कम दो n-आयामी spaces को ट्रैक करना पड़ता है जो काफ़ी अलग तरह से transform होते हैं
      points, planes, lines, normals, translations और rotations—इन सबको एक ही multivector type और एकसमान नियमों से व्यक्त करना, एक बार समझ में आ जाए तो काफ़ी मुक्तिदायक लगता है। मैं भी अभी इसे सीख ही रहा हूँ

  • नीचे वाला animation interpolation वाकई शानदार है, लेकिन मन करता है कि पेज के बाकी मॉडल थोड़े कम चंचल होते
    गणित बिना छोटे हाथी cheerleader के भी काफ़ी कठिन है

    • मुझे तो उल्टा लगा। अगर वह हाथी जैसी हौसला-अफ़ज़ाई न होती, तो मैं शायद पेज के अंत तक नहीं पहुँच पाता

  • अगर लेखक यह देख रहे हों, तो अच्छा होता कि PGA संक्षेप का पहली बार उपयोग करते समय उसका अर्थ बता देते

    • जिन लोगों को जिज्ञासा हो, उनके लिए: PGA का मतलब projective geometric algebra, यानी प्रोजेक्टिव ज्यामितीय बीजगणित है
      जिस space में आप काम कर रहे हैं, उसके basis vectors में एक null basis vector और जोड़ दिया जाता है। इससे उन geometric objects को भी algebra में व्यक्त किया जा सकता है जो origin से नहीं गुजरते
    • खासकर जहाँ “Fast PGA” को FPGA लिखा गया है, वह काफ़ी उलझाने वाला था
    • ठीक कर दिया। mea maxima culpa

  • क्या ऐसे algorithm, GPU को ध्यान में रखते हुए भी efficient हैं?
    मेरे मन में धुंधला-सा यह प्रभाव है कि GPU matrix काम के लिए अच्छी तरह अनुकूल होते हैं, इसलिए सोचता हूँ कि geometric algebra formulation अपनाने पर कहीं वह लाभ खो तो नहीं जाता और व्यवहार में यह आगे नहीं निकल पाता
    यह एक अनजान-सी अटकल है, इसलिए अगर गलत हूँ तो सुधारें

    • यह बहुत आम ग़लतफ़हमी है कि GPU standards में matrix-matrix multiplication और matrix-vector multiplication होने का मतलब GPU कंपनियाँ ज़रूर इन्हें accelerate करती होंगी
      वास्तव में पूरे shader cores पहले से ही SIMD हैं, इसलिए ऐसा होना अनिवार्य नहीं है। कुछ GPU करते हैं, कुछ नहीं
    • प्रोग्रामिंग करते समय दो बातें पता करनी होती हैं: आप किस मात्रा की गणना करना चाहते हैं, और उसे गणना करने का सबसे efficient तरीका क्या है
      PGA को समझने में काफ़ी मानसिक मेहनत लगती है, लेकिन पहली बात से निपटने के लिए यह बहुत अच्छा तरीका है। वैसे भी आम तौर पर सबसे सरल और implement करने में आसान तरीका पहले आज़माना बेहतर होता है
      PGA के ज़रिए पहली समस्या सुलझाकर जो implementation मिलती है, वह बाकी प्रोग्राम का prototype बनाने और benchmark करके असली bottleneck खोजने के लिए पर्याप्त होती है। खुशकिस्मती से ज़्यादातर मामलों में वही सबसे तेज़ computation होती है, या कम-से-कम bottleneck बनने लायक धीमी नहीं होती
      और अगर bottleneck बन भी जाए, तब भी यह आपको उस समस्या की गहरी समझ दे देती है जिसे आप सुलझाना चाहते हैं। मेरा मानना है कि cycles कम करने में जुटने से पहले ऐसी समझ होना बेहतर है, इस उम्मीद में कि चीज़ काफ़ी तेज़ हो जाएगी
    • यह लेख ठीक इसी पर बात करता है। संक्षेप में कहें तो परिणाम आम तौर पर लगभग इसी स्तर के हो सकते हैं

  • यह मुझे प्रगति की सीमा पर होने वाली बारीक़ अंतर की बहस जैसा लगता है
    3D skeletal animation आज भी GPU पर 4x4 matrices का उपयोग करती है, तो इसका मतलब है कि Half-Life 1 के दौर में CPU पर इस काम के लिए विकसित किया गया गणित अब भी अग्रिम पंक्ति में है। 1998 से 2024 तक 26 साल हो गए
    1000 साल बाद भी 3D animation शायद ऐसी ही होगी

  • यह लेख मेरी समझ की सीमा से बाहर है, लेकिन शीर्षक देखकर मुझे वह प्रयोग याद आया जब मैं एक सरल 3D renderer बनाने की कोशिश कर रहा था
    linear algebra सीखने में कई बार असफल होने के बाद, नहाते समय अचानक लगा कि 3D rotation तो बस तीन 2D rotations हैं, और वह तो मुझे पहले से आता है। लगभग एक घंटे बाद perspective सहित एक wireframe 3D renderer तैयार हो गया था
    मैं सबको सलाह दूँगा कि इसे एक बार ज़रूर आज़माएँ