WebGPU में UE5 Nanite तकनीक

 (github.com/Scthe)
1 पॉइंट द्वारा GN⁺ 2024-09-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Nanite WebGPU एक ऐसा प्रोजेक्ट है जो WebGPU के ज़रिए browser के अंदर UE5 की Nanite-जैसी rendering लागू करता है, और इसमें meshlet LOD hierarchy, software rasterizer, billboard impostor, instance/meshlet-level culling शामिल हैं
  • implementation का मुख्य लक्ष्य browser में OBJ input को preprocess करने की सरलता, और checkbox व slider से settings बदलते हुए performance में बदलावों का प्रयोग करना है
  • demo में Jinx scene 640M triangles, Lucy/Dragons आदि के अधिकतम 1.7B triangles वाले scenes उपलब्ध हैं, और Jinx के सफेद triangles WebGPU constraints के कारण 32-bit में compress करके process किए गए software rasterize result हैं
  • WebGPU में atomic<u64> नहीं है, इसलिए visibility buffer आधारित efficient software rasterizer को जस का तस implement करना मुश्किल है; मौजूदा implementation depth u16 और octahedron normal 2*u8 को 32-bit में रखकर precision artifacts को स्वीकार करती है
  • असली Nanite-जैसी implementation में मुख्य मुश्किल सिर्फ triangles की संख्या नहीं, बल्कि mesh simplification और error metric है; author स्पष्ट करता है कि उसकी implementation में UE5 के विपरीत simplification, streaming, compression, visibility buffer, 2-pass occlusion culling आदि नहीं हैं

प्रोजेक्ट का overview

  • Nanite WebGPU WebGPU का इस्तेमाल करके web browser में Nanite-जैसी rendering implement करने वाला प्रोजेक्ट है
  • इसमें शामिल मुख्य elements हैं meshlet LOD hierarchy, software rasterizer, billboard impostor, instance और meshlet-level culling
  • texture model और per-vertex normal support करता है, और हर setting के लिए slider या checkbox देता है
  • WebGPU सिर्फ Chrome में इस्तेमाल किया जा सकता है
  • पूरा app Deno का इस्तेमाल करके offline भी चलाया जा सकता है, और shader unit tests भी इसी तरीके से लिखे गए हैं

Demo scenes और scale

  • Jinx demo 120×120 instances, 640M triangles scale का है
    • एक single Jinx model को 44k triangles से 3k triangles और 59 root meshlets तक simplify किया गया है
    • सफेद triangles hardware rasterized area और दूर के background के impostor के बीच मौजूद software rasterized triangles हैं
  • Lucy and dragons में दो objects को 70×70 instances के रूप में arrange करके 1.7B triangles बनाए गए हैं
    • sample scene में लगभग 98% triangles software rasterized होते हैं, और बताया गया है कि यह path hardware से कहीं ज़्यादा तेज़ है
  • Lucy 110×110 instances, 1.2B triangles वाला scene है
    • single Lucy statue को 100k triangles से 86 triangles के एक single root meshlet तक simplify किया गया है
  • Dragons 70×70 instances, 1.2B triangles वाला scene है
    • single dragon को 250k triangles से 102 triangles के single root meshlet तक simplify किया गया है
  • Bunnies 500×500 instances, 1.2B triangles वाला scene है
    • single bunny को 5k triangles से 96 triangles के single root meshlet तक simplify किया गया है
    • bunny का size छोटा होने की वजह से उसका अधिकतर हिस्सा frustum culling में हट जाता है

Implemented features

  • Meshlet LOD hierarchy

    • mesh preprocessing browser में चलता है
    • meshoptimizer और METIS को WebAssembly के रूप में इस्तेमाल किया गया है
    • page refresh के बीच preprocessing का इंतज़ार न करना पड़े, इसके लिए file exporter भी दिया गया है

  • Software rasterizer

    • WebGPU में efficient implementation के लिए ज़रूरी atomic<u64> नहीं है
    • मौजूदा implementation depth u16 और octahedron-encoded normals 2*u8 को 32-bit में pack करता है
    • 32-bit limit की वजह से precision की बड़ी कुर्बानी देनी पड़ती है, और लक्ष्य सिर्फ यह दिखाना है कि rasterizer काम करता है
    • यह limitation occlusion culling में इस्तेमाल होने वाले depth pyramid को भी प्रभावित करती है

  • Billboard impostors

    • UP axis के चारों ओर की 12 images का इस्तेमाल करता है, और camera position के हिसाब से dithering के ज़रिए blend करता है
    • ऊपर/नीचे वाले viewpoints handle नहीं करता
    • diffuse और normal दोनों शामिल करके runtime shading करता है
    • Impostors preview impostor texture size बढ़ाया गया demo है

