'Gaussian splatting' काफ़ी शानदार है

 (aras-p.info)
2 पॉइंट द्वारा GN⁺ 2023-09-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • SIGGRAPH 2023 का 3D Gaussian Splatting पेपर फोटो-आधारित scenes को लाखों 3D Gaussians में बनाकर real-time render करने का तरीका है, और Unity visualization experiment implementation भी public किया गया है
  • Scene को mesh, voxel या distance field के बजाय space में मौजूद blobs के collection के रूप में represent किया जाता है, जिनमें position, rotation, non-uniform scale, opacity और spherical harmonics coefficients होते हैं
  • यह तरीका NeRF नहीं है, और official implementation भी fixed-function rasterization pipeline नहीं, बल्कि 100% CUDA-आधारित tiled software rendering का उपयोग करता है
  • Unity implementation NVIDIA RTX 3080 Ti पर 1200x800 के लिए official viewer के 7.40ms से धीमा, 23.8ms लेता है, लेकिन इसे सामान्य HLSL में लिखा गया है इसलिए यह Mac पर भी चलता है
  • bicycle scene disk पर 1.5GB, लगभग 60 लाख blobs, और प्रति blob लगभग 250 bytes लेता है, इसलिए performance के साथ-साथ data size और GPU memory भी सुधार के महत्वपूर्ण लक्ष्य हैं

SIGGRAPH 2023 paper और Unity experiment

  • SIGGRAPH 2023 का पेपर 3D Gaussian Splatting for Real-Time Radiance Field Rendering Kerbl, Kopanas, Leimkühler और Drettakis का काम है
  • Paper website, source code और datasets public हैं, इसलिए experiments और reproduction को सीधे try किया जा सकता है
  • Unity experiment पहले से बनाए गए Gaussian Splat “model” files लेकर real-time visualization पर focus करता है
  • Implementation aras-p/UnityGaussianSplatting पर public है, और आगे और experiments जारी रहने की योजना है
  • Data size घटाया जा सकता है या नहीं, यह भी interest का विषय है, और पहले के float compression experiments का उपयोग किए जाने की संभावना है

Gaussian Splat किन चीज़ों से बना होता है

  • Gaussian Splatting 3D scene को polygon mesh, voxel या distance field के बजाय लाखों particles से represent करता है
  • हर particle, यानी “3D Gaussian”, में यह जानकारी होती है
    • 3D space में position
    • rotation
    • non-uniform 3D scale
    • opacity
    • color information
  • Color को single color के रूप में नहीं, बल्कि third-order Spherical Harmonics coefficients के रूप में represent किया जाता है, इसलिए यह viewing direction के हिसाब से बदल सकता है
  • Rendering के समय particles को लंबी खिंची हुई 3D spheres की तरह नहीं draw किया जाता, बल्कि screen space में 2D Gaussian के रूप में “splat” किया जाता है
  • Core idea यह है कि scale और color वाले blobs के collection को photo-based scene representation बनाया जाए, और उसे तेज़ी से render किया जाए

न NeRF, न fixed-function rasterization

  • Gaussian Splatting NeRF नहीं है
    • साफ़ कहा गया है कि इसमें “Neural” element नहीं है
  • इसके तेज़ होने की वजह भी “GPU rasterization hardware का उपयोग” नहीं है
    • Official implementation rasterization pipeline का उपयोग नहीं करता
    • यह 100% CUDA में implemented है
  • Official implementation की performance fixed-function rasterization से नहीं, बल्कि लाखों scaled particles को efficiently process करने वाले tile-based software rendering से आती है
  • हालांकि tile-based “GPU पर software” rasterizer अपने आप में पूरी तरह नया concept नहीं है