Culling और rendering path

  • culling कई stages से बना है
    • Per-instance: frustum culling और occlusion culling
    • Per-meshlet: frustum culling और occlusion culling
    • Per-triangle: hardware backface culling और z-buffer
  • WebGPU में early-z नहीं है
  • occlusion culling सिर्फ पिछले frame के depth buffer से बने depth pyramid का इस्तेमाल करता है
    • reprojection और two-pass तरीका नहीं है
    • माना गया है कि मौजूदा implementation ही कई triangles को cull करने और performance improvement का आकलन करने के लिए पर्याप्त है
  • GPU-driven rendering और simple CPU implementation के बीच switch किया जा सकता है
    • CPU version में बहुत ज़्यादा optimizations नहीं हैं, लेकिन debugger से step-by-step execution संभव है
  • “Freeze culling” feature camera को move करते हुए सिर्फ last frame में draw हुई चीज़ों को inspect करने देता है

Usability और debugging

  • movement के लिए [W, S, A, D], ऊपर/नीचे जाने के लिए [Z, SPACEBAR], और तेज़ movement के लिए [Shift] इस्तेमाल होता है
  • अजीब result दिखे तो culling options को on/off करके जांच सकते हैं
    • implementation में कुछ छोटे bugs हैं
  • सफेद triangles software rasterized triangles हैं
    • WebGPU में atomic<u64> न होने की वजह से depth और normal को 32-bit में compress किया गया है
    • 16-bit depth z-fighting या leak जैसे बहुत से artifacts बना सकता है
    • software rasterizer बंद करने पर raw Nanite meshlets देखना आसान हो जाता है, लेकिन performance बहुत गिर सकती है
  • FPS browser के forced VSync की वजह से fluctuate हो सकता है, और timing check करने के लिए “Profile” button इस्तेमाल करें

डिज़ाइन लक्ष्य

  • प्रोजेक्ट का पहला लक्ष्य सरलता है
    • OBJ file से शुरू करके सारी processing ऐप के अंदर ही की जाती है
    • Blender export जैसे अलग preprocessing step की जरूरत नहीं होती
    • मकसद ऐसा flow रखना है जिसमें loadObjFile() पर breakpoint लगाकर पहले frame के खत्म होने तक follow किया जा सके
  • दूसरा लक्ष्य प्रयोगशीलता है
    • Rust और Vulkan के बजाय इसे webpage के रूप में बनाया गया है, इसलिए link पर click करके checkbox या slider बदलते हुए performance में बदलाव देखा जा सकता है
    • कोई एक setting बदलने पर FPS काफी गिर जाए, इस तरह सीधे समझा जा सकता है कि कौन-सा option महत्वपूर्ण है
  • बहुत-सा code optimize किया जा सकता है, लेकिन simplification problem हल होने तक उस optimization को महत्वपूर्ण नहीं माना गया है

UE5 Nanite से अंतर

  • error metric के रूप में सरल projected simplification error इस्तेमाल किया गया है
  • meshlet simplification सरल तरीके से की गई है
  • two-pass occlusion culling नहीं है
    • जोड़ना मुश्किल नहीं है, लेकिन debugging झंझटभरी है और GUI settings के साथ interaction पैदा होता है
    • यह code readability को नुकसान पहुंचाता है, इसलिए लक्ष्य से मेल नहीं खाता
  • visibility buffer नहीं है
    • atomic<u64> की limitation के कारण इसे implement नहीं किया जा सकता
  • built-in shadows और multiview नहीं हैं
  • shader के अंदर work queue नहीं है
    • meshlet culling और LOD selection के लिए हर meshlet पर thread dispatch किया जाता है
  • इस्तेमाल न होने वाले LOD की VRAM eviction और streaming नहीं है
  • compression नहीं है
  • बहुत सारे अलग-अलग objects के लिए scalability कम है
    • demo cases में predictable memory usage पर focus किया गया है
    • stages के बीच data रखने वाले buffer के लिए drawn meshlets की upper limit पहले से जाननी पड़ती है
  • instance के लिए BVH या hierarchy implementation नहीं है
    • सभी instances पर frustum और occlusion culling किया जाता है

triangle count किन स्थितियों को दर्शाता है

  • सिर्फ “दसियों अरब triangles” जैसी संख्या से performance का अंदाजा लगाना मुश्किल है, और performance कई factors पर निर्भर करती है

  • Dense meshes

    • अगर पास में बहुत सारे dense mesh हों, तो performance पर नकारात्मक असर पड़ सकता है
    • हालांकि, अगर वे इतने पास हों कि screen का बड़ा हिस्सा ढक दें, तो occlusion culling काम करता है
    • dense geometry में meshlet छोटे होते हैं, screen पर उनकी जगह कम होती है और वे occlusion/cone culling के लिए आसान होते हैं

  • Instance count

    • हर instance के पास mat4x3 transform matrix होती है और वह VRAM consume करता है
    • frame के दौरान render किए जाने वाले items की list भी store करनी पड़ती है
    • worst case में हर instance सबसे dense meshlets को render करता है
    • implementation में instanceCount * bottomLevelMeshletsCount * sizeof(vec2u) bytes allocate किए जाते हैं
    • Chrome की WebGPU storage buffer की default limit 128MB है, और demo scene को इसी को ध्यान में रखकर adjust किया गया है

  • Scene arrangement

    • ऐप का scene objects को square pattern में arrange करता है
    • दूर के objects का सिर्फ कुछ हिस्सा दिखता है, लेकिन coarse meshlet LOD बड़ा हिस्सा include करता है, जिससे overdraw होता है
    • dense grid placement ज्यादा पास के triangles render करता है, लेकिन depth difference छोटा होने से occlusion culling के लिए फायदेमंद है
    • दूर-दूर रखे objects में कोई arbitrary दूर pixel depth pyramid को contaminate कर सकता है

Jinx scene मुश्किल क्यों है

  • Jinx character पतला है और arms और torso के बीच खाली जगह है, जिससे occlusion culling मुश्किल हो जाता है
  • model अच्छी तरह simplify नहीं होता, इसलिए सबसे coarse LOD में भी 3k triangles हैं
  • ऐसी स्थिति बनती है जिसमें 1-pixel size के बहुत सारे triangles accumulate हो जाते हैं
  • software rasterizer काफी मदद करता है, लेकिन scene arrangement के कारण ज्यादातर instances impostor के रूप में render होते हैं
  • पास के area में hardware rasterizer काम करता है, और hardware rasterizer, software rasterizer, impostor—तीनों की अलग-अलग strengths हैं

Nanite implementation में हैरान करने वाली बातें

  • DAG का लक्ष्य सिर्फ दूर के objects के लिए कम triangles इस्तेमाल करना नहीं है, बल्कि पूरी screen पर 1 pixel == 1 triangle के करीब consistency बनाए रखना है
  • discrete LOD mesh में हर LOD अलग geometry होता है, इसलिए intermediate level की जरूरत होने पर handle करना मुश्किल है; continuous LOD की जरूरत होती है
  • meshlet hierarchy चुने गए detail level पर geometry sample करने देती है
  • Nanite itself से ज्यादा समय culling और meshlet work में लगता है
  • meshlet LOD hierarchy को चलने लायक बनाना आसान है, लेकिन efficient बनाना कठिन है
  • अगर mesh साफ तरीके से simplify नहीं होता, तो Jinx जैसी स्थिति बनती है, जहां single pixel को cover करने वाले लगभग 3,000 triangles होते हैं
  • अगर pixel-sized triangles चाहिए, तो software rasterizer की जरूरत होती है, और billboard impostor भी stability-focused fallback के रूप में उपयोगी है