पुराने technology blocks से connection

  • Gaussian Splatting खुद 2001~2002 के आसपास के EWA Splatting जैसे कामों से जुड़ा है
    • Scaled और oriented blobs को space में रखकर, screen पर उनका projection कैसे होगा यह calculate किया जाता है, फिर screen space में Gaussian form को process किया जाता है
  • 1994 का game Ecstatica ellipsoid-based renderer इस्तेमाल करने वाला एक अनोखा उदाहरण है
  • Spherical Harmonics physics में सैकड़ों साल से इस्तेमाल होते रहे हैं, और computer graphics में 2000 के आसपास Ravi Ramamoorthi और Peter-Pike Sloan के काम के जरिए widely known हुए
    • 1984 में Kajiya & Von Herzen का Ray tracing volume densities graphics में शुरुआती use case हो सकता है
    • Related theorem Patapom’s page पर देखी जा सकती है
  • Point-Based Rendering भी एक पुराना field है
    • Particle systems लंबे समय से VFX और non-solid phenomena represent करने में इस्तेमाल होते रहे हैं
    • The Use of Points as a Display Primitive 1985 का काम है
    • Surfels 2000 का paper है
  • demoscene और real-time VFX tools भी non-traditional rendering approaches इस्तेमाल करते रहे हैं
  • fogleman/primitive images को primitive shapes के collection के रूप में represent करने वाले 2016 के tool का उदाहरण है
  • Media Molecule के “Dreams” ने splat-based renderer इस्तेमाल किया था, और release version कई techniques का combination लगता है
  • Particles के लिए tiled rasterization कम से कम 2014 में Gareth Thomas के Holy smoke! Faster Particle Rendering using Direct Compute से मौजूद है
    • Screen को tiles में बांटकर tile के अंदर काम करने से memory traffic घट सकता है
    • यह तरीका mobile GPUs के overall working model से भी जुड़ता है, और PowerVR के शुरुआती design 1996 तक, Pixel Planes 5 1989 तक पीछे जाते हैं

UnityGaussianSplatting की current status

  • aras-p/UnityGaussianSplatting Gaussian Splat model का visualizer implementation है
  • Current status “चलता तो है, लेकिन तेज़ नहीं है” के करीब है
  • NVIDIA RTX 3080 Ti पर bicycle scene को 1200x800 में render करते समय performance में बड़ा अंतर है
    • Official viewer: 7.40ms, 135FPS
    • Unity implementation: 23.8ms, 42FPS
    • लगभग 4 गुना धीमा
  • Sorting method भी performance difference को प्रभावित करता है
    • Unity implementation relatively simple GPU bitonic sort इस्तेमाल करता है
    • Official implementation OneSweep algorithm पर आधारित CUDA radix sort इस्तेमाल करता है
  • Rasterization approach भी अलग है
    • Official implementation CUDA में लिखी गई tile-based approach है
    • Unity implementation सामान्य GPU rasterization pipeline से हर splat को screen space quad के रूप में render करता है
  • Unity implementation में portability का फायदा है
    • Code Unity के अंदर सामान्य HLSL में लिखा गया है, इसलिए Mac पर भी चलता है
    • Apple M1 Max पर वही scene 108ms, 9FPS पर render होता है
  • GPU memory के मामले में फिलहाल Unity implementation कम इस्तेमाल करता दिखता है
    • Official viewer: 4.8GB
    • Unity implementation: 2.2GB
    • इसमें Unity Editor द्वारा इस्तेमाल memory भी शामिल है

Data size और memory usage

  • Gaussian Splatting पर discussion अक्सर rendering quality और speed पर केंद्रित हो जाती है, लेकिन data size और memory usage भी बड़ी समस्याएँ हैं
  • bicycle scene disk पर 1.5GB लेता है
  • यह scene लगभग 60 लाख blobs से बना है
  • हर blob लगभग 250 bytes इस्तेमाल करता है
  • Runtime में sorting और tile-based rendering आदि के लिए additional memory चाहिए
  • Dreams presentation में size घटाने के लिए reference-worthy ideas हैं

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