Mesh simplification problem

  • simplification “mesh लेकर X% triangles तक घटाने” की problem नहीं है, बल्कि meshlet और METIS context के अंदर की जाने वाली problem है
  • UE5 अपने mesh simplification code को asset pipeline के पहले step के रूप में इस्तेमाल करता है
    • यहां बची cost आगे पूरे system में chain benefits देती है
    • Brian Karis की SIGGRAPH material में बताया गया है कि LOD graph single root cluster पर खत्म होता है, और किसी भी model को 128 triangles तक simplify किया जा सकता है
  • Jinx model में simplification एक खास point पर रुक जाने की problem थी
    • input में X triangles देने पर वही X triangles वापस आने की स्थिति बनती थी
    • algorithm assertion से crash हो जाता था
    • बाद में mesh के जो हिस्से पर्याप्त रूप से कम नहीं होते थे, उनके लिए DAG में multiple roots allow करने में बदलाव किया गया
  • bunny model शुरू में single 128 tris meshlet तक simplify हो गया था, लेकिन conditions बदलने पर single root तक न जाने की problem सामने आई
    • कई meshlets triangles को पर्याप्त रूप से कम नहीं कर पाए, और 128 triangles से कम वाले “non-full” meshlets भी बहुत थे
  • संबंधित चर्चाएं:

Error metric

  • 20,000,000 triangles वाले mesh को meshlet hierarchy के रूप में render करते समय, यह चुनना होता है कि कौन सा meshlet “सही” meshlet है
  • यह selection problem Nanite का core है, और simplification, meshlet DAG, software rasterizer इसके लिए लगभग prerequisite जैसे हैं
  • implementation में meshoptimizer द्वारा दिया गया projected simplification error इस्तेमाल होता है
  • लेखक के अनुसार यह metric Nanite के लिए अच्छा metric नहीं है, और अन्य vertex attributes को भी function में शामिल किया जाना चाहिए
    • हर attribute के लिए weight देने की सुविधा होनी चाहिए
    • Jinx के चेहरे के normal में बड़ी समस्या थी
  • संदर्भित सामग्री:

software rasterizer texture output क्यों नहीं करता

  • hardware rasterizer में depth test के result के आधार पर depth texture, color और normal को साथ में लिखा जा सकता है
  • software rasterizer में अगर कई threads एक ही pixel पर लिखें, तो race condition पैदा होती है
  • आम समाधान visibility buffer है
    • हर pixel में सबसे नज़दीकी triangle का sceneUniqueTriangleId output किया जाता है
    • इसे 32-bit depth के साथ जोड़कर 64-bit value बनाया जाता है और 64-bit atomic operation इस्तेमाल किया जाता है
    • एक अलग pass में triangle को फिर से rasterize किया जाता है और barycentric coordinates calculate करके shading की जाती है
  • WebGPU में 64-bit atomics नहीं हैं, इसलिए यह तरीका इस्तेमाल नहीं किया जा सकता
  • इस project का लक्ष्य यह दिखाना है कि software rasterization काम करता है; इसलिए background में software-rasterized model सफेद है और सिर्फ reasonable shading देता है

अपनी Nanite implementation पर आकलन

  • सबसे आसान जवाब UE5 इस्तेमाल करना है
  • मौजूदा engine में यह technology डालनी हो, तो पहले compute-based graphics pipeline और GPU-driven rendering pipeline implement करने का चरण ज़रूरी लगता है
  • multi-step culling, scene/world chunk management, animated meshes जैसी समस्याएं पहले सामने आती हैं
  • सुझाव दिया गया क्रम यह है कि इन चरणों के stabilize होने के बाद software rasterizer आज़माया जाए, और उसके बाद Nanite-like tech जोड़ी जाए
  • toy renderer में basic meshlet hierarchy weekend project हो सकती है, लेकिन वास्तविक implementation में simplification और error metric की समस्याओं से निपटना होगा

इस्तेमाल किए गए tools और संदर्भ सामग्री

  • meshoptimizer project implementation का मुख्य आधार है
    • newer meshoptimizer versions में Nanite clone के लिए meshopt_SimplifySparse है
    • project ने development के दौरान tested state बनाए रखने के लिए उस version पर update नहीं किया
  • METIS इस्तेमाल किया गया
  • Emscripten का इस्तेमाल meshoptimizer और METIS को browser में चलाने के लिए किया गया
  • Jinx model के लिए Sketchfab का Arcane - Jinx इस्तेमाल किया गया, और texture merging, UV adjustment, weapon removal किया गया

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