1 टिप्पणियां

 
GN⁺ 2023-09-09
Hacker News की राय

  • gradient descent और differentiable rendering का इस्तेमाल करते हुए भी “neural” से बचने वाली बात थोड़ी आत्ममुग्ध लगती है
    अवधारणात्मक रूप से, यह NeRF की तरह ही images के आधार पर 3D scene से जुड़े variables को approximate करने वाली data-driven representation को optimize करता है; फर्क यह लगता है कि NeRF पूरी light transport function, यानी radiance field, को model करता है, जबकि यहां शायद सिर्फ उन boundary conditions को model किया जाता है जहां light पहुंचती है
    target अलग है, इसलिए ज्यादा सरल representation basis उचित है और नतीजे भी अच्छे दिखते हैं, लेकिन neural network से बचना अपने-आप में तारीफ की बात हो, इस तरह कहना थोड़ा खटकता है। neural networks सिर्फ trend के कारण इस्तेमाल नहीं होते; वे वास्तव में powerful function approximators हैं, और जिन structures को “neural network” कहा जाता है उनका दायरा भी बहुत व्यापक है
    यह impression सिर्फ blog post के शुरुआती tone को देखकर बना है, इसलिए paper से अलग हो सकता है

    • NeRF और इस technique के बीच बड़ा फर्क यह है कि NeRF आपस में जुड़े nodes का black box है, जबकि यह तरीका 3D space में रखी values का collection है
      इसलिए यह समझने में आसान और editors या renderers जैसे दूसरे 3D software में integrate करने में भी आसान लगता है, और animation भी संभव लगती है। पूरे scene को एक साथ represent करने वाला black-box function approximator scalable या elegant नहीं लगता
    • neural networks इस्तेमाल करने वाले researchers को खारिज करना किसी के लिए भी अच्छा रास्ता नहीं है
      हालांकि neural networks में, problem को अच्छी तरह model करने पर भी, अक्सर यह पता नहीं होता कि trained model असल में कैसे काम करता है, और data requirements व बार-बार retraining की वजह से long-term solutions बनाने में सीमाएं हैं
      यहां मैं इसे इस तरह अच्छा मानना चाहूंगा कि authors ने कोई छोटी cultural war भड़काने के बजाय दोस्ताना मजाक किया है
    • paper का title “3D Gaussian Splatting for Real-Time Radiance Field Rendering” है
      हर rendering pixel view-dependent Gaussians, जिनकी कोई boundary नहीं होती, के contributions का weighted sum है, इसलिए यह फर्क सही नहीं है कि NeRF radiance field को model करता है और यह सिर्फ boundary conditions को
    • Aras के मजाक को मैंने ज्यादा संकुचित technical sense में पढ़ा। NeRF का मूल यह है कि real world के light field samples, यानी photos, से 5-dimensional light field—3D position और 2D direction—की neural network representation मिलती है, और 5 dimensions इतनी ज्यादा नहीं हैं
      अगर यह भी सोचें कि NeRF direction domain में low-rank spherical harmonics representation इस्तेमाल करता आया है, तो यह लगभग 3D+α के करीब है; ऐसे में इतने low-dimensional function को recover करने के लिए neural network क्यों चुना जाए, यह सवाल उठता है
      inference के समय हर pixel के लिए view ray के along neural network को बार-बार sample करना पड़ता है, जबकि graphics में light field की compressed representation पहले से लंबे समय से studied problem है, इसलिए यह हिस्सा काफी awkward लगता है
      बाद में Plenoxels ने NeRF से “Ne” निकालकर training और inference performance काफी बढ़ाई, और Nvidia के Instant NeRF ने small neural network में sophisticated input embeddings को interpolate करके कुछ हद तक इसकी भरपाई की: https://nvlabs.github.io/instant-ngp/assets/mueller2022insta...
      graphics engineering में neural networks का व्यापक उपयोग मुख्यतः sparse data restoration, खासकर denoising, में हुआ है और यह high-dimensional problem होने के कारण स्वाभाविक है। फिर भी वे hand-made algorithms को मात दें, ऐसा कम ही होता है; छोटे neural networks को compression में इस्तेमाल करने की दिशा में भविष्य दिखता है
      graphics में function approximation बहुत होता है, इसलिए neural networks के लिए जगह है, लेकिन जिन functions से deal किया जाता है वे आम तौर पर अधिक understandable और controllable होते हैं; यह natural language understanding जैसे क्षेत्रों से अलग है, जहां hand-crafted algorithmic solutions इस्तेमाल करना लगभग असंभव है
    • cultural war में चले जाने पर साधारण और reasonable लोग भी unverified ideas में बह सकते हैं
      बहुत-सी conversations AI=बुरा, CRYPTO=बुरा पर खत्म हो जाती हैं; इसका मतलब यह नहीं कि विरोधी राय गलत है, बल्कि समस्या यह है कि अगर पहले conclusion तय करके सोचना बंद कर दिया जाए, तो यह जानने का कोई तरीका नहीं बचता कि अपनी सोच पूरी तरह बेकार है या नहीं

  • वाकई शानदार काम है
    लेख में point-based rendering और particle systems का ज़िक्र है, और हाल के गेम्स में texture के टुकड़ों की बजाय ज़्यादा point-oriented, लेकिन physics system की तरह व्यवहार करने वाली नई particle style की ओर हल्का-सा shift महसूस होता है
    उदाहरण के लिए Hogwarts: https://www.gamespot.com/a/uploads/original/1816/18167535/40..., Forspoken: https://oyster.ignimgs.com/mediawiki/apis.ign.com/project-at..., Starfield: https://dotesports.com/wp-content/uploads/2023/08/temple-loc..., AC6, FF16 हैं
    common बात यह है कि ये physics वाले रंगीन transparent point particles जैसे दिखते हैं, और खासकर consoles पर CPU load के बिना GPU पर cheap effects देने के लिए इस्तेमाल होते लगते हैं। game development side से कोई जानकार हो तो जानने की इच्छा है

    • अभी मैं game development नहीं करता और graphics भी नहीं संभालता था, लेकिन पिछले 10 सालों में real-time fluid simulation ज़्यादा आम हो गई है, और यहाँ “physics” से शायद वही मतलब है
      fluid simulation न हो तो point-based particle system बस fireworks जैसा दिखता है। अगला कदम यह था कि हर particle में momentum या wind जैसी अपनी physics होती थी और उसे छोटे texture billboard के रूप में render किया जाता था; हाल तक explosions या smoke दिखाने में इसका इस्तेमाल होता था
      अब machine performance और physics algorithms बेहतर हो गए हैं, इसलिए particles के आपस में interact करने वाली fluid simulation real-time में चला सकते हैं, और अभी दिखने वाला effect उसी तरफ का लगता है
    • latest techniques की बहुत गहरी जानकारी नहीं है, लेकिन Doom से Quake की तरफ जाने के दौर में Quake का particle system भी बड़े texture sprites के silhouettes की बजाय छोटे flat color particles और उनकी movement पर काफी निर्भर था
      3D game world में सचमुच 3D primitives से ही काम करने के conceptual और structural फायदे बहुत हैं, और point sprites को लगभग infinitely छोटे 3D objects की तरह handle किया जा सकता है
      इसके उलट 2D sprites को 3D scene में डालने पर, अगर partial transparency हो तो उन्हें back-to-front sort करना पड़ता है, z-buffer से अच्छी तरह fit नहीं होते, GPU-friendly batching order से भी टकराते हैं, 3D surfaces में धंस जाते हैं और आसानी से यह जाहिर कर देते हैं कि वे 2D हैं
      इन समस्याओं को हल करने के लिए screen-door transparency, z-buffer write behavior बदलने वाले shaders, alpha testing, alpha-to-coverage जैसे कई compromises जमा होते आए हैं
      VR में 3D scene के अंदर 2D image-based rendering single screen की तुलना में और भी ज़्यादा अलग और खराब दिखती है, और यह कहीं अधिक साफ दिखता है कि वह flat billboard है। इन सब वजहों को जोड़ें तो 3D scenes में 2D texture sprite effects से दूर जाना चाहने की पर्याप्त वजह बनती है
    • पिछले कुछ वर्षों में game engines को कहीं ज़्यादा complex particle systems promote करते हुए निश्चित रूप से देखा है
      AI side के trend की वजह से GPU का RT cores और tensor cores वगैरह के साथ “GPU के अंदर छोटा instruction-set GPU” जैसा बनना भी कुछ हद तक संबंधित लगता है
      कुछ साल पहले NVIDIA की तरफ से SE(3) kernels को tensor cores पर ले जाने वाला kernel लिखा गया था, और gaussian splatting के spherical harmonics वाले हिस्से में भी compression और runtime पर कुछ porting हो सकती है, इसलिए यह चौंकाने वाला नहीं लगता: https://developer.nvidia.com/blog/accelerating-se3-transform...
      gaussian splatting में 3D space में हमेशा support region होता है, इसलिए यह काफी efficient लगती है, और roughly fast transform करने पर भी final result काफी अच्छा हो सकता है
    • Unity में कुछ साल पहले VFX Graph जोड़ा गया था, जिससे ऐसे fine-grained particle effects बनाए जा सकते हैं
      चमकते dots की खूबसूरत swirl भी relatively आसानी से बनाई जा सकती है। Unreal Engine में भी शायद ऐसा कुछ होगा, लेकिन मेरा direct experience बहुत ज़्यादा नहीं है
    • ऐसे “particle effects” मुझे करीब 11 साल पहले Unreal Engine 4 demo “Elemental” में पहली बार प्रभावशाली तरीके से दिखे थे: https://youtu.be/dD9CPqSKjTU
      मैं यह नहीं मानता कि इसकी शुरुआत वहीं से हुई, लेकिन जिस पहले milestone की ओर इशारा कर सकता हूँ, वह वही demo है

  • Siggraph paper पहली बार आया था, तब मैं सच में बहुत excited था
    पिछले करीब 10 वर्षों में जिन कमरों में रहा हूँ, उन्हें कभी 3D में recreate करने के लिए मैंने सैकड़ों angles से photos लिए हैं, और gaussian splatting पहली ऐसी technique लगती है जिससे उन्हें लगभग वास्तविक जैसा महसूस कराने वाली तरह से recreate किया जा सकता है
    tools और mature हो जाएँ तो पुराने कमरों में फिर घूमकर nostalgia में डूबने का खयाल मुझे बहुत excited करता है

  • यह ऐसा क्षेत्र है जिसके बारे में मैं ज़्यादा नहीं जानता, इसलिए सवाल अनजान-सा हो सकता है, लेकिन ये वीडियो सच में शानदार लगते हैं
    मेरी समझ के मुताबिक scene या radiance field हमेशा static होता है और lighting baked-in होती है; मैं सोच रहा हूँ कि क्या इसके dynamic तरीके से lighting बदलने और motion तक support करने की दिशा में विकसित होने की संभावना है

    • अच्छा सवाल है, और छोटा जवाब है नहीं
      radiance field में light emission, reflection, absorption जैसी अवधारणाएँ नहीं होतीं, और सब कुछ “transmitted light” नाम की एक value में मिला दिया जाता है। इस अर्थ में radiance field 3D photo के क़रीब है
      इसे बदलने के लिए inverse rendering या photogrammetry से light source की position, surfaces, materials वगैरह का अनुमान लगाना होगा, और फिर traditional path tracing का इस्तेमाल करना होगा
      एक और दिशा animation नहीं बल्कि video हो सकती है: समय के साथ radiance field को लगातार capture करना और frames के बीच similarity को compress करके temporal consistency पाना
    • motion वाली दिशा में Gaussian splatting को moving objects तक बढ़ाने का काम पहले से मौजूद है: https://dynamic3dgaussians.github.io/
      कई को जोड़कर animation भी बनाया जा सकता है: https://twitter.com/8Infinite8/status/1699460316529090568
      relighting के लिए इसे support करने वाले कई NeRF variants हैं, इसलिए splat के material parameters को optimize करना भी संभव लगता है
    • आम तौर पर एक camera को घुमाते हुए बहुत सारी photos लेकर capture किया जाता है, इसलिए यह आसान नहीं लगता
      उदाहरण के लिए, किसी indoor scene में अगर table floor पर dark shadow बनाती है, तो NeRF अभी light sources और shadows को नहीं समझता, इसलिए वह नहीं जान सकता कि floor काला है, या white floor table की shadow से ढका हुआ है, या shadow के अंदर कोई blue Stanford bunny छिपा है
      human face जैसी छोटी objects capture करने वाले 3D scanning rigs lighting को manipulate करके और BRDF को सीधे sample करके यह हल करते हैं। अगर lighting manipulate नहीं कर सकते, तो BRDF estimate किया जा सकता है, लेकिन सीमाएँ होंगी
      बाद में animation जोड़ना आसान हो सकता है, लेकिन animation को खुद capture करने के लिए कई cameras चाहिए होंगे, या फिर इंसान होने के कारण सामने न दिखने वाले हिस्से की कल्पना कर भरने वाली neural network जैसी estimation पर निर्भर करना होगा
      Intel ने कुछ साल पहले कई cameras से scene capture करके post-processing में camera position बदलने वाला एक project किया था, और शायद target American football broadcast था, लेकिन असली release की खबर नहीं सुनी। Matrix की तरह कई cameras चाहिए होते हैं
    • संभव है। एक तरीका है कि कई वास्तविक lighting conditions में splats इकट्ठा किए जाएँ और फिर उन्हें सबसे नज़दीकी simulated lighting condition पर map किया जाए
      यानी data को time of day के हिसाब से animated बनाना। data requirement बड़ी हो सकती है, लेकिन interpolation methods हैं, इसलिए शायद बहुत बुरा न हो
      अगर static scene 2GB का है, तो rough time-of-day approximation शायद 16GB से कम में हो सकती है और modern GPU पर render की जा सकती है। उसके बाद मामला कुछ साल optimization करने और H100-स्तर की performance के consumer-grade बनने का इंतज़ार करने का है

  • जब science, SF की उम्मीदों से आगे निकल जाती है, तो हमेशा मज़ा आता है
    इस मामले में मुझे तुरंत Cyberpunk 2077 का Braindance concept याद आया, जिसमें आप किसी दूसरे व्यक्ति की visual memory के अंदर, उस व्यक्ति ने scene में जितना perceive किया था उसकी सीमा तक घूम सकते हैं
    original viewpoint से अलग जगह camera ले जाने पर view 3D pixels के ढेर की तरह टूट जाता है, जो यहाँ के blob concept जैसा है, लेकिन हैरानी की बात है कि यह इस paper से कहीं कम polished दिखता है
    https://steelseries.com/blog/how-to-braindance-cyberpunk-207...

  • volume rendering में splatting काफ़ी पुरानी technique है। Westover, Lee Alan का जुलाई 1991 का paper “SPLATTING: A Parallel, Feed-Forward Volume Rendering Algorithm” है

    • क्या मतलब यह है कि इस research में कुछ नया नहीं है, या यह कि यह पहले से established approach के ऊपर बनाया गया है?
      बाद वाली बात कोई छिपाने की कोशिश करता नहीं दिखता, और पहली बात सही नहीं लगती
    • पहले मैं इसे ऐसे सोचता था जैसे window पर Gaussian snowballs फेंकना और देखना कि क्या चिपकता है
      वह insight कहाँ से आई, मुझे नहीं पता, लेकिन उस समय मैं Boston के पास रहता था और मेरे छोटे बच्चे थे
    • लगता है कि नए paper के authors ने संबंधित पुराने research का काफ़ी हिस्सा miss कर दिया होगा

  • 3DGS rendering का पहला native optimized WebGPU implementation देखने की उम्मीद है
    यह भी उत्सुकता है कि scene data को efficiently compress और decompress कैसे किया जाएगा

    • मैं भी इंतज़ार कर रहा हूँ। बड़ी बाधाओं में से एक sorting है, और मुझे अभी तक अच्छा WebGPU implementation नहीं पता
      इस सवाल पर मैंने Zulip thread में कुछ notes छोड़े हैं: https://xi.zulipchat.com/#narrow/stream/197075-gpu/topic/Gau...
    • अभी उसी पर काम कर रहा हूँ

  • हाल ही में Gaussian splatting इस्तेमाल करने का तरीका दिखाने वाला एक video देखा: Getting Started With 3D Gaussian Splats for Windows (Beginner Guide) - https://www.youtube.com/watch?v=UXtuigy_wYc

  • structure from motion की मौजूदा state of the art को लेकर जिज्ञासा है
    जब किसी जगह का वीडियो हो, तो अभी उसे वास्तव में 3D scene में कैसे बदला जाता है, यह जानना चाहता हूँ

    • “structure from motion” का मतलब images या video के सेट से camera poses और sparse point cloud को reconstruct करने की प्रक्रिया है
      इस paper में बताए गए scene reconstruction process का input यही है
      जहाँ तक मुझे पता है, SfM का basic approach पिछले करीब 10 सालों में बहुत ज़्यादा नहीं बदला है, और इसे SIFT जैसे image feature extraction, heuristic matching, bundle adjustment और outlier removal में summarize किया जा सकता है
    • Video बस still images का एक collection ही है, इसलिए resolution या motion blur से quality खराब हो सकती है, इस बात को छोड़ दें तो यह सवाल लगभग वही है कि “video के बिना 3D scene कैसे capture करते हैं”
      सामान्य photogrammetry इसका जवाब है, और NeRF-style approaches में interest और practical उपयोगिता भी धीरे-धीरे बढ़ रही है
      हालांकि, यह हैरानी की बात है कि सिर्फ video होने से infer किए जा सकने वाले extra spatial relationships पर ज़्यादा ध्यान नहीं दिया जाता। लगता है frames के बीच camera सिर्फ कुछ खास तरीकों से ही move कर सकता है, इस constraint को camera pose estimation में इस्तेमाल किया जा सकता है
    • Gaussian Splatting paper खुद COLMAP का इस्तेमाल करता है, जो कोई बहुत नया tool नहीं है
      splat किए गए Gaussians पर marching cubes चलाकर mesh निकालने का idea है, लेकिन अभी तक ऐसा कोई actual example देखा हो, ऐसा नहीं लगता
    • Deep learning और traditional SfM को साथ में इस्तेमाल करने वाली GitHub repository hierarchical localization देखना अच्छा रहेगा
    • सीधे शब्दों में, यह Gaussian splatting और NeRF ही है

  • 90s के आखिर में blob से voxel isosurface render किए थे
    पूरे 3D voxel array में surface voxels को scan किया, local density gradient से normals calculate किए, फिर उन्हें 240 में से एक में quantize किया
    इसके बाद displacement vector table का इस्तेमाल करके surface voxel chains बनाई गईं, और ज़्यादातर voxels 2 bytes के थे: previous voxel से displacement index और normal vector index
    240 normal vectors के लिए lighting पहले से calculate करके lookup table में रखी गई थी, और software z-buffer में छोटे रंगीन circles बहुत तेज़ी से paint कर सकता था
    उस समय की बड़ी कमी यह थी कि perspective इस्तेमाल नहीं कर सकते थे। displacement vectors को हर frame में screen space में transform किया जाता था, इसलिए blob को paint करना, offset करना, color lookup करना, फिर से paint करना—ऐसा workflow था। chain के end और अगले absolute position storage को mark करने के लिए एक displacement value थी, लेकिन ज़्यादातर voxels 2 bytes के थे