1 टिप्पणियां

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

  • ओह, बढ़िया। यानी Nanite playback का third-party implementation आ गया है।
    Nanite graphics mesh को बहुत चतुर तरीके से represent करता है। यह tree नहीं बल्कि directed acyclic graph है, इसलिए दोहराव copy की जगह link बन जाता है, और mesh sub-meshes को share कर सकता है, जिनके sub-meshes भी आगे share हो सकते हैं। यह mesh के अंदर level of detail (LOD) भी support करता है, इसलिए जब sub-mesh काफी छोटा हो जाता है तो उसे हटा दिया जाता है।
    इसलिए सीमित data और तेज rendering time के साथ बहुत बड़े, दोहराव वाले content को संभाला जा सकता है। चूंकि स्क्रीन पर pixels की संख्या सीमित होती है, इसीलिए वास्तव में जरूरी rendering workload की भी एक ऊपरी सीमा होती है — यही इसकी मुख्य समझ है।
    Epic के एक व्यक्ति ने इसे समझाने वाला SIGGRAPH वीडियो बहुत अच्छा बनाया है। मौजूदा GPU design, Nanite के लिए खास अनुकूल नहीं है, इसलिए अगर और ज्यादा processing GPU पर करनी हो तो नए hardware operations की जरूरत पड़ेगी। Nvidia इस समय AI market में बहुत व्यस्त है, इसलिए ऐसा बदलाव आएगा या नहीं, इस पर संदेह है।
    यह तरीका असरदार होने के लिए scene में बहुत instancing चाहता है। Unreal Engine demo में एक जैसे statues वाले hall की तरह, सीमित संख्या के objects को reuse करके बड़े content area बनाने वाले AAA games के लिए यह बहुत उपयुक्त है। अगर आप Cyberpunk 2077 के वीडियो में railings और कचरे के ढेर देखें, तो वही चीजें अलग-अलग context में बार-बार दोहराई जाती दिखेंगी।
    Nanite mesh बनाना जटिल है क्योंकि इसमें internal link offsets बहुत होते हैं, और अब तक इसे सिर्फ Unreal Engine editor ही संभालता था। अब playback वाला हिस्सा open source हो गया है, इसलिए संभव है कि कोई authoring tools भी बना दे।
    हालांकि format के internal offsets attack surface बन सकते हैं, और यह किसी दुर्भावनापूर्ण Microsoft Word .doc file की तरह छेड़छाड़ किए गए content के जरिए दुरुपयोग के लिए उपयुक्त लगता है।

    • directed acyclic graph graph cut के लिए जरूर बनाया जाता है, लेकिन अंतिम disk data तो बस clusters की एक flat list है जिसमें include/exclude criteria होते हैं। DAG कहां इस्तेमाल होता है और कैसे बनता है, इस बारे में यहां काफी बड़ी गलतफहमी दिख रही है।
      DAG vertex data के आधार पर dynamically बनाया जाता है, और artist ने sub-meshes कैसे व्यवस्थित किए, उससे इसका कोई संबंध नहीं है। यह भी नहीं है कि “दोहराव link बन जाता है।”
      और हर object instance के लिए graph cut का परिणाम अलग होता है, इसलिए traditional instancing का इस्तेमाल नहीं किया जा सकता। ऐसे में scene में instancing ज्यादा होने पर ही इसका असर होगा, यह बात मुझे समझ नहीं आती।
    • बहुत पहले 2000s में PS3 development करते समय हम Cell की भारी compute capacity का ठीक से उपयोग करने और RSX की सीमित memory bandwidth को bypass करने के तरीके खोज रहे थे। Blu-ray storage space तो काफी उपलब्ध था।
      तब हमने Nanite जैसी चीज पर काफी काम किया था, जिसे हम compressed meshes कहते थे। यह एक आम तरह का गलत दिशा में गया engineering overconfidence था।
      शुरुआती काम उम्मीद जगाने वाला लगा, लेकिन जैसे-जैसे समस्याओं में गहराई से उतरे, पूरी चीज लगातार ज्यादा जटिल होती गई। पूरा asset creation pipeline बनाना पड़ता, और अच्छे visual results देते हुए memory को फाड़े बिना समय पर पूरा करने के लिए यह बहुत बड़ा काम था।
      हम इसे इतनी दूर तक ले गए कि यह बड़े meshes को cascaded detail levels के साथ render करता हुआ दिखे, लेकिन यह बहुत धीमा था और GPU पर इतना दबाव डालता था कि subpixel accuracy ठीक न हो तो नतीजा बेहद खराब दिखता। यह मजेदार experiment था, लेकिन hardware के लिए भी बहुत भारी और अकेले संभालने के लिए भी बहुत बड़ा काम था।
      जब Epic ने Nanite दिखाया तो मैं सचमुच हैरान रह गया। उन्होंने वह किया जो मैं नहीं कर सका, और मेरी कल्पना के सबसे अच्छे तरीके से भी कहीं बेहतर ढंग से किया। यह उन तकनीकों में से थी जो आने पर hype नहीं बल्कि सचमुच का समाधान साबित हुईं, और आधुनिक graphics world का एक तकनीकी रत्न है। अगर Epic public company होती, तो मैं सिर्फ Nanite technology को देखकर भी उसमें काफी बड़ा निवेश करने के बारे में सोचता।
    • जिस SIGGRAPH talk का जिक्र हुआ, वह शायद "A Deep Dive into Nanite Virtualized Geometry" है: https://www.youtube.com/watch?v=eviSykqSUUw
      एक छोटा high-level intro वीडियो भी अच्छा था। वह है: "What is virtualized micropolygon geometry? An explainer on Nanite": https://www.youtube.com/watch?v=-50MJf7hyOw
    • यह कोई mainstream engine नहीं है, लेकिन छोटा Rust ECS game engine Bevy भी "Virtual Geometry" नाम की feature के रूप में कुछ ऐसा ही support करता है: https://bevyengine.org/news/bevy-0-14/#virtual-geometry-expe...
      इस feature के लेखकों में से एक का लिखा एक technical deep-dive भी है: https://jms55.github.io/posts/2024-06-09-virtual-geometry-be...
    • papers पढ़कर मुझे लगा कि सबसे बड़ा लाभ quantized coordinates और पूरे mesh की बजाय छोटे patches के स्तर पर dynamic level of detail से आता है।
      मेरी समझ के अनुसार Nanite का तर्क यह है कि mesh accuracy को लगभग 1-pixel precision के आसपास बनाए रखा जाए। उदाहरण के लिए, अगर perspective projection के बाद error लगभग आधा pixel ही रह जाए, तो 10-bit तक rounded coordinates वाला कम-detail mesh इस्तेमाल किया जा सकता है।
      मुझे धुंधला-सा याद है कि quantization ने दो भूमिकाएं निभाईं। इससे सिर्फ data storage size कम नहीं हुई, बल्कि vertices को space में एक ही position पर snap करके level-of-detail generation में भी मदद मिली, और बाद में deduplication भी किया जा सका।

  • इस thread में कई बार जिक्र हुआ है, लेकिन Bevy में भी Nanite के विचारों का एक implementation है। कभी-कभी इसे virtual geometry कहा जाता है। मैं उसका लेखक हूं, इसलिए सवालों के जवाब दे सकता हूं :)
    इस project पर Scthe ने सचमुच शानदार काम किया। हमने काम के दौरान कई हिस्सों पर साथ में चर्चा की, और उसी अनुभव के आधार पर Bevy code भी सुधरा: https://github.com/bevyengine/bevy/pull/15023
    इस क्षेत्र में और लोगों का आना हमेशा अच्छा लगता है। Nanite में सचमुच बहुत सारे शानदार ideas हैं।

  • क्या यह डेमो compatibility जाँचने के लिए user agent string का इस्तेमाल कर रहा है? यह अच्छी बात नहीं है। feature compatibility का फैसला हर case के हिसाब से सीधे specific feature को detect करके या उसे इस्तेमाल करके करना चाहिए
    मैं Chrome नहीं बल्कि Chromium इस्तेमाल करता हूँ और WebGPU भी हमेशा इस्तेमाल करता हूँ, लेकिन डेमो कहता है कि Chrome इस्तेमाल करें। नैतिक रूप से मैं ऐसा नहीं कर सकता। मैं सच में डेमो चलाकर देखना चाहता हूँ; यह काफी मेहनत से बना प्रोजेक्ट लगता है

    • जानकारी के लिए, Linux के Chrome में भी और Android में भी यह काम नहीं करता। वैसे वास्तविक browsing के लिए मैं लगभग हमेशा Firefox इस्तेमाल करता हूँ। detection logic में कुछ काफी अजीब है
    • ऐसा नहीं लगता। experimental WebGPU support ऑन किए हुए Firefox में यह अलग संदेश की जगह shader compile error के साथ फेल होता है
    • feature-by-feature detection को लक्ष्य बनाना अच्छी बात है
      जब मैं browser components framework खुद बनाता था, तब detection अक्सर संभव नहीं होती थी, इसलिए browser sniffing पर निर्भर रहना पड़ता था। Modernizr code में feature detection के लिए बहुत चालाक hacks हैं, और कभी-कभी बहुत गंदे hacks भी। भरोसेमंद detection code बनाने में बहुत बड़ा काम लगा, और detection भी अक्सर side effects के जरिए होती थी
      मेरा अनुमान है कि Web3D feature detection आसान नहीं है। जल्दी से खोजने पर भी कोई साफ Web3D feature detection library नज़र नहीं आई
      Modernizr के :checked support detection code का एक हिस्सा ऐसा है:
      Modernizr.addTest('checked', function(){
      return Modernizr.testStyles('#modernizr input {width:100px} #modernizr :checked {width:200px;display:block}', function(elem, rule){
    • मुझे नहीं पता आप कौन-सा build इस्तेमाल कर रहे हैं, लेकिन मैं Ungoogled Chromium इस्तेमाल करता हूँ और user agent string Google Chrome से बिल्कुल एक जैसी है
      क्या आपने site settings में उस site के लिए WebGL permission ऑन की है? मेरे मामले में शायद वह default से बंद थी
    • लगता है डेमो खुद ही टूटा हुआ है। मुझे यह error मिलती है:
      WebGPU error [frame][validation]: Fill size (7160950) is not a multiple of 4 bytes.
      • While encoding [CommandEncoder "main-frame-cmd-buffer"].ClearBuffer([Buffer "rasterize-sw"], 0, 7160950).

  • यह Federico Ponchio की 2009 की कुछ हद तक दब गई PhD thesis है, जिसमें dynamic mesh simplification algorithm का वर्णन है, जो Nanite की नींव बना। इसमें बहुत-सी तस्वीरें भी हैं
    https://vcg.isti.cnr.it/~ponchio/download/ponchio_phd.pdf कुल 107 पेज हैं

  • यह कि यह किसी हद तक काम करता है, काफी प्रभावशाली है, लेकिन WebGPU में 64-bit atomic operations नहीं हैं, इसलिए काफी कड़े समझौते करने पड़े
    उम्मीद है कि कभी इसे optional extension के रूप में जोड़ा जाएगा। कम-से-कम desktop-class hardware पर hardware support लगभग सार्वभौमिक है। AMD और Nvidia में यह बहुत पहले से था, और Apple ने M3 से इसे support किया

    • rasterizer में atomic operations का उपयोग किस लिए होता है? मुझे समझ नहीं आता कि rendering pipeline के भीतर atomics क्या कर रहे हैं। मैंने GitHub भी देखा, लेकिन वह जगह नहीं मिली जहाँ atomic operations की अपेक्षा थी
    • M2 से है

  • इसमें दिखता है कि iPhone 12 Pro Max पर WebGPU नहीं है, लेकिन experimental features में इसे ऑन करने पर दूसरी WebGPU demo site[1] काम करती है। क्या किसी ने इसे iPhone पर सफलतापूर्वक चलाया है? अच्छा होता अगर web app यह ज़्यादा विस्तार से बताती कि आखिर क्या फेल हुआ
    [1] https://webgpu.github.io/webgpu-samples/?sample=texturedCube

    • मैंने Safari में WebGPU ऑन किया, लेकिन shader errors की भरमार दिखती है
      WebGPU error [init][validation]: 6 errors generated while compiling the shader: 50:22: unresolved call target 'pack4x8snorm' 50:9: cannot bitcast from '⊥' to 'f32' 54:10: unresolved call target 'unpack4x8snorm' 59:22: unresolved call target 'pack4x8unorm' 59:9: cannot bitcast from '⊥' to 'f32' 63:9: unresolved call target 'unpack4x8unorm'
    • Safari का WebGPU support अभी पूरा नहीं हुआ है, इसलिए यह अब भी experimental feature में है

  • नाम और विवरण काफी भ्रामक हैं और trademark infringement की संभावना भी लगती है। दावे के विपरीत, इसका UE5 के वास्तविक Nanite से कोई सीधा संबंध नहीं है; लगता है UE5 से असंबंधित किसी व्यक्ति ने कुछ मिलता-जुलता लागू किया है
    Bevy का Virtual Geometry भी है, जो मिलती-जुलती functionality देता है। यह Rust में लिखा गया है और game engine में integrated है, इसलिए संभवतः काफी अधिक उपयोगी होगा: https://jms55.github.io/posts/2024-06-09-virtual-geometry-be...

    • शायद यह कोई बड़ी समस्या नहीं है। README देखने पर साफ है कि यह एक implementation है
      अगर मैं कहूँ कि मैंने “OpenAI के GPT-3 को JS में implement किया”, तो उसका मतलब यही समझा जाएगा कि मैंने whitepaper की architecture लेकर उसे फिर से implement किया

  • यह वास्तव में WebGPU पर चलने वाला UE5 Nanite नहीं है। यह Nanite जैसी ही अवधारणा का एक स्वतंत्र implementation है
    यह तकनीक अब कई जगह दिखाई देने लगी है। यह सही है कि Nanite ने इस विचार को प्रसिद्ध बनाया, लेकिन Nanite तकनीक का नाम नहीं, बल्कि एक specific implementation का नाम है

  • मुझे जिज्ञासा है कि दूसरे engines में level of detail और उससे मिलते-जुलते systems किस स्तर तक पहुँचे हैं।
    Godot में automatic level of detail feature है, और अपने-आप में यह काफ़ी अच्छा लगता है: https://docs.godotengine.org/en/stable/tutorials/3d/mesh_lod...
    Unity में भी level of detail system है, लेकिन engine की लोकप्रियता की तुलना में इसमें level of detail models हाथ से बनाने पड़ते हैं, अगर आप asset store में plugin न ढूँढें तो: https://docs.unity3d.com/Manual/LevelOfDetail.html
    कम-ज्ञात engine NeoAxis में भी मैंने एक दिलचस्प approach देखी है: https://www.neoaxis.com/docs/html/NeoAxis_Levels.htm लेकिन मेरे पुराने RX580 पर performance बहुत खराब थी, और मौजूदा A580 पर मैंने अभी तक इसे नहीं आज़माया है
    मेरी नज़र में, स्क्रीन पर बहुत सारी चीज़ें दिखाने की क्षमता के मामले में Unreal अपने competitors से काफ़ी आगे है। कमी यह है कि artists गेम में और भी high-quality assets डालना चाहेंगे, जिससे install size काफ़ी बढ़ सकती है

    • सैद्धांतिक रूप से Nanite precomputed level of detail से बेहतर है। व्यवहार में, यह बात इतनी साफ़ तौर पर कहना मुश्किल है। यह artist द्वारा हाथ से बनाए गए level of detail जितना अच्छा होना कठिन है, और ऐसी उम्मीद करना भी बहुत तर्कसंगत नहीं है
      इसका performance cost भी बड़ा है। Nanite या virtual geometry आधुनिक GPU के साथ बहुत अच्छी तरह मेल नहीं खाते। अगर मुझे सही याद है, तो अधिकतम fill rate लगभग 1/4 था। वजह यह है कि GPU rasterization shaders की तरह pixel basis पर नहीं, बल्कि 2x2 quads basis पर काम करती है
    • Intel Arc GPU Nanite rendering में बहुत खराब हैं। कारण यह है कि GPU-driven renderers में व्यापक रूप से इस्तेमाल होने वाले indirect draw और Nanite के लिए ज़रूरी 64-bit atomic operations, दोनों का hardware support इसमें नहीं है। Intel indirect draw को software में emulate करता है, इसलिए यह धीमा है

  • जब भी मैं ऐसे rendering scenes देखता हूँ जिनमें इतना repetitive static geometry होता है, मुझे पुराने vaporware videos में “unlimited detail” की बात करने वाले उस चिड़चिड़े आदमी की आवाज़ याद आ जाती है
    उस पुराने किसी चीज़ के विपरीत, Nanite सचमुच उस समस्या को हल करता हुआ लगता है। मुझे याद है कि वहाँ octree जैसी किसी चीज़ के इस्तेमाल की बात होती थी

    • मेरा ख़याल है वह दावा करने वाली company Euclidean थी। शायद वह एक Australian company थी
      online rumors में octree इस्तेमाल करने की बात थी, लेकिन बाद में आए Euclidean videos ने इसे साफ़ तौर पर नकार दिया था