के लिए: Oleg Sidorkin
विषय: app.cinevva.com/blog/2026-03-04-sketch-to-animated-3d-character
किसके आधार पर जाँचा गया: cinevva-site repo (मार्केटिंग साइट + worker)

सत्यापित ✓

• Tool नाम (Image Generator, Video Generator, 3D Model Generator) और link /tools/hunyuan3d codebase से मेल खाते हैं।
• लेखक (Oleg Sidorkin, CTO) सही है।
• Video workflow: शुरुआती + अंतिम frame interpolation, 9:16, 3–15 s अवधि, और storyboard mode सभी समर्थित हैं।
• 3D pipeline: Hunyuan3D और "3D Model Generator" सही हैं; auto-rigging (Tripo) और "upload GLB → rigged model + animation library" implementation से मेल खाते हैं।
• Cinevva Engine और "2026 की शुरुआत को दर्शाता है" सटीक हैं।

सुधार की ज़रूरत

"Seedance 1.5 Pro" — इस repo में, video को Kling 3.0 Pro (fal.ai) के साथ implement किया गया है, Seedance 1.5 Pro के साथ नहीं:

• worker/src/genai/fal-video.ts में fal-ai/kling-video/v3/pro/... का उपयोग होता है
• worker/src/index.ts cost को model: 'kling-3.0-pro' के रूप में track करता है
• tools/video.md कहता है: "Generate short AI videos from text or images using Kling 3.0 Pro"

API/product नाम "seedance" है (जैसे /genai/seedance/generate), लेकिन अंतर्निहित model Kling 3.0 Pro है। Seedance 1.5 Pro एक अलग model है (ByteDance)। सार्वजनिक स्रोत अक्सर Seedance 1.5 Pro को ~10 s तक सीमित बताते हैं; यहाँ Kling के लिए 15 s समर्थित है।

सिफ़ारिश: लेख में, video model को "Kling 3.0 Pro" नाम दें (या जैसे "Video Generator (Kling 3.0 Pro)") ताकि यह मार्केटिंग साइट और docs से मेल खाए। अगर app backend वाकई Seedance 1.5 Pro का उपयोग करता है, तो app copy और tools/video.md को align करें ताकि वे एक ही model का वर्णन करें।

repo में सत्यापित नहीं किया जा सकता

Cubcoats, Kali the Kitty, Mimi Chao, और संबंधित व्यावसायिक दावे बाहरी हैं; जाँचे नहीं गए।

आपको Game Creator में spike {{ spikeId }} पर ले जाया जा रहा है। अगर आप अपने आप redirect नहीं होते, तो इसे यहाँ खोलें।

Game Creator खोलें।

← सीरीज़ गाइड पर वापस

Mariana Muntean द्वारा, Cinevva की CEO

ठीक है, तो हमारा बिलकुल भी इरादा नहीं था कि पूरा एक हफ़्ता itch.io पर लगा दें। जो एक झटपट रिसर्च के तौर पर शुरू हुआ था, वो बदल गया... खैर, बारहवें घंटे के आसपास कहीं हमने गिनना बंद कर दिया। पूरा मकसद ऐसे games ढूंढना था जिन्हें आप तुरंत खेल सकें, कोई डाउनलोड नहीं, कोई इंस्टॉलर बैकग्राउंड में घिसटता हुआ नहीं। आप क्लिक करते हैं, आप अंदर हैं। बस।

ये वो हैं जो चुनाव में खरे उतरे।

टॉप-रेटेड इंटरैक्टिव अनुभव

Adventures With Anxiety! — Interactive Story 6,500 से ज़्यादा रेटिंग, औसत 4.9। अजीब है ना कि कोई ऐसी चीज़ जो आपको anxiety का सामना करने पर मजबूर करती है, उसके इतने फैन हैं? सबसे अच्छे तरीके से असहज करती है, वो वाला जो मन में बैठ जाता है। यहां खेलें

We Become What We Behold — Social Commentary 7,600 रेटिंग, 4.8/5 पर। खत्म करने में दस मिनट। इसके बारे में सोचना बंद करने में कई दिन। यहां खेलें

Six Cats Under — Puzzle Adventure आरामदेह और चतुर। यहां विज़ुअल्स असली भारी काम संभालते हैं, जो इसके फ़ायदे में जाता है। 6,400+ लोगों से 4.8/5। यहां खेलें

Friday Night Funkin' — Rhythm Game यह वाला अब तक हर जगह पहुंच चुका है। 11,700+ रेटिंग, 4.7/5। यहां खेलें

Sort the Court! — Kingdom Sim आपका बस एक ही काम: हां या ना कहना। सुनने में कुछ खास नहीं लगता। फिर दो घंटे गायब हो जाते हैं जबकि आप अब भी एक नन्हा सा राज्य चला रहे होते हैं। यहां खेलें

Dragonsweeper — Puzzle Roguelike Minesweeper लीजिए, उसे RPG सिस्टम्स के साथ मिला दीजिए। 4.9/5, शायद यह असल में पूरी लिस्ट की सबसे अच्छी चीज़ है। यहां खेलें

Roguelike और Strategy (browser में खेलने लायक)

Backpack Hero — Inventory Roguelike Browser वर्शन का कोई पैसा नहीं लगता। पेड वर्शन में और चीज़ें जुड़ती हैं, लेकिन मुफ़्त वेब बिल्ड अपने दम पर टिकता है। यहां खेलें

Vampire Survivors — Bullet Heaven सिर्फ़ डेमो, एक ही स्टेज, सात कैरेक्टर। फिर भी यह समझने के लिए काफ़ी है कि इस चीज़ ने सबका खाली समय क्यों निगल लिया। यहां खेलें

Dome Romantik — Mining Defense एक game jam की चीज़ के तौर पर शुरू हुआ। Dome Keeper बन गया। बहुत बड़ा बन गया। ओरिजिनल प्रोटोटाइप अब भी टिका हुआ है। यहां खेलें

खासतौर पर ये ही क्यों?

हर एक लिंक को टेस्ट किया गया। कोई झटपट नज़र नहीं, हम असल में बैठकर इन्हें खेले। ये बिना किसी नाटक के लोड होते हैं। कोई browser की अजीब हरकत नहीं। हज़ारों रेटिंग उन लोगों से आईं जिन्होंने कभी कोई डाउनलोड बटन नहीं छुआ, उन्होंने क्लिक किया और सीधे कूद पड़े। "अरे, दिलचस्प है" से लेकर असल में खेलने तक का वो बिना-रुकावट वाला रास्ता? ज़्यादातर लोग यह कम आंकते हैं कि यह कितना कुछ बदल देता है।

और वेब games देखें

अब भी और चाहिए?

• itch.io पर टॉप रेटेड HTML5 games
• सबसे अच्छे HTML5 platformers
• 2024-2025 के games

जाने-माने indie games (डाउनलोड ज़रूरी)

कुछ बढ़िया चीज़ें आपके browser में नहीं चलेंगी। ये उस अतिरिक्त कदम के लायक हैं:

Slice & Dice — Dice Roguelike Windows, Mac, Android पर चलता है। इसे itch.io पर लें

Stacklands — Card Village Builder Windows और Mac। इसे itch.io पर लें

Luck be a Landlord — Slot Machine Roguelike सुनने में एक गिमिक लगता है। ऐसा है नहीं। उस स्लॉट मशीन की सतह के नीचे असली strategy छिपी है। itch.io

Patrick's Parabox — Recursive Puzzles अपने दिमाग को दर्द होने की उम्मीद रखें। फिर भी इसे पसंद करने की उम्मीद रखें। itch.io

Dome Keeper — Mining Defense उसी jam प्रोटोटाइप का पूरा रिलीज़ जिसका हमने ज़िक्र किया था। इसे Steam पर पाएं

Brotato — Arena Survivor Steam पर उपलब्ध

अगर आप games बना रहे हैं तो यहां सोचने लायक एक बात है: browser बिल्ड खिलाड़ियों और आपके काम के बीच कुछ नहीं रखते। कोई डाउनलोड नहीं जो किसी कतार में पड़ा रहे और वे भूल जाएं। कोई इंस्टॉल स्क्रीन नहीं जिसमें क्लिक करते जाना पड़े। एक क्लिक और वे पहले से ही राय बना रहे होते हैं कि आपने क्या बनाया। इस तरह की तुरंत-पहुंच पर उतनी बात नहीं होती जितनी होनी चाहिए, लेकिन यह सब कुछ बदल देती है।

अपने खुद के game के लिए यही चाहते हैं? आप एक game सीधे browser में Cinevva game creator के साथ बना सकते हैं, और जिन्हें हम फ़ीचर करते हैं वे हमारे community आर्केड में जगह पाते हैं।

• game creators के लिए
• एक वेब game बनाएं जो तेज़ लोड हो

Oleg Sidorkin द्वारा, Cinevva के CTO और Co-Founder

अगर आप 2026 में एक ऐसा 3D game शिप करना चाहते हैं जो browser में चले, तो आपके पास चार मुख्य विकल्प हैं और कुछ नए विकल्प भी। इन्हें एक साथ "web game engines" कह दिया जाता है, लेकिन ये असल में अलग-अलग tools हैं जो अलग-अलग समस्याएं हल करते हैं। गलत वाला चुनने पर आपके कई महीने बर्बाद हो जाते हैं। यह एक ताज़ा, फैक्ट-चेक की हुई तुलना है, जिसे उन लोगों ने लिखा है जो रोज़ी-रोटी के लिए एक web 3D engine बनाते हैं और अपना खुद का बनाने से पहले इन सबको परख चुके हैं।

हम हर विकल्प को बारी-बारी देखेंगे, वो असल में क्या है, किसके लिए है, और कहां कमज़ोर पड़ता है, फिर आखिर में आपको एक छोटी डिसीज़न गाइड देंगे। जहां हम version नंबर बताते हैं, वे June 2026 तक सही हैं।

झटपट तुलना

बाकी की यह पोस्ट इस टेबल को समझाती है।

PlayCanvas

PlayCanvas web पर Unity-स्टाइल workflow के सबसे नज़दीक की चीज़ है। यह engine MIT लाइसेंस के तहत open source है और 5 June 2026 तक v2.19.6 पर है। यह एक entity-component system इस्तेमाल करता है, आप game की लॉजिक TypeScript या JavaScript में लिखते हैं, और assets एक server-side pipeline से होकर गुज़रते हैं जो GLB बनाती है। इस पर असली कमर्शियल games चलते हैं, और बड़ी कंपनियां इसे प्रोडक्शन में इस्तेमाल करती हैं, Snap इसका एक सार्वजनिक उदाहरण है।

PlayCanvas के बारे में दो चीज़ें लोग गलत समझते हैं, जिन्हें सुधारना ज़रूरी है। पहली, भले ही engine MIT-लाइसेंस वाला है, लेकिन जिस होस्टेड visual editor को ज़्यादातर टीमें असल में इस्तेमाल करती हैं वो एक कमर्शियल प्रोडक्ट है, open source नहीं। आप इसके बिना भी engine को मुफ़्त में इस्तेमाल कर सकते हैं, लेकिन editor-प्लस-क्लाउड वाला workflow पैसे वाला हिस्सा है। दूसरी, PlayCanvas WebGL2-फर्स्ट है। इसमें एक WebGPU रास्ता है, लेकिन वो रास्ता डिफ़ॉल्ट renderer होने के बजाय अभी परिपक्व ही हो रहा है, इसलिए आज PlayCanvas को इस उम्मीद से मत चुनिए कि उसमें प्रोडक्शन-लेवल WebGPU compute shaders मिलेंगे।

PlayCanvas जहां सचमुच आगे है वो है 3D Gaussian splatting। इसका SuperSplat editor और viewer, जिसे टीम ने open-source किया, web पर splat scenes कैप्चर करने और शिप करने के लिए कहीं भी मौजूद बेहतरीन tooling में से एक है, बड़े कैप्चर के लिए WebGPU-आधारित streaming के साथ। अगर फोटोरियल स्कैन किए हुए environments आपकी चीज़ हैं, तो यहां से शुरू करने की यह एक असली वजह है।

PlayCanvas चुनें अगर आप browser के लिए एक Unity-जैसा editor और एक मैनेज की हुई asset pipeline चाहते हैं, और आप वैसा game शिप कर रहे हैं जैसा कोई स्टूडियो बनाएगा। कहीं और देखें अगर आपको आज WebGPU compute चाहिए, या आप एक होस्टेड कमर्शियल editor से बचना चाहते हैं।

Three.js

Three.js कोई game engine नहीं है। यह एक रेंडरिंग लाइब्रेरी है, और इस क्षेत्र में काफी बड़े अंतर से सबसे ज़्यादा इस्तेमाल होने वाली लाइब्रेरी है। यह आपको एक scene graph, cameras, lights, materials, geometry, loaders और एक renderer देती है, और फिर रुक जाती है। न कोई editor है, न physics, न entity system, और game को कैसे संरचित करना है इस पर कोई राय नहीं। वो सब आप खुद जोड़ते हैं या ecosystem से उठाते हैं।

यही सौदा पूरी कहानी है। आपको सबसे ज़्यादा कंट्रोल और web 3D का सबसे बड़ा कम्युनिटी मिलता है, इस कीमत पर कि renderer के ऊपर की हर चीज़ आपको बनानी या जोड़नी पड़ती है। इसका WebGPU renderer लगातार बढ़ता रहा है और आज इस्तेमाल लायक है, हालांकि बाकियों की तरह यहां भी WebGL2 रास्ता ही परिपक्व डिफ़ॉल्ट है। Three.js MIT-लाइसेंस वाला है।

Three.js चुनें अगर आप पूरा कंट्रोल, एक मिनिमल बेस चाहते हैं, और आपके पास इसके ऊपर अपने game systems बनाने की इंजीनियरिंग क्षमता है। कहीं और देखें अगर आप चाहते हैं कि editor और game systems आपको बने-बनाए मिल जाएं।

Babylon.js

Babylon.js एक पूरा engine है, MIT-लाइसेंस वाला और Microsoft की एक टीम के समर्थन से। Three.js के उलट, इसके साथ वो हिस्से आते हैं जिन्हें आपको वरना खुद जोड़ना पड़ता: एक component model, इंटीग्रेटेड Havok physics engine, एक मुफ़्त web-आधारित editor, और एक asset pipeline। इसका WebGPU काम तेज़ी से आगे बढ़ा है और general-purpose engines में से ज़्यादा एडवांस्ड में से एक है, हालांकि यह अभी भी WebGL2 को व्यापक-कम्पैटिबिलिटी रास्ते के रूप में बनाए रखता है।

अगर आपकी सोच यह है कि "मुझे एक पूरा engine चाहिए, उसके साथ physics शामिल हो, और मैं उसके तौर-तरीकों के भीतर काम करके खुश हूं," तो Babylon एक मज़बूत डिफ़ॉल्ट है और यकीनन इस क्षेत्र का सबसे feature-complete मुफ़्त विकल्प है।

Babylon.js चुनें अगर आप चाहते हैं कि सब कुछ शामिल मिले, बिल्ट-इन physics हो, और एक मुफ़्त editor हो। कहीं और देखें अगर आप एक छोटा dependency फुटप्रिंट चाहते हैं या आप खासतौर पर एक Unity-स्टाइल होस्टेड workflow चाहते हैं।

Unity WebGL

Unity WebGL कोई web engine नहीं है, यह एक export target है। आप Unity डेस्कटॉप editor में, C# में बनाते हैं, और एक WebGL bundle में compile करते हैं जो WebAssembly के ज़रिए browser में चलता है। इससे यह एक खास हालत के लिए साफ़ जवाब बन जाता है: आपके पास पहले से एक Unity game है और आप उसका एक browser वर्ज़न चाहते हैं।

एक web-फर्स्ट प्रोजेक्ट के लिए इसकी असली कीमत है। runtime और डाउनलोड का वज़न काफी ज़्यादा है, स्टार्टअप एक native web engine से धीमा है, और मोबाइल browser परफॉर्मेंस एक जानी-मानी दिक्कत है। Unity प्रोप्राइटरी है और इसका WebGL आउटपुट WebGL2 को टारगेट करता है।

Unity WebGL चुनें अगर आपके पास browser में लाने के लिए एक मौजूदा Unity प्रोजेक्ट है, या आपकी टीम पहले से Unity में ही रहती है। कहीं और देखें अगर मिड-रेंज फोन पर तुरंत लोड होना एक सख्त ज़रूरत है, या आप बिल्कुल नए सिरे से और web-फर्स्ट शुरू कर रहे हैं।

AI-native और in-world creation कहां फिट बैठती है

ऊपर की हर चीज़ एक मान्यता साझा करती है: एक developer एक डेस्क पर, एक editor में game बनाता है, और एक runtime शिप करता है। यह मान्यता ज़्यादातर प्रोजेक्ट्स के लिए सही है, और अगर यह आपके वाले का वर्णन करती है, तो ऊपर के चारों में से चुनिए।

यह जानना ज़रूरी है कि यह मान्यता अब इकलौता विकल्प नहीं रही, क्योंकि एक अलग श्रेणी उभर रही है। हम Cinevva बनाते हैं, जो एक सिर्फ-WebGPU world platform है जहां games को world के अंदर से बनाया जाता है। एक editor खोलने के बजाय, आप एक avatar होते हैं जो उस जगह में खड़ा है, और आप बताते हैं कि आपको क्या चाहिए, और एक AI builder उसे terrain, objects और behavior में बदल देता है जबकि आप वहीं खड़े रहते हैं। Creation और play एक ही सेशन हैं। पर्दे के पीछे इसका मतलब था compute-shader terrain के साथ सिर्फ-WebGPU जाना, एक general physics engine के बजाय एक कस्टम character solver लिखना, और एक animation और retargeting system बनाना, जिसके बारे में हमने हमने अपना खुद का WebGPU engine क्यों बनाया में लिखा।

यह PlayCanvas या Babylon की जगह नहीं है। अगर आप एक developer हैं जो एक खास game बना रहा है, तो वही सही tools हैं। Cinevva उस अलग मकसद के लिए है जो उन लोगों को, जो engine developers नहीं हैं, चीज़ों का वर्णन करके खेलने लायक spaces बनाने और साझा करने देता है। हम इसका ज़िक्र यहां इसलिए कर रहे हैं क्योंकि "मुझे कौन सा web game engine इस्तेमाल करना चाहिए" का जवाब अब बढ़ते हुए एक पांचवां जवाब रखता है जो कोई engine है ही नहीं।

पूरा फीचर मैट्रिक्स

ऊपर की झटपट टेबल सुर्ख़ी है। यह उसका विस्तृत वर्ज़न है, subsystem के हिसाब से बांटा हुआ। इसे कैसे पढ़ें इस पर कुछ ईमानदार नोट। "BYO" का मतलब है अपना खुद का लाएं, यानी engine इसे शिप नहीं करता लेकिन ecosystem या आपका अपना code इसे जोड़ सकता है। यह सबसे ज़्यादा Three.js के लिए मायने रखता है, जो डिज़ाइन से ही एक रेंडरिंग लाइब्रेरी है, इसलिए वहां "BYO" फिलॉसफी की एक खूबी है, कोई कमी नहीं। Unity के लिए "Export-only" का मतलब है कि क्षमता डेस्कटॉप editor में मौजूद है और WebGL build में साथ चली आती है, web-native होने के बजाय। कॉम्पिटिटर वाले खाने mid-2026 तक की out-of-the-box क्षमता और अच्छी तरह दस्तावेज़ी व्यवहार को दर्शाते हैं। Cinevva वाले खाने वो दर्शाते हैं जो हमारे शिप किए हुए build में चलता है, जहां "planned" उसे चिह्नित करता है जो डिज़ाइन किया गया है पर अभी बना नहीं।

Rendering

World और terrain

Physics और character

Animation

Multiplayer और backend

Creation और authoring

Assets और distribution

मैट्रिक्स का पैटर्न ही असली कहानी है। general-purpose engines अपनी ताकत क्षैतिज रूप से फैलाते हैं, वे हर एक ज़्यादातर चीज़ें ठीक-ठाक करते हैं और world, backend और creation flow आप पर छोड़ देते हैं। Cinevva लंबवत रूप से केंद्रित करता है, यह कम चीज़ें करता है पर renderer से लेकर एक shared world तक के पूरे रास्ते का मालिक है जिसे आप अंदर से बनाते हैं। अमूर्त रूप से न तो एक आकार बेहतर है। वे अलग-अलग सवालों का जवाब देते हैं।

चुनाव कैसे करें

एक फीचर चेकलिस्ट के बजाय tool को हालत से मिलाएं।

अगर आपके पास पहले से एक Unity game है, तो उसे Unity WebGL से export करें और वज़न को स्वीकार करें। अगर आप एक स्टूडियो हैं जो browser games के लिए एक editor-संचालित workflow चाहता है, तो PlayCanvas इस्तेमाल करें। अगर आप physics शामिल वाला एक पूरा मुफ़्त engine चाहते हैं, तो Babylon.js इस्तेमाल करें। अगर आप पूरा कंट्रोल चाहते हैं और आपके पास एक नंगे renderer पर बनाने वाली टीम है, तो Three.js इस्तेमाल करें। और अगर आपका मकसद एक game बनाना नहीं बल्कि लोगों को चीज़ों का वर्णन करके एक shared world के अंदर बनाने और खेलने देना है, तो वही श्रेणी है जिसमें हम काम करते हैं, और आप Cinevva आज़मा सकते हैं।

जो भी चुनें, कमिट करने से पहले असली spikes के साथ परख करें। इनमें से हर एक एक असली game संभाल सकता है, और बीच रास्ते में स्विच करने की कीमत वो महीने हैं जो आपने शिप करने में नहीं लगाए।

लेखक Oleg Sidorkin, Cinevva के CTO और Co-Founder

जो भी तकनीकी इंसान Cinevva World को देखता है, वह पाँच मिनट के अंदर एक ही बात पूछता है। आपकी टीम छोटी है। पक्के web 3D engines पहले से मौजूद हैं। आपने PlayCanvas या Babylon पर खड़े होकर तेज़ी से shipping करने के बजाय अपना खुद का renderer, अपना character physics, अपना animation system क्यों लिखा?

यह एक जायज़ सवाल है, और "यहाँ नहीं बना तो हम नहीं लेंगे" इसका गलत जवाब है। हमने अपना होमवर्क किया। फैसला लेने से पहले हमने मौजूदा engines चलाए, उनका source पढ़ा, और उनमें से दो के ऊपर spikes ship किए। यह पोस्ट उसी फैसले का ईमानदार वर्ज़न है: तैयार विकल्प असल में किसमें अच्छे हैं, वे चार जगहें जहाँ हमारी ज़रूरतें इतनी ज़्यादा अलग हो गईं कि अपना बनाना सही लगा, और वे हालात जहाँ आपको हमारी नकल करने के बजाय इनमें से कोई एक चुनना चाहिए। हमने इस build को एक लंबी चलने वाली open-world-in-the-browser engineering series में दर्ज किया है, तो नीचे जहाँ किसी दावे के पीछे एक चलता हुआ log है, वहाँ मैं उसका link दूँगा।

जिन विकल्पों को हमने वाकई परखा

चार चीज़ों को "web game engines" कहा जाता है, और वे एक जैसी चीज़ें नहीं हैं।

Three.js एक rendering library है, game engine नहीं। यह आपको एक scene graph, materials, loaders, और एक renderer देता है, और फिर आपके रास्ते से हट जाता है। कोई editor नहीं, कोई physics नहीं, कोई entity system नहीं, आपके game की संरचना को लेकर कोई राय नहीं। यही इसका आकर्षण है और यही इसकी कीमत भी। renderer के ऊपर सब कुछ आप खुद बनाते हैं, पर कोई चीज़ आपसे नहीं लड़ती। यह MIT-licensed है, इस क्षेत्र में इसका ecosystem सबसे बड़ा है, और जब रात के 2 बजे आप किसी अनजान shader bug में फँसते हैं तो एक forum जवाब पहले से मौजूद होता है।

Babylon.js एक पूरा engine है जिसमें एक scene graph, एक physics integration (Havok), एक asset pipeline, और एक web editor है। यह MIT-licensed है, Microsoft की एक टीम इसके पीछे है, और इसका WebGPU काम तेज़ी से आगे बढ़ रहा है। अगर आप सब कुछ शामिल चाहते हैं और engine की संरचना के भीतर रहकर खुश हैं, तो यह एक मज़बूत डिफ़ॉल्ट है।

PlayCanvas "web के लिए Unity" के सबसे करीब है। इसे लिखते वक्त engine v2.19.6 पर है, जो 5 जून 2026 को रिलीज़ हुआ, और engine खुद MIT के तहत open source है। पर ज़्यादातर लोग असल में जो इस्तेमाल करते हैं वह है hosted visual editor, और वह editor एक commercial product है, open source नहीं। PlayCanvas एक entity-component system इस्तेमाल करता है, आप TypeScript या JavaScript में script करते हैं, assets एक server-side GLB pipeline से होकर जाते हैं, और असली commercial games इस पर ship हो चुके हैं (एक के लिए, Snap अपना production काम PlayCanvas पर चलाता है)। इसका renderer WebGL2 पर चलता है, और इसका WebGPU path अभी डिफ़ॉल्ट होने के बजाय पक रहा है। वह आखिरी बात जितनी लगती है उससे ज़्यादा मायने रखती है, और मैं उस पर वापस आऊँगा।

Unity WebGL कोई web engine है ही नहीं। यह एक export target है। आप Unity desktop editor में बनाते हैं और एक WebGL bundle में compile करते हैं। यह तब सही टूल है जब आपके पास पहले से एक Unity game हो और आप उसे एक browser में चाहते हों, और तब गलत टूल है जब "एक mid-range phone पर एक tab में तुरंत load हो जाए" एक सख्त ज़रूरत हो, क्योंकि runtime और download का वज़न साथ में चला आता है।

इनमें से कोई भी एक सामान्य web game के लिए एक वाजिब नींव है। हमारे पास एक सामान्य web game नहीं था।

फैसला एक: WebGPU हमारी फर्श है, हमारी आखिरी रेखा नहीं

जो बँटवारा हमें हर तैयार समाधान से हटाता है वह यह है। हमारे लिए WebGPU एक ज़रूरत है, कोई ऐसी सुविधा नहीं जिसमें हम धीरे-धीरे बढ़ेंगे।

हमारा terrain एक स्थिर heightmap नहीं है। यह एक streamed heightmap field और signed-distance field से समर्थित marching-cubes chunks का एक hybrid है, ताकि world में असली caves और overhangs हो सकें, और creators इसे live sculpt कर सकें। sculpt brushes, foliage scatter, और terrain meshing सब compute shaders की तरह चलते हैं। compute हटा दो तो world बिगड़ता नहीं, वह चलता ही नहीं।

यह ठीक उसके उलट है जहाँ general-purpose engines आज बैठे हैं। उनका WebGPU support एक WebGL2-first renderer के ऊपर progressive enhancement की तरह बनाया गया है, और जिन browsers में यह नहीं है उनके लिए एक fallback path के साथ। खास तौर पर PlayCanvas WebGL2-first है और इसका WebGPU अभी beta में है। उनके लिए यह सही फैसला है, क्योंकि उनका काम है games के सबसे चौड़े संभव मैट्रिक्स को devices के सबसे चौड़े संभव मैट्रिक्स पर चलाना। हमारा काम संकरा और गहरा है, इसलिए हमने उलटा फैसला लिया: हम spike 13 पर WebGPU-only हो गए और फिर कभी पीछे मुड़कर नहीं देखा। WebGPU के बिना browsers को घटाया नहीं जाता, वे असमर्थित हैं, और हम इसे एक reach संख्या की तरह track करते हैं, यह दिखावा करने के बजाय कि एक WebGL2 fallback बस एक config flag दूर है। वह नहीं है। वह हमारे terrain और foliage stages का एक आंशिक rewrite होगा।

एक WebGL2-first engine पर बनाने का मतलब होता या तो हर compute feature पर उसकी fallback मान्यताओं से लड़ना, या हमेशा के लिए दो rendering paths बनाए रखना। renderer का मालिक होने से हमें compute को बेसलाइन की तरह बरतने का मौका मिला।

फैसला दो: एक character solver, एक physics engine नहीं

किताबी चाल है एक physics engine लाकर डाल देना। हमने वह आज़माया। एक शुरुआती spike ने एक worker में Rapier को चलते हुए validate किया, और वह ठीक लगा।

फिर भी हमने अपना खुद का लिखा, और shipped build में कहीं भी Rapier, Cannon, या Ammo नहीं है। वजह है scope। हमें rigid bodies, joints, ragdolls, या एक constraint solver की ज़रूरत नहीं है। हमें एक capsule चाहिए जो terrain के खिलाफ सही ढंग से चले, और हमें walking, sliding, gliding, climbing, और swimming को "मैं grounded हूँ या नहीं, किस surface पर, किस कोण पर" के एक साझा जवाब पर सहमत होना चाहिए। एक general physics engine इसे आसान नहीं, मुश्किल बनाता है, क्योंकि वे modes आखिर में उसके भीतरी springs और dampers से लड़ने लगते हैं।

तो हमारा character controller एक pluggable multi-channel state machine है। हर mode एक छोटी unit है जो बताती है कि क्या वह इस frame में control चाहती है और, अगर वह जीतती है, तो velocity और facing लिखती है। वे तीन channels के पार प्राथमिकता से तय करती हैं, resource फिर stance फिर locomotion, और वे सब एक ही terrain query पढ़ती हैं। Collision chunk के हिसाब से heightmap या signed-distance field के खिलाफ एक capsule probe है।

जिस ब्योरे पर मुझे सबसे ज़्यादा गर्व है वह बेरंग है। Ground detection आपके पैरों के नीचे की ऊर्ध्वाधर column में हर surface को scan करता है और SDF gradient पर भरोसा करने के बजाय capsule के बराबर या नीचे वाली सबसे ऊँची surface चुनता है। एक overhang के किनारे पर बगल में सबसे नज़दीकी surface cliff का चेहरा होती है, तो एक gradient-आधारित normal "floor" और "wall" के बीच टिमटिमाता है और आपको phantom sliding मिलती है। column query एक ledge पर खड़ा होना उबाऊ बना देती है, जो बिलकुल वही है जो आप चाहते हैं। एक तैयार heightfield collider हमें यह मुफ्त में नहीं देता, क्योंकि वह तो हमारे terrain को देख ही नहीं सकता। terrain हमारे format में GPU पर रहता है। कोई बाहरी engine इसके खिलाफ collide नहीं कर सकता बिना हमारे हर edit पर पूरे field को उसके collider format में कॉपी किए।

फैसला तीन: ऐसा animation जो rigs के पार सफर करे

Avatars Synty POLYGON rig इस्तेमाल करते हैं, और हमारे motion clips एक बड़ी open animation library से आते हैं। चूँकि rig और clips bone names साझा करते हैं, आम मामले में runtime पर किसी retargeting की ज़रूरत नहीं होती, tracks बस name से bind हो जाते हैं। हमने पूरी character pipeline को universal characters में लिखा है।

दिलचस्प काम वह मामला है जहाँ वे मेल नहीं खाते। हमने एक retargeting pass बनाया जो एक skeleton को दूसरे पर map करता है, और इसे सही करने का मतलब था तीन खास समस्याएँ हल करना। आप पहले bind poses को align करते हैं, क्योंकि एक T-pose के खिलाफ एक A-pose चुपचाप हर joint पर लगभग तीस डिग्री जोड़ देती है। आप root motion और stride को दो अलग अनुपातों से scale करते हैं, ऊर्ध्वाधर के लिए hip-to-floor और क्षैतिज के लिए कुल अनुपात। और आप retargeted clips को उनके source के खिलाफ एक तय sample rate पर test करते हैं, ताकि regressions एक player के सामने आने से पहले दिख जाएँ। वही pipeline है जो हमें नए animation sources, और आखिरकार creator-supplied characters, जोड़ने देती है बिना हर clip को हाथ से ठीक किए।

उसके ऊपर एक animation state machine बैठता है जो हर frame में motion state से सही clip family चुनता है: speed के हिसाब से jump variant, impact के हिसाब से landing की तीव्रता, terrain gradient के खिलाफ velocity के dot से slope की दिशा, foot-phase-सही stops ताकि आप रुकते वक्त moonwalk न करें, और एक सौ-millisecond का debounce ताकि एक दीवार से टकराने पर आप walk और fall के बीच न टिमटिमाएँ। इसमें से कुछ भी अनोखा नहीं है, पर यह वैसी चीज़ है जो आपको सिर्फ इस layer का मालिक होने से मिलती है।

फैसला चार: वह हिस्सा जो कोई engine ship नहीं करता

बाकी तीन फैसले इस बारे में हैं कि world कैसे चलता है। यह इस बारे में है कि product क्या है, और यही वजह है कि PlayCanvas से तुलना आखिर में एक category की गलती है।

PlayCanvas, Babylon, Unity, और एक हाथ से बना Three.js app सब एक ही आकार मान लेते हैं: आप अपना game एक डेस्क पर, एक 2D editor में बनाते हैं, world को बाहर से देखते हुए, और फिर आप play दबाते हैं और एक अलग runtime ship करते हैं। यहाँ तक कि उनका in-engine editing भी एक workstation पर बैठे आप होते हैं जो एक scene को देखते हुए उससे छेड़छाड़ कर रहे होते हैं।

Cinevva World इसे उलट देता है। आप world के भीतर से, एक avatar के रूप में उसी जगह खड़े होकर जहाँ आपके players खड़े होंगे, यह बताकर कि आप क्या चाहते हैं और उसे प्रकट होते हुए देखकर बनाते हैं। Creation और play एक लगातार चलने वाला session हैं, एक runtime से जुड़ा कोई build step नहीं। सबसे करीबी संदर्भ बिंदु Roblox, Rec Room, और Horizon Worlds हैं, web 3D engines नहीं, और वे भी ज़्यादातर creation को एक डेस्क पर ही रखते हैं। जो चीज़ इसे एक mouse-चालित editor के बिना संभव बनाती है वह है AI builder, जो "यहाँ एक lantern से रोशन dock रखो" को geometry और placement में बदल देता है।

आप इसे एक general-purpose engine पर जोड़ नहीं सकते, क्योंकि यह कोई rendering feature नहीं है। यह पूरे stack की बुनियादी मान्यता है, इस बात से कि terrain runtime पर कैसे editable है, इस बात तक कि network हर object को कैसे ऐसी चीज़ की तरह बरतता है जिसे पास खड़े किसी इंसान ने अभी बनाया हो।

आपको कब वह नहीं करना चाहिए जो हमने किया

यह वह हिस्सा है जिसे "हमने अपना engine बनाया" वाली पोस्टें आम तौर पर छोड़ देती हैं। अगर आप इसी तिमाही एक browser game ship करना चाहते हैं, तो हमारी नकल मत करिए। PlayCanvas इस्तेमाल करिए अगर आप एक Unity-शैली का editor और एक managed pipeline चाहते हैं। Babylon इस्तेमाल करिए अगर आप physics सहित एक पूरा engine चाहते हैं और उसकी संरचना के भीतर खुश हैं। Three.js इस्तेमाल करिए अगर आप ज़्यादा से ज़्यादा control और कम से कम राय चाहते हैं और आपके पास इसके ऊपर बनाने वाली टीम है। Unity से port करिए अगर आपके पास पहले से एक Unity game है।

अपना खुद का renderer, physics, और animation लिखना सिर्फ तभी सही फैसला है जब आपके product की बुनियादी मान्यता तैयार समाधानों के साथ बेमेल हो, जब आप जो बना रहे हैं वह किसी engine पर एक game न होकर एक ऐसी जगह हो जो संयोग से एक engine से बनी है। हमारे लिए यह सच था। आपके लिए शायद सच नहीं है, और यह ठीक है। मूल्यांकन ईमानदारी से करने का मकसद यही है कि पहली लाइन लिखने से पहले आप जान लें कि आप किस मामले में हैं।

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

अब हम worlds generate कर सकते हैं, और मेरा मतलब किसी demo reel से नहीं है। ऊपर की तस्वीर हमारा editor है। किसी ने एक chat box में "build a second floor" टाइप किया और देखा कि AI ने फर्श की deck बिछाई, आगे, बगल और पीछे की दीवारें खड़ी कीं, और सीढ़ियों व छत के साथ आगे बढ़ने की पेशकश की। props नहीं, textures नहीं, पूरी संरचनाएं, एक ऐसी दुनिया में रखी गईं जिसमें दूसरे लोग चलकर आ सकते हैं। हमारी pipeline पहले से ही हिस्से भी बनाती है: 3D models, music, sound, materials।

तो हम Cinevva World को जनता के लिए खोलने के करीब हैं। और ऐसा करने से पहले, मैं गया और मौत की खबरें पढ़ीं।

क्योंकि हम जो बना रहे हैं उसके बारे में असहज सच यही है। पंद्रह साल से, बहुत समझदार, बहुत अच्छी फंडिंग वाली टीमों ने साझा रचनात्मक worlds को काम करने लायक बनाने की कोशिश की है। कुछ इंसानियत की बनाई सबसे बड़ी चीज़ों में से बन गए। ज़्यादातर मर चुके हैं। इन दो नतीजों के बीच का फासला न प्रतिभा है और न पैसा, क्योंकि कुछ मरने वालों के पास हमसे कहीं ज़्यादा दोनों थे। फासला है कुछ चंद फैसले जो लगभग कोई भी पहली बार में सही नहीं कर पाता। मुझे यही मिला।

कब्रिस्तान

नाकामियों से शुरू करें, क्योंकि वे कामयाबी की कहानियों से ज़्यादा ईमानदार होती हैं। जीतने वाले अपना इतिहास एक साफ-सुथरी कहानी में दोबारा लिख देते हैं। हारने वाले memos leak कर देते हैं।

Meta Horizon Worlds: अब तक का सबसे महंगा खाली कमरा

Meta ने अपने metaverse दांव पर दसियों अरब डॉलर खर्च किए। Reality Labs ने 2026 की शुरुआत में रिपोर्ट किया गया एक ही तिमाही में $6.02 अरब का operating loss दर्ज किया, और वह सालों से हर तिमाही कई अरब का घाटा झेल रहा था। flagship था Horizon Worlds। यहां वह है जो उस पैसे ने खरीदा।

एक leak हुआ internal memo, जिसे Fortune और Ryan Schultz ने रिपोर्ट किया, उसने बताया कि creators ने जो worlds बनाए उनमें से सिर्फ़ करीब 9 प्रतिशत को कभी 50 या ज़्यादा लोगों ने देखा। ज़्यादातर को उनके अपने बनाने वाले के सिवा शून्य visits मिले। एक memo ने engagement की समस्या को एक वाक्य में समेट दिया जो इस क्षेत्र के हर founder पर गुदवा देना चाहिए: "खाली दुनिया एक उदास दुनिया है।" active users का survey करने के इच्छुक शोधकर्ताओं को उनमें से सिर्फ़ 514 ही मिल पाए, क्योंकि player base इतना छोटा था।

retention के आंकड़े और भी बुरे थे। leak हुए data से पता चला कि पहले महीने के बाद सिर्फ़ हर 10 में से करीब 1 user लौटा। Meta ने चुपचाप अपने 2022 के लक्ष्य को 500,000 monthly users से घटाकर 200,000 कर दिया, और तब भी platform पर VRChat से कम और Second Life, जो 2003 का एक game है, से भी कम concurrent users थे। internal dogfooding dashboards ने दिखाया कि Meta के अपने कर्मचारी इसका इस्तेमाल नहीं कर रहे थे, जिसने management को साप्ताहिक logins के लिए managers को जवाबदेह ठहराना शुरू करने पर मजबूर किया। एक VP ने टीम को बाकी साल के लिए "quality lockdown" में डाल दिया और लिखित में माना कि वे एक ऐसे product पर काम कर रहे थे जिसने product-market fit नहीं पाया था।

मार्च 2026 में, Meta ने पूरी तरह VR support बंद करने की घोषणा की और Horizon Worlds को लगभग पूरी तरह एक mobile app में बदल दिया, headsets के बिना लोगों के लिए एक entry point, जो उनके अपने शब्दों में, Roblox की तरह काम करता है। अब तक बना सबसे महंगा metaverse अपनी ज़िंदगी उसी चीज़ बनने की कोशिश में खत्म कर रहा था जो उसे पहले ही दिन होना चाहिए था।

सबक "VR बहुत जल्दी आ गया" नहीं है, हालांकि वह था। सबक यह है कि कितनी भी पूंजी एक खाली दुनिया को नहीं भर सकती। Content density ऐसी चीज़ नहीं जो आप marketing budget से खरीद सकें। अगर worlds खाली हैं, तो लोग चले जाते हैं, और जब लोग चले जाते हैं, तो worlds खाली रह जाते हैं। उस चक्र ने Meta को ज़िंदा निगल लिया।

Decentraland और The Sandbox: अरबों डॉलर के भुतहा शहर

अक्टूबर 2022 में, एक अकेले data point ने crypto की दुनिया में आग लगा दी। DappRadar ने रिपोर्ट किया कि Decentraland के 38 daily active users थे। The Sandbox के 522। इन दोनों प्रोजेक्ट्स की उस समय market capitalization करीब $1.3 अरब थी।

अब, प्रोजेक्ट्स ने पलटवार किया, और बारीकी असल में इस तंज़ से ज़्यादा मायने रखती है। 38 का आंकड़ा सिर्फ़ एक दिन में on-chain transactions करने वाले unique wallets को गिनता था, जिसे DappRadar "payers" कहता है, न कि उन लोगों को जो log in करके इधर-उधर घूमे बिना blockchain को छुए। Decentraland ने जवाब दिया कि उसके 56,697 monthly logged-in users थे और दूसरे अनुमानों के मुताबिक करीब 8,000 daily। The Sandbox ने एक alpha season के दौरान 39,000 daily होने का दावा किया जिसमें day-14 retention 40 प्रतिशत था।

लेकिन एक पल के लिए इस फासले के साथ बैठिए, क्योंकि यह इस पूरे निबंध का सबसे ज़रूरी आंकड़ा है। उदार आंकड़े मान लें तब भी, आपके पास अरबों डॉलर की valuations हैं जो ज़्यादा से ज़्यादा कुछ हज़ार daily users के ऊपर टिकी हैं। तुलना के लिए, शोध में सामने आया कि non-blockchain Roblox के पास उसी दौर में 52 मिलियन daily active users थे लेकिन सिर्फ़ 11.3 मिलियन monthly paying users। मुफ़्त virtual worlds में ज़्यादातर लोग कभी-कभार या कभी नहीं transact करते। यह दोनों तरफ काटता है। इसका मतलब है कि 38-DAU वाला तंज़ नाइंसाफ़ी था, और इसका मतलब है कि अरबों डॉलर की valuation एक कल्पना थी। दोनों चीज़ों ने गलत आंकड़ा नापा। valuation ने token speculation नापा। तंज़ ने wallet transactions नापीं। किसी ने भी यह नहीं नापा कि कोई मज़े कर रहा था या नहीं।

यह vanity-metric जाल अपने सबसे शुद्ध रूप में है। registered accounts, token market cap, total addressable market, press impressions: इनमें से कोई भी आपको नहीं बताता कि आपकी दुनिया ज़िंदा है या नहीं। ऐसा बताने वाले एकमात्र आंकड़े हैं कि कितने लोग दोबारा आते हैं, और क्या चीज़ें बनाने वाले लोग चीज़ें बनाते रहते हैं।

Dreams: सबसे खूबसूरत tool जिसमें कोई टिक न सका

Media Molecule, वह studio जो LittleBigPlanet के पीछे था, उसने Dreams बनाने में करीब एक दशक का बड़ा हिस्सा बिताया, एक ऐसा creation tool जो इतना गहरा था कि लोगों ने उसके अंदर खेलने लायक games, animated short films, और music albums बनाए। आलोचकों ने इसे बहुत सराहा। और सितंबर 2023 में, studio ने live service बंद कर दी, साफ़ कहते हुए कि उन्हें एक टिकाऊ business model नहीं मिल पाया।

postmortem खुद को पहुंचाई गई चोटों की एक चेकलिस्ट है, और मैं यह बहुत सम्मान के साथ कहता हूं, क्योंकि हम इनमें से हर एक कर सकते हैं। Dreams ने creators को अपने काम से कभी कमाई करने नहीं दी। वादा किया गया in-game store कभी आया ही नहीं। कोई cosmetics नहीं, कोई battle pass नहीं, कुछ नहीं। गंभीर creators, वो किस्म जो एक tool को platform में बदलते हैं, उनके पास सालों लगाने की कोई वजह नहीं थी जब कोई फ़ायदा ही नहीं था। यह PS4-only launch हुआ, launch पर न कोई PC version और न native PS5 build के साथ, जिसने इसके संभावित audience पर कड़ी रोक लगा दी। और co-founder Mark Healey ने बाद में कहा कि उनका सबसे बड़ा अफ़सोस multiplayer पर ध्यान न देना था, और कि टीम यह समझ गई कि उनकी रचना एक creative tool के मुकाबले एक game के रूप में बेहतर काम करती थी।

उस आखिरी हिस्से को दोबारा पढ़िए। धरती पर सबसे प्रतिभाशाली UGC studio ने, बाद में, यह निष्कर्ष निकाला कि यह चीज़ पहले एक game और बाद में एक tool होनी चाहिए थी। यह इस पूरे अध्ययन का सबसे ज़रूरी एकमात्र वाक्य है, और हम इस पर वापस आएंगे।

बाकी का कब्रिस्तान

यह पैटर्न खौफ़नाक नियमितता से दोहराता है।

Crayta, एक सहयोगी UGC creation platform, मार्च 2023 में बंद हो गया और users ने वह सब खो दिया जो उन्होंने बनाया था। इसके developer को 2021 में Meta ने खरीदा था और फिर भी platform मार दिया गया। तत्काल वजह: यह Google Stadia पर launch हुआ, और जब Stadia मरा, तो Crayta उसके साथ मर गया। Platform dependency आपके अपने सिर पर तनी एक भरी हुई बंदूक है।

Project Spark, Microsoft का UGC game-maker, सालों पहले उसी राह पर बंद हुआ: एक ताकतवर tool, टिकने वाले लोग पर्याप्त नहीं। Sansar, Linden Lab का Second Life का VR उत्तराधिकारी, audience न पाने के बाद बेच दिया गया। High Fidelity, Second Life के अपने ही founder Philip Rosedale की दूसरी metaverse कंपनी, virtual worlds से पूरी तरह दूर हट गई।

और एक ऐसे संकेत में जिसे आप नज़रअंदाज़ नहीं कर सकते क्योंकि यह अभी हो रहा है, Rec Room ने 1 जून 2026 से बंद होने की घोषणा की, यह बताते हुए कि वह कभी टिकाऊ मुनाफ़े तक नहीं पहुंचा।

metaverse कंपनियों के founders, metaverses बना रहे थे, अपने ही metaverses में टिक नहीं सके। यह उस किसी को भी डरा देना चाहिए जो सोचता है कि मुश्किल हिस्सा rendering है।

बचे हुए, और असल में किसने उन्हें बचाया

अब ज़िंदा रहने वाले। सीख देने वाली बात यह है कि इनमें से किसी ने भी उस तरह नहीं जीता जैसा आप उम्मीद करेंगे, और कइयों ने उन्हीं नियमों को तोड़कर जीता जिनका नाकामियों ने पालन किया।

Roblox: बारह साल वाली रातों-रात कामयाबी

हर कोई Roblox को model के तौर पर पेश करता है। लगभग कोई भी उसकी नकल नहीं करता जो असल में हुआ, क्योंकि असल में जो हुआ वह बारह साल तक एक नाकामी जैसा दिखना था।

Roblox के 2006 के beta ने करीब 100 tech उत्साही खींचे जिनमें peak concurrency 30 से 40 लोगों की थी। फिर इसने एक दशक से ज़्यादा तक धीरे-धीरे आगे बढ़ना जारी रखा। यह 2016 की शुरुआत में 9 मिलियन users से 2019 में 90 मिलियन और 2023 तक 214 मिलियन तक पहुंचा। founder David Baszucki ने user-generated-content vision से पलटने से इनकार कर दिया, तब भी जब Minecraft 2009 में उनसे आगे फट पड़ा। उन्होंने इसे एक जानबूझकर धीमी पकाई की तरह लिया, और जो एकमात्र कदम मायने रखा वह यह फैसला था कि community को सारे games खुद बनाने दिया जाए बजाय उन्हें in-house बनाने के। इसने content की लागत हटा दी और हर creator को एक growth engine में बदल दिया।

लेकिन यहां वह हिस्सा है जो नकलची चूक जाते हैं, और यही वजह है कि मैं एक दूसरा source खुला रखता हूं। Matthew Ball का 2024 का teardown दिखाता है कि Roblox भारी पैमाने पर भी एक कठोर घाटे में चल रहा है, करीब negative-38-प्रतिशत operating margin, जहां किसी दिए गए महीने में सिर्फ़ 6 प्रतिशत users उसकी currency खरीदते हैं और per user revenue console platforms का एक अंश है। Roblox दुनिया का सबसे बड़ा game है और फिर भी वह पैसा बनाने के लिए संघर्ष करता है। flywheel असली है और economics मुश्किल है। जो भी आपसे कहे कि एक creator platform पैसे छापने का license है, वह आपको कुछ बेच रहा है।

गहरा सबक, हालांकि, उन्हीं user आंकड़ों में साफ़ छुपा है। Roblox के करोड़ों users में भारी बहुमत कभी कुछ नहीं बनाता। वे दूसरों के बनाए करोड़ों games की एक catalog खेलने आते हैं। उस catalog को बढ़ने में एक दशक और एक developer-payout economy लगी। Roblox कोई building tool नहीं है जिसे लोग खेलते भी हैं। यह खेलने की एक जगह है जिसे लोगों का एक छोटा हिस्सा बनाता भी है। वह क्रम ही सब कुछ है।

Minecraft: वह दुनिया जो खाली हो ही नहीं सकती थी

Minecraft के पास कभी खाली-दुनिया वाली समस्या नहीं थी, और यह समझना कि क्यों, यही पूरा खेल है।

Minecraft procedural generation के साथ एक survival game के रूप में आया। दुनिया खुद को बनाती है, अनंत रूप से, और पहले ही मिनट पर आप यह सोचते हुए एक खाली canvas को नहीं ताक रहे होते कि क्या करें। रात ढल रही है और कोई चीज़ आपको मार डालने वाली है, इसलिए आप खुदाई करते हैं। game एक अकेले इंसान के लिए शून्य दूसरे users और शून्य user-generated content के साथ मज़ेदार है, हमेशा के लिए, क्योंकि procedural generator एक अटूट content मशीन है। mods, servers, custom maps, पूरा रचनात्मक ecosystem, यह सब एक ऐसे game के ऊपर उगा जो पहले ही खुद को बेच चुका था। creative mode तब आया जब लाखों लोग पहले ही survival के दीवाने हो चुके थे। बाकी काम word of mouth और YouTube ने किया।

Minecraft ने cold-start को हल किया उसे कभी रखकर ही नहीं। यही cheat code है, और हम इसे चुरा लेंगे।

Browser games: distribution ही पूरी खाई

फिर वह genre है जो हमारी असल delivery mechanism के सबसे करीब है, बिना-download वाला browser game।

Agar.io अपने 2015 के launch के हफ़्तों के भीतर करीब 5 मिलियन daily players तक पहुंच गया। Slither.io ने 68 मिलियन mobile downloads और 67 मिलियन browser plays बटोरे। शोध इस बारे में दो-टूक है कि क्यों: ".io genre के लिए competitive खाई distribution ही है, game mechanic नहीं।" आप एक link पर click करते हैं और आप खेल रहे होते हैं। कोई install नहीं, कोई account नहीं, कोई app store नहीं। Agar.io का onboarding एक click का था: एक नाम टाइप करो, play दबाओ, आप अंदर हैं। यह chat apps के ज़रिए उसी तरह फैला जैसे video TikTok पर फैलता है।

लेकिन इस तोहफ़े में एक चाकू है, और वह हमारी तरफ भी काटता है। कोई download नहीं का मतलब कोई commitment नहीं। वही frictionlessness जो किसी को अंदर लाती है, वही उसे बाहर भी कर देती है, क्योंकि एक tab बंद करने की कोई कीमत नहीं। Browser virality असली है और by default उथली भी है। .io games इससे बच गए क्योंकि वे पहले दस सेकंड में फ़ौरन, साफ़ तौर पर मज़ेदार थे। जो browser worlds मरे, वे घुसने में frictionless थे और एक बार पहुंचने पर आपको रुकने की कोई वजह नहीं देते थे।

Among Us, Figma, Townscaper, VRChat: जीतने के चार और तरीके

चार झटपट वाले, क्योंकि हर एक एक अलग लीवर को अलग कर दिखाता है।

Among Us 2018 में launch हुआ और दो साल तक एक commercial शून्य रहा। developers ने इसे लगभग छोड़ ही दिया था। फिर सितंबर 2020 में लगातार बड़े होते streamers की एक सीढ़ी ने इसे खोजा, जिसका चरम एक कई घंटे लंबा Sodapoppin stream था, और यह एक वैश्विक तूफ़ान बन गया। शुरुआती ऑक्सीजन एक itch.io front-page feature और एक Korean audience से आई जो इसकी आधी बिक्री बन गया। सबक: breakout launch के सालों बाद आ सकता है, एक ऐसे channel से जिसकी आपने योजना नहीं बनाई, बशर्ते आप खोजे जाने तक काफ़ी देर ज़िंदा रहें।

Figma करीब तीन साल stealth में रहा, मुफ़्त launch हुआ, और charge करने से पहले दो साल और इंतज़ार किया। इसका activation moment multiplayer था: वह पल जब एक designer ने महसूस किया कि कोई और उसी file को edit कर रहा है। और यहां वह हिस्सा है जो मायने रखता है। Figma का free tier मूल रूप से आपको 2 collaborators तक सीमित करता था, जिसने ठीक उसी जादुई पल का गला घोंट दिया जो product को बेचता था, और उन्होंने इसे collaborators को असीमित बनाकर ठीक किया ताकि लोग असल में उस चीज़ को महसूस कर सकें। उन्होंने community को सीधे Twitter पर design influencers को target करके seed किया। सबक: अपना aha moment खोजो, फिर एक नए user और उसके बीच की हर बाधा हटा दो।

Townscaper एक नन्हा creative खिलौना था जो screenshots के दम पर hit बन गया। इसके developer ने अपने Twitter following को करीब 20,000 से 90,000 तक छलांग लगाते देखा, सिर्फ़ development के दौरान clips पोस्ट करके, और इसे इस शुरुआती संकेत के तौर पर पढ़ा कि यह अच्छा चलेगा। सबक: अगर आपकी चीज़ खूबसूरत है और लोग launch से पहले ही बिना कहे उसे share करते हैं, तो यह उससे ज़्यादा असली validation और कोई नहीं है।

और VRChat, उन्हीं महीनों में जब Meta के अरबों और Rec Room दोनों ढह गए, करीब 160,000 concurrent users के एक record पर पहुंचा। यह community-driven, creator-driven है, और दूर-दूर तक उन चीज़ों जितना अच्छी फंडिंग वाला नहीं जो उसके आसपास मरीं। VRChat अपने टिकने का श्रेय पूंजी के बजाय community की वफ़ादारी और रचनात्मकता को देता है। सबक, खुद बचे हुए के शब्दों में: जुड़ी हुई creator की लगन पैसे से ज़्यादा टिकती है।

असल में ज़िंदा को मरे हुए से क्या अलग करता है

कहानियों को साथ-साथ रखिए और पैटर्न सूक्ष्म नहीं है।

जो चीज़ रचनात्मक worlds को मारती है वह खाली कमरा है। Horizon Worlds, Decentraland, Dreams, Crayta, Project Spark, Sansar, सब एक ही मौत मरे: पर्याप्त लोग नहीं, पर्याप्त content नहीं, लौटने की पर्याप्त वजह नहीं, एक ऐसे चक्र में जो खुद को ही खाता है। cold-start समस्या boss fight है। बाकी सब एक tutorial level है।

जो चीज़ उन्हें बचाती है वह भीड़ के आने से पहले मौजूद रहने की एक वजह होना है। Minecraft के पास procedural survival थी। Roblox के पास सब्र से बोए गए games का एक दशक था। .io games के पास दस सेकंड का मज़ा था। हर बचा हुआ एक खाली catalog के साथ आपके समय के लायक था। हर शिकार एक खूबसूरत डिब्बा था जो इंतज़ार कर रहा था कि दूसरे लोग उसे देखने लायक बनाएं। यह Dreams की स्वीकारोक्ति को आम बना देना है: पहले एक game बनाओ और बाद में एक platform। platform दूसरा अंक है। आप इसे पहले खुद के लिए कुछ ऐसा बनकर कमाते हैं जिसे लोग उसकी अपनी खातिर इस्तेमाल करते हैं।

जो metrics असल में टिकने की भविष्यवाणी करते हैं वे press release वाले नहीं हैं। शोध यहां एकमत है। product-market fit का परिभाषित करने वाला संकेत यह है कि आपकी retention curve समतल हो जाती है: लोगों का कोई समूह हमेशा के लिए लौटता रहता है। एक curve जो शून्य की ओर गिरती है उसका मतलब है कोई fit नहीं, चाहे funnel का ऊपरी हिस्सा कितना भी बड़ा हो। रफ़ industry benchmarks हैं 40 प्रतिशत day-1, 20 प्रतिशत day-7, 10 प्रतिशत day-30 retention, जहां day-30 वह है जो दीर्घकालिक सेहत की भविष्यवाणी करता है। और किसी भी creator-side वाली चीज़ के लिए, supply side वह जगह है जहां आप मरते हैं: नाकाम हुए marketplaces में करीब 67 प्रतिशत supply पर ढहते हैं, demand पर नहीं। Creator retention जान का संकेत है। registered accounts और valuations vanity हैं।

कहानियों से कुछ और भी निकलते हैं। अपने creators को पैसे दो या उन्हें खो दो, क्योंकि Dreams ने साबित किया कि प्रतिभाशाली लोग बिना किसी फ़ायदे के सालों नहीं लगाएंगे। multiplayer आम तौर पर मकसद होता है, कोई feature नहीं, Media Molecule के अपने अफ़सोस के मुताबिक। ऐसे platform पर अपना घर कभी मत बनाओ जो तुम्हें निकाल सके, Crayta के मुताबिक। और no-download दोधारी तलवार है: यह मौजूद सबसे बेहतरीन acquisition channel है और सबसे कमज़ोर commitment उपकरण, इसलिए बोझ पूरी तरह पहले साठ सेकंड के अच्छे होने पर पड़ता है।

इन सबके नीचे का जाल

एक और परत है, और यह वही है जो हमारे पल के लिए खास है, क्योंकि हमारे पास एक tool है जो मरने वालों के पास कभी नहीं था। हम AI से worlds generate कर सकते हैं। जो एक विरोधाभास खड़ा करता है जिस पर मैं हफ़्तों आगे-पीछे होता रहा हूं।

अगर यह AI है, तो क्या हर दुनिया अनोखी, हर इंसान के लिए नई generate की गई, उसके मुताबिक tune की गई, नहीं होनी चाहिए? लेकिन अगर हर इंसान की दुनिया अनोखी है, तो कोई भी कभी किसी और से कैसे टकराएगा, यह देखते हुए कि एक साझा पल के लिए एक साझा जगह चाहिए? और अगर दुनिया को वैसे भी साझा होना ही है, तो AI का इस्तेमाल ही क्यों किया जाए, बजाय एक असली studio की तरह एक खूबसूरत जगह को हाथ से गढ़ने के?

इनमें से हर खिंचाव, अपने अंत तक ले जाने पर, किसी ऐसी चीज़ पर पहुंचता है जो काम नहीं करती। सिर्फ़ आपके लिए generate की गई दुनिया एक ऐसी दुनिया है जिसमें कोई नहीं। Google का Genie एक वाक्य से एक खेलने लायक environment खड़ा कर सकता है और वह एक मिनट बाद गायब हो जाता है, single-player, कोई याददाश्त नहीं, कोई पड़ोसी नहीं। यह अकेला मृत-अंत है। लेकिन एक तय दुनिया को हाथ से गढ़ना भी एक मृत-अंत है: दो वर्ग किलोमीटर को हाथ से भरना सौ लोगों का, कई साल का काम है, और जब आप कर लेते हैं तो वह जमी हुई होती है, आपकी सौवीं यात्रा पर वही जैसी पहली पर, लोगों के आने पर बढ़ने में असमर्थ।

बाहर निकलने का रास्ता है "दुनिया" को एक चीज़ की तरह मानना बंद करना। यह तीन परतें हैं, और अनोखापन व साझापन बिना लड़े अलग-अलग परतों में रह सकते हैं। वह ज़मीन जिस पर हर कोई खड़ा होता है एक साझा दुनिया है, एक ऊंचे स्तर पर curated, मिलने की जगह। आप उसमें जो लाते हैं, आपके AI-generated assets, आपकी बनाई इमारत, वह बेहद अनोखा है, और आप उसे साझा दुनिया में जमा करते हैं ताकि आपका अनोखापन बाकी सबकी खोज बन जाए। और उसमें से होकर आपका रास्ता, जो quests आपको मिलती हैं, जो यह आपको दिखाता है, वह मुफ़्त में personalized है, क्योंकि एक रास्ता कोई जगह नहीं है। झूठा चुनाव था "एक personalized दुनिया", जो multiplayer को मार देती है, बनाम "एक साझा दुनिया से होकर एक personalized रास्ता", जो उसे और गहरा करता है। हमें दूसरा चाहिए।

तो AI का काम कभी हर इंसान को एक निजी दुनिया थमाना नहीं था। उसका काम एक साझा दुनिया को अनंत, ज़िंदा, और उसमें घूमने के लिए personal महसूस कराना है। अनोखापन उस हर चीज़ से आता है जो समय के साथ उसमें जमा होती है, हर creator का अपनी तरह का अकेला योगदान। हर Minecraft server अनोखा है। एक दिए गए server पर हर कोई उसे साझा करता है। यह कोई विरोधाभास नहीं है। यही पूरी तरकीब है, और इस पोस्ट के ऊपर वाला screenshot, AI एक ऐसा घर बना रहा है जो एक ऐसी दुनिया में टिका रहता है जिसमें दूसरे लोग चलकर आ सकते हैं, वह तरकीब हकीकत बनी हुई है।

हम Cinevva World को कैसे launch कर रहे हैं

तो यहां है कि यह सब हमारे लिए किसमें बदलता है। कोई marketing plan नहीं। पांच दांव, जानबूझकर उन पांच चीज़ों के खिलाफ़ लगाए गए जिन्होंने इस लेख के पहले हिस्से में सबको मारा। और मैं हर एक को इस आधार पर grade करूंगा कि सबूत असल में उसका कितना समर्थन करता है, क्योंकि एक plan जिसे आप grade नहीं कर सकते वह बस अच्छी रोशनी वाली एक ख्वाहिश है।

दांव एक, वह जिस पर मैं कंपनी लगा दूंगा: हम एक game launch करते हैं, एक platform नहीं। यह कोई पसंद नहीं है, यह पूरे अध्ययन का सबसे लगातार मिलने वाला निष्कर्ष है। Minecraft, Roblox, और Fortnite सबने करने को कुछ मज़ेदार के साथ अगुवाई की और उसके ऊपर creator परत बढ़ाई। Media Molecule, ज़िंदा सबसे प्रतिभाशाली creation studio, ने बाद में निष्कर्ष निकाला कि Dreams को पहले एक game होना चाहिए था। तो Cinevva World में एक नया इंसान पहली चीज़ जो करेगा वह एक खाली प्लॉट को ताकना नहीं होगा। यह एक लक्ष्य वाला loop होगा, एक मंगलवार को वहां होने की एक वजह जब लगभग कोई और online न हो। ज़्यादातर लोग जो आएंगे वे खेलेंगे और कभी नहीं बनाएंगे, और यह design है, कोई नाकामी नहीं। यह Roblox की असली शक्ल है: करोड़ों जो खेलते हैं, उन लोगों की एक पतली परत पर बैठे जो बनाते हैं। flywheel दूसरा अंक है, और हमें इसे कमाना होगा। मुझे इसका भरोसा है क्योंकि कब्रिस्तान पहले ही यह प्रयोग चला चुका है।

दांव दो, वह जो ईमानदारी से एक सट्टा है: AI हमें वह supply बनाने देता है जिसका इंतज़ार करते-करते बाकी सब मर गए। मैं इस बारे में सटीक रहना चाहता हूं कि यह एक दांव क्यों है और कोई गारंटी क्यों नहीं, क्योंकि इस अध्ययन में किसी भी platform को कभी generative AI से bootstrap नहीं किया गया था। मेरे पास एक mechanism है, कोई सबूत नहीं। mechanism: करीब दो-तिहाई two-sided platforms supply side पर मरते हैं, demand side पर नहीं। क्लासिक उपाय है supply को तब तक नकली बनाना जब तक वह असली न हो, जैसे DoorDash ने खुद खाना पहुंचाया, Reddit की टीम ने नकली handles के नीचे पोस्ट किया, और Roblox के founders ने सालों तक शुरुआती games हाथ से बनाए। हम यह generation से कर सकते हैं, एक ऐसी लागत और गति पर जो उनमें से किसी के पास नहीं थी। लेकिन यहां वह हिस्सा है जो मुझे ईमानदार रखता है, और यह Decentraland की कब्र है: Decentraland generated चीज़ों से भरा था और एक दिन में करीब तीस लोग खींचता था, क्योंकि सुंदर होना समय-के-लायक होने के बराबर नहीं है। तो मैं यह दांव नहीं लगा रहा कि AI दुनिया को मज़ेदार बनाता है। यह नहीं कर सकता। मैं यह दांव लगा रहा हूं कि AI asset की रुकावट हटा देता है ताकि हमारी दुर्लभ इंसानी मेहनत का हर घंटा उस एक चीज़ में जाए जो असल में लोगों को टिकाती है, loop। AI पहाड़ी सस्ते में बनाता है। हम उस पर चढ़ने की वजह हाथ से बनाते हैं। और हम synthetic seed को करीब 30 प्रतिशत पर सीमित रखते हैं, उसे करीब 60 दिनों के भीतर असली creator content में बदलते हुए, क्योंकि नकली supply जो कभी असली नहीं होती, जैसे ही कोई गौर करता है उसी पल भरोसा तोड़ देती है।

दांव तीन: हम अपने खुद के kill-criteria प्रकाशित करते हैं। यही एक ज़मीनी plan और एक उम्मीद भरे plan के बीच का फ़र्क है। हर एक मामले में टिकने की भविष्यवाणी करने वाला metric यह था कि retention curve समतल होती है या नहीं, कोई समूह शून्य की ओर सड़ने के बजाय लौटता रहता है या नहीं। तो यही वह कसौटी है जिस पर हम खुद को खरा उतारते हैं, खुलकर। अगर alpha day-7 retention समतल नहीं होती, अगर वे players जो कभी नहीं बनाते लौटते नहीं, अगर AI-seeded content को नज़रअंदाज़ करके आगे निकल जाया जाता है, तो thesis गलत है, और हम इसे बदलते हैं या हम रुक जाते हैं। हम players और creators को दो अलग funnels के रूप में, दो अलग aha moments के साथ, track करेंगे, क्योंकि data साफ़ है कि वे एक ही इंसान नहीं हैं। और हम यह दिखावा नहीं करेंगे कि पैसा शुरुआती काम करता है। पचास users पर, या एक हज़ार पर भी, tips और marketplace कमाई शून्य के बराबर है, इसलिए वे अभी किसी को नहीं टिकाते। शुरुआती retention loop से आता है या बिल्कुल नहीं आता। Dreams इसे उल्टा करने की रसीद है।

दांव चार: हम जानबूझकर संकरे से शुरू करते हैं। networked products पर शोध एकमत है। आप एक market के लिए launch नहीं करते, आप एक "atomic network" के लिए launch करते हैं, वह सबसे छोटा समूह जो अपने दम पर ज़िंदा रहने लायक घना हो। Facebook एक स्कूल से शुरू हुआ। हमारा पहले से मौजूद है: वे Cinevva creators जिन्होंने 3D assets, music, और sound generate किए हैं, और जिनके पास रखने के लिए पहले से inventory है। उनमें से पचास एक ही दुनिया में एक ही घंटे पर, एक लक्ष्य और एक सीमा के साथ, पचास हज़ार बिखरे हुए signups की तुलना में एक घनी और ज़्यादा ज़िंदा चीज़ है। सबूत इसका ज़ोरदार समर्थन करते हैं।

दांव पांच, सबसे नरम, और मैं यह कह दूंगा: हम खालीपन को छुपाने के बजाय उसके बारे में सच बोलते हैं। एक चमकीली, शांत दुनिया मरी हुई लगती है, और सभी नाकामियों ने उसे ambient effects से ढकने की कोशिश की। हम इसका उल्टा कोशिश करेंगे। यह पांचों में सबसे कम साबित कदम है, एक निष्कर्ष से ज़्यादा एक अंदाज़े के करीब। अंदर आने वाले पहले लोग किसी अधूरे product को नहीं देख रहे। वे एक ऐसी जगह के संस्थापक नागरिक हैं जो खाली है क्योंकि वे जल्दी आए हैं, और जो वे बनाएंगे वह तब भी खड़ा होगा जब अगले हज़ार आएंगे।

यही plan है, ईमानदारी से grade किया गया। चार दांव जिनका कब्रिस्तान ज़ोरदार समर्थन करता है, और एक असली सट्टा एक ऐसे tool पर जो मरने वालों में से किसी के पास नहीं था, ठीक उसी अनुशासन से घिरा हुआ जिसकी उनमें कमी थी। हम पहाड़ी generate कर सकते हैं। हम उस पर सबसे पहले चढ़ने का एहसास, या ऊपर से हाथ हिलाने वाले अजनबी को generate नहीं कर सकते। काम है उस हाथ हिलाने को मुमकिन बनाना, उसे retention curve पर साबित करना, और जिस पल curve "नहीं" कहे, उसी पल खुद को धोखा देना बंद कर देना।

Oleg Sidorkin द्वारा, Cinevva के CTO और सह-संस्थापक

यहाँ नए हैं? सीरीज़ गाइड का इस्तेमाल करें। यह बताती है कि स्पाइक क्या होता है और सभी भागों को लिंक करती है।

भाग 29 ने हमें एक ऐसा कंट्रोलर दिया जो किसी भी बॉडी को चलाता है। बॉडी अब सही तरीके से चलती है। वह चलती है, फिसलती है, तैरती है, ग्लाइड करती है, caves में चढ़ती है, और overhangs के नीचे झुकती है। समस्या यह है कि उसे क्या देख रहा है। उनतीस भागों तक कैमरा एक stock orbit rig था जो प्लेयर के पीछे चलता था और शर्मिंदगी से बचने के लिए ठीक एक चतुर काम करता था, वह क्षितिज से नीचे झुकने से इनकार करता था ताकि वह समतल ज़मीन के नीचे न फिसल सके। वह clamp ही पोल खोलता है। यह इसलिए मौजूद है क्योंकि कैमरे को यह पता ही नहीं था कि वर्ल्ड की geometry असल में कहाँ है, इसलिए clipping के खिलाफ़ एकमात्र बचाव वही angles मना करना था जहाँ clipping की सबसे ज़्यादा संभावना थी। किसी पहाड़ी की तरफ़ चलें और कैमरा पहाड़ी के अंदर बैठ जाता था। भाग 7 की marching-cubes caves में से किसी एक में कदम रखें और आप एक चट्टान के अंदर देख रहे होते थे। भाग 16 के authoring tools से एक घर बनाएँ और किसी कमरे में खड़े हों, तो कैमरा दीवार के बाहर तैरता रहता था और siding को देखता रहता था। यह भाग कैमरे को geometry के लिए वही सम्मान देता है जो बॉडी के पास पहले से है।

समस्या का आकार, और समाधान का आकार

एक third-person कैमरे का एक काम मुश्किल होता है और एक दर्जन आसान। आसान काम हैं फॉलो करना, smoothing, और orbit input, और ये हमारे पास पहले से थे। मुश्किल वाला यह है कि academic साहित्य इसे एक visibility constraint कहता है, और जिस survey का हर कोई हवाला देता है, Christie और Olivier का Camera Control in Computer Graphics, वह पूरे क्षेत्र को इसी के इर्द-गिर्द ढालता है: subject को framed और बिना रुकावट के रखें जबकि वर्ल्ड का सम्मान करते रहें। runtime पर यह हर frame पूछे जाने वाले एक धोखे से सरल सवाल में सिमट जाता है। प्लेयर pivot है। user ने घुमाकर और zoom करके उनके पीछे कुछ दूरी पर एक मनचाही कैमरा position तय की है। कैमरा असल में उस रेखा के साथ कितना पीछे बैठ सकता है, इससे पहले कि वह किसी ठोस चीज़ में घुस जाए? इसका ईमानदारी से जवाब दें और कैमरा खुद को पहाड़ी के सामने टिका लेता है, जब आप किसी कोने में पीछे हटते हैं तो boom के नीचे सरक जाता है, और cave की छत के बीच से घुसने के बजाय वहीं रुक जाता है।

जो pattern इसका जवाब देता है वह पुराना और आज़माया हुआ है। Unreal इसे spring arm कहता है, Godot एक SpringArm3D node देता है, और Unity का Cinemachine इसे एक third-person follow rig और एक deoccluder extension में बाँट देता है। विचार हमेशा एक ही रहता है। कैमरे को pivot पर लगे एक boom के सिरे से लटका दें। जब रास्ता साफ़ हो तो उसे मनचाही लंबाई पर रखें, जब कुछ रास्ते में आए तो उसे pivot की तरफ़ खींच लें, और जब रास्ता साफ़ हो जाए तो उसे वापस बाहर spring कर दें। Mark Haigh-Hutchinson की Real-Time Cameras, जिसे Metroid Prime के camera lead ने लिखा था, उन failure modes पर पूरे-पूरे अध्याय खर्च करती है जो इसके किसी भोले संस्करण को कुछ ऐसा बना देते हैं जो प्लेयर्स को बीमार कर देता है। हमने वह pattern लिया और अपना खुद का बनाया, इतना छोटा कि एक ही बैठक में पढ़ा जा सके, public/world/src/camera-rig.mjs में।

एक boom जो सिर्फ़ अपनी लंबाई का मालिक है

जिस design नियम ने rig को छोटा रखा वह भाग 29 के कंट्रोलर काम से उधार लिया गया है: एक चीज़ का मालिक बनो, पूरी तरह, और बाकी सब से इनकार कर दो। rig boom की लंबाई का मालिक है और कुछ नहीं। Yaw, pitch, orbit की damping, touch और wheel gestures, यह सब OrbitControls के पास रहता है, जो इसे पहले से ही अच्छी तरह सुलझा देता है और जिसे दोबारा लिखने में हमारी कोई दिलचस्पी नहीं। तो rig एक camera controller नहीं है। यह एक post-process है जो orbit math के बाद चलता है और ठीक एक संख्या को सही करता है, pivot से कैमरे तक की दूरी।

वह फ़ैसला सुथरा लगता है और यह लगभग तुरंत टूट गया, क्योंकि OrbitControls जिस तरह सोचता है। हर update की शुरुआत में वह कैमरे की मौजूदा position पढ़ता है और उससे अपना orbit radius निकालता है। यह आम तौर पर अदृश्य रहता है। लेकिन जिस पल हमारा rig किसी दीवार से बचने के लिए कैमरे को छोटा करता है, अगले frame में OrbitControls उस छोटी की गई position को पढ़ता है, यह नतीजा निकालता है कि user ने ज़रूर zoom in किया होगा, और उस छोटे होने को user की मनचाही zoom में पका देता है। इसके कुछ frames और कैमरा प्लेयर के सिर पर ढह जाता है और वापस बाहर नहीं आता। इसका समाधान दो calls हैं जो orbit update को घेरती हैं और यही पूरा integration है। OrbitControls चलने से पहले, beforeControls() कैमरे को पिछले frame की पूरी, बिना-छोटी की गई दूरी पर वापस लाता है, ताकि orbit math हमेशा user की असली zoom पढ़े। OrbitControls चलने के बाद, afterControls(dt) उस ताज़ा orbit की गई मनचाही position को पढ़ता है, collision सुलझाता है, लंबाई को damp करता है, और कैमरे को वहाँ लिखता है जहाँ उसे असल में render होना चाहिए। user का इरादा और collision की सुधार कभी एक-दूसरे को नहीं छूते, और dolly ठीक उतना ही responsive रहता है जितना rig के मौजूद होने से पहले था। rig के लिए हमने जो headless test लिखा वह इसे बिल्कुल पिन कर देता है: boom को साठ frames तक एक दीवार में घुसाओ, दीवार साफ़ करो, और लंबाई collision की दूरी पर अटकने के बजाय user की दस मीटर की पूरी zoom पर वापस spring हो जाती है।

एक contract, कोई भी collider

rig कभी नहीं पूछता कि वर्ल्ड किस चीज़ से बना है। एक collider बस एक ऐसा object है जिसके पास एक probe method है, और rig उसे एक ray, एक अधिकतम दूरी, और कैमरे का probe radius देता है, और बदले में एक संख्या पाता है, वह सबसे दूर की दूरी जहाँ तक कैमरा उस collider के रोकने से पहले सफ़र कर सकता है। rig हर पंजीकृत collider से पूछता है और सबसे नज़दीकी hit लेता है। यही पूरा contract है, और यह वही चाल है जो character controller ने तब चली थी जब उसने locomotion को pluggable behaviors में बदला था। Terrain प्लग होता है, props प्लग होते हैं, building shells प्लग होते हैं, हर एक उसी probe के पीछे, और rig इन सब से अनजान रहता है। एक नई तरह की रुकावट जोड़ना मतलब एक list में एक collider जोड़ना है, कैमरा edit करना नहीं।

contract में एक बात अपनी कीमत वसूल करती है, और वह है probe radius। हम pivot से कैमरे तक एक पतली ray नहीं डालते, हम एक sphere डालते हैं जो इतना बड़ा हो कि कैमरे के near plane को समा सके। एक अकेली ray कैमरे के केंद्र को दीवार पर रोक देती है, लेकिन near plane की चौड़ाई होती है, इसलिए उसके कोने दीवार में पहले से दब चुके होते, इससे पहले कि केंद्र वाली ray कभी कोई hit रिपोर्ट करती। एक ray के बजाय एक छोटा sphere चलाना ही वह है जो हर shipping implementation करता है, Unreal इसे probe size के रूप में सामने रखता है, और यही उस कैमरे और उस कैमरे के बीच का फ़र्क है जो सतह से साफ़-साफ़ टिकता है बनाम वह जो स्क्रीन के किनारों पर आपको आर-पार देखने देता है।

हम उस radius का अंदाज़ा नहीं लगाते, हम उसे निकालते हैं। कैमरे से near plane का सबसे दूर का बिंदु उसके कोनों में से एक है, और उस तक की दूरी सीधे projection से निकल आती है। near plane $n$ और vertical field of view $\theta$ के साथ, half-height $h=n\tan (\theta /2)$ है, half-width $w=h\cdot \text{aspect}$ है, और कोना यहाँ बैठता है

probe radius वही कोने की दूरी है, एक छोटे safety margin से गुणा, एक तय floor के साथ ताकि वह बहुत संकरे frustum पर कभी एक समझदार न्यूनतम से नीचे न गिरे। जब भी field of view, aspect ratio, या near plane बदलता है, radius दोबारा गणना होता है, ताकि एक window resize या एक ऐसी zoom जो projection को छूती है, चुपचाप probe को इतना छोटा न छोड़ दे कि वह उन कोनों को ढक न सके जिन्हें उसे बचाना है।

वह collider जो caves के बारे में जानता है

terrain collider वह जगह है जहाँ यह दिलचस्प हो जाता है, क्योंकि हमारे engine में terrain एक heightmap नहीं है। भाग 7 से यह एक signed distance field रहा है, एक ऐसा function जो लौटाता है कि space में कोई भी बिंदु निकटतम ठोस सतह से कितनी दूर है और वह चट्टान के अंदर है या बाहर। धनात्मक मतलब हवा, ऋणात्मक मतलब चट्टान, और वही एक तथ्य यही वजह है कि हमारा कैमरा कुछ ऐसा कर सकता है जो एक heightmap कैमरा संरचनात्मक रूप से नहीं कर सकता। एक heightmap किसी x और z पर ज़मीन की ऊँचाई जानता है। उसके पास छत की कोई धारणा नहीं है, क्योंकि किसी भी बिंदु के ऊपर कभी सिर्फ़ एक ही सतह होती है। तो एक heightmap कैमरा आपको पहाड़ी में चलने से रोक सकता है, लेकिन उसे यह पता ही नहीं कि एक overhang का किनारा या एक cave की छत pivot के ऊपर लटक रही है, और वह दोनों के बीच से सीधे निकल जाता है। एक distance field तीन dimensions में हर सतह के बारे में जानता है, इसलिए वही probe जो कैमरे को एक पहाड़ी की ढलान पर रोकता है, उसे एक cave की छत पर भी एक भी special case के बिना रोक देता है।

field के साथ probe को चलाना एक ऐसी तकनीक है जिसका एक नाम है और जिसके पीछे एक paper है। John Hart की Sphere Tracing, 1996 से, एक distance field के खिलाफ़ एक ray को march करने का मानक तरीका है, और चाल यह है कि field आपको सिर्फ़ यह नहीं बताता कि आपने किसी चीज़ से टकराया या नहीं, वह आपको एक सुरक्षित दूरी बताता है जितनी आप किसी चीज़ से टकराए बिना आगे बढ़ सकते हैं। तो छोटे-छोटे तय कदमों में रेंगने के बजाय, आप field को sample करते हैं, उतना आगे बढ़ते हैं जितनी ढील वह रिपोर्ट करता है, और दोहराते हैं, खुली हवा में लंबे डग भरते हुए और किसी सतह के पास पहुँचते ही छोटे, सावधान कदम लेते हुए।

हालाँकि एक पेच है जो हमारी terrain हम पर थोपती है। एक असली distance field निकटतम सतह तक की असल Euclidean दूरी रिपोर्ट करता है, और उस ढील के बराबर एक पूरा डग हमेशा सुरक्षित होता है। लेकिन जहाँ terrain अभी भी carved voxels के बजाय एक heightmap है, वह field जिसे हम सस्ते में sample कर सकते हैं वह असली distance नहीं है, वह vertical clearance है, सीधे नीचे ज़मीन तक का अंतर। किसी ढलान पर वह संख्या ज़्यादा बता देती है कि कैमरा असल में कितना दूर जा सकता है, क्योंकि निकटतम चट्टान बगल में है, सीधे नीचे नहीं। ईमानदार दूरी एक ऐसे factor से छोटी होती है जो gradient के साथ बढ़ता है, $\sqrt{1+\Vert \mathrm{\nabla }h{\Vert }^2}$, इसलिए रिपोर्ट की गई ढील के हिसाब से नापा गया एक डग आगे निकल जाता है और एक चोटी के साफ़ ऊपर से कूद सकता है। इसका समाधान under-relaxation है, रिपोर्ट की गई ढील के पूरे के बजाय सिर्फ़ एक अंश के हिसाब से आगे बढ़ना, जो लगभग साठ डिग्री की ढलान तक सुरक्षित रहता है और true-distance voxel क्षेत्रों पर कुछ अतिरिक्त samples के अलावा कुछ खर्च नहीं करता। हम इसे एक stride floor के साथ जोड़ते हैं, ताकि एक या दो cell मोटी cave की दीवार कभी साफ़ ऊपर से न लाँघी जाए, और एक सख़्त ceiling के साथ जो march को सस्ता रखता है। जब sphere आखिरकार सतह को छूता है तो एक छोटा bisection contact point को कस देता है, और कैमरा अपने ही radius जितना पीछे हटकर वहीं टिक जाता है।

लिखकर बताएँ तो, boom pivot $\mathbf{p}$ से unit दिशा $\mathbf{d}$ के साथ एक ray $\mathbf{r}(t)=\mathbf{p}+t\mathbf{d}$ है, और march field की ढील के एक under-relaxed अंश के हिसाब से contact तक आगे बढ़ता है, दोनों सिरों पर clamp किया हुआ:

यहाँ $\mathrm{\Phi }$ signed distance है, हवा में धनात्मक और चट्टान में ऋणात्मक, $r$ probe radius है, $\lambda \in (0,1]$ वह under-relaxation factor है जो ज़्यादा बताने वाले heightmap field को एक ढलान कूदने से रोकता है, और $s_{min},s_{max}$ वे step clamps हैं जो एक पतली दीवार को skip होने से और march को लंबा चलने से रोकते हैं। Contact पहला $t$ है जहाँ $\mathrm{\Phi }(\mathbf{r}(t))\le r$, मतलब sphere की सतह चट्टान तक पहुँच गई है, और कैमरा उस arc लंबाई पर रुकता है, अपने radius जितना कम।

collider एक और method एक safety net के रूप में रखता है, depenetration। Collision को सबसे पहले तो कैमरे को ठोस से बाहर रखना चाहिए, लेकिन कुछ हालात इसके पास से सरक जाते हैं, एक pivot जो एक ऐसी पतली दीवार के दोनों तरफ़ बँटा है कि boom उसके अंदर ही शुरू हो जाता है, एक cave जिसे terrain tools ने तब ताज़ा तराशा जब कैमरा उस चट्टान में बैठा था जो अब गायब है, एक building piece जो कैमरे के चारों ओर गिरा दिया गया। उनके लिए collider जाँचता है कि क्या कैमरे ने frame ठोस के अंदर खत्म किया, जहाँ $\mathrm{\Phi }(\mathbf{c})<r$, और अगर ऐसा हुआ, तो field के gradient को पढ़ता है, जो सीधे खुली हवा की तरफ़ इशारा करता है क्योंकि $\mathrm{\Phi }$ तब बढ़ता है जब आप चट्टान छोड़ते हैं, और कैमरे को उसके साथ बाहर कदम रखाता है:

उन कुछ iterations से यह $r$-isosurface पर converge हो जाता है, और यही वह चीज़ है जिसका मतलब है कि एक sculpting tool कैमरे के नीचे से ज़मीन खोद सकता है और view अगले frame पर रिकवर हो जाता है, काला होने के बजाय।

अंदर snap होना, बाहर easing, और fence posts पर न झिझकना

एक boom जो हर frame बस collision की दूरी पर कूद जाता है, किसी boom न होने से भी बदतर है, क्योंकि वर्ल्ड पतली चीज़ों से भरा है जिनके पीछे कैमरा एक frame के लिए गुज़रता है, एक fence post, एक lamp, एक पेड़ का तना, और एक कैमरा जो हर एक से बचने के लिए झपटता है और वापस झपटता है, मतली पैदा करता है। Haigh-Hutchinson की किताब और Itay Keren का camera motion पर खूब पसंद किया गया talk दोनों एक ही अंतर्ज्ञान पर पहुँचते हैं, कि कैमरे को खतरों और जोखिम पर उससे तेज़ प्रतिक्रिया करनी चाहिए जितनी तेज़ी से वह उनसे आराम पाता है। तो damping जानबूझकर असममित है। जब कोई occluder दिखता है और boom को छोटा होने की ज़रूरत होती है, तो वह लगभग तुरंत अंदर snap हो जाता है, क्योंकि clipping का एक frame भद्दा होता है और प्लेयर एक तेज़ tuck को माफ़ कर देता है। जब occluder साफ़ हो जाता है और boom लंबा होना चाहता है, तो वह धीरे-धीरे बाहर ease होता है, और सिर्फ़ तब जब लगातार साफ़ रहने का एक छोटा dwell timer बीत चुका हो। वह dwell ही वह hysteresis है जो झिझक को खत्म कर देती है। कैमरे को एक पतले post के पास से तेज़ी से घुमाएँ और post कभी इतनी देर तक साफ़ नहीं रहता कि धीमी extension को trigger करे, इसलिए कैमरा उसके पास से ऐसे सरकता है जैसे वह वहाँ था ही नहीं, जो ठीक वही है जो आपकी आँख चाहती है। Cinemachine इसी विचार को collision में damping और collision से बाहर damping के अलग-अलग मानों के रूप में सामने रखता है, और असममितता ही वह हिस्सा है जो इसे एक spring के बजाय एक camera operator जैसा महसूस कराता है।

code में यह exponential smoothing की एक लाइन है जिसकी rate बदलाव के चिह्न पर switch होती है। अगर $\ell$ मौजूदा boom लंबाई है, $a$ वह लंबाई है जिसकी इस frame collision इजाज़त देता है, और $\mathrm{\Delta }t$ frame समय है, तो

और ease-out branch सिर्फ़ तब चलती है जब clearance dwell समय $\tau$ तक टिकी रहे। $1-e^{-k\mathrm{\Delta }t}$ रूप सुथरा दिखने से कहीं ज़्यादा मायने रखता है। यह response time constant को frame rate की परवाह किए बिना $1/k$ पर तय कर देता है, इसलिए कैमरा 30 और 144 frames प्रति सेकंड पर एक जैसा महसूस होता है, जहाँ भोला constant-blend $\ell \leftarrow \ell +\alpha (a-\ell )$ एक तेज़ मशीन पर ज़्यादा तेज़ी से snap होता और एक धीमी मशीन पर लसलसा जाता।

आखिरी behavior उन तंग interiors के लिए है जिन्होंने यह पूरा भाग शुरू किया। जब boom इतना छोटा ढह जाता है कि कैमरा प्लेयर के ठीक ऊपर होता है, तो हम प्लेयर के अपने avatar को छिपा देते हैं और view को first person के पास बैठने देते हैं। यही Breath of the Wild एक तंग shrine में करता है और यही ज़्यादातर third-person games एक कोने में सहारा लेते हैं, क्योंकि विकल्प, एक कैमरा जो दीवार से सटा हुआ एक सिर के पिछले हिस्से को घूर रहा हो, बेकार है। rig इसके लिए एक अकेला flag सामने रखता है, और world loop उस flag को पढ़ता है और local avatar की दृश्यता को toggle करता है। एक मीटर boom से नीचे आप असल में first person में होते हैं, दीवारों का सम्मान होता है, और जिस पल आप जगह वाले किसी कमरे में पीछे हटते हैं avatar वापस fade in हो जाता है और boom बढ़ जाता है।

आगे क्या प्लग होता है

terrain collider आज ship होता है और यही मुश्किल आधा है, क्योंकि terrain हर जगह है और एक distance field probe करने के लिए मुश्किल चीज़ है। authoring spikes के props और building shells आसान आधा हैं, और contract पहले से ही उनका इंतज़ार कर रहा है। एक दूसरा collider, एक raycast collider, pivot से कैमरे की तरफ़ meshes की एक list के खिलाफ़ cast करता है और निकटतम hit को उसी तरह रिपोर्ट करता है जैसे terrain collider करता है। सस्ता संस्करण एक अकेली ray cast करता है, जो तब तक ठीक है जब तक prop की गिनती न चढ़े, और upgrade यह है कि ray को three-mesh-bvh का इस्तेमाल करके एक swept sphere से बदल दें, Garrett Johnson की library जो एक mesh को एक bounding-volume hierarchy में लपेटती है ताकि spatial queries brute force के बजाय log time में चलें। किसी भी तरह rig नहीं बदलता। वह colliders की एक लंबी list से पूछता है और निकटतम hit लेता है, जो पहले contract और बाद में colliders बनाने का पूरा मक़सद है।

इस अध्याय में संदर्भित तकनीक

एक boom जो एक संख्या का मालिक है। camera rig OrbitControls के ऊपर एक post-process है, उसका विकल्प नहीं। यह boom की लंबाई का मालिक है और yaw, pitch, zoom, और gesture handling को उस orbit controller के पास छोड़ देता है जिस पर हम पहले से भरोसा करते थे। integration दो घेरने वाली calls हैं: beforeControls() पिछले frame की पूरी दूरी बहाल करता है ताकि orbit math user की असली zoom पढ़े, न कि एक collision की छोटाई को एक dolly-in समझे, और afterControls(dt) collision सुलझाता है और render की गई position लिखता है। उस जोड़ी के बिना कैमरा कुछ frames में प्लेयर पर ढह जाता है।

एक pluggable collider contract। एक collider कोई भी ऐसा object है जिसके पास एक probe है जो जवाब देता है कि "कैमरा pivot से इस ray के साथ कितना दूर सफ़र कर सकता है इससे पहले कि तुम उसे रोको।" rig हर collider से पूछता है और निकटतम hit लेता है, इस बात से अनजान कि रुकावट terrain है, एक prop है, या एक दीवार है, जो वही एक-चीज़-का-मालिक अनुशासन है जो pluggable character controller ने locomotion के लिए इस्तेमाल किया था। probe एक swept sphere है जो near plane को समाने जितना बड़ा है, एक पतली ray नहीं, इसलिए frustum के कोने कभी किसी ऐसी सतह को clip नहीं करते जिसे केंद्र वाली ray चूक जाती। इसका radius projection से निकाला जाता है, एक near-plane कोने तक की दूरी $\sqrt{n^2+w^2+h^2}$ एक safety margin से गुणा, और जब भी field of view, aspect, या near plane बदलता है तो दोबारा गणना होता है।

एक signed-distance terrain probe जो overhangs और caves का सम्मान करता है। क्योंकि terrain एक heightmap के बजाय एक signed distance field है, वही probe जो कैमरे को एक पहाड़ी की ढलान पर रोकता है उसे एक cave की छत पर भी रोकता है, वह case जिसे एक heightmap raycast संरचनात्मक रूप से नहीं देख सकता। march Hart-शैली का sphere tracing है, field जो ढील रिपोर्ट करता है उसके एक under-relaxed अंश के हिसाब से कदम बढ़ाते हुए और दोनों सिरों पर clamp किया हुआ, क्योंकि heightmap क्षेत्र असली distance के बजाय vertical clearance रिपोर्ट करते हैं और ज़्यादा बताते हैं कि कैमरा एक ढलान पर कितना दूर जा सकता है, इसलिए एक पूरा डग एक चोटी कूद जाता। एक gradient-संचालित depenetration pass वह safety net है जो view को रिकवर करता है जब कैमरे के नीचे से ज़मीन तराश दी जाती है।

dwell timer के साथ असममित damping। boom तब तेज़ी से अंदर snap होता है जब कोई occluder दिखता है और एक बार साफ़ होने पर धीरे-धीरे बाहर ease होता है, और सिर्फ़ लगातार साफ़ रहने की एक छोटी खिड़की के बाद, ताकि एक fence post के पास से तेज़ी से गुज़रना कभी कैमरे को झपटाए नहीं। एक collapse threshold से नीचे rig near-first-person flag करता है और world loop local avatar को छिपा देता है, जो तंग interiors के लिए मानक सहारा है, दीवार में दबे एक कैमरे के बजाय।

संदर्भ

camera control को एक visibility constraint के रूप में ढालना Marc Christie और Patrick Olivier के Camera Control in Computer Graphics (Computer Graphics Forum, 2008) से आता है। distance-field march John C. Hart का Sphere Tracing: A Geometric Method for the Antialiased Ray Tracing of Implicit Surfaces (The Visual Computer, 1996) है। spring-arm pattern और इसका probe-sphere collision Epic के Spring Arm Component और Unity के Cinemachine Deoccluder और Third Person Follow में documented हैं। motion और damping का अंतर्ज्ञान Mark Haigh-Hutchinson की Real-Time Cameras (Morgan Kaufmann, 2009), और Itay Keren के Scroll Back: The Theory and Practice of Cameras in Side-Scrollers (GDC 2015) से है। mesh-collider upgrade path Garrett Johnson का three-mesh-bvh है।

30 में से भाग 30। पिछला: भाग 29 - एक कंट्रोलर, कोई भी बॉडी सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide

Oleg Sidorkin द्वारा, Cinevva के CTO और सह-संस्थापक

यहाँ नए हैं? सीरीज़ गाइड का इस्तेमाल करें। यह बताती है कि स्पाइक क्या होता है और सभी भागों को लिंक करती है।

भाग 28 ने घास और occlusion को कवर किया। अट्ठाईस भागों ने खड़े होने लायक एक वर्ल्ड बनाया: ऐसी terrain जिसे आप पढ़ सकते हैं, ऐसा पानी जिसमें आप तैर सकते हैं, ऐसी foliage जो क्षितिज तक टिकी रहती है, एक ऐसा server जो याद रखता है कि आपने क्या बदला। यह भाग उस चीज़ के बारे में है जो इस सबके बीच से होकर गुज़रती है, और यह पूरे engine का फल है, क्योंकि लक्ष्य एक प्लेयर कंट्रोलर नहीं है। यह एक ऐसा कंट्रोलर है जिसे इस बात की परवाह नहीं कि वह कौन सी बॉडी चला रहा है, उसके animations कहाँ से आए, या स्टीयरिंग पर कोई इंसान है या कोई AI। स्पाइक 58 movement को एक physics engine के ऊपर pluggable behaviors के एक stack के रूप में बनाता है जिसे locomotion के बारे में कुछ भी नहीं पता, फिर तीन अलग-अलग बॉडीज़ को उसकी एक ही कॉपी के ज़रिए चलाकर architecture को सिद्ध करता है। स्पाइक 59 उस कंट्रोलर की एक भी लाइन बदले बिना उस पर एक असली retargeted avatar लटका देता है। स्पाइक 60 एक अलग animation पैक लटका देता है जिसे retargeting की ज़रूरत ही नहीं, और clip चुनने वाले logic को बाहर खींचकर ऐसी चीज़ में बदल देता है जिसे आप सचमुच test कर सकते हैं।

एक physics engine जिसे चलने के बारे में कुछ नहीं पता

Spike 58 को नए टैब में खोलें ↗ · सोर्स देखें

डिज़ाइन का नियम सख्त है और यही पूरी बात है: capsule engine के पास कोई locomotion नहीं है। न walk, न run, न jump, न friction, न top-speed cap, यहाँ तक कि न gravity। यह बस एक kinematic capsule को terrain के सापेक्ष integrate करता है और इससे ज़्यादा कुछ नहीं। हर locomotion behavior, walk, slide, glide, climb, swim, crouch, stamina, engine के साथ रजिस्टर किए गए एक स्वतंत्र कंट्रोलर में रहता है। हर frame पर engine हर कंट्रोलर को tick करता है, हर एक से पूछता है कि क्या वह control चाहता है, और सबसे ऊँची priority वाले दावेदार को velocity लिखने देता है। Walk का कोई खास दर्जा नहीं है। यह बस सबसे कम priority वाला कंट्रोलर है जो हमेशा हाँ कहता है, इसलिए जब और कुछ नहीं चलता तो यही default है। एक कंट्रोलर छह छोटे functions का बना होता है: एक tick जो हर frame पर अपनी internal state को अपडेट करता है, तब भी जब वह active नहीं होता, एक pure wantsControl predicate जो frame पर दावा करता है, एक applyForces जिसे सिर्फ़ विजेता चलाता है और जो velocity लिखता है और अगर चाहे तो अपनी gravity लगाता है, साथ ही वैकल्पिक onEnter, onExit, और stateName। Swim अपने applyForces से ownsCollision: true लौटाता है ताकि terrain handling अपने हाथ में ले ले, क्योंकि वरना उसका buoyancy spring engine के foot-snap से लड़ता।

वे चीज़ें भी जो locomotion नहीं हैं, फिर भी उस contract से होकर रिसती हैं, और यही उस अगले विचार की वजह बना। architecture को सार्थक बनाने वाला हिस्सा channels हैं। एक पुराने single-channel डिज़ाइन में सब कुछ एक ही arbitration से होकर गुज़रता था, जिसका मतलब था कि एक stamina tracker या एक crouch stance को locomotion होने का दिखावा करना पड़ता था और फिर सिर्फ़ अपनी bookkeeping चलाने के लिए wantsControl के false लौटाने वाले एक hack से control से इनकार करना पड़ता था। यह fix कंट्रोलर्स को नामित channels में बाँट देता है जो स्वतंत्र रूप से arbitrate करते हैं और एक तय क्रम में लागू होते हैं: पहले resource, फिर stance, फिर locomotion। Resource पहले चलता है क्योंकि उसके writes, जैसे stamina decay, बाकी द्वारा पढ़े जाते हैं। Stance दूसरे नंबर पर चलता है क्योंकि crouch द्वारा capsule की height घटाना तब लागू होना चाहिए जब walk उसे पढ़कर top speed cap करे, उससे पहले। Locomotion आखिर में चलता है और per-frame velocity write उसके पास है। तो एक stamina observer और एक crouch modifier और एक active swim कंट्रोलर सब साफ़-साफ़ साथ रहते हैं, हर एक अपने channel में, और किसी कंट्रोलर को अपने बारे में झूठ नहीं बोलना पड़ता। डेमो इस सबको एक नंगे capsule से visualize करता है जो active कंट्रोलर के हिसाब से रंग बदलता है, ताकि आप arbitration होते देख सकें: एक खड़ी ढलान पर green walk नारंगी हो जाता है जैसे ही slide ले लेता है, झील में cyan हो जाता है जैसे swim जीतता है, हवा में cream हो जाता है जब आप glide टैप करते हैं।

एक engine, तीन बॉडीज़

"कोई locomotion नहीं" का असली test प्लेयर नहीं है। यह है कि क्या वही engine, बिना छुए, कुछ ऐसा चला सकता है जो प्लेयर है ही नहीं। createCapsuleEngine एक pure factory है जिसमें कोई module-level state नहीं, कोई singletons नहीं, और कोई per-instance side effects नहीं, इसलिए स्पाइक इसे तीन बार instantiate करता है। प्लेयर पूरे कंट्रोलर सेट वाला एक instance है। एक सवारी करने लायक घोड़ा दूसरा instance है जो सिर्फ़ एक walk कंट्रोलर रजिस्टर करता है, जो इस पूरे विचार को शब्दशः साकार करता है: एक बॉडी की movement की शब्दावली बस वही कंट्रोलर्स हैं जो आपने रजिस्टर किए, इसलिए घोड़ा समतल पर तेज़ है और शारीरिक रूप से न चढ़ सकता है, न तैर सकता है, न glide कर सकता है, क्योंकि वे कंट्रोलर्स कभी जोड़े ही नहीं गए। एक स्वायत्त NPC तीसरा instance है, जिसे प्लेयर के साथ-साथ हर frame पर tick किया जाता है, एक wander कंट्रोलर से चलाया जाता है जो अपना खुद का input बनाता है ताकि बॉडी खुद को steer करे, keyboard पर कोई हाथ नहीं। engine को कभी पता नहीं चलता कि उसकी एक बॉडी घोड़ा है या दूसरी AI-चालित है। वे सब अलग-अलग कंट्रोलर सूचियों वाला वही capsule integrator हैं।

Mounting वह एक हिस्सा है जो जानबूझकर engine के बाहर रहता है। प्लेयर और घोड़े के बीच control अदला-बदली का मतलब है दो engines में तालमेल बिठाना, और एक कंट्रोलर एक engine के अंदर चलता है और उस सीमा के पार नहीं देख सकता, इसलिए mount logic host स्तर पर बैठता है: यह एक छोटी state machine है जो तय करती है कि इस frame में कौन सा engine step किया जाए, दूसरे को फ्रीज़ कर देती है, सवार को तीन-चौथाई सेकंड के एक smoothstep के साथ काठी पर बैठा देती है, और camera को बताती है कि किस बॉडी को track करना है। engine factory को इसके बारे में कभी कुछ नहीं सुनना पड़ता। architecture यही लकीर खींचता है और बनाए रखता है। एक बॉडी से जुड़े behaviors कंट्रोलर्स हैं; बॉडीज़ के बीच तालमेल host का काम है, और उन्हें अलग रखना ही वह वजह है कि एक चौथी या चालीसवीं बॉडी की कोई नई लागत नहीं होगी।

बिना ब्राउज़र के tested

क्योंकि engine न किसी window तक पहुँचता है, न किसी document तक, और न Three.js तक, पूरी चीज़ headless चलती है। स्पाइक एक Node harness के साथ आता है जो terrain interface को mock करता है, scripted input के साथ engine को frame दर frame चलाता है, और परिणामी state पर assert करता है, ताकि वे regressions जिन्हें play-testing से पकड़ना दर्दनाक है, इसके बजाय एक script में पकड़ी जाएँ: jump-and-land transition, swim में घुसने और निकलने की thresholds, surface के समतल होने पर climb का auto-clear होना, stamina के घटने की दरें। वही input और timestep sequence दो बार feed करना और byte-identical output state की जाँच करना engine को deterministic साबित करता है, जो वह गुण है जिस पर एक networked build आखिरकार टिकेगी। harness ने एक regression पकड़ी जो याद रखने लायक है: walkable ज़मीन से एक ऐसी ढलान पर कदम रखना जो walk से ज़्यादा खड़ी थी, पहले slide कंट्रोलर को engage कर देता था और प्लेयर को वापस पहाड़ी पर उछाल देता था। इसका fix एक descent gate था। Sliding तभी शुरू होता है जब capsule सचमुच ढलान पर गिर रहा हो, इसलिए एक खड़ी सतह में horizontally चलना अब saaf-suthre तरीके से रुक जाता है बजाय slide करने के, और वह test जो "एक non-walkable ढलान में चलना प्लेयर को रोकता है" पर assert करता है, इसे fix रखता है।

कंट्रोलर्स को छुए बिना एक असली avatar plug करना

Spike 59 को नए टैब में खोलें ↗ · सोर्स देखें

स्पाइक 59 इस बात का test है कि क्या कंट्रोलर परत सचमुच बॉडी से decoupled है। यह रंगीन capsule को एक असली skinned कैरेक्टर से बदल देता है, 3MIKE FBX rig जिस पर Quaternius Universal Animation Library clips retargeted हैं, और कंट्रोलर्स बिल्कुल नहीं बदलते। सीवन एक अकेला string है। हर कंट्रोलर पहले से ही stateName के ज़रिए एक state नाम रिपोर्ट करता है, idle, walk, run, jump, fall, land, slide, glide, swim, swimIdle, और avatar परत उस नाम को एक alias table के ज़रिए एक retargeted clip से map करती है और switch पर crossfade करती है। Walk grounded plus vertical velocity plus horizontal speed से अपनी sub-state खुद dynamically चुनता है, इसलिए एक अकेला walk कंट्रोलर idle, walk, run, jump, fall, और land चलाता है, और avatar बस रिपोर्ट किए गए नाम का अनुसरण करता है। क्योंकि यह स्पाइक single-player है, avatar पुराने networked स्पाइक्स से wire-integer indirection और multi-character abstraction को छोड़ देता है और state नाम को सीधे एक clip से map करता है। इसका सबूत यह है कि capsule से rigged इंसान तक का पूरा visual upgrade locomotion code की शून्य लाइनें छूता है, जो ठीक वही है जो एक pluggable कंट्रोलर से मिलना चाहिए।

एक पैक जिसे retargeting की ज़रूरत नहीं, और एक picker जिसे आप test कर सकते हैं

Spike 60 को नए टैब में खोलें ↗ · सोर्स देखें

स्पाइक 60 एक तीसरी बॉडी plug करता है, Synty का POLYGON Base Locomotion पैक, और loader लगभग कुछ भी नहीं है। हर clip एक standalone FBX के रूप में आता है जो उसी Synty skeleton की एक embedded कॉपी plus एक baked animation साथ लाता है, और क्योंकि कैरेक्टर rig और हर clip समान bone नाम इस्तेमाल करते हैं, आप clip को fbx.animations[0] से उठाते हैं और बिना किसी retargeting library के सीधे कैरेक्टर के mixer पर चला देते हैं। Three.js animation track targets को object identity के बजाय bone नाम से resolve करता है, इसलिए matching rig के सापेक्ष बनाया गया एक Synty या Mixamo-शैली का पैक बस काम कर जाता है। यह पिछले स्पाइक के UAL path के साथ जानबूझकर किया गया विरोधाभास है, जिसे भारी-भरकम retargeting की ज़रूरत है क्योंकि source clips और target rig अलग-अलग skeletons के सापेक्ष बनाए गए थे। वही कंट्रोलर, वही state-name सीवन, उसके पीछे दो पूरी तरह अलग animation pipelines।

स्पाइक 60 का दूसरा आधा हिस्सा clip चुनने वाले logic को testable बनाना है। कौन सा clip चलाना है यह चुनना judgment thresholds से भरा है, और वह logic avatar परत के अंदर FBXLoader और DOM के बगल में दफ़न था जहाँ इसे exercise नहीं किया जा सकता था। स्पाइक picker को pure functions में निकालता है जो न Three.js को छूते हैं न window को: वे एक सादा player record (velocity, horizontal speed, facing, grounded, ground normal, impact velocity) और एक clip-action stand-in लेते हैं, और एक clip alias string लौटाते हैं। इससे thresholds नामित, asserted constants के रूप में रह पाते हैं। Jump walk कंट्रोलर की असली sprint threshold से aligned speed buckets के हिसाब से walking, running, और sprinting variants में बँट जाता है; landings impact velocity के हिसाब से soft, medium, और hard में बँट जाती हैं; uphill और downhill clip variants एक slope-projection dot product से fire होते हैं जिसमें लगभग सात डिग्री से नीचे एक flat-clip deadzone होता है; एक idle-to-locomotion bridge हमेशा आगे की ओर resolve करता है ताकि एक standing start कभी किसी clip को उल्टा न चलाए; और एक stop bridge एक न्यूनतम time-in-loop से gated है, क्योंकि Synty के foot-phase stop clips में लगभग एक सेकंड का authored deceleration होता है जो उस step पर चिपकाए जाने पर हास्यास्पद लगता है जो प्लेयर ने मुश्किल से लिया। एक छोटा state debouncer fall state को कुछ frames के लिए रोके रखता है ताकि एक सीवन के पार एक frame के लिए ज़मीन का संपर्क खोने पर animation झिलमिलाए नहीं। उस सबको rendering shell से बाहर खींचने का मतलब है कि नियमों को बिना GPU के unit test किया जा सकता है, वही headless अनुशासन जो engine को खुद स्पाइक 58 में मिला, जो locomotion के उस अनुभव के बीच का फ़र्क है जिसे आप अंदाज़ा लगाकर tune करते हैं और उस locomotion अनुभव के बीच जिसे आप तय कर सकते हैं।

इस अध्याय में संदर्भित तकनीक

एक locomotion-रहित physics engine। capsule engine एक kinematic body को terrain के सापेक्ष integrate करता है और इसके पास कोई walk, run, jump, friction, speed cap, या gravity नहीं है। हर behavior एक रजिस्टर किया गया कंट्रोलर है जो tick, wantsControl, applyForces, और वैकल्पिक onEnter/onExit/stateName expose करता है। Walk बस सबसे कम priority वाला हमेशा-हाँ default है, और एक कंट्रोलर terrain handling अपने हाथ में लेने के लिए ownsCollision: true लौटा सकता है (swim लौटाता है, ताकि उसका buoyancy spring foot-snap से न लड़े)।

स्वतंत्र arbitration channels। कंट्रोलर्स नामित channels (resource, stance, locomotion) में रजिस्टर होते हैं जो अलग-अलग arbitrate करते हैं और एक तय क्रम में लागू होते हैं, इसलिए stamina जैसे observers और crouch जैसे modifiers active locomotion के साथ साथ रहते हैं, बजाय control का दिखावा करके उससे इनकार करने के। Resource के writes (stamina) stance और locomotion द्वारा पढ़े जाते हैं; stance के writes (crouch capsule height) locomotion के speed cap द्वारा पढ़े जाते हैं; locomotion आखिर में चलता है और velocity write उसके पास है।

एक factory, कई बॉडीज़। createCapsuleEngine एक pure factory है जिसमें कोई singletons नहीं, इसलिए वही engine प्लेयर, एक walk-only सवारी करने लायक घोड़े, और synthetic input से खिलाए गए एक खुद-steer करने वाले NPC को चलाता है। एक बॉडी की movement शब्दावली ठीक उसका रजिस्टर किया गया कंट्रोलर सेट है, इसलिए घोड़ा चढ़ या तैर नहीं सकता क्योंकि वे कंट्रोलर्स कभी जोड़े ही नहीं गए। Mounting host स्तर पर रहता है, किसी कंट्रोलर में नहीं, क्योंकि यह दो engines में तालमेल बिठाता है जो एक-दूसरे के पार नहीं देख सकते। देखें GPU-driven LOD।

Headless, deterministic testing। engine न किसी window, document, या Three.js को छूता है, इसलिए एक Node harness इसे frame दर frame चलाता है और jump-and-land, swim thresholds, climb auto-clear, और stamina drain पर assert करता है। समान input दो बार replay करना और समान output की जाँच करना determinism साबित करता है, और एक regression test उस descent gate को pin करता है जो एक खड़ी सतह में एक horizontal walk को प्लेयर को पीछे की ओर slide करने से रोकता है।

Testable picker के साथ body-agnostic avatar binding। कंट्रोलर्स एक state-name string रिपोर्ट करते हैं और visual परत उसे एक clip से map करती है, इसलिए एक capsule को एक retargeted 3MIKE + UAL avatar से बदलना locomotion code की शून्य लाइनें छूता है। Synty POLYGON clips rig के साथ bone नाम साझा करते हैं और बिना retargeting के चलते हैं (Three.js tracks को bone नाम से bind करता है), UAL path की भारी-भरकम retargeting के उलट। clip picker को jump speed buckets, landing severity, slope-projection variants, एक हमेशा-आगे idle bridge, एक stop-bridge न्यूनतम-समय गार्ड, और एक fall-state debouncer के लिए नामित constants वाले pure functions में निकाला गया है, इसलिए locomotion का अनुभव अंदाज़े के बजाय unit-testable है।

भाग 29, कुल 30 में से। पिछला: भाग 28 - क्षितिज तक घास, और ऐसी ज़मीन जो खुद को छिपाती है अगला: भाग 30 - एक camera जो दीवारों का सम्मान करती है सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? series guide का इस्तेमाल करें। यह बताती है कि spike क्या होता है और सभी भागों को जोड़ती है।

भाग 27 ने island बनाया और उसे ऐसी ज़मीन दी जो tiled न दिखे। यह भाग उन दो चीज़ों को कवर करता है जो terrain को खाली के बजाय आबाद महसूस कराती हैं। Spike 56 घास है, वह सतह की बारीकी जो एक textured ढलान को ऐसी जगह बना देती है जहां से आप गुज़रना चाहें, और समस्या यह है कि एक मैदान को बिखरी लकीरों के बजाय एक मैदान की तरह दिखाया जाए। Spike 57 ज़्यादा draw करने का उलटा है: यह उस चीज़ को न draw करने के बारे में है जो कोई पहाड़ी पहले से ही छिपा रही है, और दिलचस्प नतीजा यह है कि इसे जांचने का तेज़ तरीका सही तरीका भी निकला।

घास जो मैदान की तरह दिखे, confetti की तरह नहीं

Spike 56 को नए tab में खोलें ↗ · View source

मूल फैसला geometric है। एक अकेली पतली नुकीली पत्ती ज़्यादातर camera कोणों से sub-pixel होती है, इसलिए आधे मिलियन सपाट पत्तियां एक मैदान के बजाय बिखरे हुए हरे confetti की तरह दिखती हैं। हल है एक cross-quad गुच्छा: तीन नुकीले quads जो local up axis के चारों ओर साठ डिग्री के अंतर पर घुमाए गए हैं, ताकि किसी भी viewing दिशा से कम से कम एक quad camera के लगभग लंबवत बैठे और हर instance वास्तविक screen क्षेत्र में लगभग तीन पत्ती-चौड़ाई को ढके। यही हरे लकीरें देखने और घास देखने के बीच का फर्क है।

एक WebGPU compute kernel हर गुच्छे को init पर एक बार रखता है। यह instance index को पांच decorrelated random streams में hash करता है, patch के अंदर एक XZ position चुनता है, उसी FBM से ground height sample करता है जिसे CPU ground mesh इस्तेमाल करता है (एक TSL port जिसमें sign-preserving mod है ताकि values बिल्कुल मेल खाएं और पत्तियां सतह पर बैठें न कि ऊपर तैरती रहें), एक central-difference normal लेता है, और हर गुच्छे की एक width, height और hue तय करता है। render की तरफ एक TSL vertex graph है जो instance matrix को पूरी तरह bypass करता है और सीधे clip space में लिखता है: यह unit cross-quad को scale करता है, Rodrigues' formula से local up को ground normal पर घुमाता है, और गुच्छे की position पर translate करता है। Distance LOD बिना किसी culling pass के मुफ्त में मिलता है, क्योंकि vertex graph गुच्छे की height को $1-\text{smoothstep}(\text{fadeNear},\text{fadeFar},\text{dist})$ से गुणा करता है, इसलिए दूर के गुच्छे शून्य height तक सपाट हो जाते हैं और fill पर खर्च होना बंद कर देते हैं। हवा गुच्छे के world XZ और time पर sin और cos के दो octaves हैं, जो horizontally लगाई जाती है और height fraction से gated होती है ताकि आधार जगह पर टिका रहे जबकि सिरे हिलें, और एक नन्हा camera-aware झुकाव हर गुच्छे को देखने वाले की ओर झुकाता है ताकि वे सपाट cards की तरह दिखने के बजाय perspectivally खुलें।

रंग का नुस्खा NedMakesGames के Breath of the Wild URP shader से लिया गया है: flat shading जिसमें पत्ती का रंग height fraction के साथ एक root tone से tip tone तक का lerp है, जहां root और tip tones खुद हर गुच्छे की hue value से दो palettes के बीच lerp होते हैं। इससे वह चितकबरा दो-रंगी रूप मिलता है जो असली BotW घास के मैदान का होता है। Diffuse सूरज के सामने ground normal को एक ambient floor के साथ इस्तेमाल करता है, क्योंकि cross-quad के per-quad normals एक stylized रूप के लिए अलग-अलग shade करने को लेकर बहुत noisy हैं। पूरा मैदान एक draw है, जो पूरी तरह GPU पर रखा और animate किया गया है।

कोई पहाड़ी क्या छिपा रही है, उसे cull करने के चार तरीके

Spike 57 को नए tab में खोलें ↗ · View source

Spike 57 उसी procedural world पर चार culling रास्ते bench करता है जिसे production client stream करता है, vertically 1.8x scale किया हुआ ताकि पहाड़ियां सचमुच foliage को occlude करें। T0 केवल distance पर है, उससे मेल खाता हुआ जो shipping chunk visibility पहले से करती है। T1 frustum culling जोड़ता है, सबसे बड़ी सस्ती जीत, जो view cone के बाहर की हर चीज़ हटा देती है। T2 एक terrain-aware horizon test जोड़ता है: आंख से हर instance तक एक ray march करो और उसे reject कर दो अगर heightmap रास्ते में कहीं भी ray से ऊपर उठती है, ताकि किसी ridge के पीछे का पेड़ cull हो जाए भले ही वह frustum के अंदर हो। T3 वही horizon test रखता है पर उसे एक max-height pyramid से accelerate करता है, और T4 पूरे distance-plus-frustum-plus-horizon test को एक TSL compute kernel में port करता है जो हर instance के लिए एक visibility scale लिखता है जिसे foliage material पढ़कर छिपे हुए vertices को collapse करता है। एक two-frame stay-visible counter उस single-frame झिलमिलाहट को smooth करता है जब camera हल्का हिलने पर कोई sample point किसी texel के ठीक अंदर या बाहर गिरता है, जिसे जानबूझकर छोटा रखा गया है क्योंकि इससे लंबा कुछ भी algorithmic bugs को ठीक करने के बजाय छिपा देता है।

pyramid वही जगह है जहां spike अपनी कीमत वसूल करता है, और सबक यह है कि test को उससे मिलाओ जो वास्तव में screen पर है। rendered terrain एक triangle mesh है जिसके vertices एक तय दो-मीटर grid पर हैं, और vertices के बीच rasterizer linearly interpolate करता है, इसलिए किसी भी rectangle के अंदर असली rendered height उसके अंदर के vertices का max है, कभी भी उनके बीच का continuous noise peak नहीं। अगर occlusion pyramid noise को किसी बारीक grid पर sample करे, तो उसे ऐसे phantom peaks मिलते हैं जो mesh कभी दिखाती ही नहीं और वह उन rays को block करने लगती है जिनके आर-पार camera साफ देख सकता है। इसलिए pyramid के base texels बिल्कुल vertex grid पर बैठते हैं, हर एक अपने चार कोने vertices का max store करता है, और ऊपरी levels पाठ्यपुस्तक जैसे 2x2 max reductions हैं, जो इसे rendered mesh के संबंध में exact बनाता है। per-step ray test के लिए code जानबूझकर mesh को bilinear interpolation से point-sample करता है, pyramid से query करने के बजाय, क्योंकि एक sub-texel AABB query पूरे texel का max लौटाती है और तीखी ridges पर height को कई मीटर बढ़ा देती है, और यही वह over-occlusion है जो दिखने वाले props को छिपा देगी।

चौंकाने वाला नतीजा यह है कि T2, brute-force reference, ही गलत वाला है। क्योंकि T2 सीधे continuous noise को point-sample करता है, यह mesh vertices के बीच के ऐसे peaks पकड़ लेता है जो render नहीं होते, इसलिए यह थोड़ा over-occlude करता है और उस foliage को छिपा देता है जिसे player सचमुच देख सकता है। pyramid रास्ता दोनों है, तेज़ भी, chunk-level tests के लिए $O(\log N)$ AABB reduction की वजह से, और geometrically ज़्यादा सही भी, क्योंकि यह केवल वही heights लौटा सकता है जिन्हें mesh सचमुच दिखाती है। यही spike का पूरा मतलब है: accelerated structure कोई quality समझौता नहीं है जिसे आप speed के लिए मान लेते हैं, यह वह version है जो हकीकत से मेल खाता है। Chunk culling हर chunk पर एक पांच-बिंदु test चलाता है (chunk की max height पर चार ऊपरी कोने और केंद्र) और हर chunk के अपने footprint को occluder set से बाहर रखता है ताकि कोई chunk खुद को कभी occlude न करे। अनुशंसित production रास्ता T4 है: instance metadata और height field को storage buffers में push करो और एक compute shader में indirect draw के साथ वही loop चलाओ, क्योंकि renderer वैसे भी WebGPU की ओर बढ़ रहा है।

इस अध्याय में संदर्भित technology

Cross-quad GPU घास। हर गुच्छे में साठ डिग्री के अंतर पर घुमाए गए तीन नुकीले quads किसी भी कोण से एक लगभग-लंबवत quad की गारंटी देते हैं, ताकि आधा मिलियन instances एक मैदान की तरह दिखें न कि sub-pixel confetti। एक compute kernel हर गुच्छे को रखता है (FBM ground height उसी sign-preserving mod से sample की गई जो CPU mesh इस्तेमाल करता है, central-difference normal, हर गुच्छे की size और hue), और एक TSL vertex graph instance matrix को bypass करके scale, normal पर Rodrigues-rotate, translate, और height-gated हवा लगाता है। Distance LOD मुफ्त है: गुच्छे $1-\text{smoothstep}(\text{fadeNear},\text{fadeFar},\text{dist})$ से शून्य height तक collapse हो जाते हैं। रंग NedMakesGames के BotW नुस्खे का अनुसरण करता है, दो hue-mixed palettes पर एक root-to-tip gradient। देखें GPU-driven LOD।

Terrain horizon occlusion culling। production world पर चार bench किए गए रास्ते: distance, साथ में frustum, साथ में एक heightmap ray test जो किसी ridge के पीछे के instances को reject करता है, साथ में एक max-height pyramid जो इसे accelerate करता है, साथ में एक TSL compute port। pyramid उसी exact दो-मीटर vertex grid पर sample करता है जिस पर mesh tessellate करता है (base texel = चार कोने vertices का max, ऊपर की ओर 2x2 max-reduce), इसलिए यह केवल वही heights लौटाता है जिन्हें rasterizer सचमुच दिखाता है।

Accelerated और सही, कोई सौदा नहीं। Continuous noise को point-sample करना (brute-force T2 रास्ता) mesh vertices के बीच ऐसे peaks ढूंढ लेता है जो कभी render नहीं होते, दिखने वाले foliage को over-occlude करता है। vertex-grid pyramid दोनों है, तेज़ ($O(\log N)$ AABB reduction) और geometrically exact, इसलिए per-step ray tests pyramid के per-texel max से query करने के बजाय mesh को bilinear-sample करते हैं, जो तीखी ridges पर heights को मीटरों बढ़ा देता। Chunk culling एक पांच-बिंदु test इस्तेमाल करता है और हर chunk के अपने footprint को बाहर रखता है ताकि वह खुद को कभी self-occlude न करे। production रास्ता metadata और height field को storage buffers में push करता है, indirect draw के साथ एक compute-shader cull के लिए।

भाग 28, कुल 29 में से। पिछला: भाग 27 - noise से बना एक island, ऐसी ज़मीन जो ज़मीन जैसी दिखे अगला: भाग 29 - एक controller, कोई भी body Series guide: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? series guide का इस्तेमाल करें। यह बताती है कि spike क्या होता है और सभी भागों को जोड़ती है।

भाग 26 ने world पर पानी रखा। यह भाग उसके नीचे की ज़मीन बनाता है, दो चरणों में जो इस बात का अक्स हैं कि कोई असली जगह कैसे बनती है। Spike 54 खुद terrain है: हाथ से नहीं गढ़ा गया बल्कि noise से उगाया गया, फिर तब तक मौसम और कटाव झेलता रहा जब तक उसमें वैसी drainage और coastline न आ गई जैसी किसी ऐसी जगह की होती है जहां सचमुच पानी बहा हो। Spike 55 उस terrain की त्वचा है: उस समस्या को हल करना जो लगभग हर procedural ज़मीन को हरा देती है, यानी कि एक tiled texture tiled ही दिखती है। दोनों मिलकर एक सवाल का जवाब देते हैं, क्या कोई creator बिना किसी artist के छुए एक भरोसेमंद island और ऐसी ज़मीन पा सकता है जो ज़मीन जैसी पढ़ी जाए, और जवाब है हां, बशर्ते आप सही recipes की नकल करें।

एक coastline जो अकेला noise आपको नहीं देगा

Spike 54 को नए tab में खोलें ↗ · Source देखें

Heightmap, Red Blob Games की recipes का अनुसरण करता है, जो छोटे-छोटे transforms का एक ढेर हैं और हर एक raw noise की किसी खास खामी को ठीक करता है। Fractional Brownian motion, Perlin noise के कई octaves को जोड़ता है ताकि terrain में चौड़ी पहाड़ियां और बारीक detail दोनों हों, लेकिन सादा FBM नरम और grid के साथ संरेखित दिखता है, इसलिए sample point को पहले domain-warp किया जाता है: आप हर coordinate को एक और noise field से खिसकाते हैं, $p^{\prime }=p+\text{noise}(p)\cdot s$, जो ridges को axis पर बंधे होने के बजाय कुछ organic रूप में मोड़ देता है। फिर redistribution, elevation को एक power $e^k$ तक उठाना, midtones को नीचे धकेलता है ताकि world में सपाट घाटियां और तीखी चोटियां हों, बजाय इसके कि सब कुछ एक ही हल्की ढलान पर बैठा रहे। वह हिस्सा जो इसे अंतहीन पहाड़ियों के बजाय एक island बनाता है, वह है radial falloff: केंद्र से euclidean दूरी निकालें, $d=min(1,\sqrt{n_x^2+n_y^2})$, और elevation को $1-d$ की ओर blend करें ताकि terrain किनारों पर समुद्र में उतर जाए। एक दूसरा स्वतंत्र noise field एक moisture map बन जाता है, जो shape के लिए कुछ नहीं करता मगर बाद में biome चरण को feed करता है।

इससे आपको एक shape मिल जाता है, लेकिन वह noise का shape है। इसमें कोई नदियां नहीं हैं, पानी से कटी कोई घाटियां नहीं, कोई sediment fans नहीं, क्योंकि इस पर कभी कुछ बहा ही नहीं। इसका हल है hydraulic erosion, जो Sebastian Lague के MIT-licensed implementation से port किया गया है। हज़ारों पानी की बूंदें यादृच्छिक जगहों पर पैदा होती हैं और ढलान से नीचे लुढ़कती हैं, हर एक के पास inertia होता है ताकि वह तीखे समकोण मोड़ न ले, तेज़ होने पर sediment उठाती है और धीमी होने या जमा होने पर उसे जमा करती है, साथ ही एक पहले से गणना किया गया circular brush हर erosion घटना को एक छोटे radius में फैला देता है ताकि कटाव एक pixel की खरोंच के बजाय smooth रहे, और evaporation जो बूंद को उसके जीवनकाल में retire कर देता है। पर्याप्त बूंदें चलाओ और terrain वह चीज़ उगा लेता है जिसे noise नकली नहीं बना सकता: ऐसी drainage networks जो मिलती हैं, घाटियां जो नीचे की ओर चौड़ी होती जाती हैं, और सपाट जगहें जहां sediment बैठ गया।

GPU पर erosion, और नदियां जो जानती हैं कि वे कहां हैं

CPU erosion सही है मगर धीमा, इसलिए spike इसे एक WebGPU compute shader में भी port करता है, और दिलचस्प हिस्सा यह है कि GPU atomics आप पर क्या मजबूर कर देते हैं। Heights को fixed-point i32 के रूप में दस लाख के scale पर store किया जाता है, क्योंकि WGSL में floats पर atomic add नहीं है, और हज़ारों बूंदों के लिए एक ही cell से बिना races के समानांतर sediment जमा करने और हटाने का इकलौता तरीका integers पर atomicAdd और atomicSub है। Fixed-point round-trip का मतलब है कि भारी समानांतर drag के तहत कोई cell कभी-कभार थोड़ा negative हो सकता है, जो हानिरहित है और readback पर clamp कर दिया जाता है। CPU version हर cell के लिए एक brush table पहले से गणना करता है, मगर ${1001}^2$ grid पर वह table लगभग 100 MB का होता है, इसलिए GPU port इसके बजाय हर बूंद के brush को मौके पर ही फिर से गणना करता है, थोड़े arithmetic के बदले बहुत सारी memory की बचत करता है। बूंदों की शुरुआती positions अब भी CPU से एक Mulberry32 generator के ज़रिए आती हैं ताकि runs deterministic रहें।

दो और passes मौसम-कटाव झेले terrain को एक पढ़ने योग्य map में बदल देते हैं। Drainage, Red Blob D8 flow-accumulation method इस्तेमाल करता है: हर cell पर बारिश की एक इकाई डालो, सभी cells को elevation के घटते क्रम में sort करो, और हर cell का जमा पानी उसके इकलौते सबसे नीचे वाले पड़ोसी को पास कर दो, ताकि पानी प्राकृतिक घाटियों के साथ ढेर हो जाए, और जिस भी cell का accumulation एक threshold पार करता है उसे river चिह्नित कर दिया जाता है। पेच यह है कि एक eroded heightmap में pits होते हैं, यानी ऐसी स्थानीय गहराइयां जिनसे नीचे की ओर कोई निकास नहीं, और pit में घुसता पानी बस रुक जाता है, जिससे accumulation टूट जाता है। इसलिए drainage चलने से पहले Planchon-Darboux pit filling हर pit को उसके सबसे नीचे वाले पड़ोसी से ज़रा ऊपर तक उठा देता है, $\text{minNeighbour}+ϵ$, बीस से कम passes तक iterate करते हुए जब तक हर cell के पास निकलने की कोई जगह न हो। आख़िर में biomes Red Blob तरीके से तय किए जाते हैं, elevation बनाम moisture पर एक two-axis lookup ताकि एक ऊंचा-और-सूखा cell rock बन जाए जबकि एक नीचा-और-गीला cell marsh, और उसके ऊपर slope-aware overrides: तीखी ढलानें moisture की परवाह किए बिना rock पर मजबूर हो जाती हैं, waterline band beach बन जाता है, और सबसे ऊंची elevations snow ले लेती हैं। नतीजा एक ऐसा island है जिसे आप एक नज़र में पढ़ सकते हैं, दो noise seeds से शुरू से आख़िर तक generate किया गया।

वह tile जो दोहराना बंद नहीं करता

Spike 55 को नए tab में खोलें ↗ · Source देखें

एक terrain को ऐसे material की ज़रूरत होती है जो एक ऐसी texture से किलोमीटरों को ढके जो कुछ ही मीटर चौड़ी है, और जिस पल आप एक tile को ज़मीन ढकने के लिए बड़ा करते हैं, आंख दोहराव पर अटक जाती है। Spike 55 एक ही geometry और lighting पर चार sampling modes का एक A/B bench है, ताकि इकलौता चर यही रहे कि texture कैसे पढ़ी जाती है। Baseline है plain: scaled UV पर एक sample, जो हर कुछ मीटर पर साफ़ tile करता है और सिर्फ़ इसलिए मौजूद है ताकि उसे हराया जा सके। मुफ़्त PBR layers Poly Haven से उनके CDN के ज़रिए आती हैं, diffuse के साथ packed ARM map (ambient occlusion, roughness, metalness) के साथ एक GL normal, सब CC0, anisotropy 8 और mipmaps के साथ load किए गए।

दिलचस्प तीन, repeat पर अलग-अलग हमले हैं। hex-linear mode, Heitz-Neyret triangle grid है: surface पर एक तिरछी triangular lattice बिछाओ, और हर fragment एक triangle के अंदर बैठता है जिसके तीनों vertices एक-एक यादृच्छिक रूप से खिसका हुआ tap लेते हैं, barycentric weights से blend किया जाता है ताकि पड़ोसी क्षेत्र texture के अलग-अलग हिस्सों को sample करें और बड़े पैमाने की tiling घुल जाए। मगर तीन taps का सादा linear blend triangle के किनारों पर उनके रंगों का औसत निकाल देता है, जिससे एक दिखाई देने वाला triangular pattern बच जाता है, ठीक वही artifact जिससे spike 48 टकराया था। hex-vp mode उसी 2018 के paper से प्रकाशित fix है: barycentric sum के बाद, texture के mean color को घटाओ, squared weights के sum के inverse square root से rescale करो ताकि variance स्थिर रहे, फिर mean को वापस जोड़ दो। इससे blend भर में contrast स्थिर रहता है ताकि triangles गायब हो जाएं, यही वजह है कि material हर load की गई texture का 1-by-1 readback करता है ताकि पहले से उसके mean color का अंदाज़ा लगा सके। चौथा mode, iq-untiled, Inigo Quilez की Texture Repetition technique 3 है: एक low-frequency variation pattern से blend किए गए दो offset taps, तीन के बजाय बस दो samples और शुरू से कोई triangle structure नहीं, सस्ता विकल्प जो टिका रहता है।

किसी भी mode के ऊपर एक वैकल्पिक triplanar projection बैठता है, यही वह चीज़ है जो उसी material को बिना खींचे एक cliff पर लपेटने देती है। एक UV के बजाय, shader तीन world-axis projections को sample करता है, X की ओर वाली surfaces YZ plane पढ़ती हैं, Y, ZX पढ़ता है, Z, XY पढ़ता है, और इन्हें abs(normalWorld) से blend करता है जिसे चार और आठ के बीच एक sharpening power तक उठाया जाता है ताकि 45-डिग्री की ढलान तीनों projections को घोलकर लुगदी न बना दे। Bench इस अदला-बदली को साफ़ कर देता है: variance-preserving hex blending गुणवत्ता का विजेता है और Quilez का two-tap performance के लिहाज़ से सजग वाला, और दोनों plain को इतने बड़े अंतर से हराते हैं कि किसी creator को कभी plain tile ship नहीं करनी चाहिए।

इस अध्याय में बताई गई technology

Recipe-stacked heightmap generation. Red Blob Games की recipes raw noise को terrain में बुनती हैं: organic ridges के लिए domain-warped FBM ($p^{\prime }=p+\text{noise}(p)\cdot s$), सपाट घाटियों और तीखी चोटियों के लिए $e^k$ redistribution, और किनारों को समुद्र में उतारकर island बनाने के लिए $1-d$ की ओर blend किया गया euclidean radial falloff। एक दूसरा noise field biome assignment के लिए moisture map है। देखें landscape generation।

Hydraulic erosion, CPU और GPU. Sebastian Lague का droplet model (inertia, carrying capacity, एक पहले से गणना किया गया circular deposit brush, evaporation) असली drainage काटता है जिसे noise नकली नहीं बना सकता। WebGPU compute port heights को दस लाख के scale पर fixed-point i32 के रूप में store करता है ताकि बूंदें एक ही cell को समानांतर रूप से atomicAdd/atomicSub कर सकें, ${1001}^2$ पर ~100 MB की table से बचने के लिए हर बूंद के brush को मौके पर फिर से गणना करता है, और शुरुआती positions को एक deterministic Mulberry32 generator से seed करता है।

Pit filling के साथ D8 drainage. Red Blob D8 flow accumulation हर cell पर बारिश की एक इकाई डालता है, cells को घटते elevation के क्रम में sort करता है, और हर cell का पानी उसके सबसे नीचे वाले पड़ोसी को पास करता है, एक threshold से ऊपर वाली नदियों को चिह्नित करते हुए। Planchon-Darboux pit filling पहले हर स्थानीय गहराई को $\text{minNeighbour}+ϵ$ तक उठाता है (बीस से कम passes तक iterate करते हुए) ताकि पानी कभी फंसे नहीं और accumulation जुड़ा रहे। एक two-axis elevation-by-moisture lookup biomes तय करता है, slope overrides के साथ जो cliffs पर rock, waterline पर beach, और चोटियों पर snow मजबूर करते हैं।

Texture tiling को चार तरीकों से तोड़ना. एक जैसी geometry और lighting पर: plain (एक tap, साफ़ tile करता है), hex-linear (Heitz-Neyret triangle grid, linear blend एक triangle pattern छोड़ देता है), hex-vp (EGSR 2018 §3.3 variance-preserving fix जो mean घटाता है, squared weights के inverse-sqrt से rescale करता है, और mean को फिर से जोड़ता है, हर texture के लिए एक 1×1 mean readback चाहिए), और iq-untiled (Inigo Quilez two-tap technique 3)। Triplanar projection तीन world-axis planes को sample करता है जिन्हें abs(normalWorld) से 4-8 की power तक blend किया जाता है ताकि cliffs न खिंचें। variance-preserving गुणवत्ता पर जीतता है, two-tap लागत पर। देखें terrain materials।

29 में से भाग 27। पिछला: भाग 26 - पानी बनाने के तीन तरीके अगला: भाग 28 - क्षितिज तक घास, और ऐसी ज़मीन जो खुद को छुपा लेती है Series guide: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? सीरीज़ गाइड इस्तेमाल करें। यह बताता है कि spike क्या है और सारे भागों को link करता है।

भाग 25 ने avatars को कपड़े पहनाए। यह भाग पानी के बारे में है, और इसमें तीन spike हैं क्योंकि पानी वही surface है जहां एक सस्ता shortcut और सही जवाब screenshot में बिलकुल एक जैसे दिखते हैं और motion में पूरी तरह अलग। Spike 51 reflection को screen-space तरीके से बनाता है, वो लुभावना तरीका, और सीधे अपनी built-in सीमा से टकरा जाता है। Spike 52 उस method पर switch करता है जिसे हर शिप होने वाला game असल में इस्तेमाल करता है। Spike 53 एक तैयार water library डालकर देखता है कि "done" हमसे कितनी दूर है। तीनों एक ही refraction layer share करते हैं, इसलिए पहले दो के बीच सिर्फ एक चीज़ बदलती है: reflection कैसे compute होता है।

उसी screen से reflection जो आपके पास पहले से है

Spike 51 को नए tab में खोलें ↗ · Source देखें

Screen-space reflection उसी frame को दोबारा इस्तेमाल करता है जिसे आप पहले ही render कर चुके हैं। हर water pixel के लिए, आप view ray को surface से reflect करते हैं, उस reflected ray को depth buffer के आर-पार march कराते हैं, और जब ray किसी record की गई surface के पीछे से गुज़रता है तो आपको मिल गया कि पानी क्या reflect करता है, सीधे color buffer से sample किया हुआ। यह port three.js की SSRNode line को line-by-line follow करता है, जो खुद lettier के SSR primer को follow करती है। March screen space में एक DDA walk है: ray के start और end को pixel coordinates में project करें और जो भी axis लंबा हो उसके साथ step करें, हर pixel पर एक tap। हर step पर reflected ray की depth को perspective-correct interpolation चाहिए, $\frac{1}{1/z_0+s(1/z_1-1/z_0)}$, क्योंकि view-Z को linearly interpolate करना सीधे-सीधे गलत है और गलत जगह पर hits पैदा करता है।

दो चीज़ें इसे slideshow की जगह इस्तेमाल करने लायक बनाती हैं। Coarse march 64 steps पर capped है, क्योंकि एक लंबा ray जो हज़ार pixels के पार project होता है वरना हर fragment के लिए सैकड़ों iterations चला देता, और दस लाख-fragment वाला water plane गुणा सैकड़ों iterations गुणा कुछ texture samples एक 30 fps scene है। Quality उस cap के अंदर effective stride को control करती है, iteration count को नहीं। और चूंकि एक capped coarse march दिखने वाली stair-step banding छोड़ता है, इसलिए एक छह-iteration वाला binary refinement आखिरी miss और hit के बीच के interval को bisect करता है, जो 64x sub-step accuracy है, इतनी कि पड़ोसी water fragments उसी coarse hit position पर lock होना बंद कर देते हैं। एक आखिरी point-to-line distance check पुष्टि करता है कि candidate सचमुच reflection ray पर है, न कि सिर्फ उसी depth पर, एक thickness tolerance के साथ जो उस depth पर एक pixel की view-space width के हिसाब से auto-scale होती है, पास में tighter और दूर में looser।

इस spike का ईमानदार हिस्सा उसके अपने comments में लिखा है: SSR उस चीज़ को reflect नहीं कर सकता जिसे main camera ने कभी sample नहीं किया। किसी पेड़ का नीचे का हिस्सा, off-screen कुछ भी, occluded कुछ भी, इनमें से कुछ भी buffers में मौजूद नहीं है, इसलिए reflection में दिख ही नहीं सकता। यही वो "wrong-side information loss" है जिसे कितनी भी march quality ठीक नहीं करती, और यही ठीक वो वजह है जिसके लिए अगला spike मौजूद है।

वो mirror जो झूठ नहीं बोल सकता

Spike 52 को नए tab में खोलें ↗ · Source देखें

एक planar reflection scene को दूसरी बार render करता है, water plane के आर-पार mirror की गई एक camera से, एक offscreen target में, और water shader उस target को sample करता है। यह canonical pattern है, जिसे UE5 Water, three.js की अपनी WaterMesh, ABZÛ, और Sea of Thieves सब इस्तेमाल करते हैं, क्योंकि इसके पास draw करने के लिए scene का हर pixel मौजूद है, उस geometry समेत जिसे SSR कभी देख नहीं सकता। TSL में यह लगभग anticlimactic है: reflector() mirror की गई helper camera और उसका render target allocate करता है, आप उसके target को mesh में जोड़ते हैं ताकि वह हर frame update हो, और आप उसका color sample करते हैं। जब बाद में waves आती हैं, तो reflection reflector के UV node में एक distortion offset जोड़कर wobble करता है, जो ठीक वही line है जो WaterMesh इस्तेमाल करती है।

record करने लायक bug safety net में था, mirror में नहीं। एक पुराने version ने reflector के output को एक procedural sky के साथ fallback के तौर पर blend किया, reflected color की magnitude के हिसाब से weighted, इस theory पर कि करीब-शून्य reflection का मतलब है target में वहां कुछ नहीं था। पर एक dark canopy की छाया की magnitude भी कम होती है, इसलिए clamp कभी full strength तक नहीं पहुंचा और वो असल में dark pixels bright sky के साथ mix हो गए। user ने जो symptom पकड़ा वह सटीक था: debug mode में raw mirror target perfect dark पेड़ दिखा रहा था, जबकि composed render में washed-out reflections थे, और diagnosis यह था कि shader "dark colors को गायब कर देता है।" Fix था deletion। Reflector target पहले frame के बाद reliable रहता है, इसलिए fallback की कोई ज़रूरत ही नहीं। दोनों spike नीचे वही refraction share करते हैं: surface के पीछे का scene sample करें, reconstruct करें कि हर pixel waterline से कितना नीचे बैठा है, और per-channel Beer-Lambert extinction लगाएं ताकि red कुछ ही meters में मर जाए जबकि blue बना रहे, एक sky mask के साथ ताकि far-plane backdrop fog न हो जाए। Schlick Fresnel refraction को तब mix करता है जब आप सीधे पानी में नीचे देखते हैं और reflection को तब जब आप उसके पार देखते हैं।

पूरा हो चुका कैसा दिखता है

Spike 53 को नए tab में खोलें ↗ · Source देखें

Spike 53 build-versus-buy check है। यह threejs-water-pro को वैसा ही डालता है जैसा वह ship होता है, अपने tropical preset, default ocean clipmap, camera tracking, और Rayleigh sky के साथ, और वही island glTF load करता है जो library का अपना demo इस्तेमाल करता है। मकसद है एक hand-rolled flat-water shader और एक पूरे ocean system के बीच का फ़र्क़ देखना, और यह फ़र्क़ बड़ा है: इस वाले में एक buoyancy system है जो किसी ship के hull के नीचे कई points पर wave height sample करता है ताकि वह सिर्फ ऊपर-नीचे होने की जगह pitch और roll करे, एक wake generator, shoreline और surface foam, और एक mask pass जो ship के hull के अंदर water rendering को दबा देता है ताकि ripples deck के आर-पार न रिसें।

इसे integrate करने से वो किस्म का detail सामने आया जो आप किसी library को इस्तेमाल करके ही सीखते हैं, उसका README पढ़कर नहीं। Foam textures को preset में filename से reference किया जाता है पर उन्हें load करना consumer का काम है, और उनके बिना shoreline breaking surf की जगह एक सख्त waterline edge जैसा दिखता है। Island ऐसे positioned है कि उसकी underwater geometry ocean floor के पार नीचे गिर जाती है, जिससे library का floor mesh model के बाहरी ring को बिना किसी दिखने वाले plane edge के occlude कर देता है, जो library का intended pattern है: एक 3D model लाओ, terrain synthesize मत करो। और antialiasing renderer पर जानबूझकर off है, एक post-process FXAA pass के पक्ष में, क्योंकि MSAA depth-aware atmospheric fog चलने से पहले edge fragments को background के against blend कर देता है, जहां भी geometry fog से मिलती है वहां एक पतला dark fringe छोड़ देता है। Aliasing को fog से पहले की जगह fog के बाद resolve करने से वह fringe हट जाता है। यह जो de-risk करता है वह खुद decision है: एक production ocean एक बड़ा, specialized system है, और जिन cases में हमें एक चाहिए, वहां एक maintained library अपनाना wakes और buoyancy और foam को शुरू से दोबारा बनाने से बेहतर है, जबकि spike 52 का planar-mirror shader उस छोटे inland water के लिए सही जवाब बना रहता है जिसे कोई creator अपनी दुनिया में रखता है।

इस chapter में reference की गई technology

Screen-space reflection water. एक reflected view ray DDA के ज़रिए screen space में depth buffer को march करता है, perspective-correct 1/z interpolation का इस्तेमाल करते हुए, per-fragment cost को bound करने के लिए एक hard step cap, और एक capped march जो banding छोड़ता है उसे हटाने के लिए एक binary refinement pass। depth-scaled thickness वाला एक point-to-line confirmation false hits को reject करता है। Method की hard limit यह है कि यह सिर्फ वही geometry reflect कर सकता है जिसे main camera पहले ही sample कर चुका है, इसलिए off-screen और wrong-side surfaces कभी नहीं दिखतीं। देखें terrain materials।

Planar mirror reflection. Water plane के आर-पार mirror की गई एक helper camera scene को एक offscreen target में render करती है जिसे water shader sample करता है, जो pixel-perfect reflections देता है, उस geometry समेत जिसे SSR देख नहीं सकता। यह वही pattern है जो UE5 Water और three.js WaterMesh इस्तेमाल करते हैं, wave distortion को reflector के UV node पर एक offset के तौर पर लगाया जाता है। एक magnitude-weighted sky fallback ने गलती से dark reflection pixels मिटा दिए; reflector target पहले frame के बाद reliable रहता है, इसलिए fallback हटाना ही fix था।

Beer-Lambert depth tint refraction. दोनों shaders surface के पीछे का scene sample करते हैं, हर backdrop pixel की waterline से नीचे की depth reconstruct करते हैं, और per-channel exponential extinction (red meters में मरता है, blue बना रहता है) लगाते हैं जो एक water-fog color की तरफ composite होता है, एक sky mask के साथ ताकि far plane fog न हो। Schlick Fresnel normal incidence पर refraction को grazing angles पर reflection के साथ blend करता है।

एक production water library अपनाना. threejs-water-pro एक ocean clipmap, Rayleigh sky, ship के pitch और roll के लिए multi-point buoyancy, wakes, foam, और एक hull mask pass ship करती है। Consumer-side के details मायने रखते हैं: foam textures को explicitly load करना ज़रूरी है, island की underwater geometry को ocean floor के पार नीचे गिरना चाहिए ताकि floor उसके edges को occlude करे, और antialiasing को MSAA की जगह एक post-process FXAA pass के तौर पर चलना चाहिए ताकि geometry edges पर एक dark fog fringe से बचा जा सके।

29 में से भाग 26। पिछला: भाग 25 - एक skeleton, हर outfit अगला: भाग 27 - noise से एक island, ज़मीन जो ज़मीन जैसी दिखे सीरीज़ गाइड: /blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

एक जंगल उन सबसे बुरी चीज़ों में से एक है जो आप किसी GPU से render करने को कह सकते हैं। हर पत्ता एक textured quad होता है जिसमें से एक alpha mask काटा गया होता है। ऐसे दर्जनों quads हर view ray के साथ एक-दूसरे के ऊपर ढेर हो जाते हैं। Rasterizer को पहले से जानने का कोई तरीका नहीं होता कि कौन से fragments alpha test पास करेंगे, इसलिए standard early-Z optimization जो opaque scenes को बचाता है, ज़्यादातर बंद हो जाता है। नतीजा यह कि एक ही screen pixel frame के स्थिर होने से पहले पूरे leaf shader को 10 या 15 बार चला सकता है। यही foliage overdraw है, और यह पिछले दशक में आए किसी भी game में एक open-world frame का सबसे महंगा हिस्सा है।

अच्छी खबर यह है कि यह एक हल हो चुकी समस्या है। इस मायने में नहीं कि किसी ने इसे एक ही trick से ठीक कर दिया, बल्कि इस मायने में कि सात या आठ techniques का एक stack है जो मिलकर एक घने जंगल में effective overdraw को 8-15x से घटाकर 1-2x कर देता है। हर आधुनिक engine इस stack का कोई न कोई रूप ship करता है। आइए देखें इसमें क्या है, हर टुकड़ा क्यों मौजूद है, और हर एक के canonical references क्या हैं।

1. Foliage overdraw इतना तकलीफदेह क्यों है

एक आम opaque scene में GPU early depth rejection करता है: pixel shader के चलने से पहले ही hardware मौजूदा depth buffer को देखता है और उन fragments को skip कर देता है जो पहले से किसी चीज़ के पीछे हैं। यह असल में मुफ्त है और यही घनी geometry की लागत को संभाले रखता है।

Alpha-tested foliage इसे तोड़ देता है। Fragment shader को असल में चलना पड़ता है ताकि alpha texture का मूल्यांकन हो और masked-out pixels पर discard (या clip) call हो। Hardware यह नहीं जान सकता कि कोई fragment मारा जाएगा या नहीं, जब तक shader चल न जाए, इसलिए ज़्यादातर GPUs पर किसी shader में कहीं भी discard का इस्तेमाल उस draw call के लिए early-Z को पूरी तरह बंद कर देता है। Tile-based GPUs (mobile, M-series, कुछ consoles) पर यह पूरे frame के लिए Hi-Z और depth compression को बंद कर सकता है। Pixel shader हर उस triangle के लिए एक बार चलता है जो किसी pixel को ढकता है, और उनमें से ज़्यादातर मूल्यांकन एक discard के साथ खत्म होते हैं।

एक ही screen pixel के सामने 10 leaf quads ढेर कर दें और leaf shader 10 बार चलता है। इसे 40 लाख pixels से गुणा करें और लागत क्रूर हो जाती है। Marco Salvi का लेख To Early-Z, or Not To Early-Z hardware स्तर पर यह क्यों होता है इसका सबसे सहज दौरा है, और अगर आपने पहले कभी इसके बारे में नहीं सोचा तो शुरुआत के लिए यही सही जगह है।

2. Masked geometry के लिए depth prepass

सबसे बड़ी अकेली जीत, और वह technique जो हर आधुनिक engine ship करता है, foliage draw को दो passes में बाँटना है। पहला pass सिर्फ़ depth लिखता है, एक न्यूनतम shader के साथ जो alpha test करता है, masked pixels को discard करता है, और और कुछ नहीं लिखता। दूसरा pass पूरे material को render करता है जिसमें depth testing "equal" पर सेट होता है और depth writes बंद होते हैं। अब हर दिखने वाला pixel पूरे BRDF को ठीक एक बार shade करता है, चाहे उसके पीछे कितने भी leaf quads ढेर हों।

यह दोगुना काम लगता है क्योंकि आप एक ही triangles को दो बार छूते हैं, लेकिन prepass shader इतना सस्ता है (एक texture sample, एक discard, एक depth write) कि main pass पर हुई बचत इस अतिरिक्त लागत को बौना कर देती है। एक घने जंगल में main pass पूरे leaf shader को प्रति pixel 10-15 बार चलाने से घटकर ठीक एक बार चलाने पर आ जाता है।

Unreal, Frostbite, Decima, और आधुनिक Rage तथा Dunia शाखाएं सभी यह करती हैं। यही वह मुख्य वजह भी है कि इन engines में masked materials अब भी translucent materials से सस्ते हैं।

गहराई में:

• Pettineo, To Early-Z, or Not To Early-Z (discard Hi-Z और early-Z के साथ कैसे interact करता है, इसका canonical लेख)।
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, Frostbite का depth-prepass और prepass-driven culling architecture)।
• Sanders, Between Tech and Art: The Vegetation of Horizon Zero Dawn (GDC 2018, Decima के two-pass foliage rendering के साथ)।
• Persson, A couple of notes about Z (depth-equal testing और prepass अर्थशास्त्र की अब भी सबसे साफ व्याख्याओं में से एक)।

3. आक्रामक LODs और octahedral imposters

दूसरी सबसे बड़ी जीत है पत्तों को बिल्कुल भी न draw करना जब आपको ज़रूरत न हो। Foliage assets कई LOD tiers के साथ ship होते हैं। सबसे नज़दीकी अलग-अलग leaf cards वाला पूरा mesh होता है। मध्यम दूरी पर पत्ते घने composite cards में सिमट जाते हैं (30 पत्तों का गुच्छा एक ही silhouette वाला 1 textured card बन जाता है)। एक दूरी की सीमा से परे, पूरा पेड़ एक imposter बन जाता है: geometry का एक छोटा टुकड़ा जो पेड़ के कई कोणों से pre-rendered views से textured होता है।

आधुनिक imposter format है octahedral imposter: geometry का एक 8-फलकीय टुकड़ा जो octahedral mapping का इस्तेमाल करके एक sphere के points से कैद किए गए views के atlas से textured होता है। Runtime पर shader camera direction के आधार पर सबसे नज़दीकी दो या तीन pre-rendered views चुनता है और उनके बीच blend करता है। नतीजा कुछ-triangle का एक stand-in होता है जो हर कोण से 3D दिखता है और इसमें सही shading, normal maps, और यहां तक कि wind animation हो सकता है। Ryan Brucks का implementation, जो मूल रूप से एक community plugin था और अब Unreal का हिस्सा है, यहां reference है। Microsoft Flight Simulator के अरबों-पेड़ वाले जंगल असल में camera को छोड़कर हर जगह octahedral imposters हैं।

बड़ी संरचनात्मक जीत यह है कि imposters दूरी पर opaque या लगभग-opaque होते हैं। 30-पत्ते वाला composite card 30 quads के बजाय एक ही masked quad है। पूरे-पेड़ का imposter कुछ फलक है, हज़ारों नहीं। Far-field overdraw लगभग शून्य पर सिमट जाता है।

गहराई में:

• Brucks, Octahedral Impostors (canonical reference, math और UE implementation के साथ)।
• Halen, Octahedral Impostors in Unreal Engine (एकीकृत UE workflow)।
• Häggström, Real-Time Rendering of Vegetation (LOD chains, imposters, और उनके पीछे के math को कवर करने वाला एक साफ thesis)।
• Crytek, SpeedTree integration in CryEngine 3 (GPU Gems 3, अब भी tree LOD chains पर सबसे अच्छा primer)।

4. Cluster और GPU-driven culling

depth prepass के बावजूद, prepass की खुद की एक लागत होती है: इसे अब भी हर दिखने वाले (या संभावित रूप से दिखने वाले) पेड़ के हर triangle को छूना पड़ता है। आधुनिक engines उस लागत को GPU-driven cluster culling से नीचे धकेलते हैं, जो rasterizer के देखने से पहले ही triangles के पूरे समूहों को फेंक देता है।

Pipeline ऐसा दिखता है: हर mesh को 64 या 128 triangles के clusters में पहले से बाँट दिया जाता है, जिनके पास एक tight bounding box और normals का एक cone होता है। Render time पर एक compute shader instance list पर चलता है, हर instance का frustum-test करता है, फिर हर दिखने वाले instance के हर cluster का frustum-test करता है, फिर हर बचे हुए cluster का पिछले frame के depth pyramid के विरुद्ध Hi-Z occlusion-test करता है। पेड़ों की पूरी शाखाएं जो किसी पहाड़ी के पीछे या किसी दूसरे पेड़ के सामने छिपी हैं, किसी भी vertex shader के चलने से पहले cull हो जाती हैं। Output "इन clusters को draw करो" arguments की एक compact list होती है जो सीधे एक ही DrawIndirect call में दी जाती है।

यही वह चीज़ है जो 10,000 पेड़ों के जंगल को सेकंडों के बजाय milliseconds में render कराती है। Ubisoft की Assassin's Creed Unity talk ने इस pipeline को production रूप में पेश किया (20-40% triangles culled, 30-80% shadow triangles culled, पिछली पीढ़ी की तुलना में screen पर 10x ज़्यादा instances), और Wihlidal की Frostbite talk ने इसे और आगे ले गई। UE5 Nanite इस दिशा का दिखने वाला अंतिम रूप है: pixel तक cluster culling।

गहराई में:

• Haar और Aaltonen, GPU-Driven Rendering Pipelines (SIGGRAPH 2015, मूलभूत Assassin's Creed Unity talk)।
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, Frostbite का GPU-driven prepass)।
• Karis, Stubbe, Wihlidal, A Deep Dive into Nanite Virtualized Geometry (SIGGRAPH 2021, meshlet granularity पर cluster culling)।
• Liktor, Geometry Rendering Pipeline Architecture at Activision (cluster culling का Call of Duty संस्करण, 2021)।

5. Front-to-back instance और cluster sorting

एक बार prepass अपना काम कर रहा हो, तो क्रम मायने रखने लगता है। Prepass depth लिखता है, लेकिन सिर्फ़ उन fragments के लिए जो alpha test पास करते हैं। अगर आप जंगल का पिछला हिस्सा पहले और अगला हिस्सा आखिर में draw करें, तो हर front fragment एक back fragment को overwrite करता है, और prepass shader फिर भी back के लिए चलता है। अगर आप front-to-back draw करें, तो हर अगला draw छोटे values के साथ depth buffer को और भरता है, और Hi-Z shader के चलने से पहले back fragments को और-और ज़्यादा reject कर देता है।

यही वजह है कि लगभग हर आधुनिक engine prepass जारी करने से पहले foliage instances को camera से दूरी के हिसाब से sort करता है। Sort सस्ता है (radix sort का इस्तेमाल करके GPU पर कुछ लाख instances), और यह prepass को खुद ही self-pruning operation में बदल देता है। Cluster-level culling इसी वजह से meshlet granularity पर sort करता है। Depth prepass और front-to-back ordering वह जोड़ी है जहां हर एक अच्छा है और दोनों का मेल शानदार है।

गहराई में:

• Persson, Depth in-depth (depth-buffer ordering, prepass अर्थशास्त्र, और Hi-Z व्यवहार पर architectural notes)।
• Giesen, A trip through the graphics pipeline (Hi-Z reject rate draw order पर कैसे निर्भर करता है इसकी गहरी तकनीकी व्याख्या)।
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, Frostbite का GPU-side instance sort शामिल है)।

6. Dithered LOD transitions और hashed alpha

दूसरा बड़ा जाल है fading। दो LODs के बीच transition करने का (या camera के पास आने पर किसी instance को fade in या out करने का) भोला तरीका alpha blending है। लेकिन blended geometry depth buffer में नहीं लिख सकती, जो हर fading पेड़ को धीमे translucent path में धकेल देता है और prepass को तोड़ देता है। हल है geometry को masked path में रखना और fade को alpha test के अंदर करना।

दो मुख्य techniques:

• Dithered LOD transitions एक 4x4 या 8x8 Bayer pattern (या एक screen-space blue-noise texture) sample करती हैं और उसे प्रति-pixel cutoff modifier के रूप में इस्तेमाल करती हैं। 50% blend वाले पेड़ में बचे हुए pixels का एक checkerboard होता है; गायब pixels अगले LOD के पूरक checkerboard से भर जाते हैं। TAA दो या तीन frames में checker को एक smooth blend में हल कर देता है। सस्ता, स्थिर, engine की हर बाकी चीज़ के साथ blend होता है।
• Hashed alpha testing (Wyman & McGuire, I3D 2017) तय 0.5 alpha threshold की जगह [0,1) में एक प्रति-pixel hashed threshold रखता है। दूर की alpha geometry जो सामान्यतः पूरी तरह गायब हो जाती (क्योंकि mipmapped alpha 0.5 से नीचे चला जाता है) बचे हुए pixels का एक स्थिर बिखराव बनाए रखती है। TAA फिर से सफाई करता है।

दोनों techniques foliage को opaque/masked path में रखती हैं जहां depth prepass काम करता है, इसलिए किसी चीज़ को सिर्फ़ fade in करने के लिए आपको पूरी translucent rendering लागत नहीं चुकानी पड़ती। Alpha to coverage इसी विचार का MSAA-युग वाला रिश्तेदार है: alpha को एक sub-pixel coverage mask में बदलो, masked path छोड़े बिना आंशिक transparency पाओ। पेच यह है कि A2C असल में सिर्फ़ MSAA के साथ चमकता है, जिसे ज़्यादातर आधुनिक deferred renderers अब इस्तेमाल नहीं करते।

गहराई में:

• Wyman और McGuire, Hashed Alpha Testing (I3D 2017, canonical hashed-alpha paper)।
• Castaño, Computing Alpha Mipmaps (The Witness blog, alpha-tested textures को mip करने का सही तरीका ताकि दूर के पेड़ गायब न हों)।
• Yuksel, Alpha Distribution for Alpha Testing (alpha mipmaps पर एक और हालिया सुधार)।
• NVIDIA, Anti-Aliased Alpha Testing (A2C, hashed alpha, और dithered विकल्पों का एक survey)।

7. Masked pixels पर shading लागत घटाना

एकदम सही prepass और एकदम सही culling के बावजूद, आपको अब भी हर दिखने वाले foliage pixel को एक बार shade करना पड़ता है। Engines वह लागत भी घटाते हैं:

• सस्ता BRDF। Foliage matte होता है और इसे असल में पूरे Cook-Torrance specular path की ज़रूरत नहीं। एक wrapped-Lambertian diffuse और एक एक-लाइन specular अनुमान काफी है।
• कम-frequency normal maps। पत्ते पहले से ही noisy हैं। एक 256x256 normal map आम viewing distances पर 1024x1024 जैसा ही दिखता है और bandwidth बचाता है।
• No parallax, no anisotropy, no clearcoat। पत्तों के लिए PBR feature menu बंद कर दिया जाता है।
• Two-sided thin transmission पूरे subsurface scattering के बजाय। पत्ते पीछे से रोशनी transmit करते हैं, लेकिन आप इसे एक ही back-light dot product से नकली बना सकते हैं।
• कुछ engines में Half-resolution shading। Foliage को 1/4 या 1/2 pixel rate पर shade किया जाता है और upscale किया जाता है। TAA का stochastic noise resampling को छिपा देता है।
• masked materials पर default रूप से detail textures और decals को skip करें।

इनमें से हर एक अकेले एक छोटी जीत है। मिलकर, masked-foliage shaders समकक्ष opaque material से 2-3x तेज़ चल सकते हैं।

गहराई में:

• Lagarde और de Rousiers, Moving Frostbite to Physically Based Rendering 3.0, foliage और translucency पर sections (SIGGRAPH 2014, thin two-sided materials के लिए canonical PBR adjustments)।
• Jimenez, Next Generation Character Rendering (wrapped-Lambertian और back-translucency math, मूल रूप से त्वचा के लिए पर पत्तों में व्यापक रूप से port किया गया)।
• Sanders, Between Tech and Art: The Vegetation of Horizon Zero Dawn (GDC 2018, Decima के foliage shader सरलीकरणों के साथ)।

8. Masked materials के लिए visibility buffers और Nanite

overdraw का सबसे साफ जवाब है shading को rasterization से पूरी तरह अलग कर देना। एक visibility buffer geometry को एक पतले buffer में rasterize करता है (प्रति pixel सिर्फ़ triangle ID और instance ID), फिर पूरे material को एक deferred pass के रूप में चलाता है जो visibility buffer पढ़ता है और हर pixel को ठीक एक बार shade करता है। संरचना के हिसाब से ही, shading stage पर कोई overdraw नहीं होता। Burns और Hunt के 2013 के paper ने यह पेश किया; UE5 Nanite production-quality साकार रूप है, जिसमें UE 5.5 से masked foliage भी शामिल है।

Nanite का मोड़ यह है कि यह cluster-level virtualized geometry के साथ ऐसा करता है, इसलिए rasterizer खुद sub-pixel triangles के लिए एक software path पर चलता है और overdraw को सीमित रखता है। Nanite में masked materials को "programmable raster" feature की ज़रूरत होती है: alpha test visibility-buffer pass के दौरान चलता है, लेकिन material shading अब भी deferred resolve में प्रति दिखने वाले pixel एक बार होती है। नतीजा यह कि बहुत घना Nanite foliage, जो कभी masked materials पर धीमा होने के लिए बदनाम था, अब opaque के बराबर या उससे भी सस्ता है, क्योंकि shading समय पर overdraw शून्य है। एक tradeoff है: अक्सर low-poly masked-card पेड़ों को रखने के बजाय high-poly opaque tree geometry को Nanite से धकेलना बेहतर होता है, क्योंकि masked path programmable-raster लागत जोड़ता है।

गहराई में:

• Burns और Hunt, The Visibility Buffer: A Cache-Friendly Approach to Deferred Shading (JCGT 2013, मूल paper)।
• Karis, Stubbe, Wihlidal, A Deep Dive into Nanite Virtualized Geometry (SIGGRAPH 2021, production architecture)।
• Epic, Nanite GPU Driven Materials (GDC 2024, masked-material और programmable-raster pipeline के साथ)।
• Notes from "Nanite GPU Driven Materials" (उसी talk का एक साफ तीसरे-पक्ष का walkthrough)।

9. Foliage के लिए अलग shadow representations

Alpha-tested foliage के लिए shadow maps किसी भी open-world frame में दूसरी सबसे महंगी shadow समस्या है, बड़े cascades के बाद। हर cascade को अपने depth prepass की ज़रूरत होती है, हर prepass alpha test चलाता है, और लागत 4 cascades और दर्जनों light frusta में तेज़ी से ढेर हो जाती है। इसलिए ज़्यादातर engines foliage shadows को उस तरह render नहीं करते जैसे वे foliage color render करते हैं।

आम विकल्प:

• Mesh distance-field shadows (UE Lumen, custom engines)। हर mesh के पास एक precomputed signed distance field होता है। SDF के बीच से एक छोटा cone trace alpha-tested mesh को छुए बिना एक soft shadow देता है। पेड़ों के लिए खास तौर पर अच्छा क्योंकि SDF canopy silhouette को एक ही ठोस blob के रूप में कैद करता है और प्रति-पत्ता detail को नज़रअंदाज़ कर देता है।
• Foliage के लिए कम-resolution cascades। Foliage shadows एक half-resolution slice में जाते हैं और edge-aware filtering के साथ up-sample होते हैं। आंख resolution गिरावट को नहीं देखती क्योंकि shadows पहले से ही soft हैं।
• MSAA के साथ alpha-to-coverage shadow maps। जिन engines के shadow path में अब भी MSAA है, उन पर A2C पूरी alpha test लागत के बिना smooth-edged foliage shadows देता है।
• तने और बड़ी शाखाओं के लिए capsule shadows, canopy के लिए distance-field, पूरी alpha test सिर्फ़ सबसे नज़दीकी cascade पर। अलग-अलग दूरियों के लिए अलग-अलग representations, lighting pass में blend।
• WPO disable distance। Wind-driven World Position Offset एक threshold से परे मार दिया जाता है ताकि cached shadow data frames में valid रहे। UE के Virtual Shadow Maps इस पर बहुत भरोसा करते हैं।

गहराई में:

• Epic, Distance Field Soft Shadows in Unreal Engine (mesh DF shadows के लिए canonical UE reference)।
• Wright, Lumen: Real-Time Global Illumination in Unreal Engine 5 (SIGGRAPH 2022, foliage के लिए Lumen के mesh-SDF integration के साथ)।
• Epic, Virtual Shadow Maps (आधुनिक UE5 shadow architecture, foliage-विशिष्ट WPO disable और caching नियमों के साथ)।
• Persson, Practical Cascaded Shadow Maps (अब भी canonical CSM reference, alpha-tested casters पर notes के साथ)।

10. Wind, animation, और shadow caching

एक सूक्ष्म संबंधित समस्या: ज़्यादातर foliage हिलता है। Wind-driven vertex animation (UE में World Position Offset, Frostbite और Decima में समकक्ष) का मतलब है कि foliage geometry frame दर frame स्थिर नहीं रहती, जो shadow caching और reprojection को तोड़ देता है। आधुनिक engines इससे दो तरीकों से लड़ते हैं:

• दूरी पर WPO को सीमित करें। एक threshold से परे wind animation का amplitude सहजता से शून्य हो जाता है। आंख वैसे भी उतनी दूर के झूलने को नहीं देख सकती, और shadow caches valid रहते हैं।
• Wind को cluster bounds में bake करें। Cluster bounding boxes अधिकतम WPO offset से फुला दिए जाते हैं ताकि culling बिना प्रति frame re-upload के conservative बनी रहे।
• Per-instance phase offsets। एक जैसे पेड़ wind phase को offset करने के लिए एक प्रति-instance random seed का इस्तेमाल करते हैं, ताकि एक जंगल प्रति पेड़ अलग animation की कीमत चुकाए बिना एक साथ कदम-से-कदम न झूले।

यह वह तरह का detail है जो technique lists में नहीं दिखता पर असल में 3 ms जंगल और 9 ms जंगल के बीच का फर्क है।

गहराई में:

• Sanders, Between Tech and Art: The Vegetation of Horizon Zero Dawn (GDC 2018, Decima wind-animation pipeline और shadow caching के साथ)।
• McAuley, Rendering the World of Far Cry 4 (GDC 2015, vegetation के लिए wind-grid sampling शामिल है)।
• Epic, Foliage and Virtual Shadow Maps (WPO disable distance और VSM caching पर UE5 community मार्गदर्शन)।

11. संयुक्त गणित

इनमें से कोई trick रामबाण नहीं है। दिलचस्प बात यह है कि जब आप इन्हें एक के ऊपर एक रखते हैं तो क्या होता है:

• एक घने जंगल scene पर एक भोला masked-foliage pass 8-15x effective overdraw मापता है। हर दिखने वाला pixel leaf shader को 8 से 15 बार चलाता है।
• एक depth prepass जोड़ें और main pass ~1x overdraw पर गिर जाता है, पर prepass खुद अब भी सब कुछ छूता है।
• Front-to-back sorting जोड़ें और prepass खुद को pruning करने लगता है।
• Cluster-level GPU culling जोड़ें और prepass सिर्फ़ उसे छूता है जो संभवतः दिख सकता है।
• LOD chains और imposters जोड़ें और 30 m से परे दिखने वाले quads की संख्या एक अंक के क्रम से गिर जाती है।
• Visibility-buffer / Nanite path जोड़ें और shading stage घने overlap पर भी सचमुच प्रति pixel एक बार चलता है।
• Distance-field shadows जोड़ें और shadow लागत alpha test के साथ scale करना बंद कर देती है।

मुख्य नतीजा, जो ऊपर लिंक की गई talks में बार-बार दोहराया गया है: effective overdraw 8-15x से 1-2x में सिमट जाता है, और एक घने जंगल scene में कुल foliage frame लागत 4-6x गिर जाती है। यही पूरी वजह है कि आधुनिक open-world games consumer hardware पर जंगलों को 60+ fps पर render कर सकते हैं।

12. Browser के लिए इसका क्या मतलब है

इस stack का ज़्यादातर हिस्सा WebGPU पर साफ-साफ map होता है। हम पहले ही open-world browser engine में GPU-driven culling, indirect dispatch, Hi-Z occlusion, और front-to-back sorted prepasses ship कर चुके हैं। Masked geometry के लिए depth prepass सीधा है: WebGPU fragment shaders में depth-equal testing और discard का समर्थन करता है, early-Z को लेकर उन्हीं चेतावनियों के साथ। Octahedral imposters यांत्रिक रूप से port होते हैं, math बस sphere-to-octahedron unwrapping और atlas indexing है।

मुश्किल टुकड़े आधुनिक वाले हैं। WebGPU में एक visibility buffer का मतलब है एक render target में 32-bit triangle ID लिखना और एक fullscreen compute pass में materials को resolve करना; building blocks मौजूद हैं पर orchestration जटिल है। Mesh distance-field shadows प्रति asset एक 3D texture और एक छोटा cone trace चाहते हैं, दोनों WebGPU की पहुंच में हैं। Hashed alpha और dithered LODs हर एक एक shader function हैं।

Browser foliage के लिए आगे का रास्ता वही है जो इस stack में बाकी हर चीज़ के लिए है: सस्ते, मज़बूत टुकड़े पहले ship करो (prepass, sorted instances, LODs, imposters, hashed alpha) और भारी मशीनरी (visibility buffer, mesh-SDF shadows) उसके ऊपर जोड़ो। Browser hardware का floor आखिरकार इतना ऊंचा है कि कोई architectural वजह नहीं कि एक WebGPU जंगल किसी console जैसे न दिखे और न चले। बस engineering वजहें हैं, और engineering वजहें वही हैं जो हमें पसंद हैं।

पूरे stack में आगे पढ़ने के लिए

अगर आप एक ऐसा source चाहते हैं जो यह सब एक साथ खींच लाए, तो SIGGRAPH "Advances in Real-Time Rendering in Games" archive (advances.realtimerendering.com) में 2014 तक की canonical foliage और GPU-driven-rendering talks हैं। Adrian Courrèges के GPU profiling articles में GTA V और Horizon Zero Dawn के frame-by-frame breakdowns हैं जो यहां चर्चित हर pass को production क्रम में दिखाते हैं। खास तौर पर alpha-test math के लिए, Chris Wyman के research page पर reference shaders के साथ hashed-alpha और stochastic-transparency papers हैं। और Real-Time Rendering, 4th edition के transparency, sampling, और depth handling पर अध्याय अब भी पाठ्यपुस्तक की शुरुआती जगह हैं।

Oleg Sidorkin द्वारा, Cinevva के CTO और सह-संस्थापक

यहाँ नए हैं? सीरीज़ गाइड का इस्तेमाल करें। यह बताती है कि स्पाइक क्या होता है और सभी भागों को लिंक करती है।

भाग 24 ने वर्ल्ड को persistent बनाया और उसकी वनस्पति को हवा दी। यह भाग फिर से उसमें मौजूद लोगों के बारे में है, लेकिन वॉर्डरोब की तरफ से: क्या एक creator एक बेस बॉडी चुन सकता है, कपड़े बदल सकता है, हेयरस्टाइल चुन सकता है, और कोई भी एनिमेशन चला सकता है, वह सब एक मुफ्त asset पैक पर, बिना किसी rigging और बिना किसी एनिमेशन authoring के? एक कस्टम rig बनाना de-risk करने लायक सही चीज़ नहीं है। जवाब देने लायक सवाल यह है कि क्या एक CC0 पैक पूरा भार उठा सकता है।

एक पैक जो आपस में फिट होने के लिए ही बनाया गया था

Spike 50 को नए टैब में खोलें ↗ · सोर्स देखें

Quaternius चार assets भेजता है जो लगभग संदेहास्पद रूप से अच्छी तरह मेल खाते हैं: Universal Base Characters जिसमें पुरुष और महिला बॉडी के साथ आठ हेयरस्टाइल और दो आइब्रो सेट हैं, Modular Character Outfits जो body, arms, legs और feet हिस्सों में बँटे हैं और साथ में pauldrons और एक hood जैसी accessories हैं, और Universal Animation Library पैक एक और दो, कुल मिलाकर 262 क्लिप जो locomotion, combat, climbing, farming, fishing, idles और social moves को कवर करते हैं। उनके glTF का निरीक्षण करने पर पता चला कि वे क्यों फिट होते हैं: चारों पैक का हर एक mesh एक ही 65-जॉइंट UE5-स्टाइल स्केलेटन पर rigged है, वही जॉइंट नाम, वही bind poses, root से pelvis और spine होते हुए head तक, हर तरफ पंद्रह उँगली जॉइंट वाली मिरर की हुई arms, मिरर की हुई legs। कोई retargeting नहीं चाहिए। यह स्पाइक 35 की तीन-स्केलेटन retargeting समस्या के बिल्कुल उलट है, जहाँ एक 213-बोन फेस rig को एक 65-बोन Mixamo rig से बात करनी पड़ती थी। यहाँ चारों पैक जानबूझकर एनिमेशन लाइब्रेरी के स्केलेटन पर authored थे, और यह जुड़ाव बिल्कुल सटीक है।

इसने इस स्पाइक को एनिमेशन-पाइपलाइन के अभ्यास के बजाय एक बाइंडिंग अभ्यास में बदल दिया। बेस लेयर एक body glTF लोड करती है, सीन को SkeletonUtils.clone से क्लोन करती है ताकि हर कैरेक्टर को एक ताज़ा स्केलेटन इंस्टेंस मिले बजाय इसके कि bone म्यूटेशन वापस loader के कैश्ड सीन में जाएँ, और उस 65-बोन स्केलेटन को canonical के रूप में कैश करती है साथ ही उस armature ऑब्जेक्ट को भी जो एनिमेशन का root है।

एक कोट को बॉडी पर री-बाइंड करना

जो ट्रिक पूरी चीज़ को काम करवाती है वह यह है कि आप किसी outfit के mesh को सीधे सीन में दोबारा parent नहीं कर सकते, क्योंकि वह अब भी अपने खुद के glTF की bones को रेफर करता है, जो एक अलग subtree में बैठी होती हैं। हर modular हिस्सा, एक peasant body या एक ranger की legs, अपने खुद के SkinnedMesh के रूप में आता है जिसके पास उसी armature का अपना क्लोन होता है। बाइंडिंग सोर्स स्केलेटन की bones को उनके मूल क्रम में चलती है, हर एक को नाम से canonical स्केलेटन में ढूँढती है, और उन री-बाउंड bones से एक नया Skeleton बनाती है जो सोर्स के bind-inverse मैट्रिसेज़ को फिर से इस्तेमाल करता है, फिर सोर्स के identity bind मैट्रिक्स के साथ SkinnedMesh.bind को कॉल करती है। बाइंडिंग के बाद, mesh अपने सोर्स सीन से अलग हो जाता है और सीधे कैरेक्टर root के नीचे parent हो जाता है। चूँकि bind मैट्रिक्स bind समय पर world transform को कैप्चर कर लेता है और root identity पर बैठा है, mesh का अपना world transform आउटपुट को कभी प्रभावित नहीं करता और skinning पूरी तरह अब-साझा bones के ज़रिए होती है।

Hair और eyebrows भी slots हैं, और उन्होंने एक गलत धारणा को सुधार दिया। फोल्डर स्ट्रक्चर कहता था "rigged to head bone," जिससे लगता था कि hair एक स्टैटिक mesh होगा जो head के साथ एक baked offset के साथ parent किया गया है। ऐसा नहीं है। हर hair फाइल एक SkinnedMesh है जो सभी 65 जॉइंट पर weighted है, जिसमें long hair का weight ऊपरी spine और neck में फैलता है ताकि कैरेक्टर के नीचे देखने पर वह झूल जाए। तो hair भी किसी भी outfit हिस्से जैसा ही नाम-आधारित री-बाइंडिंग रास्ता अपनाता है। एकमात्र खास मामला outfit body slot है: जब यह attach होता है, तो बेस body mesh को छिपा दिया जाता है ताकि outfit उसमें से clip न करे, जबकि arms, legs, feet और accessories बस एक के ऊपर एक स्टैक हो जाते हैं क्योंकि पैक ने उन्हें इस तरह authored किया है कि वे बेस body के साथ सह-अस्तित्व में रहें और जहाँ कपड़े त्वचा को खुला छोड़ते हैं वहाँ वह दिखती रहे।

मुफ्त में 262 एनिमेशन

एक बार स्केलेटन साझा हो जाने के बाद एनिमेशन लगभग anticlimactic है। दोनों लाइब्रेरी glbs लोड होती हैं, उनके क्लिप एक नामांकित सूची में सपाट हो जाते हैं, और उन क्लिप में track नाम सटीक जॉइंट नामों को bone.position, bone.quaternion और bone.scale के ज़रिए रेफर करते हैं। कैरेक्टर के armature पर rooted एक AnimationMixer उन bones को नाम से ढूँढता है और उन्हें सीधे चलाता है, स्विच पर crossfade करते हुए। viewer का दायाँ पैनल सभी 262 क्लिप की एक फ़िल्टर-योग्य सूची है जिसमें एक source pill है, तो "fish" खोजने पर दोनों लाइब्रेरी की हर fishing एनिमेशन सामने आ जाती है। सॉफ्ट shadows के साथ स्टैंडर्ड three-point lighting, पैरों के नीचे एक polar grid, और ACES tone mapping स्टाइलाइज़्ड बेस textures को पढ़ने लायक बनाए रखते हैं बिना गहरे bodysuit की shadows को कुचले।

यह प्रोडक्ट के लिए जो de-risk करता है वह बहुत बड़ा है। avatar कस्टमाइज़ेशन फीचर शून्य rigging काम और शून्य एनिमेशन authoring के साथ एक CC0 पैक पर शिप हो सकता है: चारों पैक डाल दें, एक वॉर्डरोब UI वायर कर दें, और आपके पास लगभग छह outfits गुणा आठ हेयरस्टाइल गुणा दो लिंग गुणा 262 एनिमेशन जितनी विविधता बॉक्स से बाहर निकलते ही मिल जाती है। 65-जॉइंट स्केलेटन इतना छोटा है कि GPU skinning की लागत नगण्य है, और स्पाइक 45 का batched-skinning काम इस आकार के rig पर पहले से ही 200-प्लस avatars संभाल लेता है। CC0 पर कोई इस्तेमाल पाबंदी नहीं होती, तो एक paid creator प्लेटफॉर्म पर commercial उपयोग ठीक है। बाकी बचा खुला सवाल कस्टम-अपलोड किए गए outfits का है, जो एक Phase 3 की समस्या है और इसे अपलोड समय पर इस canonical स्केलेटन पर retargeting करके हल किया जाता है, जो स्पाइक 35 की runtime retargeting का उलटा है। asset का फुटप्रिंट डिस्क पर लगभग 147 MB है जो raw 2K PNGs और uncompressed एनिमेशन glbs के रूप में है, जिसे production KTX2 texture compression और एक gltf-transform पास के साथ घटाकर लगभग 30 MB कर देगा।

इस अध्याय में संदर्भित तकनीक

एक पैक भर में एक canonical स्केलेटन। चार Quaternius पैक (बेस बॉडी, modular outfits, दो एनिमेशन लाइब्रेरी) सभी एक समान 65-जॉइंट UE5-स्टाइल स्केलेटन पर एक ही जॉइंट नामों और bind poses के साथ rigged हैं, तो उन्हें जोड़ने के लिए कोई retargeting नहीं चाहिए। बेस को SkeletonUtils.clone से क्लोन करने पर हर कैरेक्टर को loader के कैश्ड सीन को म्यूटेट करने के बजाय एक ताज़ा स्केलेटन इंस्टेंस मिलता है।

नाम-आधारित स्केलेटन री-बाइंडिंग। हर modular हिस्सा अपने खुद के armature को रेफर करते हुए अपना खुद का SkinnedMesh भेजता है। री-बाइंडिंग सोर्स bones को क्रम में चलती है, हर एक को नाम से canonical स्केलेटन में मैप करती है, सोर्स bind-inverses को फिर से इस्तेमाल करते हुए एक नया Skeleton बनाती है, और identity bind मैट्रिक्स के साथ SkinnedMesh.bind को कॉल करती है, फिर mesh को साझा कैरेक्टर root के नीचे parent करती है ताकि skinning पूरी तरह साझा bones के ज़रिए चले। outfit body slot clipping से बचने के लिए बेस body को छिपा देता है; बाकी slots स्टैक हो जाते हैं।

एक skinned slot के रूप में Hair। Hair एक स्टैटिक head-bone attachment नहीं बल्कि एक SkinnedMesh है जो सभी 65 जॉइंट पर weighted है, जिसमें long hair को ऊपरी spine और neck में weight किया गया है ताकि नीचे देखने पर वह झूल जाए। यह outfit हिस्सों जैसा ही री-बाइंडिंग रास्ता अपनाता है।

मुफ्त में नाम-कुंजी आधारित एनिमेशन retargeting। Animation Library क्लिप जॉइंट को सटीक नाम से रेफर करते हैं, तो साझा armature पर rooted एक AnimationMixer सभी 262 क्लिप को crossfade के साथ सीधे चलाता है, बिना किसी प्रति-क्लिप retargeting के। एक CC0 लाइसेंस commercial उपयोग को कवर करता है, और छोटा जॉइंट काउंट GPU skinning को इतना सस्ता रखता है कि स्पाइक 45 के batched-skinning रास्ते को फिर से इस्तेमाल किया जा सके। देखें GPU-driven LOD।

29 में से भाग 25। पिछला: भाग 24 - एक वर्ल्ड को सेव करना, और वह हवा जो आप देख सकते हैं अगला: भाग 26 - वह पानी जो हर पैमाने पर टिकता है सीरीज़ गाइड: /blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहाँ नए हैं? series guide का इस्तेमाल करें। यह बताती है कि spike क्या होता है और सभी भागों को link करती है।

भाग 23 ने दुनिया में लोगों को रखा और उन्हें एक आवाज़ दी। यह भाग इस बारे में है कि दुनिया को यह याद रखवाना कि लोगों ने उसके साथ क्या किया, और उसे तब भी जीवंत महसूस कराना जब कोई उसे छू नहीं रहा हो। Spike 47 persistence है: एक creator terrain को आकार देता है और props रखता है, और वे edits एक reload के बाद बच जाते हैं, हर दूसरे peer के साथ sync होते हैं, और जब दो लोग एक साथ edit करें तो साफ़-सुथरे तरीके से फैसला हो जाता है। Spike 49 wind है: एक stylized nature pack के vegetation shaders को port करना ताकि पेड़, झाड़ियाँ और घास उस तरह हिलें जैसा artist ने चाहा था, जो math से ज़्यादा shader compiler के साथ एक लड़ाई बन गई।

एक दुनिया जो याद रखती है

Spike 47 को एक नए tab में खोलें ↗ · Source देखें

सेटअप एक shared authoring session है। Players एक दुनिया में चलते हैं, एक click से props रखते हैं, एक right-click से उन्हें हटाते हैं, और एक brush को drag करके ज़मीन को आकार देते हैं, heightmap को ऊपर-नीचे करते हैं या SDF terrain में volumetric गुफाएँ काटते हैं जो एक chunk को marching cubes तक promote कर देता है। वे जो कुछ भी करते हैं वह एक Cloudflare WorldChunkDO में persist होता है, एक server-authoritative Durable Object जो अपने ही SQLite storage द्वारा backed है। Clients state को सीधे नहीं लिखते। वे intent भेजते हैं, DO फैसला करता है और नतीजा broadcast करता है, और DO ही single source of truth है, इसलिए एक नया जुड़ने वाला एक snapshot पाता है और ठीक उसी दुनिया में उतरता है जो बाकी सब देखते हैं।

दो persistence विवरणों ने अपनी जगह बनाई। Terrain को join पर replay किए जाने वाले event log के रूप में store नहीं किया जाता; इसे per-chunk binary blobs के रूप में store किया जाता है जो source of truth हैं, stroke-end पर upload किए जाते हैं, इसलिए जुड़ने वाला हज़ारों brush samples को फिर से चलाने के बजाय committed bytes को सीधे load करता है। और वे blobs एक बड़ी row के बजाय per chunk एक storage key में रहते हैं, क्योंकि एक अकेला SDF chunk 168 KB का है और DO में per-row limit 2 MB है। एक chunk index यह track करता है कि कौन-सी keys मौजूद हैं ताकि DO जागने पर पूरे map को rehydrate कर सके। Identity को client पर दो storages से संभाला जाता है: player id sessionStorage में रहती है ताकि दो tabs दो अलग peers हों, न कि एक ऐसा peer जो DO के player map में खुद को overwrite कर दे, जबकि display name localStorage में रहता है ताकि एक tab में किया गया rename उन सब में पहुँच जाए।

Concurrent edits को converge कराना

Multiplayer authoring का असली कठिन हिस्सा यह है कि जब दो लोग ठीक एक ही पल में overlapping ज़मीन को edit करें तो क्या होता है। Spike edits को उनके algebra के हिसाब से बाँटता है। Additive operations, heightmap पर raise और lower और SDF पर add और subtract, commutative हैं: उन्हें किसी भी क्रम में लगाने पर वही नतीजा मिलता है, इसलिए वे एक optimistic-stamp path पर चलती हैं जहाँ हर client locally apply करता है और stamp भेज देता है, और DO बिना किसी coordination के उसे सबको broadcast कर देता है। क्रम सचमुच मायने नहीं रखता, इसलिए coordinate करने को कुछ है ही नहीं।

Order-dependent operations, smooth और flatten, दिलचस्प मामला थीं। पहले design ने उन्हें एक region lock दिया था: एक client pointer-down पर एक lock का अनुरोध करता है, DO उसे grant या deny करता है, client press के दौरान samples को buffer करता है, और pointer-up पर DO पूरे stroke को atomically apply कर देता है। यह काम करता है, पर यह अपने ही lock TTL और grant/deny round-trip वाला एक अलग protocol है। जिस साफ़-सुथरे जवाब ने उसकी जगह ली वह एक precomputed delta है: originator smooth या flatten brush को locally चलाता है, फिर per-cell deltas की जो list बनी उसे भेज देता है, और हर peer बस उन deltas को अपने ही cells में जोड़ देता है बिना कुछ भी फिर से derive किए। यह एक order-dependent operation को उसके नतीजे को source पर freeze करके commutative बना देता है, इसलिए पूरा edit system एक ही uniform commutative protocol पर चलता है, समान convergence के साथ और बिल्कुल कोई locks नहीं। Prop locks एक अलग वजह से बने रहते हैं: per-record locking ने owner-only deletion की जगह ली, इसलिए कोई भी peer किसी भी prop को delete कर सकता है जब तक कि किसी ने उसे lock न कर रखा हो, और सिर्फ़ lock करने वाला ही उसे clear कर सकता है। Undo और redo इस तरह काम करते हैं कि client किसी prop की id को रखने से पहले ही उसका नाम तय कर देता है, इसलिए वह server के echo से पहले id को जान लेता है और अपने ही actions को deterministically उल्टा कर सकता है। Hibernating WebSockets एक निष्क्रिय room को पूरे समय मुफ़्त रखते हैं, वही property जिसने पिछले भाग में avatar relay को सस्ता बना दिया था।

Wind को ईमानदारी से port किया, फिर लड़ाई हुई

Spike 49 को एक नए tab में खोलें ↗ · Source देखें

Spike 49 Quaternius का Stylized Nature MegaKit लेता है और उसकी wind को हमारे stack में port करता है। Pack अपने source Godot shaders भेजता है, चार shaders, और सही कदम एक re-invention के बजाय एक ईमानदार translation था। Bark का vertex function खाली है, इसलिए तने rigid हैं; एक पहले की procedural-mask कोशिश तनों को लहरा रही थी, और fix बस यह था कि bark पर wind लगाना पूरी तरह बंद कर दिया जाए। Leaves को एक triangular-pulse hash से per-vertex अव्यवस्थित sway मिलता है, height से masked ताकि canopy हिले और base टिका रहे। Base foliage को world space में एक noise-modulated sin/cos sway मिलता है। Grass base foliage के साथ एक wind-line bobble है, एक power curve के ज़रिए एक scrolling noise texture को sample करती है ताकि texture के सिर्फ़ चमकीले bands ही योगदान दें, जो वे दिखने वाली ripples पैदा करता है जो एक मैदान के आर-पार दौड़ती हैं। Dispatch pack के अपने material-naming convention को मानता है, इसलिए Leaves_Birch नाम का एक material leaves path तक route होता है और Grass_Common grass path तक, कोई अंदाज़ा नहीं।

Port से एक हैरानी यह है कि leaf का रंग texture में नहीं है। Quaternius leaf की दिखावट को पूरी तरह एक vertical gradient और एक Fresnel rim से author करता है: albedo canopy के नीचे एक अतिरिक्त रंग से ऊपर leaf रंग तक का एक mix है, height पर keyed, साथ में emission के रूप में जोड़ा गया एक subsurface-scattering tint जो एक $(1-\mathbf{N}\cdot \mathbf{V}{)}^3$ Fresnel term से scale होता है। इसीलिए एक सादा textured pass flat लगता था। रंग gradient और rim से आते हैं, painted map से नहीं। Port raw local Y के बजाय एक baked heightFactor vertex attribute पढ़ता है, load time पर world-space Y से per leaf group normalize किया गया, इसलिए gradient और wind mask दोनों सही व्यवहार करते हैं चाहे FBX import ने हर mesh के local axes को कैसे भी rotate किया हो। Godot color constants sRGB tagged हैं और shader के देखने से पहले linear में convert हो जाते हैं, इसलिए port भी वही conversion करता है, बजाय इसके कि चमकीले sRGB numbers को linear मानकर खिलाए और foliage को धो दे।

वह recompile जिसने frame rate खा ली

इसके पहले एक FBX baseline के रूप में ship होने की वजह, पूरे wind material को एक .bak file में अलग रखकर, एक per-frame recompile bug है जिसने scene को लगभग 1 fps तक गिरा दिया। FBX-loaded materials के ऊपर custom TSL को layer करना Three.js को हर frame shader programs फिर से बनाने पर मजबूर कर रहा था, needsUpdate असल में अटका हुआ रहता था। Diagnostic अनुशासन यह था कि हर foliage material को बिना किसी custom nodes वाले एक सादे textured pass तक छील दिया जाए और देखा जाए कि recompile loop बना रहता है या नहीं। अगर वह रुक गया, तो custom graph ही दोषी था; अगर वह चलता रहा, तो वजह FBX material setup या ख़ुद Three.js में, ऊपर की तरफ़ थी। जिस fix ने असली shaders को वापस आने दिया वह यह था कि हर per-material अंतर, leaf color, SSS color, strength, और blend, को uniforms के रूप में bind कर दिया जाए ताकि सारे leaf assets एक ही compiled program साझा करें, बजाय इसके कि compiler हर unique color combination के लिए एक नया shader निकाले और compile queue को thrash करे।

दो और टुकड़े रखने लायक हैं। Grass हर source file के लिए एक InstancedMesh के रूप में render होती है, और उसकी wind world space में compute होती है क्योंकि sin phases world position पर key होते हैं। पर displacement को instance matrix चलने से पहले local space में लगाना पड़ता है, और WGSL में call करने को कोई inverse() नहीं है। translation, एक Y rotation, और एक uniform scale वाले एक instance matrix के लिए, ऊपरी 3×3 का inverse बस उसका transpose है जो scale के वर्ग से भाग किया गया हो, इसलिए shader world displacement को transposed model matrix से गुणा करता है और matrix के पहले column की लंबाई के वर्ग से भाग देता है, बिना किसी square root के scale को वापस पा लेता है। Vertex transform के matrix को फिर से लगाने के बाद, motion ठीक वैसे world space में उतरती है जैसे author की गई थी, हर tuft के rotation या scale से स्वतंत्र। और हर tuft एक per-vertex GPU frustum cull चलाता है: यह instance center को clip space तक project करता है, और अगर वह margin के साथ frustum के बाहर गिरता है, तो हर vertex को local origin तक collapse कर देता है ताकि हर triangle के तीनों vertices एक हो जाएँ, rasterizer उस degenerate triangle को छोड़ देता है, और off-screen grass के लिए कोई fragment, alpha-test, या shadow काम नहीं होता। यह उस coarse per-chunk bounding-sphere cull के ऊपर जुड़ता है जो Three.js पहले से करता है, booleans के बजाय float step से बना ताकि वह सीधे position mix में गुणा हो जाए।

इस अध्याय में संदर्भित तकनीक

Server-authoritative world persistence. एक WorldChunkDO Durable Object prop placement और terrain edits का फैसला करता है, per-chunk binary blobs को source of truth के रूप में persist करता है (इसलिए जुड़ने वाले एक event log को replay करने के बजाय committed bytes load करते हैं), और DO की 2 MB per-row limit के नीचे रहने के लिए per chunk एक storage key store करता है। Player id sessionStorage में रहती है ताकि tabs अलग peers हों; display name localStorage में रहता है ताकि renames tabs के पार पहुँचें।

Commutative edit convergence. Additive terrain ops (raise/lower, SDF add/subtract) commutative हैं और बिना coordination के एक optimistic-stamp path पर चलती हैं। Order-dependent ops (smooth, flatten) को एक region lock हासिल करने के बजाय precomputed per-cell deltas भेजकर commutative बनाया जाता है, इसलिए पूरा system बिना locks के एक ही uniform protocol के तहत converge होता है। Per-record prop locks owner-only deletion की जगह लेते हैं, और client-named object ids server के echo के पहुँचने से पहले deterministic undo/redo को संभव बनाती हैं। देखें GPU-driven LOD।

Godot से TSL में ईमानदार shader porting. Quaternius के चार source wind shaders line-for-line translate होते हैं: rigid bark, height-masked leaf sway, world-space foliage sway, और एक scrolling wind-line bobble वाली grass, pack के material-naming convention से dispatched। Leaf color texture के बजाय एक height gradient और एक Fresnel-driven SSS rim से आता है, और sRGB authoring constants linear में convert होते हैं ताकि look reference renders से मेल खाए।

Per-frame shader recompiles से बचना. FBX materials पर custom TSL को layer करना needsUpdate को pin कर सकता है और हर frame programs फिर से बना सकता है, ~1 fps तक गिर जाता है। हर per-material अंतर को एक uniform के रूप में bind करना सारे variants को एक ही compiled program साझा करने देता है, बजाय इसके कि हर unique parameter set पर एक नया shader निकले। एक plain-textured diagnostic pass यह अलग कर देता है कि वजह custom graph है या ऊपर का setup।

Instanced foliage पर world-space wind. Grass wind world space में compute होती है और एक hand-derived inverse (scale-squared पर transpose) से वापस local में transform होती है क्योंकि WGSL में कोई inverse() नहीं है। एक per-vertex GPU frustum cull off-screen tufts को एक degenerate triangle तक collapse कर देता है ताकि कोई fragment या shadow काम न चले, Three.js के per-chunk bounding-sphere cull के ऊपर जुड़कर।

भाग 24, कुल 29 में से। पिछला: भाग 23 - पचास avatar और कमरे में एक आवाज़ अगला: भाग 25 - एक skeleton, हर outfit Series guide: /hi/blog/2026-02-25-open-world-browser-series-guide

लिखा है Oleg Sidorkin ने, Cinevva के CTO और को-फाउंडर

यहाँ नए हैं? सीरीज़ गाइड देखिए। यह बताती है कि spike क्या होता है और सारे भागों के लिंक देती है।

भाग 22 ने world के ऊपर एक sky लगाया। यह भाग उसमें लोग डालता है। एक third-person open world चाहता है कि किसी भी पल में 50 से ज़्यादा character दिखें, और चाहता है कि आपके पास खड़े लोगों की आवाज़ सुनाई दे। Spike 45 rendering का पक्ष है: इतने सारे animated avatar को GPU पर लाना, वह भी main thread को पिघलाए बिना। Spike 46 audio का पक्ष है: peer-to-peer voice जो position के हिसाब से pan और attenuate होती है, ऐसे tune की गई कि किसी tech demo की जगह एक सामान्य video call जैसी लगे।

पचास नाचने वालों के लिए एक draw call

Spike 45 को नए tab में खोलें ↗ · सोर्स देखें

डिफ़ॉल्ट Three.js path हर character को उसका अपना SkinnedMesh, अपना AnimationMixer, अपना bone-matrix upload, और अपना draw call देता है। लोकल Mac पर 50 avatar पर यह करीब 13 ms का शुद्ध JavaScript overhead था per frame, इससे पहले कि GPU एक भी काम करे। पूरे multiplayer track के लिए de-risking सवाल यह था कि क्या एक batched-skinning architecture इसे काबू में ला सकता है और character count के साथ linearly scale कर सकता है।

जवाब इस बात में बँटा है कि animation कहाँ compute होती है और कहाँ draw होती है। तीन character class एक FBX template साझा करते हैं। लोकल player एक सामान्य Avatar है, अपने mixer वाला पूरा skeleton clone, मानक Three.js path, क्योंकि इसका हमेशा सिर्फ़ एक ही होता है। हर remote peer एक VirtualSkeleton है: यह भी अपने mixer के साथ एक पूरा clone जो वही clip चलाता है, लेकिन हर SkinnedMesh node को clone करने के तुरंत बाद हटा दिया जाता है ताकि सिर्फ़ bone बचें। यह कभी scene में नहीं आता। हर frame में, mixer के update होने और matrices के स्थिर हो जाने के बाद, यह सभी 100 bone के लिए (bone.matrixWorld × boneInverse) को एक साझा Float32Array के एक slot में pack करता है। फिर BatchSkinnedRenderer हर geometry piece के लिए एक InstancedMesh का मालिक होता है, ये सब एक ही StorageBufferAttribute से bone matrices पढ़ते हैं जिसका आकार maxInstances × numBones × mat4 है, यानी 60 × 100 × 64 = 384 KB। custom positionNode और normalNode वाला एक MeshStandardNodeMaterial हर vertex के लिए चार bone influence सीधे उस storage buffer से पढ़ता है। नतीजा यह कि पूरी भीड़ के लिए हर geometry piece पर एक storage upload और एक draw call होता है, चाहे उसमें कितने भी लोग हों। Skinning vertex shader में रहती है, और per-avatar JavaScript की लागत घटकर एक mixer चलाने और 100 matrix copy करने तक रह जाती है।

इसे मापने वाले HUD को भी फिर से बनाना पड़ा। पुराना version तब "over budget" दिखाता था जब पूरे-frame का GPU time 3 ms पार करता, लेकिन frame में हमेशा shadow map, ground, और लोकल player का पूरा skinned mesh शामिल होते हैं, जो मिलकर असली hardware पर 3 से 5 ms चलते हैं, चाहे कितने भी synthetic peer मौजूद हों। fix एक ऐसा budget है जो खुद को calibrate करता है: जब तक कोई batched avatar मौजूद न हो, यह live GPU time को एक तेज़ EMA के ज़रिए baseline के रूप में capture करता है, फिर उस baseline को freeze कर देता है और synthetic दिखने पर हर जुड़े avatar पर budget को 0.06 ms की दर से linearly बढ़ाता है। यह हर machine पर idle में PASS दिखाता है और भीड़ बढ़ने पर आनुपातिक रूप से कसता है।

bug एक ऐसा चेहरा था जो आपको दिखता नहीं था

Chrome में पहले run में ground पर silver shadow और कोई avatar बिल्कुल नहीं दिखा, साथ में एक WGSL parse error: एक ऐसी line पर cannot index type 'f32' जो object.nodeUniform2[i] को subscript करने की कोशिश कर रही थी जहाँ uniform एक scalar के रूप में declare किया गया था। इस कहानी का ईमानदार हिस्सा यह है कि पहला fix ग़लत था और फिर भी काम कर गया। अंदाज़ा यह था कि InstancedMesh का instance-matrix path ख़राब code बना रहा था, और एक StorageInstancedBufferAttribute डालने से Chrome में error ग़ायब हो गया। पर वह इसलिए ग़ायब हुआ क्योंकि नए path ने अलग shader code emit किया, इसलिए नहीं कि उसने वजह को हल किया, और यही सबसे ख़तरनाक तरह का fix है।

असली अपराधी थे morph target। 3MIKE.fbx blend-shape facial expression के साथ आता है, cloned geometry morphAttributes को विरासत में लेती है, और Three.js का MorphNode.setup() morphTargetInfluences को एक scalar float के रूप में declare करता है और फिर एक synthesized loop के अंदर उसे .element(i) करने की कोशिश करता है, जो ठीक वही scalar-subscript है जिसे compiler ने नकार दिया। fix एक line है, उस geometry पर geometry.morphAttributes = {} clear करना जो morph का इस्तेमाल नहीं करती, ताकि Three.js MorphNode को inject ही न करे। वह अनजाने वाला Chrome fix कुछ देर के लिए टिका रहा और फिर पलटकर काट गया: Safari पर, storage-instanced path ने 256 बार Vertex buffer is not big enough दिया, क्योंकि Safari का WebGPU backend इसे साफ़-सुथरे ढंग से translate नहीं करता। उसे revert करना सही फ़ैसला था, और सादा bone-matrix storage buffer, जो किसी generated instance path के बजाय core WebGPU है, हर जगह ठीक काम करता है। सीखने लायक सबक़ यही है: जब कोई fix एक browser पर काम करे और आप उसकी मशीनरी समझा न सकें, तो आपने किसी लक्षण पर पट्टी लगाई है, इसलिए असली generated WGSL पढ़िए। spike में बाद में जोड़ा गया एक getCompilationInfo() shim Three.js के सामान्य "module is not valid" को असली Tint error में बदल देता है और उसने अपनी क़ीमत कई गुना वसूल कर ली।

इसके पास ही एक मिलती-जुलती framework-evasion तरकीब बैठी है। Three.js मानक skinIndex और skinWeight attribute नाम पहचान लेता है और अपना SkinningNode inject करने की कोशिश करता है, उस InstancedMesh पर भी जिसका custom positionNode पहले से ही skinning करता है। उन attribute के नाम बदलकर boneIndex और boneWeight करने से वे framework से छिप जाते हैं, और custom TSL उन्हें नए नामों से पढ़ता है।

एक relay जो शब्दों के बीच आपको भूल जाता है

पहले version ने peer को BroadcastChannel पर sync किया, यानी असली wire format और cadence के साथ एक same-browser नमूना, और protocol comment में वादा था कि असली transport में बदलना एक line का काम होगा। उस वादे को भुनाने का मतलब था एक AvatarRoomDO, एक 74-line का Cloudflare Durable Object जो 36-byte वाली binary frame को decode तक नहीं करता। यह हर message को जैसा है वैसा ही कमरे के बाकी हर peer को आगे भेज देता है, क्योंकि भेजने वाले की id frame में embedded है और हर receiver अपनी ही echo को client-side filter कर लेता है। relay को identity की कोई जानकारी नहीं होती। Hibernating WebSocket एक खाली कमरे को मुफ़्त बना देते हैं: messages के बीच DO memory से बाहर निकल जाता है और runtime अगले packet पर tagged socket बहाल कर देता है। हर peer के 10 event per second पर यह 36,000 DO request per peer-hour है, करीब आधा सेंट, Cloudflare पर egress मुफ़्त और equivalent AWS WebSocket आकार से करीब 6 से 10 गुना सस्ता।

इस बदलाव ने एक state-machine bug सामने ला दिया जो रखने लायक है। एक remote player रुकने के बाद भी चलता रहा। animation request this._state यानी अभी चल रहे clip के विरुद्ध guard कर रही थी, न कि आख़िरी queued नाम के, इसलिए जब दो network message एक ही tick में आए, पहले walk फिर idle, तो idle एक ऐसे state से तुलना कर रहा था जो अभी आगे बढ़ा ही नहीं था और चुपचाप drop हो गया। peer हमेशा के लिए चलने में अटक गया, क्योंकि आगे आने वाले idle packet upstream में बिना बदलाव के deduplicate हो रहे थे। fix यह है कि हमेशा pending नाम को overwrite किया जाए और transition helper को असली same-state request को short-circuit करने दिया जाए, जो वह पहले से करता था। यह bug का एक आम वर्ग है: ग़लत reference value के विरुद्ध एक dedup check चुपचाप उसी input को निगल जाता है जो मायने रखता है।

Safari को दो और guard की ज़रूरत थी। यह WebSocket को Chrome से तेज़ खोलता है, इसलिए पहला inbound peer message batch renderer के बन जाने से पहले आ सकता था और null को dereference कर देता था; renderer के मौजूद न होने पर messages drop करना सुरक्षित है क्योंकि peer हर 100 ms में दोबारा broadcast करते हैं। और 'gpu' in navigator ने true लौटाया जबकि requestAdapter() ने null लौटाया, इसलिए Three.js चुपचाप WebGL2 पर वापस आ गया, जहाँ storage-buffer skinning chain का कोई valid translation नहीं है और उसने errors उगल दिए। एक असली adapter की जाँच करना और यह सुनिश्चित करना कि backend सचमुच WebGPU है, एक degraded render को एक साफ़ loading-screen message में बदल देता है। यहाँ तक कि एक WGSL dialect gap भी था: Three.js आधुनिक दो-argument वाला @interpolate(flat, either) emit करता है जिसे WebKit के compiler ने अभी भेजा नहीं है, इसे createShaderModule में जाते वक़्त shader source को rewrite करके दूसरा argument हटाकर patch किया गया, जो मुफ़्त है क्योंकि flat interpolation हर vertex पर एक ही value रखती है चाहे जो भी हो।

वह आवाज़ जो कमरे के साथ pan होती है

Spike 46 को नए tab में खोलें ↗ · सोर्स देखें

Spike 46 proximity voice है: HRTF spatial audio के साथ peer-to-peer WebRTC, साफ़ तौर पर इस दायरे में रखी गई कि एक शांत-से-मध्यम-शोर वाले कमरे में Google Meet और Microsoft Teams की क्वालिटी से मेल खाए। एक VoiceRoomDO signaling को एक JSON relay की तरह संभालता है, हर नए peer को एक roster भेजता है, join और leave की घोषणा करता है, SDP और ICE को socket tag के ज़रिए एक ख़ास peer तक route करता है, और position update broadcast करता है जो spatial panner को चलाते हैं। यह हर message पर भेजने वाले की id छाप देता है ताकि peer एक-दूसरे की नकल न कर सकें, और audio खुद कभी DO को नहीं छूता। हर remote peer के लिए एक RTCPeerConnection, जहाँ lexicographically छोटी peer id हमेशा offer बनाती है ताकि दोनों पक्ष इस बात पर सहमत हो जाएँ कि कौन शुरू करता है, बिना किसी पूरे perfect-negotiation implementation के।

receive side पर हर peer का audio एक PannerNode से होकर गुज़रता है जो HRTF पर inverse distance rolloff के साथ सेट है, और AudioListener हर frame लोकल player की position और facing से update होता है, forwardX = sin(facing), forwardZ = cos(facing) का इस्तेमाल करते हुए, जो scene के atan2(wx, wz) facing convention से मेल खाता है। Chrome की एक ख़ासियत ने एक घंटा खर्च करा दिया: सिर्फ़ Web Audio द्वारा consume होने वाली एक MediaStream कभी-कभी packet नहीं खींचती, इसलिए हर stream एक छिपे हुए muted <audio> element से भी जुड़ती है ताकि decoder को schedule करने पर मजबूर किया जा सके। क्वालिटी की ओर, browser डिफ़ॉल्ट रूप से करीब 32 kbps mono Opus चलाते हैं, इसलिए spike हर offer और answer पर fmtp line को बदलकर उसे 128 kbps तक बढ़ाता है, in-band FEC enabled और DTX disabled के साथ, फिर एक ऊँची max bitrate के साथ setParameters call करता है ताकि गारंटी रहे कि encoder सचमुच वही इस्तेमाल करे जो SDP बताता है। bitrate बढ़ाने के बाद FEC दूसरी सबसे बड़ी सुनाई देने वाली जीत है, यह बिना renegotiation के packet loss से उबर जाता है।

साफ़ audio तक पहुँचने का रास्ता हटाते हुए

जो audio chain भेजी गई वह उससे कहीं छोटी है जिससे मैंने शुरुआत की थी, और उसे सिकोड़ना ही असली सबक़ था। पहले version में एक high-pass filter, keyboard noise पकड़ने के लिए tune किया गया एक click limiter, एक compressor, एक noise gate, और एक wet-dry crossfade था, जिसके आगे एक floating panel था जिसमें बारह से ज़्यादा slider थे। जब user ने सुनाई देने वाले keyboard click की रिपोर्ट की, तो सहज प्रवृत्ति यह थी कि click limiter को और ज़ोर से tune किया जाए और dry mix घटाई जाए, यानी पट्टियों का ढेर। structural जवाब यह था कि जैसे ही chain में एक ML denoiser आ जाता है, click limiter और gate और ज़्यादातर high-pass सब बेकार हो जाते हैं, क्योंकि RNNoise को ठीक keyboard, mouse और typing noise पर ही train किया गया है, और amplitude clipping उसी काम का एक सख़्ती से घटिया version है। production client ML denoise, echo cancellation, automatic gain, और level के लिए एक soft compressor भेजते हैं, और कुछ नहीं। तो चार stage बाहर हो गए, slider panel बाहर हो गया, और "अपनी noise reduction चुनें" वाले toggle बाहर हो गए, और पीछे एक तय pipeline रह गई।

बचा हुआ हर stage अपनी जगह कमाता है। Browser echo cancellation चालू रहता है क्योंकि RNNoise echo नहीं संभालता, और इसके बिना speaker-से-mic feedback की कोई सीमा नहीं रहती। Browser noise suppression बंद रहता है क्योंकि उसे RNNoise के ऊपर रखने से s, sh, और f जैसी fricative पर artifact बनते हैं, इसलिए आप एक ही denoiser चुनते हैं। Browser automatic gain चालू रहता है, क्योंकि उसे बंद करने से signal इतना धीमा हो जाता था कि compressor के काम लायक न रहे और Web Audio के DynamicsCompressorNode में भरपाई के लिए कोई makeup-gain parameter नहीं है; browser का व्यापक levelling और spike का तेज़ compressor अलग-अलग timescale पर काम करते हैं और साथ रहते हैं। RNNoise 92 प्रतिशत wet पर चलता है, 8 प्रतिशत dry के साथ मिलाकर, क्योंकि यह s, sh, और f जैसे unvoiced consonant को ज़्यादा दबा सकता है जिनकी voice probability गिर जाती है, और छोटा dry path उन्हें थोड़े से keystroke leak की क़ीमत पर बचाए रखता है।

दो feature इसे पूरा करते हैं। Push-to-talk track.enabled को नहीं पलटता, क्योंकि वह pipeline buffer में बचा हुआ सब कुछ फेंक देता है और key छोड़ने पर आख़िरी syllable काट देता है। इसके बजाय tail के पास एक GainNode setTargetAtTime के साथ ramp करता है, तेज़ attack ताकि पहली syllable बची रहे और धीमी release ताकि आख़िरी consonant निकल जाए, और track को हमेशा के लिए enabled छोड़ दिया जाता है। और एक पाँच-सेकंड का broadcast delay, जो एक radio-style feature के रूप में माँगा गया था, एक bypass leg और एक DelayNode leg को साथ crossfade करके चलता है, एक dump button के साथ जो delayed output को silence पर ले जाता है और audio लौटने से पहले HUD पर उल्टी गिनती करता है। denoiser को bundle करना अपने आप में एक छोटी गाथा थी: published RNNoise worklet ऐसे bare-specifier import इस्तेमाल करता है जिन्हें कोई CDN resolve नहीं करता, इसलिए fix एक local esbuild bundle था जो एक self-contained 1.9 MB file बनाता है जिसमें WASM base64-inlined है, repo में commit किया गया और module के सापेक्ष एक URL से referenced किया गया ताकि वह dev server, VitePress build, और custom domain सब के तहत resolve हो जाए। अगर worklet कभी load होने में नाकाम रहे, तो chain फिर भी एक सादे high-pass और compressor के ज़रिए audio बनाती रहती है, और HUD उस नाकामी को लाल रंग में दिखाता है।

इस अध्याय में जिस तकनीक का ज़िक्र हुआ

भीड़ के लिए batched GPU skinning. Remote avatar एक headless VirtualSkeleton चलाते हैं (एक पूरा clone जिसमें skinned mesh हटा दिए गए हैं, bone रखे गए हैं, अपना mixer है) जो हर bone के लिए bone.matrixWorld × boneInverse को एक साझा StorageBufferAttribute में pack करता है। हर geometry piece के लिए एक InstancedMesh उन matrices को एक custom TSL positionNode/normalNode में पढ़ता है, इसलिए पूरी भीड़ की लागत हर piece पर एक storage upload और एक draw call है, जहाँ per-avatar CPU काम एक mixer update और एक matrix copy तक सीमित है। देखें GPU-driven LOD।

लक्षण नहीं, generated WGSL पढ़ना. एक cannot index type 'f32' compile error का सुराग Three.js के MorphNode तक पहुँचा जो morphTargetInfluences को एक scalar के रूप में declare करके उसे subscript कर रहा था, जिसे उस geometry पर morphAttributes clear करके fix किया गया जो morph का इस्तेमाल नहीं करती। एक पहला fix जिसने सिर्फ़ यह बदला कि कौन सा shader path generate हुआ, वजह को छिपा गया और बाद में Safari को तोड़ गया। skinIndex/skinWeight का नाम बदलकर boneIndex/boneWeight करने से attribute Three.js के automatic SkinningNode injection से छिप जाते हैं ताकि एक custom skinning material गणित का मालिक बने।

Hibernating Durable Object relay. एक pure-binary AvatarRoomDO 36-byte frame को बिना decode किए बाकी हर peer को आगे भेजता है, जहाँ भेजने वाले की पहचान frame में embedded है और self-echo client-side filter होती है। Hibernating WebSocket एक खाली कमरे को मुफ़्त बना देते हैं, और यह आकार 10 Hz पर करीब आधा सेंट per peer-hour खर्च करता है, equivalent managed-WebSocket pricing से कहीं नीचे। एक dedup guard जो last-queued के बजाय चल रहे animation state से तुलना करता था, चुपचाप stop message drop कर देता था और remote player को एक walk loop में अटका देता था।

HRTF के साथ WebRTC proximity voice. हर peer के लिए एक RTCPeerConnection जहाँ offer/answer की भूमिकाएँ peer-id क्रम से तय होती हैं, audio एक HRTF PannerNode से route होता है जहाँ AudioListener हर frame player facing से update होता है, और Opus को resilience के लिए in-band FEC के साथ 128 kbps तक बदला जाता है। एक muted छिपा हुआ <audio> element Chrome को एक Web-Audio-only stream से packet खींचने पर मजबूर करता है।

Subtractive audio engineering. Meet/Teams की क्वालिटी से मेल खाने का मतलब था stage जोड़ना नहीं, हटाना: ML denoise और echo cancellation और automatic gain और एक soft compressor, बिना किसी gate और बिना किसी click limiter के, क्योंकि keyboard noise पर train किया गया एक ML denoiser amplitude clipping को बेकार बना देता है। Push-to-talk track पलटने के बजाय एक asymmetric envelope के साथ एक tail GainNode को ramp करता है ताकि syllable न कटें, और denoiser worklet bare-specifier import resolution से बचने के लिए एक अकेले self-contained esbuild bundle के रूप में भेजा जाता है।

29 में से भाग 23। पिछला: भाग 22 - वो बादल जिन्हें आप light कर सकते हैं, और वह culling जिसे खिलाना पड़ता है अगला: भाग 24 - एक world को save करना, और वह हवा जो आप देख सकते हैं सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide

लिखा है Oleg Sidorkin ने, Cinevva के CTO और को-फाउंडर

यहाँ नए हैं? सीरीज़ गाइड देखिए। यह बताती है कि spike क्या होता है और सारे भागों के लिंक देती है।

भाग 21 एक ऐसी rendering technique के बारे में था जिसने फ़ायदा नहीं दिया। इस भाग में एक ऐसी है जिसने दिया, और एक जिसे काम करने के लिए एक सावधान fix की ज़रूरत पड़ी। Spike 43 sky है: एक physically based atmosphere और volumetric clouds, वह नींव जो किसी scene को tech demo की जगह एक असली जगह जैसा दिखाती है। Spike 44 meshlet-style GPU culling है, जहाँ सबक़ यह था कि occlusion test उतना ही अच्छा होता है जितने अच्छे occluders आप उसे खिलाते हैं।

physics से बनी sky, gradient से नहीं

Spike 43 नए tab में खोलें ↗ · सोर्स देखें

लगभग हर cinematic weather effect दो हिस्सों की infrastructure पर टिका होता है: एक physically based atmosphere, ताकि sky का रंग और sun का रंग किसी हाथ से tune किए gradient की जगह physics से time of day का पीछा करें, और एक volumetric cloud volume, ताकि sky में किसी baked cubemap की जगह 3D structure हो। Spike 43 ठीक यही जोड़ी मौजूदा WebGPU और TSL stack पर बनाता है, इससे ज़्यादा कुछ नहीं, क्योंकि एक बार ये दोनों मौजूद हो जाएँ तो बाक़ी weather stack (fog, god rays, गीली सतहें, बर्फ़) छोटे और जाने-पहचाने follow-ons की एक कतार बन जाती है।

Atmosphere Hillaire 2020 model है, lookup tables का एक सेट जो WGSL compute shaders में compute होता है। एक transmittance table sun light को Rayleigh, Mie, और ozone density profile के आरपार integrate करती है और सिर्फ़ तब फिर से compute होती है जब sun हिलता है। एक sky-view table हर frame फिर से bake होती है क्योंकि यह इतनी सस्ती है कि इसे gate करना code के लायक़ नहीं, horizon के आसपास एक non-linear parameterization के साथ ताकि banding न आए। Multiple scattering अभी proper table की जगह एक analytic fit इस्तेमाल करता है, और sunsets सही दिखते हैं, तो यह शॉर्टकट अच्छे से छिपा हुआ है। बादल एक Schneider Nubis-शैली का ray-march हैं जो एक horizontal slab के आरपार जाता है, shape एक 128³ Perlin-Worley texture से आता है जिसे एक 32³ Worley texture ने eroded किया है, दोनों boot पर compute में bake होते हैं बिना किसी network fetch के, Beer's law extinction, एक dual-lobe phase function, और एक powder approximation से रोशन। मुख्य coupling यह है कि बादल का sun color हर step पर वही transmittance table sample करता है, तो cloud lighting दूसरे tuning pass के बिना sunset का पीछा करती है।

एक M1 पर पूरी चीज़ half-resolution clouds पर 1.1 से 2.0 ms पर बैठती है, 6 ms के budget से ख़ासा नीचे, लगभग 14 MB GPU memory इस्तेमाल करते हुए, 100 FPS से ऊपर चलते हुए। दोनों thesis के दावे practice में टिके रहे। Sunset हीरो शॉट है, वह पल जो renderer को cinematic महसूस कराता है, और यह per-time-of-day tuning के बिना physics से ही निकल आता है। और एक ख़ुशनुमा इत्तेफ़ाक़: cloud slab को 800 m और 4000 m के बीच parameterize करने पर, horizon पर दूर के बादल एक नीची camera से dark mountain ridges जैसे दिखते हैं, जो दुनिया को background terrain देता है बिना किसी के background terrain model किए।

एक architecture नोट याद रखने लायक़ है। स्वाभाविक तरीक़ा यह है कि पहले sky को swap chain में paint किया जाए, फिर three.js को autoClear = false के साथ उसके ऊपर geometry draw करने दिया जाए। यह r184 पर WebGPU renderer के साथ नहीं टिकता, क्योंकि वह flag color load op को उस तरह gate नहीं करता जैसे WebGL में करता है, तो three.js हर frame sky को मिटा देता है। Fix यह है कि three.js को एक offscreen target में render किया जाए और final composite (mix(skyCloud, scene, scene.alpha) फिर ACES फिर sRGB) अपने ख़ुद के एक pass में किया जाए जो swap chain का मालिक हो।

ऐसी culling जो अपने occluders जितनी ही अच्छी है

Spike 44 नए tab में खोलें ↗ · सोर्स देखें

Spike 44 चार rendering modes को एक-दूसरे के ख़िलाफ़ bench करता है: plain forward, CPU cluster culling, GPU compute culling, और Hi-Z occlusion culling के साथ एक visibility buffer। Hi-Z path दिलचस्प वाला है, और इसमें एक चुपचाप छिपा bug था: इसका HUD कहता था occlusion चालू है, मगर "Hi-Z killed" counter हमेशा बिल्कुल 0.0% पर बैठा रहता था। Frustum culling काम कर रहा था, तो cull shader का upstream ठीक था। Occlusion वाला आधा हिस्सा एक no-op था जो पूरी क़ीमत चुका रहा था।

एक Hi-Z occlusion test एक cluster के bounding box को screen पर project करता है, एक depth-pyramid mip level चुनता है ताकि screen rectangle लगभग 2×2 texels का हो, उस rectangle में सबसे गहरे occluder की depth sample करता है, और cluster को reject कर देता है अगर उसका सबसे क़रीबी point अब भी उस occluder से दूर हो। Depth pyramid हर frame बनती है, mip 0 को एक opaque-depth pre-pass से seed करके और ऊपर तक max-reduce करके। Opaque pre-pass जानबूझकर सिर्फ़ ठोस occluders शामिल करता है, ज़मीन और per-tree trunk proxies, क्योंकि alpha-tested foliage ऐसे gaps बना देती जो एक max-reduce को धोखा दे जाते।

Bug geometric था, logical नहीं। Trunk proxy 0.5 m गुणा 4 m गुणा 0.5 m का box था। 30 m पर यह screen पर लगभग 17 pixels पर project होता है। मगर एक आम 50 m grass cluster mip 5 चुनता है, जहाँ हर texel 32 source pixels ढकता है। एक 17-pixel का trunk एक भी mip-5 texel को पूरा नहीं ढकता, तो trunk को छूता हर texel आसपास की ज़मीन को भी छूता है। सबसे पहला 2×2 max-reduce बड़ी depth value चुन लेता है, जो trunk के पीछे की दूर वाली ज़मीन है, और trunk की depth पहली ही reduction पर मिट जाती है। mip 5 तक pyramid लगभग हर जगह ground depth रखती है, cluster कभी ज़मीन से दूर नहीं होता, और कुछ भी कभी occlude नहीं होता।

Fix यह है कि proxy को इतना बड़ा बनाया जाए कि वह जिन texels में गिरे उन पर हावी हो जाए, उसे पेड़ की लकड़ी की जगह उसके silhouette के हिसाब से size दिया जाए। लगभग 2 m गुणा 6 m गुणा 2 m का proxy असली canopy से अब भी छोटा है, तो gaps के बीच से दिखने वाली पत्तियाँ कभी over-cull नहीं होतीं, मगर यह इतना बड़ा है कि उन दूरियों तक max-reduce में टिक जाए जो मायने रखती हैं, और occlusion counter फ़ौरन non-zero हो गया। यह सीख production engine के लिए एक नियम में बदल जाती है: जिस भी चीज़ पर Hi-Z occluder के तौर पर भरोसा किया जाए, उसे उसके on-screen silhouette के हिसाब से size देना होगा, क्योंकि खुली foliage वाले scenes में Hi-Z की असरदारी relevant mip पर occluder coverage से तय होती है, depth-test math की elegance से नहीं। Grass-बनाम-grass occlusion तो वैसे भी fire नहीं हो सकता, क्योंकि एक पत्ती उसके नीचे की ज़मीन जितनी ही depth पर बैठती है, तो असली जीत पेड़ों के दूर की foliage को occlude करने और पेड़ों के पेड़ों को occlude करने में है।

इस अध्याय में बताई गई technology

Hillaire 2020 atmosphere LUTs. एक transmittance table (Rayleigh, Mie, और ozone profile के आरपार sun light) जो सिर्फ़ sun के हिलने पर फिर से compute होती है, साथ में एक per-frame sky-view table एक non-linear horizon parameterization के साथ, physically based sky और sun colors देती है जो किसी हाथ से tune किए gradient के बिना time of day का पीछा करते हैं। एक analytic multiple-scattering fit पूरी table की जगह तब तक काम चलाता है जब तक कोई artifact proper bake पर मजबूर न कर दे। Sunset per-time-of-day tuning के बिना physics से ही निकल आता है।

Schneider Nubis volumetric clouds. एक horizontal slab के आरपार एक ray-march, जिसे एक boot-baked 128³ Perlin-Worley texture shape देता है और एक 32³ Worley texture eroded करता है, Beer's law extinction, एक dual-lobe phase, और एक powder term से रोशन। हर step पर उसी transmittance table से cloud sun color sample करने से cloud lighting बिना किसी ख़र्च के sunrise और sunset का पीछा करती है। Half-resolution ray-march आम दूरी पर बिना किसी दिखने वाले quality loss के full से लगभग 4× सस्ता चलता है, यही standard production trade है।

r184 पर raw WebGPU को three.js के साथ compositing करना. Sky को swap chain में paint करके और three.js geometry को autoClear = false के साथ उसके ऊपर draw करना नाकाम रहता है क्योंकि वह flag WebGPU backend में color load op को gate नहीं करता। three.js को एक offscreen RGBA16F target में render करें और final mix साथ ही tone-map साथ ही sRGB एक ऐसे pass में करें जो swap chain का मालिक हो।

Hi-Z occlusion culling और occluder sizing. Max-reduce से बनी एक depth pyramid एक GPU cull pass को उन clusters को reject करने देती है जिनका सबसे क़रीबी point उनके screen rectangle में सबसे गहरे occluder के पीछे हो। यह test चुपचाप कुछ नहीं करता अगर occluders इतने छोटे हों कि चुने गए mip पर एक texel पर हावी न हो सकें, क्योंकि पहला max-reduce occluder की depth को उसके पीछे के दूर वाले background से बदल देता है। Occluders को उनके on-screen silhouette के हिसाब से size देना होगा, उनके physical core के हिसाब से नहीं। देखें GPU-driven LOD।

29 में से भाग 22। पिछला: भाग 21 - एक तेज़ renderer जो तेज़ नहीं निकला अगला: भाग 23 - पचास avatars और कमरे में एक आवाज़ सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहाँ नए हैं? series guide का इस्तेमाल करें। यह बताती है कि spike क्या होता है और सभी भागों को link करती है।

भाग 20 ने एक सपाट quad पर surface की गहराई का भ्रम बनाया। यह भाग एक render-architecture फ़ैसले के बारे में है, और यही वह spike है जहाँ किताबी जवाब हमारे hardware के लिए गलत निकला। सवाल यह था: third-person camera के नीचे cinematic-घनत्व वाली alpha-tested घास के लिए, 200-player घनत्व तक पहुँचने से पहले क्या हमें एक visibility buffer चाहिए? चलन वाली सलाह ज़ोरदार हाँ कहती है। हमने इसे बनाया, मापा, और जवाब ना था।

वह तकनीक जिसकी हर कोई सिफ़ारिश करता है

Spike 40 को नए tab में खोलें ↗ · View source

एक visibility buffer rendering को दो pass में बाँट देता है। Pass 1 geometry को rasterize करता है और बिना कोई shading किए सिर्फ़ triangle और instance ID एक compact integer target में depth के साथ लिखता है। Pass 2 एक fullscreen pass है जो हर ढके हुए pixel पर ID पढ़ता है, उस triangle के vertices दोबारा fetch करता है, interpolated attributes दोबारा बनाता है, और हर दिखने वाले pixel को ठीक एक बार shade करता है। दावा perfect overdraw rejection का है: depth test उन fragments के खिलाफ़ चलता है जिन्होंने कोई shading काम नहीं किया, इसलिए महँगा material सिर्फ़ उसी पर चलता है जो आप असल में देखते हैं।

यह spike एक ही canvas और एक ही device पर दो रास्ते चलाता है ताकि अकेला variable यह रहे कि shading कहाँ रहता है। Forward रास्ता three.js के ज़रिए एक सामान्य MeshStandardNodeMaterial है। Vis-buffer रास्ता three.js के बाहर चलने वाली एक कच्ची two-pass WebGPU pipeline है, जो three.js की घास का texture सीधे backend से पढ़ता है, pass 1 में एक RG32Uint target में (instanceId, triId) लिखता है और pass 2 में lighting हल करता है। दोनों एक ही ground-truth lighting setup साझा करते हैं।

दो implementation बातें ध्यान रखने लायक हैं। WebGPU में अब भी fragment shaders में कोई portable primitive_index builtin नहीं है, इसलिए तरकीब यह है कि un-indexed geometry पर per-vertex triangle ID bake किया जाए और उसे flat-interpolated पढ़ा जाए, जिसमें vertex count 3× हो जाता है पर 12-vertex घास card पर यह नगण्य है। और three.js के renderer के साथ canvas साझा करना ज़्यादातर कोई बड़ी बात नहीं, जब तक आप कभी context को reconfigure न करें या canvas dimensions को न छुएँ, क्योंकि दोनों three.js के अधीन हैं। Forward रास्ते की timing करना झंझट भरा हिस्सा था, क्योंकि three.js अपने render pass के अंदर GPU timestamp queries डालने का कोई hook नहीं देता; इसका जुगाड़ यह है कि उसके काम को दो no-op timestamp pass से घेर दिया जाए, जो उसके पहले और बाद में submit किए जाते हैं और GPU उन्हें submission क्रम में चलाता है।

आँकड़े उल्टी दिशा में जाते हैं

~1080p पर एक M-series Mac पर, 80 m के मैदान पर cross-card घास की पत्तियों के साथ:

50,000 instances पर vis-buffer रास्ता 25% से जीता, 4.13 ms बनाम forward के 5.51 ms। 100,000 पर यह बराबरी पर रहा। 200,000 instances पर forward 44% से जीता, 5.44 ms बनाम vis-buffer के 7.80 ms। घनत्व बढ़ने के साथ vis-buffer रास्ता अपेक्षाकृत खराब होता जाता है, जो उस लोककथा के बिलकुल उलट है जो कहती है कि यह तभी जीतता है जब overdraw भारी हो।

Forward क्यों टिका रहता है

Apple Silicon GPUs tile-based deferred renderers हैं, और यह पूरा गणित बदल देता है। TBDR पर forward shading में एक hidden-surface-removal चरण होता है जो fragment shader से पहले चलता है: rasterizer एक tile पर map होने वाले हर fragment को इकट्ठा करता है, उन्हें depth के हिसाब से sort करता है, और सिर्फ़ बचे हुए (post-alpha-test) ही fragment shader तक पहुँचते हैं। तो forward रास्ता पहले से ही visibility buffer के "हर pixel पर एक बार shade" वाले वादे का ज़्यादातर हिस्सा मुफ़्त में, hardware के अंदर, चुका रहा है। जैसे-जैसे पत्तियाँ screen पर भरती हैं, कोई shading चलने से पहले HSR पर ज़्यादा fragments reject हो जाते हैं, और forward की असरदार per-pixel लागत overdraw के साथ बढ़ने के बजाय लगभग सपाट बनी रहती है।

Vis-buffer रास्ते के pass 1 को वही TBDR फ़ायदा मिलता है। दिक्कत पूरी की पूरी pass 2 में है। Pass 2 हर pixel का instance matrix एक buffer से पढ़ता है जो 200,000 instances पर 12.8 MB का है, किसी भी GPU cache से कहीं बड़ा। Screen पर पास-पास के pixel आमतौर पर अलग-अलग घास instances के होते हैं (scatter एक jittered grid है, इसलिए पड़ोसी पत्तियों के instance ID मनमाने होते हैं), इसलिए उस buffer से टकराने वाली हर wave divergently cache miss करती है। वह असंगत random access अकेले ही हर frame करीब 4 ms छुपा लेता है। Forward इससे पूरी तरह बच जाता है क्योंकि instance matrix per-instance attribute रास्ते से vertex के साथ ही आ जाता है, तो जब तक fragment shader चलता है तब तक transformed vertex data पहले से tile-local registers में होता है, megabyte-scale random read की ज़रूरत नहीं।

यही वह लागत है जिसे amortize करने के लिए Nanite की material-classification pass मौजूद है: pixels को instance के हिसाब से bin करो और sorted compute waves dispatch करो ताकि हर wave के reads coherent हों। हमारे पास वह नहीं है। एक मोटे अनुमान के मुताबिक pixels को instance के हिसाब से sort करने से वह 4 ms शायद 1.5 से 2 ms तक गिर जाएगा और crossover को 400,000 से 500,000 instances तक धकेल देगा। पर यह एक ऐसी architecture पर optimizations जमा करना है जो यहाँ शुरू से ही जीत नहीं रही।

ईमानदार निष्कर्ष, और वह audit जिसने इसे कमाया

Apple Silicon WebGPU पर alpha-tested cross-card foliage के लिए, three.js की TSL pipeline वाला forward रास्ता पहले से ही vis-buffer लागत के बराबर या उससे नीचे है, और vis-buffer की पूरी plumbing 200,000 instances से काफ़ी आगे तक कुछ भी दिखने लायक नहीं देती और तभी देती है जब आप साथ में एक sorting या binning pass भी जोड़ें। production engine के लिए व्यावहारिक फ़ैसला यह है कि पिछले spikes का forward प्लस LOD प्लस imposter stack बनाए रखें और vis-buffer infrastructure में तब तक निवेश न करें जब तक या तो हम discrete NVIDIA या AMD GPUs को प्रमुख deployment के रूप में न साधें (जहाँ overdraw लागत ज़्यादा linear होती है) या हम एक meshlet architecture पर न चले जाएँ जहाँ vis-buffer वैसे भी स्वाभाविक output है।

चूँकि वह नतीजा अंतर्ज्ञान के उलट है, निष्कर्ष की कोई कीमत तभी है जब तुलना निष्पक्ष हो, इसलिए spike को एक पूरा audit pass मिला। कई असली bug सामने आए और ठीक हुए: एक blade-scale slider जो चुपचाप दोनों रास्तों को desync कर रहा था, आधी forward पत्तियाँ anti-parallel normals की वजह से घुप अँधेरी render हो रही थीं (canonical upward-normal foliage तरकीब से ठीक हुआ), और vis-buffer energy-conserving 1/π के बजाय एक हाथ से चुने Lambert factor, एक hardcoded ambient term, और गायब tone mapping के कारण करीब 2× ज़्यादा चमकीला पढ़ रहा था। fix ने three.js की हूबहू ACES filmic curve को WGSL में copy किया और हर frame असली scene lights से light colors और intensities पढ़ता है। बची हुई जानी-पहचानी कमी, pass 2 में गायब direct specular, तुलना को vis-buffer के पक्ष में झुकाती है, यानी forward सख्ती से हर pixel पर ज़्यादा काम कर रहा है और फिर भी उच्च घनत्व पर जीत रहा है। इससे मुख्य निष्कर्ष आशावादी नहीं, बल्कि conservative बन जाता है। एक चेतावनी टिकती है: यह सब M-series-विशिष्ट है, और एक discrete card पर crossover पलट भी सकता है, इसलिए non-Apple targets के लिए stack पक्का करने से पहले इसे दोबारा चलाना अच्छा रहेगा।

इस अध्याय में संदर्भित तकनीक

Visibility buffer rendering. Pass 1 geometry को rasterize करता है और बिना कोई shading किए सिर्फ़ triangle और instance ID plus depth लिखता है। Pass 2 एक fullscreen resolve है जो हर ढके हुए pixel पर ID पढ़ता है, source triangle दोबारा fetch करता है, perspective-correct barycentric attributes दोबारा बनाता है, और हर दिखने वाले pixel को एक बार shade करता है। चूँकि WebGPU में portable fragment primitive_index नहीं है, triangle ID को un-indexed geometry पर एक flat-interpolated per-vertex attribute के रूप में bake किया जाता है।

TBDR hidden-surface removal बनाम deferred resolve. एक tile-based deferred GPU (Apple Silicon) पर, forward shading fragment shader चलने से पहले ही occluded fragments को reject कर देता है, इसलिए यह visibility buffer के shade-once फ़ायदे का ज़्यादातर हिस्सा मुफ़्त में पकड़ लेता है, और overdraw बढ़ने पर इसकी per-pixel लागत लगभग सपाट रहती है। बजाय इसके एक vis-buffer resolve pass एक बड़े per-instance buffer (200k instances पर 12.8 MB) में असंगत random access की कीमत चुकाता है, जो उच्च घनत्व पर हावी हो जाता है, जब तक कि pixels को पहले instance के हिसाब से sort या bin न किया जाए, जैसे Nanite की material classification करती है।

three.js के WebGPURenderer के साथ canvas साझा करना. कच्चे WebGPU command buffers साझा queue पर three.js submissions के साथ सही ढंग से interleave होते हैं, जब तक आप context.configure() दोबारा कभी न call करें या canvas.width/height न लिखें, क्योंकि दोनों renderer के अधीन हैं। Forward-path GPU timing, जिसके लिए three.js कोई hook नहीं देता, उसके render call के इर्द-गिर्द submit किए गए दो no-op timestamp render passes से घेरी जा सकती है, क्योंकि GPU command buffers को submission क्रम में चलाता है।

एक अंतर्ज्ञान-विरोधी benchmark को validate करना. एक चौंकाने वाला performance नतीजा उतना ही भरोसेमंद होता है जितनी तुलना की निष्पक्षता। दोनों रास्तों को एक जैसे scene content और shading पर audit करना (matched ACES tone mapping, energy-conserving Lambert, एक ही objects से पढ़ी गई lights, एक जैसा blade scale) ही वह चीज़ है जिसने "vis-buffer धीमा है" को एक संभावित measurement artifact से एक टिकाऊ निष्कर्ष में बदला, बची हुई एक असमानता conservative दिशा में झुकी हुई।

भाग 21 / 29। पिछला: भाग 20 - एक सपाट plane पर गहराई का भ्रम अगला: भाग 22 - बादल जिनके बीच से आप उड़ सकते हैं, और culling जो असल में काम आती है Series guide: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहाँ नए हैं? series guide का इस्तेमाल करें। यह बताती है कि spike क्या होता है और सभी भागों को link करती है।

भाग 19 ने दूरी पर पूरे पेड़ का भ्रम बनाने के लिए एक सपाट quad का इस्तेमाल किया। यह भाग पास से गहराई का भ्रम बनाने के लिए एक सपाट quad का इस्तेमाल करता है: parallax occlusion mapping, वह तरकीब जो एक cobblestone सड़क को ऐसा दिखाती है जैसे उसमें 5 cm की धंसी हुई grouting हो, बिना एक भी अतिरिक्त vertex खर्च किए। मकसद यह था कि इसे production stack (Three.js r184, WebGPU, TSL) पर उतारा जाए ताकि terrain detail materials उस गहराई के भ्रम को वहाँ ले जा सकें जहाँ वह मायने रखता है और बाकी हर जगह सपाट-texture जितनी ही लागत चुकाएँ।

गहराई का भ्रम बनाने के तीन तरीके, अगल-बगल

Spike 39 को नए tab में खोलें ↗ · Source देखें

यह spike तीन सपाट 5×5 m planes अगल-बगल रखता है, सभी का material scaffold एक जैसा, फर्क सिर्फ उस UV में जो samplers को feed करता है। Flat texture को सीधा sample करता है, यह reference baseline है। Single-sample parallax UV को view direction के साथ एक बार उस बिंदु की height के हिसाब से shift करता है, जो सस्ता है और कम amplitude पर ठीक है पर grazing angles पर तैरने लगता है। POM tangent space में ray-march करता है: view ray के साथ step बढ़ाओ, वह पहली layer ढूँढो जहाँ ray heightfield के नीचे जाती है, और crossing को परिष्कृत करो। Tangent space सरल बना रहता है क्योंकि हर test plane axis-aligned है, इसलिए view direction पूरे per-vertex TBN matrix की जगह बस कुछ sign flips के साथ tangent space में पैक हो जाती है। Texture set live Polyhaven file API से खींचता है, वही path जो भाग 17 की model search ने इस्तेमाल किया था।

दो WebGPU दीवारें, और एक branchless ray-march

किताबी POM loop पहली crossing पर search से बाहर निकल जाता है। r184 पर वह काम नहीं करता, दो अलग वजहों से। If(...).and(...) बिना errors के compile हुआ पर ऐसा WGSL पैदा किया जहाँ loop body कभी चली ही नहीं, इसलिए post-loop refinement कचरे पर चला और plane लगभग सफेद render हुआ। और standalone node के तौर पर Break() r184 build में आया ही नहीं था, इसलिए काम करने वाले If के साथ भी "पहली crossing पर रुको" कहने का कोई तरीका नहीं था। दोनों इस version range में If और Loop सीमाओं के पार TSL control flow के over-optimizing से जुड़े जाने-माने three.js issues तक जाते हैं।

Rewrite branchless है। हर iteration बिना शर्त texture sample करता है, जो texture access को uniform control flow में रखता है जैसा WGSL spec चाहता है, फिर नई state को एक float के रूप में रखे done flag के जरिए मोड़ देता है। एक बार done 1 पर पलटता है, तो per-iteration mix calls "state को अपरिवर्तित रखो" में degenerate हो जाती हैं, जो break का branchless समकक्ष है। done flag एक step helper से बनता है जिसे 0.5 + 0.5 × sign(x + ε) के रूप में लागू किया गया है क्योंकि boolean-to-float coercion r18x line में अनिश्चित रहा है और sign() हर जगह सुरक्षित है। लागत यह है कि हर fragment सभी 64 iterations चलाता है चाहे वह असल में कहीं भी cross करे, पर fragment scale पर यह सही सौदा है: runtime वैसे भी max steps पर gate करता है, और एक असली GPU भी एक "असली" break के पार speculate कर लेता। यहाँ एक साफ fallback मायने रखता है, एक अंतिम mix(baseUV, refined, done), ताकि zero amplitude पर (distance fade के दूर वाले छोर पर) कोई fragment cross न करे, done 0 रहे, और POM material सपाट से bit-identical हो। यही तो distance-LOD तरकीब का पूरा मकसद है: जहाँ effect वैसे भी sub-pixel है वहाँ सपाट लागत में collapse कर दो।

Bug गणित की चूक नहीं, अनुशासन की चूक थी

Branchless version चला पर विकृत दिखा, मध्यम amplitude पर streaky horizontal artifacts और कम amplitude पर सूक्ष्म-रूप-से-गलत-पर-साफ-नहीं नतीजा। Fix एक एक-line prompt से आया: जाओ canonical reference पढ़ो। जिस LlamAcademy tutorial ने इसे प्रेरित किया वह बस एक Unity ShaderGraph node है, इसलिए असली implementation Unity के PerPixelDisplacement.hlsl में रहता है। उसे line दर line पढ़ने से तीन semantic फर्क सामने आए जो मैंने अनजाने में डाल दिए थे: ray-height baseline में एक off-by-one (Unity loop से पहले एक initial advance करता है, इसलिए मेरा frame of reference पूरे एक step से phase से बाहर था, करीब आधे समय crossings को गलत layer में उतार रहा था), max offset पर एक sign convention जिस पर refinement step निर्भर करता है, और एक cumulative-offset बनाम cumulative-UV bookkeeping चुनाव जिसने मेरे refinement गणित को ज्यादा मेहनत करवाई और sign को उलझा दिया।

मूल वजह कोई एक error नहीं थी, वह दो references को मिलाना थी। मैंने LearnOpenGL POM tutorial को अपना guide बनाया था, जो मिलते-जुलते पर अलग sign conventions और एक अलग refinement formula इस्तेमाल करता है, और एक mongrel हालत में जा पहुँचा जहाँ दो-तिहाई गणित एक source से मेल खाता था और एक-तिहाई दूसरे से। Rewrite Unity के HLSL का TSL में लगभग verbatim port है, वही variable names, वही initial advance, वही refinement, ऊपर branchless done flag रखे हुए। यह सबक साथ ले जाने लायक है: जब आप किसी और stack से एक known-good shader port करें, तो पहले उसे उन्हीं names के साथ line-दर-line port करो, फिर local style के लिए refactor करो। Port के बीच में किसी दूसरे reference के खिलाफ दोबारा derive मत करो।

एक reference plane जो झूठ नहीं बोल सकता

Side-by-side में स्पष्ट चीज़ गायब थी: एक real-geometry plane। उसके बिना "POM काफी अच्छा दिखता है" अप्रमाणनीय है। किसके मुकाबले अच्छा? तो spike ने एक चौथा plane जोड़ा, वही heightmap असली vertex positions के जरिए धकेला हुआ। WebGPU में hardware tessellation नहीं है (यह spec में है ही नहीं, Metal compatibility के लिए हटा दिया गया), इसलिए विकल्प एक सघन-रूप से subdivided plane है (256×256 segments, 131,072 triangles) जिसमें vertex stage में vertex displacement है। वही amplitude uniform POM और geometry plane दोनों को चलाता है, इसलिए वे साथ fade होते हैं और तुलना हर दूरी पर apples-to-apples बनी रहती है।

Screen पर ground truth होने से गुणात्मक दावे मापने योग्य हो गए। नीचे देखते हुए 16° orbit पर, POM और tessellated plane internal shading पर सहमत हैं। Grazing angles पर वे ठीक वहीं अलग होते हैं जहाँ उन्हें होना चाहिए: POM geometry के बिल्कुल सीधे rectangular edge पर clamp होता है, जबकि असली mesh असली peaks और valleys का एक उबड़-खाबड़ horizon profile दिखाता है जो रोशनी पकड़ता है। तो POM का edge "तैरना" अब साबित होकर algorithm में अंतर्निहित है, texture या lighting का artifact नहीं। दोनों लागत के आकार भी साफ हैं: POM fragment-bound है (लागत covered pixels के साथ बढ़ती है), tessellated plane vertex-bound है (लागत coverage की परवाह किए बिना mesh density के साथ बढ़ती है)। एक terrain chunk के लिए, जो पहले से एक heightmap-driven plane की vertex लागत चुकाता है, sub-mesh detail के लिए POM सही जवाब है।

Reference plane ने एक सूक्ष्म UX bug भी पकड़ा। User ने गौर किया कि amplitude बढ़ने पर surface धँसता दिखता था। यह Unity की उस convention तक जाता है जो geometric plane को heightfield के top के रूप में मानती है, इसलिए peaks flush anchor होते हैं और बाकी सब नीचे की ओर parallax होता है, औसत surface को सपाट baseline से (1 − mean_h) × amplitude जितना नीचे खींचते हुए। Fix convention को फिर से center करता है ताकि h = 0.5 plane हो, peaks camera की ओर उठें और valleys धँसें। Algorithm ठीक वैसे ही चलता है जैसे Unity बताता है; spike बस output को आधे offset से post-process करता है ताकि slider खींचने वाले इंसान के लिए "amplitude" का जो मतलब होना चाहिए उससे मेल खाए।

एक और चीज़ reference plane ने सुलझाई। एक "Steps" slider कुछ करता नहीं दिखता था, जो एक plumbing bug जैसा लगता था पर था नहीं। linear search के बाद का तीन-iteration secant refinement इतना अच्छा है (Tatarchuk के 2006 के POM paper में लिखा है कि 4-step search plus 3-step secant नज़र से एक 64-step search से अलग नहीं किया जा सकता) कि एक smooth heightmap पर 4 से 64 तक हर step count उसी sub-texel UV पर converge हो जाता है। Fix एक toggle था, re-plumbing नहीं: secant बंद करो और step slider crossing precision पर एकमात्र control बन जाता है, इसलिए 4 पर गिराने से cobblestone साफ-साफ stair-step करता है और 64 पर चढ़ाने से वापस smooth हो जाता है। Toggle एक 0/1 uniform है जो बंद होने पर हर secant state update को no-op में mix कर देता है, इसलिए toggle करने से material कभी rebuild नहीं होता और कभी stutter नहीं करता।

इस अध्याय में संदर्भित तकनीक

TSL में parallax occlusion mapping. POM tangent space में एक heightfield के बीच से view direction पर ray-march करता है, वह पहली layer ढूँढता है जहाँ ray surface के नीचे गिरती है, और crossing को परिष्कृत करता है, बिना अतिरिक्त geometry के एक सपाट quad पर धँसी-mortar गहराई पैदा करता है। एक अंतिम mix(baseUV, refined, done) material को सपाट से bit-identical बना देता है जब कोई fragment cross नहीं करता, और यही वह चीज़ है जो distance-LOD amplitude attenuation को दूरी पर लागत को सपाट-texture लागत में collapse करने देती है। देखें terrain materials।

WebGPU control flow के लिए branchless loops. Three.js r184 पर, TSL If(...).and(...) ऐसे WGSL में compile हो सकता है जिसकी loop body कभी चलती नहीं, और standalone Break() उपलब्ध नहीं है। Portable pattern है हर iteration में एक बिना शर्त texture sample (WGSL spec के अनुसार texture access को uniform control flow में रखना) plus एक float के रूप में रखा done flag जो set होने पर हर state update को no-op में mix कर देता है। sign(x + ε) से बना एक step helper अविश्वसनीय boolean-to-float coercion से बचाता है। लागत early-out बिंदु की परवाह किए बिना constant max iterations है, fragment scale पर सही सौदा।

Verbatim shader porting. किसी और engine से एक known-good shader port करना पहले original के variable names के साथ line-दर-line होना चाहिए, local style के लिए refactor दूसरे नंबर पर। दो references मिलाने (Unity का PerPixelDisplacement.hlsl और LearnOpenGL tutorial) ने एक mongrel पैदा किया जिसमें एक off-by-one ray baseline, एक उल्टा offset sign, और एक refinement formula थी जिसका clamp out-of-range weights को spatial discontinuities के रूप में छिपा देता था। एक canonical ground truth, दोबारा-derivation नहीं।

Vertex-displaced ground-truth reference. WebGPU में hardware tessellation न होने पर, vertex stage में displaced एक सघन-रूप से subdivided plane (256² segments) एक fragment-stage भ्रम को validate करने के लिए असली geometry के तौर पर खड़ा होता है। दोनों को एक ही amplitude uniform से चलाना तुलना को दूरी भर ईमानदार रखता है। POM fragment-bound है (covered pixels के साथ बढ़ता है) और geometry plane vertex-bound है (mesh density के साथ बढ़ता है), इसलिए वे ठीक silhouette edges पर अलग होते हैं, साबित करते हुए कि POM का edge swim अंतर्निहित है, artifact नहीं।

29 में से भाग 20। पिछला: भाग 19 - वह imposter जिसे एक जंगल झेलना है अगला: भाग 21 - एक तेज़ renderer जो तेज़ नहीं था Series guide: /hi/blog/2026-02-25-open-world-browser-series-guide

लिखा है Oleg Sidorkin ने, Cinevva के CTO और Co-Founder

यहाँ नए हैं? series guide देखें। यह समझाती है कि spike क्या होता है और सभी भागों को लिंक करती है।

भाग 18 ने creators को एक brush दिया जो किसी पहाड़ी को पेड़ों से भर देता है। पेच यह है कि जब स्क्रीन पर हज़ारों पेड़ हों तो उनकी कीमत क्या होती है। एक दूर का पेड़ चार pixel देने के लिए 2,000 triangles की ज़रूरत नहीं रखता। यह भाग सबसे गहरा LOD है: imposter, एक चपटा quad जो पेड़ की एक तस्वीर पहने हुए है, और "एक पेड़ जो सही दिखता है" से लेकर GPU पर उनके दस लाख तक का रास्ता।

एक पेड़ billboard पर दो textures है

Spike 38 को नए tab में खोलें ↗ · Source देखें

एक imposter किसी prop को देखने के कोणों के एक grid से दो texture atlases में पहले से render कर देता है, एक color के लिए और एक world-space normals के लिए, फिर runtime पर एक ही camera-facing quad दिखाता है जो वह tile sample करता है जो मौजूदा view से मेल खाती है। Bake प्रति tile दो passes का होता है: diffuse एक unlit material के साथ ताकि texture में कोई lighting bake न हो, और normals को normalWorld × 0.5 + 0.5 के रूप में encode किया जाता है जिसमें alpha source से आगे भेजा जाता है ताकि silhouette pixel-दर-pixel मेल खाए। Runtime material एक पूरा MeshStandardNodeMaterial है, इसलिए imposter अब भी किसी भी दूसरी surface की तरह scene का sun और IBL लेता है। फायदा geometry में है: हज़ारों triangles के बजाय एक quad, और detail एक 1 MB texture में रहती है।

इसे अपने अलग spike में खींच लाना अपने आप में एक सबक था। Imposter spike 37 के scatter system के अंदर सबसे गहरे LOD के रूप में शुरू हुआ था, और bake पर हर iteration को पूरी scatter pipeline के ज़रिए test करना पड़ता था, जहाँ bake की सही-गलती instance-matrix migration और LOD swaps में उलझी रहती थी। इसे एक prop, एक quad तक अलग करके, original के साथ कंधे से कंधा मिलाकर रखने से iteration का समय मिनटों से सेकंडों तक गिर गया।

जब किताबी जवाब ही गलत जवाब हो

पहले implementation में octahedral encoding इस्तेमाल हुई, जो sphere directions को एक square में pack करने की किताबी mapping है। इसने numerical roundtrip tests पास किए, और फिर भी user बार-बार imposter के ऐसे tile पर snap हो जाने के screenshot भेजता रहा जो पेड़ को सामने से देखने के बजाय थोड़ा ऊपर से देखता हुआ लगता था। छह दौर की fixes आईं (एक per-quad view-direction uniform, एक square bake aspect, debug materials, static billboarding) और हर एक सचमुच ज़रूरी थी पर कोई भी असली bug नहीं था। Fix तभी आया जब "इसे शुरू से फिर सोचो, KISS, कोई band-aid नहीं।"

Rewrite ने octahedral folding को फेंक दिया और सादे azimuth बनाम elevation को अपनाया: az = atan2(dir.x, dir.z), el = asin(dir.y), uv = (az/2π, el/π + ½)। यही पूरी encoding है, कोई L1 normalize नहीं, sign-of-zero के कोई corner cases नहीं। यह यहाँ बेहतर इसलिए नहीं है कि यह ज़्यादा सटीक है (यह एक कम uniform sphere sample करता है), बल्कि इसलिए कि CPU cell-picker और GPU shader एक ही primitives इस्तेमाल करते हैं, इसलिए वे किसी boundary direction पर उस तरह असहमत नहीं हो सकते जैसे octahedral जोड़ी चुपचाप हो जाती थी। Atlas एक contact sheet की तरह पढ़ा जाता है: column है prop के चारों ओर का कोण, row है elevation, overlay में एक नज़र में साफ दिखता है।

इसके बाद भी "थोड़ा ऊपर से देखता है" वाली शिकायत बनी रही, और इसकी वजह एक quantization चुनाव थी, encoding नहीं। एक 4×4 grid के साथ row centers ±22.5° और ±67.5° पर आते हैं, इसलिए ठीक 0° elevation पर कोई row नहीं होती। क्षैतिज देखने वाला viewer, जो कहीं ज़्यादा आम मामला है, हमेशा किसी tilt पर bake की गई row में गिरता है। Fix है odd N: एक 5×5 grid row centers को 0° और ±36° और ±72° पर रखता है, इसलिए क्षैतिज viewer को ठीक क्षैतिज पर bake की गई tile मिलती है। "आधे cell जितनी चूक" वाली गलती का यही परिवार अगले भाग के parallax काम में फिर सामने आता है, और इलाज वही सवाल है: क्या मेरा discrete sample point वाकई वहीं गिरता है जहाँ canonical input के लिए मैं सोचता हूँ?

दो और बातें मायने रखती थीं। Billboard को piecewise-static होना ज़रूरी है, लगातार camera की ओर मुँह करने वाला नहीं। Imposter एक खास bake direction से ली गई चपटी तस्वीर है, इसलिए runtime quad के image plane को उस bake camera के plane से मेल खाना ही चाहिए, जिसका मतलब है कि यह उस arc भर में अपना orientation थामे रखता है जहाँ एक cell चुनी रहती है, फिर boundary पर snap हो जाता है। और budget को वहाँ जाना चाहिए जहाँ players असल में देखते हैं: एक बाद के pass ने tilted top-down rows को पूरी तरह हटाकर उनकी जगह 15° के फासले पर 24 horizontal ring slots और एक सीधी-नीचे वाली tile रख दी, क्योंकि पेड़ करीब-करीब हर वक्त आँख की ऊँचाई से देखे जाते हैं।

Snap, और blending ने उसे कैसे मिटाया

Spike 42 को नए tab में खोलें ↗ · Source देखें

Piecewise-static billboard दूरी पर अदृश्य रहता है और करीब आने पर pop करता है, जो तब तक ठीक है जब तक आप orbit न करें। Spike 42 ने चार variants को साथ-साथ रखा (original prop, az/el 5×5 baseline, और दो hemi-octahedral grids) ताकि flicker को अलग करके खत्म किया जा सके। दो artifacts snap को चलाते हैं। Cell pop इसलिए होता है क्योंकि fragment shader view direction को 25 cells में से एक में quantize कर देता है, इसलिए किसी boundary को पार करना उसी frame पर sample की गई tile बदल देता है और quad को फिर से aim कर देता है। Pole degeneracy है top-down view, जहाँ हर azimuth एक ही point पर ढह जाता है और ring तथा top tile के बीच का पुल atlas का सबसे बुरा transition है।

Hemi-octahedral mapping दोनों को ठीक करती है। यह ऊपरी hemisphere को unit square पर लगातार map करती है, इसलिए पास-पास की 3D directions पास-पास की UVs पर गिरती हैं और कोई pole singularity नहीं रहती और किसी खास top-down tile की ज़रूरत नहीं पड़ती। Flicker का इलाज है bilinear cell blending: सबसे नज़दीकी tile पर snap करने के बजाय, encode की गई direction को घेरने वाला 2×2 tiles का group ढूँढो और चारों को blend करो, कुल मिलाकर 8 texture taps (4 diffuse, 4 normal)। पास-पास के views अब pop करने के बजाय cross-fade करते हैं। दो unit vectors का normal blend खुद unit length का नहीं होता, इसलिए इसे फिर से normalize किया जाता है, जो पड़ोसी tiles के बीच के छोटे कोणों के लिए एक slerp जैसा बर्ताव करता है। कीमत असली है (एक 12×12 atlas az/el के 1.6 MB के मुकाबले करीब 9 MB का है, और bake 288 render-target passes पर लगभग 5× ज़्यादा लंबा चलता है) पर bake load के वक्त एक बार का होता है और blend एक pop-free नतीजा देता है, जो imposters को तब इस्तेमाल लायक बनाता है जब camera वाकई चल रहा हो।

दस लाख पेड़, प्रति frame एक camera-position copy

Spike 41 को नए tab में खोलें ↗ · Source देखें

Spike 38 का runtime प्रति quad प्रति frame एक CPU lookAt करता है, जो एक पेड़ के लिए ठीक है और एक जंगल के लिए जानलेवा। दस लाख पेड़ों पर प्रति-frame matrix updates और instance-buffer upload सब कुछ हावी कर देंगे। Spike 41 पूरी per-frame pipeline को GPU पर ले जाता है। हर instance का center, yaw, और scale build time पर एक बार instanced attributes के रूप में upload होता है और कभी नहीं बदलता। Vertex shader world-space view direction camPos − center से billboard basis बनाता है और एक साझा unit quad को world space में फैलाता है। Fragment shader प्रति pixel hemi-octahedral encode और bilinear blend करता है। पूरे जंगल के लिए एकमात्र per-frame CPU काम है camera-position uniform को update करने वाला एक Vector3.copy, जो पेड़ों की गिनती के साथ बिल्कुल भी नहीं बढ़ता।

गणित का एक अच्छा हिस्सा यह है कि per-instance yaw normal decode से कट जाता है। Bake normals को bake camera के frame में store करता है, और चूँकि world up के चारों ओर एक yaw rotation +Y को बरकरार रखता है और cross product rotation-equivariant है, इसलिए world-up reference के साथ बना runtime basis पहले से ही rotated bake basis के बराबर है। तो shader normals को runtime basis varyings के ज़रिए सीधे decode करता है, per-instance yaw को कभी छुए बिना। Placement शुद्ध random scatter के बजाय एक jittered grid इस्तेमाल करता है: इलाके को cells में बाँटो, हर cell में center पर एक पेड़ डालो और साथ में एक bounded offset, जो एक न्यूनतम spacing की गारंटी देता है (कोई दो पेड़ एक दूसरे के ऊपर नहीं) जबकि फिर भी एक प्राकृतिक जंगल जैसा पढ़ा जाता है। एक detail जिसे चूकना आसान है वह है bounding sphere। Geometry template बस एक unit quad है, इसलिए three.js पूरे जंगल को उसी पल frustum-cull कर देता जिस पल camera origin से दूर देखता। पूरे इलाके को और एक quad के margin को ढकने वाली एक explicit bounding sphere set करना कोने के पेड़ों को तिरछे कोणों पर कटने से बचाता है।

इस अध्याय में उल्लिखित technology

Octahedral और azimuth-elevation imposter atlases. एक imposter किसी prop को view directions के एक grid से एक diffuse atlas और एक world-space normal atlas में bake करता है, फिर एक ही billboard render करता है जो मेल खाती tile sample करता है, हज़ारों triangles को दो textures से बदल देता है। किताबी octahedral mapping uniform sphere coverage देती है पर fold boundaries पर CPU/GPU divergence की ओर झुकी रहती है; एक सादा azimuth-बनाम-elevation grid एक कम uniform sphere sample करता है पर construction से ही गारंटी देता है कि cell-picker और shader सहमत रहें। Odd N इस्तेमाल करें ताकि एक row ठीक 0° elevation पर आए, और tile budget को horizontal ring पर खर्च करें क्योंकि props ज़्यादातर आँख की ऊँचाई से देखे जाते हैं।

Piecewise-static billboard orientation. एक imposter एक खास bake direction से ली गई तस्वीर है, इसलिए runtime quad के image plane को bake camera के plane से मेल खाना ज़रूरी है, runtime camera की ओर लगातार मुँह करना नहीं। Quad उस arc भर में अपना orientation थामे रखता है जहाँ एक cell चुनी रहती है, फिर boundary पर snap हो जाता है, जो imposter दूरी पर अदृश्य रहता है और सिर्फ करीब आने पर pop करता है जहाँ imposters इस्तेमाल नहीं होते।

Hemi-octahedral atlas with bilinear cell blend. ऊपरी hemisphere को unit square पर लगातार map करने से pole singularity और खास top-down tile हट जाती है। Encode की गई view direction को घेरने वाले 2×2 tile group को sample करके और चारों tiles को bilinear-blend करके (8 taps) snap को खत्म किया जाता है, इसलिए पास-पास के views cross-fade करते हैं। Blended normals को फिर से normalize किया जाता है, जो छोटे inter-tile कोण पर एक slerp के करीब आता है। कीमत है एक बड़ा atlas (12×12 पर करीब 9 MB) और एक लंबा एक बार का bake, जो camera की गति में pop-free shading के बदले में दिया जाता है।

GPU-driven instanced imposters. Per-instance center, yaw, और scale एक बार instanced attributes के रूप में upload होते हैं; vertex shader billboard basis बनाता है और एक साझा unit quad को फैलाता है, और fragment shader प्रति pixel encode और blend करता है। पूरे जंगल के लिए per-frame CPU कीमत एक अकेली camera-position uniform copy है, जो instance count से स्वतंत्र है। Per-instance yaw normal decode से कट जाता है क्योंकि world up के चारों ओर yaw cross-product basis construction से बरकरार रहता है। एक explicit जंगल-भर की bounding sphere three.js को पूरे instanced mesh को frustum-cull करने से रोकती है जब camera unit-quad template के origin से दूर देखता है। देखें GPU-driven LOD।

29 में से भाग 19। पिछला: भाग 18 - एक scatter brush जो AI-placed महसूस होता है अगला: भाग 20 - एक चपटे plane पर depth का भ्रम Series guide: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

कुछ हफ़्ते पहले मैंने उन रेंडरिंग तकनीकों के बारे में लिखा था जो आधुनिक AAA गेम्स असल में शिप करते हैं। एक क्षेत्र जिस पर मैंने हल्का छुआ था वह था आसमान और मौसम, क्योंकि यह अपनी अलग सूची का हकदार है। बादल, कोहरा, बारिश और बर्फ वे सिस्टम हैं जो एक terrain डेमो को एक जगह में बदल देते हैं। ये दिखने से ज़्यादा कोड आपस में साझा करते हैं। वॉल्यूमेट्रिक बादल, ज़मीनी कोहरा और god rays सब एक ही ray-march हैं। गीली सड़कें, बर्फ का जमाव और पैरों के निशान सब एक ही displacement प्लस PBR ट्रिक हैं। हवा एक दिशा वेक्टर है जिसे सीन की हर चीज़ पढ़ती है।

यहाँ 2026 में बड़े स्टूडियो इस सामग्री को कैसे बनाते हैं, इसका एक छोटा और मतवाला दौरा है, हर हिस्से के पीछे के पेपर और engine टॉक्स के साथ।

1. Physically based आसमान और वातावरण

Atmospheric scattering ही बुनियाद है। आसमान का रंग, क्षितिज की धुंध, दूर के पहाड़ों का नीला पड़ना, सूर्यास्त का नारंगी रंग, ये सब हवा से होकर रोशनी के scatter होने से आते हैं। आधुनिक engine इसे physics से कैलकुलेट करते हैं: नीले रंग के लिए Rayleigh scattering, सूरज के आसपास की धुंध के लिए Mie scattering, और zenith पर गहरे बैंगनी रंग के लिए ozone absorption।

मूल 2008 का Bruneton तरीका सब कुछ 4D लुकअप टेबल्स में bake कर देता था, जिससे डायनामिक time-of-day सीमित हो जाता था और कम सूरज के कोणों पर LUT artifacts जुड़ जाते थे। Sébastien Hillaire का 2020 का अपडेट, जो UE5 का Sky Atmosphere कंपोनेंट शिप करता है, उच्च-आयामी LUT की जगह कुछ 2D टेक्सचर और एक multiple-scattering approximation रख देता है जो हर frame पर अपडेट होता है। यह एक फ़ोन से लेकर हाई-एंड PC तक चलता है।

गहराई से पढ़ें:

• Hillaire, A Scalable and Production Ready Sky and Atmosphere Rendering Technique (EGSR 2020, आधुनिक मानक, UE5 में इस्तेमाल होता है)।
• Bruneton and Neyret, Precomputed Atmospheric Scattering (EGSR 2008, मूल LUT तरीका)।
• Bruneton, Precomputed Atmospheric Scattering: a New Implementation (ओपन-सोर्स संदर्भ, ozone और multi-planet सपोर्ट)।
• Epic Games, Sky Atmosphere Component (UE5 डॉक्स)।

2. Perlin-Worley noise के साथ वॉल्यूमेट्रिक बादल

आधुनिक गेम्स में बादलों की बुनियादी तकनीक Andrew Schneider के 2015 के Horizon Zero Dawn टॉक से शुरू हुई। बादल mesh नहीं होते। वे layered noise से बने एक 3D density function होते हैं: एक low-frequency Perlin-Worley मिश्रण बादल का समग्र आकार देता है, और एक higher-frequency Worley noise silhouette को पतले धुँधले किनारों में घिसता है। एक weather map (एक 2D टेक्सचर जिसे world XZ से sample किया जाता है) हर क्षेत्र के लिए coverage, बादल का प्रकार और वर्षा को नियंत्रित करता है। एक height-based gradient ऊँचाई के हिसाब से cumulus, stratus और cirrus प्रोफ़ाइल के बीच ब्लेंड करता है।

रेंडरर कैमरे से बादल वॉल्यूम के बीच से एक ray मार्च करता है, density और scattering इकट्ठा करता हुआ। 2017 के "Nubis" संस्करण ने regional-scale authoring और animation जोड़ा, और मूल PS4 इम्प्लीमेंटेशन पूरे आसमान के लिए लगभग 2 ms में चलता था। आज जो ज़्यादातर स्टूडियो वॉल्यूमेट्रिक बादल शिप करते हैं वे अब भी अपनी विरासत इसी पेपर तक खींचते हैं।

गहराई से पढ़ें:

• Schneider, The Real-Time Volumetric Cloudscapes of Horizon Zero Dawn (SIGGRAPH 2015, प्रामाणिक संदर्भ)।
• Schneider, Nubis: Authoring Real-Time Volumetric Cloudscapes with the Decima Engine (SIGGRAPH 2017, regional-scale फ़ॉलो-अप)।
• Hillaire, Physically Based Sky, Atmosphere and Cloud Rendering in Frostbite (SIGGRAPH 2016, Frostbite संस्करण)।
• Häggström, Real-time rendering of volumetric clouds (एक साफ़, सुलभ थीसिस जिसमें पूरा shader कोड है)।

3. Voxel बादल और Nubis³

Nubis के 2023 के विकास ने 2.5D shape representation को पूरी तरह छोड़कर असली 3D voxels को अपनाया। हर voxel बादल की density सीधे स्टोर करता है, जिससे आर्टिस्ट बादल के आकार को उसी तरह तराश और animate कर सकते हैं जैसे वे terrain गढ़ते हैं। एक घने representation पर जाने की लागत compressed signed distance fields के साथ ray-march acceleration और sparse voxel डेटा के चतुर up-rezzing से वसूल हो जाती है।

नतीजा वह तरह का cloudscape है जिसके बीच से आप उड़ सकते हैं आर-पार बिना अंदरूनी ट्रिक्स को बिखरते देखे। यह ज़्यादातर स्टूडियो के लिए ज़रूरत से ज़्यादा है, पर यही दिशा है जिधर हाई-एंड बढ़ रहा है।

गहराई से पढ़ें:

• Schneider, Nubis³: Methods (and madness) to model and render immersive real-time voxel-based clouds (SIGGRAPH 2023, voxel-cloud टॉक)।
• Schneider, Nubis, Evolved (SIGGRAPH 2022, 2.5D और पूर्ण 3D के बीच का पुल)।
• Schneider, Real-time Volumetrics and VFX (Andrew की निजी साइट, कोर्स नोट्स और ब्रेकडाउन के साथ)।

4. Layered बादल रेंडरिंग और 2D बैकड्रॉप

हर स्टूडियो full-volume बादल वहन नहीं कर सकता, और हर कैमरा कोण को उनकी ज़रूरत नहीं होती। बहुत से गेम्स तकनीकें मिलाते हैं: high-altitude cirrus को एक scrolling 2D layer के रूप में रेंडर करना, mid-altitude cumulus को वॉल्यूमेट्रिक rays के रूप में, और low-altitude stratus को एक पतले participating-media स्लैब के रूप में। क्षितिज को अक्सर एक pre-baked sky cubemap मिलता है जिसमें वॉल्यूमेट्रिक pass एक fade distance के पार ब्लेंड कर देता है।

यही layering बादल बजट को ईमानदार रखती है। पूरी क्वालिटी पर एक अकेला बादल प्रकार 4-6 ms खा सकता है; अलग-अलग बादल ऊँचाइयों के लिए अलग-अलग क्वालिटी layer करना उसी लुक को आधी लागत पर रोक सकता है।

गहराई से पढ़ें:

• Vos, The Real-Time Volumetric Cloudscapes of Horizon Zero Dawn (GDC 2016 वीडियो, layering ब्रेकडाउन दूसरे हिस्से में है)।
• Bauer, Creating the Atmospheric World of Red Dead Redemption 2 (SIGGRAPH 2019, RDR2 की संयुक्त sky/clouds/volumetrics पाइपलाइन)।
• Hillaire, Volumetric clouds and mega particles in REDengine 4 (GDC 2025, Cyberpunk 2077 की बादल पाइपलाइन)।

5. Froxel grids के साथ वॉल्यूमेट्रिक कोहरा

कोहरा एक 3D फ़ील्ड है, 2D स्क्रीन इफ़ेक्ट नहीं। मानक आधुनिक तरीका froxel grid है: कैमरे के view frustum से aligned एक 3D टेक्सचर, जिसका हर सेल ("froxel" = frustum + voxel) density और lit color स्टोर करता है। एक compute shader हर light source से scattering को grid में inject करता है, view ray के साथ extinction इकट्ठा करता है, और नतीजे को एक fullscreen pass के रूप में लागू करता है।

यही आपको खिड़कियों से आती light shafts, point lights के आसपास रंगीन कोहरा, और विस्फोटों के चारों ओर दिखने वाले volumes देता है। यही "atmospheric perspective" के पीछे की मशीनरी भी है जो दूर की चीज़ों को हवा में धुँधला कर देती है। यह तकनीक Bart Wronski ने Assassin's Creed 4 के लिए पेश की और Sébastien Hillaire ने Frostbite में मानकीकृत की।

गहराई से पढ़ें:

• Wronski, Volumetric Fog: Unified Compute Shader Based Solution to Atmospheric Scattering (SIGGRAPH 2014, मूल froxel-grid पेपर)।
• Hillaire, Physically Based and Unified Volumetric Rendering in Frostbite (SIGGRAPH 2015, production-grade इम्प्लीमेंटेशन)।
• Kovalovs, Volumetric Effects of The Last of Us Part Two (SIGGRAPH 2020, temporal jitter और depth-correct compositing पर नोट्स के साथ)।
• Wright et al., Lumen: Real-Time Global Illumination in Unreal Engine 5 (SIGGRAPH 2022, इसमें वॉल्यूमेट्रिक कोहरे के साथ Lumen का interaction शामिल है)।

6. God rays और crepuscular shafts

धुँधली हवा में सूरज की रोशनी की दिखने वाली किरणें कोई अलग इफ़ेक्ट नहीं हैं। वे उसी कोहरा सिस्टम से निकलती हैं, बशर्ते कोहरे की density और shadow map दोनों उसी compute shader को उपलब्ध हों। जब shader एक froxel में रोशनी inject करता है, तो वह उस froxel की world position पर shadow map को sample करता है। छाया में पड़े सेल अँधेरे रहते हैं, रोशनी में पड़े सेल सूरज का रंग पकड़ लेते हैं। कैमरा ray को नतीजे के बीच से मार्च करें और चमकीले सेल लगातार shafts बना देते हैं।

सस्ते screen-space वैरिएंट मौजूद हैं (सूरज की position से depth buffer में radial blur) और मोबाइल या low-end हार्डवेयर पर अब भी सही चुनाव हैं। वे ऑफ़-स्क्रीन सूरज की positions छोड़ देते हैं पर लगभग कुछ खर्च नहीं करते।

गहराई से पढ़ें:

• Mitchell, Volumetric Light Scattering as a Post-Process (GPU Gems 3, screen-space radial-blur तरीका)।
• Engelhardt and Dachsbacher, Epipolar Sampling for Shadows and Crepuscular Rays in Participating Media (I3D 2010, ज़्यादा सटीक GPU तकनीक)।
• Vos, Volumetric Light Effects in Killzone: Shadow Fall (SIGGRAPH 2014, shadow integration के साथ production संस्करण)।

7. बिजली और stochastic मौसम घटनाएँ

बिजली एक one-frame इफ़ेक्ट है जिसके दो हिस्से होते हैं: bolt mesh, और पूरे सीन का tonemap और लाइटिंग प्रतिक्रिया। bolt खुद आमतौर पर एक procedural billboard mesh होता है जो एक recursive line-segment subdivision एल्गोरिथ्म से बनाया जाता है, अराजकता के लिए jittered और ज़मीन की ओर tapered। कुछ engine इसे एक screen-space additive flash के रूप में रेंडर करते हैं, अन्य एक पूरी तरह lit emissive geometry के रूप में जो एक one-frame point-light injection के ज़रिए दुनिया पर रोशनी डालती है।

दिलचस्प हिस्सा है बाकी सब कुछ: बादलों के पेंदे नीचे से रोशन होते हैं, ज़मीन दो frames के लिए चमकती है, auto-exposure metering को उबरने में कुछ frames लगते हैं, और दूरी के आधार पर एक देर से आने वाली गरज की आवाज़ बजती है। अच्छी तरह किया जाए तो यह एक 16 ms की चमक को पाँच-सेकंड के क्रम में बदल देता है जो मौसम को दुनिया में होती किसी चीज़ की तरह बेचता है, सिर्फ़ उसके ऊपर नहीं।

गहराई से पढ़ें:

• Reed and Wyvill, Visual Simulation of Lightning (SIGGRAPH 1994, recursive bolt एल्गोरिथ्म जो आज भी सब इस्तेमाल करते हैं)।
• Kim and Lin, Fast Animation of Lightning Using an Adaptive Mesh (IEEE TVCG 2007, ज़्यादा physically grounded)।
• Bauer, Creating the Atmospheric World of Red Dead Redemption 2 (SIGGRAPH 2019, RDR2 की storm पाइपलाइन जिसमें बिजली की timing शामिल है)।

8. बारिश के particles, बारिश के meshes, और screen-space बूँदें

आधुनिक गेम्स में गिरती बारिश शायद ही कभी सिर्फ़ particles होती है। सस्ता और विश्वसनीय समाधान scrolling टेक्सचर का एक छोटा सेट है जो vertical या screen-aligned quads पर खिंचा होता है, और बाकी हर चीज़ की तरह उन्हीं सूरज और आसमान probes से रोशन होता है। कैमरे के पास, अलग-अलग streak particles विस्तार जोड़ते हैं। कैमरे के lens पर ही, droplet टेक्सचर, फिसलते trails, और impact ripples "आप तूफ़ान के अंदर हैं" का अहसास बेचते हैं।

हवा बारिश की दिशा को प्रभावित करती है। वही wind वेक्टर बादल weather map को धकेलता है, घास को मोड़ता है, और बारिश के quads को झुकाता है। एक पूरे सीन का वेक्टर, दर्जनों उपभोक्ता।

गहराई से पढ़ें:

• Tatarchuk, Artist-Directable Real-Time Rain Rendering in City Environments (EGSR 2006, प्रामाणिक layered-rain संदर्भ)।
• Garg and Nayar, Photorealistic Rendering of Rain Streaks (SIGGRAPH 2006, बारिश की बूँदों से होकर रोशनी की physics)।
• Wojciechowski, Rain in Cyberpunk 2077 (GDC 2021, एक आधुनिक production वॉकथ्रू)।

9. गीली सतहें, पोखर, और ripples

ऐसी बारिश जो ज़मीन को नहीं बदलती, तुरंत नकली दिखती है। गीली सतहें अपना albedo गहरा करके (पानी आती रोशनी को सोख लेता है), अपने normals को चपटा करके (पानी की परत microsurface को चिकना कर देती है), और अपनी roughness घटाकर (पानी तीखे कोणों पर लगभग एक संपूर्ण आईना है) प्रतिक्रिया देती हैं। shader में बदलाव छोटा है, विज़ुअल बदलाव बहुत बड़ा।

पोखर mask-driven होते हैं: एक height-based या vertex-painted mask उन निचली जगहों को परिभाषित करता है जो "wetness" parameter बढ़ने पर पानी से भर जाती हैं। Ripples flipbook normal-map टेक्सचर होते हैं जो बारिश की बूँदों के impacts से trigger होते हैं। वाकई अच्छे इम्प्लीमेंटेशन wetness state को समय के साथ बनाते हैं, ताकि एक लंबा तूफ़ान दुनिया को धीरे-धीरे भिगो दे और एक छोटी फुहार सिर्फ़ ऊँची जगहों को गहरा करे।

गहराई से पढ़ें:

• Lagarde and de Rousiers, Moving Frostbite to Physically Based Rendering 3.0, section 5.5 (SIGGRAPH 2014, प्रामाणिक wet-surface PBR समायोजन)।
• Lagarde, Adopting a Physically Based Shading Model (मूल ब्लॉग सीरीज़ जिसमें wet-PBR गणित है)।
• Cyanilux, Rain Effects Breakdown (पोखर, ripples, और droplets का एक सुलभ Shader Graph वॉकथ्रू)।

10. बर्फ का जमाव और deformation

बर्फ बारिश की सममित समस्या है: दुनिया को इसे याद रखना होता है, सिर्फ़ पाना नहीं। मानक तरीका एक top-down "snow accumulation" टेक्सचर इस्तेमाल करता है जो समय के साथ वहाँ जमता है जहाँ आसमान दिखता है (एक top-down depth या shadow map के विरुद्ध कैलकुलेट किया गया)। terrain shader इस mask को sample करता है और छायादार क्षेत्रों में बर्फ का material और खुले इलाकों में snow-deep displacement ब्लेंड करता है।

पैरों के निशान और टायर के निशान खिलाड़ी पर केंद्रित एक sliding deformation map में रेंडर होते हैं। जैसे-जैसे कैमरा हिलता है, पुराने पैरों के निशान scroll होकर बाहर निकलते हैं और टेक्सचर चारों ओर wrap हो जाता है। terrain या snow shader इस deformation map को sample करता है और जहाँ लिखा गया है वहाँ vertices को नीचे धकेलता है। Battlefield 5 की बर्फ यह हार्डवेयर tessellation से करती है; सस्ते तरीके सिर्फ़ vertex displacement के साथ एक high-density terrain mesh इस्तेमाल करते हैं।

गहराई से पढ़ें:

• Barré-Brisebois, Hands-on with Battlefield 5: how the small things matter (Frostbite बर्फ का production लेख)।
• St-Amour, Real-time snow deformation (पूरे GPU इम्प्लीमेंटेशन विवरण के साथ एक थीसिस)।
• Andersson, Terrain Rendering in Frostbite Using Procedural Shader Splatting (वह splat-सिस्टम बुनियाद जिसके ऊपर snow accumulation सवार होता है)।

11. एक global सिस्टम के रूप में हवा

हवा कोई particle इफ़ेक्ट नहीं है। production engines में यह एक अकेला global वेक्टर है (कभी-कभी एक low-resolution 3D फ़ील्ड) जिसे हर डायनामिक सिस्टम अपने vertex shader में पढ़ता है। घास की पत्तियाँ झुकती हैं, पेड़ की शाखाएँ डोलती हैं, कपड़ा फड़फड़ाता है, पत्तियाँ बहती हैं, बारिश झुकती है, धुआँ बहता है, बादल weather maps scroll होते हैं। हर frame पर अपडेट होने वाला एक uniform, दर्जनों उपभोक्ता।

समृद्ध संस्करण एक "wind grid" है जो world position से sample की गई दिशा और ताकत स्टोर करता है, जिससे स्थानीय झोंकों वाले तूफ़ान, सुरक्षित घाटियाँ, और इमारतों के पीछे की wakes संभव होती हैं। Foliage को आमतौर पर authoring समय पर bake किया गया एक per-vertex offset भी मिलता है ताकि एक जैसे पेड़ एक साथ ताल में न डोलें। नतीजा एक ऐसी दुनिया है जो एक ही गति से साँस लेती है।

गहराई से पढ़ें:

• McAuley, Rendering the World of Far Cry 4 (GDC 2015, इसमें वनस्पति के लिए Far Cry 4 का wind grid शामिल है)।
• Habel and Wimmer, Realistic Real-Time Rendering of Landscapes Using Billboard Clouds (पुराना, पर वनस्पति पर हवा का गणित अब भी वही है)।
• Frostbite, The Vegetation of Horizon Zero Dawn (SIGGRAPH 2017, wind-सिस्टम architecture के साथ)।

12. रेतीले तूफ़ान, बर्फ़ीले तूफ़ान, और घना मौसम

भीषण मौसम अपनी अलग रेंडरिंग श्रेणी है। एक रेतीला तूफ़ान एक मोटा, अपारदर्शी, ground-aligned कोहरा है जिसमें एक मज़बूत दिशात्मक झुकाव और आक्रामक distance fog होता है। एक बर्फ़ीला तूफ़ान कैमरे के पास एक particle धमाका और घटी हुई दृश्यता जोड़ता है। ज्वालामुखीय राख और धुआँ अलग रंगों के साथ वही architecture हैं।

जो चीज़ इन्हें बेचती है वह particles नहीं है, वह है coupling: सूरज मद्धम पड़ता है, आसमान का रंग बदलता है, post-process color grading खिसकती है, ambient ऑडियो बदलता है, पैरों की आवाज़ बदलती है, खिलाड़ी की आवाज़ दबी हुई हो जाती है अगर उसकी कोई हो। रेंडरर संदेशवाहक है; immersion गेम के हर सिस्टम के एक ही समय पर प्रतिक्रिया देने से आता है।

गहराई से पढ़ें:

• Burley, The Real-Time Sky and Atmosphere of Uncharted: The Lost Legacy (GDC 2018, घने-मौसम composition पर नोट्स के साथ)।
• Khalifa, Atmospheric Weather Effects in Forza Horizon 5 (GDC 2022, आधुनिक open-world मौसम)।
• Karis, The Technology Behind the Unreal Engine 5 "Lumen in the Land of Nanite" Demo (SIGGRAPH 2021, गुफा की धूल वाले सीन का वॉल्यूमेट्रिक stack)।

13. Time of day और डायनामिक आसमान

रियल-टाइम time of day वह गुणक है जो इस सूची के हर दूसरे सिस्टम को शिप करने लायक बना देता है। सूरज की दिशा और रंग एक 24-मिनट या 24-घंटे के चक्र पर अपडेट होते हैं। atmosphere LUT सूरज के कोण के साथ अपडेट होता है। बादलों की लाइटिंग हर frame पर फिर से कैलकुलेट होती है। shadow cascades फिर से इंगित होती हैं। reflection probes रीफ़्रेश होते हैं। ambient रंग खिसकता है। post-process exposure adapt होता है।

इसे बिना दिखने वाले artifacts के करना ज़्यादातर texture caching और temporal stability की कहानी है। तेज़ तकनीकें आसमान को निश्चित सूरज कोणों पर precompute करती हैं और interpolate करती हैं; धीमी तकनीकें हर frame फिर से कैलकुलेट करती हैं। Hillaire 2020 का atmosphere मॉडल फिर से कैलकुलेट करने लायक तेज़ है, यही वजह है कि UE5 इसे शिप करता है। बादल weather map हवा के साथ scroll होता है, इसलिए coverage बिना किसी के keyframes authoring के स्वाभाविक रूप से खिसक जाता है।

गहराई से पढ़ें:

• Hillaire, A Scalable and Production Ready Sky and Atmosphere Rendering Technique (EGSR 2020, डायनामिक time-of-day चर्चा के साथ)।
• Pesce, Real-Time Sky Rendering: Techniques and Tradeoffs (Ray Tracing Gems II अध्याय, आधुनिक सर्वेक्षण)।
• Bauer, Creating the Atmospheric World of Red Dead Redemption 2 (SIGGRAPH 2019, 24-घंटे पाइपलाइन के साथ)।

14. मौसम state machine

इस सब के नीचे एक छोटी सी state machine है। ज़्यादातर गेम्स 4 से 12 मौसम states के बीच कहीं शिप करते हैं (साफ़, आंशिक रूप से बादल, घना बादल, हल्की बारिश, तेज़ बारिश, गरज वाला तूफ़ान, कोहरा, बर्फ, बर्फ़ीला तूफ़ान, रेतीला तूफ़ान), हर एक parameters के एक सेट से परिभाषित: बादल coverage और प्रकार, हवा की गति और दिशा, वर्षा का प्रकार और तीव्रता, ambient रंग, ऑडियो प्रोफ़ाइल, post-process grade।

Transitions 30 से 120 सेकंड में parameter सेट के बीच linear interpolations होती हैं। transition कोई विशेष मामला नहीं है, यह बस दो states के बीच lerp होना है, जिसमें हर रेंडरिंग सबसिस्टम उस frame के मौजूदा parameter मानों को पढ़ता है। मौसम scripted हो सकता है (cutscene को एक तूफ़ान चाहिए), seeded (हर क्षेत्र के लिए हर इन-गेम दिन पर deterministic ताकि एक ही दुनिया में दो खिलाड़ी एक जैसा मौसम देखें), या एक region grid पर पूरी तरह authored। सबसे साफ़ पाइपलाइन इन तीनों को एक ही parameter buffer में लिखने वाले अलग-अलग schedulers की तरह मानती हैं।

गहराई से पढ़ें:

• Bauer, Creating the Atmospheric World of Red Dead Redemption 2 (SIGGRAPH 2019, weather-state पाइपलाइन के साथ)।
• Khalifa, Atmospheric Weather Effects in Forza Horizon 5 (GDC 2022, parameter-blend तरीके के साथ)।
• Schneider, The Real-Time Volumetric Cloudscapes of Horizon Zero Dawn (SIGGRAPH 2015, weather-map-driven बादल विकास के साथ)।

15. सिनेमाई पल

यह पूरा stack कुछ हस्ताक्षर पलों के लिए मौजूद है। एक रिज पर खड़े होना जब एक storm front लुढ़कता हुआ आता है। canopy में एक खुली जगह से एक sun shaft को जलते देखना। एक गुफा से बाहर बर्फ में निकलना। एक cumulus बादल के बीच से उड़ना और अंदर की रोशनी देखना।

ये वे पल हैं जिनके खिलाड़ी screenshots लेते हैं। ये वे पल भी हैं जहाँ ऊपर का हर सिस्टम एक ही समय पर काम कर रहा होना चाहिए: cloud volumetrics, atmospheric scattering, shadow integration के साथ कोहरा, wet PBR, foliage पर हवा, time-of-day color grading, और मौसम states के बीच एक transition, सब एक frame में composing होते हुए। इनमें से कोई एक भी गलत करें और जादू टूट जाता है।

इसका browser के लिए क्या मतलब है

इनमें से ज़्यादातर तकनीकें WebGPU पर साफ़-साफ़ map हो जाती हैं। हमने open-world browser engine में बुनियादी atmospheric कोहरा, equirectangular skybox ब्लेंडिंग, और screen-space distance haze शिप किया है। मुश्किल हिस्से (पूर्ण वॉल्यूमेट्रिक बादल, froxel grid कोहरा, डायनामिक पोखरों के साथ wet PBR, snow deformation maps) अब अगला स्पष्ट कदम हैं जब terrain पाइपलाइन स्थिर है। Spike 24 का skybox से per-fragment fog color sampling इस पहेली का एक टुकड़ा है। एक compute-shader cloud raymarcher जो उसी atmosphere LUT में feed करता है, अगला टुकड़ा है।

अच्छी खबर यह है कि browser हार्डवेयर का फ़र्श अब काफ़ी ऊँचा है। WebGPU compute, 3D टेक्सचर, indirect dispatch, और timestamp queries सब मौजूद हैं। Hillaire 2020 atmosphere को WebGL पर कई बार पोर्ट किया गया है। Schneider के Nubis के GLSL में ओपन-सोर्स reference implementations हैं जो यांत्रिक संपादनों के साथ WGSL में बदल जाते हैं। अब कोई रेंडरिंग वजह नहीं बची है कि एक browser गेम के पास वही आसमान न हो जो एक console के पास है। बस इंजीनियरिंग वजहें हैं, और इंजीनियरिंग वजहें वह तरह की हैं जो हमें पसंद हैं।

पूरे stack में आगे पढ़ने के लिए

अगर आप एक ऐसा स्रोत चाहते हैं जो इस सब को एक साथ खींचे, तो SIGGRAPH "Advances in Real-Time Rendering in Games" आर्काइव (advances.realtimerendering.com) में 2014 तक के प्रामाणिक मौसम और वातावरण टॉक्स हैं। विशिष्ट गेम्स अपना आसमान और मौसम कैसे रेंडर करते हैं, इसके production tear-downs के लिए Adrian Courrèges के GPU profiling लेखों में GTA V, Horizon Zero Dawn, और Doom Eternal के विस्तृत frame-by-frame ब्रेकडाउन शामिल हैं। खासकर आसमान और वातावरण के गणित के लिए, scratchapixel.com का volume rendering अध्याय सबसे सहज परिचय है, और Hillaire की ओपन-सोर्स implementation repository production-quality reference है।

लिखा है Oleg Sidorkin ने, Cinevva के CTO और Co-Founder

अगर आप 2026 के किसी AAA game की rendering pipeline खोलकर देखें, तो उसमें से ज़्यादातर चीज़ें तकनीकों के एक छोटे से समूह से जुड़ी मिलेंगी, जो सभी studios में इस्तेमाल होती हैं। engines के बीच नाम बदल जाते हैं, पर विचार वही रहते हैं। यहाँ एक छोटी सूची है कि screen पर असल में काम क्या कर रहा है, हर एक के लिए एक figure और कुछ गहरे technical references के साथ।

1. Physically based rendering (PBR)

Materials को albedo, roughness, metallic, normal और ambient occlusion textures से बताया जाता है, और energy-conserving shaders (Cook-Torrance specular, Lambertian या Disney diffuse) से रोशनी दी जाती है। यह वह आधार है जिसे हर आधुनिक AAA engine मानकर चलता है। अगर कोई surface धूप में, lamp की रोशनी में और flashlight में एक जैसा दिखता है, तो उसकी वजह PBR है।

गहराई से जानें:

• Burley, Physically-Based Shading at Disney (मूल "Disney BRDF" course notes, SIGGRAPH 2012)।
• Karis, Real Shading in Unreal Engine 4 (SIGGRAPH 2013, canonical UE4 PBR talk)।
• Lagarde और de Rousiers, Moving Frostbite to Physically Based Rendering 3.0 (SIGGRAPH 2014, पूरी Frostbite pipeline)।
• Real-Time Rendering, 4th edition, chapter 9 (textbook reference)।

2. Deferred और visibility-buffer shading

Geometry सबसे पहले attributes (normals, material IDs, depth) को एक G-buffer या visibility buffer में लिखती है। Lighting एक fullscreen pass की तरह चलती है जो उन buffers को पढ़कर हर pixel को एक बार shade करती है। Visibility buffers (Nanite और इससे मिलती-जुलती तकनीकों में इस्तेमाल होते हैं) इसे और आगे ले जाते हैं, सिर्फ़ triangle IDs को store करके और material parameters को बाद में per pixel resolve करके, जिससे dense geometry पर overdraw सस्ता रहता है।

गहराई से जानें:

• Engel, Deferred Shading (NVIDIA, नींव रखने वाला talk)।
• Burns और Hunt, The Visibility Buffer: A Cache-Friendly Approach to Deferred Shading (JCGT 2013, मूल visibility buffer paper)।
• Wihlidal, "Optimizing the Graphics Pipeline with Compute" (GDC 2016, Frostbite का compute आधारित deferred path)।
• Karis, Stubbe, Wihlidal, A Deep Dive into Nanite Virtualized Geometry (SIGGRAPH 2021, इसमें Nanite visibility buffer विस्तार से है)।

3. Virtualized geometry (Nanite-style)

Meshes को पहले से clusters की एक hierarchy में बना लिया जाता है। runtime पर GPU clusters को उस resolution पर stream और select करता है जो हर pixel से मेल खाती है, जिससे बिना manual LODs के sub-pixel-accurate detail मिलती है। Unreal का Nanite इसका सबसे जाना-पहचाना उदाहरण है। अब दूसरे engines भी अपने-अपने variants देते हैं। इसका असली नतीजा है बिना LOD authoring के real time में film-quality assets।

गहराई से जानें:

• Karis, Stubbe, Wihlidal, A Deep Dive into Nanite Virtualized Geometry (SIGGRAPH 2021)।
• Brian Karis, Nanite GDC 2021 talk (आसानी से समझ आने वाला video walkthrough)।
• Liktor, Geometry Rendering Pipeline Architecture at Activision (cluster आधारित rendering, 2021)।
• Schied et al., Spatiotemporal Variance-Guided Filtering (इससे जुड़ी cluster culling तकनीकें)।

4. Shadows, reflections और AO के लिए real-time ray tracing

Hardware ray tracing (DXR, Vulkan RT) हर frame में बने एक BVH के विरुद्ध shadow rays, mirror और glossy reflection rays, और ambient occlusion rays trace करती है। per pixel कुछ rays भी screen-space तकनीकों से बेहतर नतीजा देती हैं, खासकर off-screen reflections और contact shadows के लिए। ज़्यादातर games इसका इस्तेमाल सोच-समझकर करते हैं, हर चीज़ के लिए नहीं।

गहराई से जानें:

• Microsoft, DirectX Raytracing (DXR) Functional Spec (API reference)।
• Wyman, Introduction to DirectX Raytracing (SIGGRAPH course notes, बहुत आसान)।
• Boksansky और Marrs, Ray Tracing Gems II, chapters 17-19 (मुफ़्त PDF, आधुनिक DXR तकनीकें)।
• Stachowiak, Stochastic Screen-Space Reflections (Frostbite, SSR से RT तक का पुल)।

5. Software ray tracing (Lumen-style)

हर player के पास RTX card नहीं होता, इसलिए engines distance-field या surface-cache fallbacks भी देते हैं। Unreal का Lumen, उदाहरण के लिए, सस्ती diffuse GI के लिए signed distance fields और surface caches के विरुद्ध trace करता है, और ज़रूरत पड़ने पर ही hardware rays तक बढ़ता है। AAA games consoles पर "ray-traced look" इसी तरह हासिल करते हैं।

गहराई से जानें:

• Wright et al., Lumen: Real-Time Global Illumination in Unreal Engine 5 (SIGGRAPH 2022, Lumen paper)।
• Epic Games, Lumen Technical Details (आधिकारिक engine docs)।
• Wright, Radiance Caching for Real-Time Global Illumination (SIGGRAPH 2021)।
• Wright, Lumen GDC 2022 talk (video version)।

6. ReSTIR और reservoir sampling

हज़ारों light sources के साथ direct और indirect lighting के लिए, ReSTIR (Reservoir Spatio-Temporal Importance Resampling) pixels और frames के बीच light samples दोबारा इस्तेमाल करता है। Path Tracing के साथ Cyberpunk 2077 जैसे games per pixel एक या दो rays पर noise इसी तरह कम रखते हैं। जैसे-जैसे path tracing high-end target बनता जाएगा, इसे और engines में देखने को मिलेगा।

गहराई से जानें:

• Bitterli et al., Spatiotemporal Reservoir Resampling for Real-Time Ray Tracing with Dynamic Direct Lighting (SIGGRAPH 2020, मूल ReSTIR paper)।
• Ouyang et al., ReSTIR GI: Path Resampling for Real-Time Path Tracing (HPG 2021, indirect-illumination ReSTIR)।
• Lin et al., Generalized Resampled Importance Sampling (SIGGRAPH 2022, गणितीय आधार)।
• NVIDIA, Cyberpunk 2077 Path Tracing Tech Deep Dive (engineering blog)।

7. Volumetric clouds, fog और atmosphere

Skies को 3D noise और density volumes के बीच से ray-march किया जाता है। Atmosphere सूरज और चाँद के transitions के लिए precomputed scattering tables (Bruneton-style) इस्तेमाल करती है। Fog एक froxel grid है (view frustum से aligned एक 3D texture की तरह सोचिए) जो local lighting को पकड़ता है। मिलकर ये आपको skybox की जगह "weather as a system" देते हैं।

गहराई से जानें:

• Schneider, The Real-Time Volumetric Cloudscapes of Horizon Zero Dawn (SIGGRAPH 2015, canonical clouds reference)।
• Hillaire, A Scalable and Production Ready Sky and Atmosphere Rendering Technique (EGSR 2020, UE5 में इस्तेमाल होने वाला आधुनिक Bruneton successor)।
• Wronski, Volumetric Fog: Unified Compute Shader Based Solution to Atmospheric Scattering (SIGGRAPH 2014, Assassin's Creed 4 froxel fog)।
• Hillaire, Physically Based and Unified Volumetric Rendering in Frostbite (SIGGRAPH 2015)।

8. Cascaded shadow maps और virtual shadow maps

सूरज की shadows के लिए, cascaded shadow maps frustum को ranges में बाँटते हैं और हर एक को उचित resolution पर render करते हैं। Virtual shadow maps इससे आगे जाते हैं: एक विशाल shadow map को pages में बाँटा जाता है और सिर्फ़ वही pages render होते हैं जो camera से दिखते हैं। AAA games player के पास crisp shadows बिना भारी memory खर्च के इसी तरह रखते हैं।

गहराई से जानें:

• Dimitrov, Cascaded Shadow Maps (NVIDIA whitepaper, standard reference)।
• Microsoft, Common Techniques to Improve Shadow Depth Maps (DirectX docs)।
• Wright, Virtual Shadow Maps in Fortnite Battle Royale Chapter 4 (SIGGRAPH 2023, UE5 VSM talk)।
• Epic Games, Virtual Shadow Maps documentation।

9. Screen-space effects (SSAO, SSR, SSGI, SSSSS)

depth और normal buffers को सस्ते में पढ़कर आपको ambient occlusion (SSAO), reflections (SSR), one-bounce global illumination (SSGI), और त्वचा के लिए subsurface scattering (SSSSS) मिलते हैं। ये off-screen detail को छोड़ देते हैं, इसीलिए ray tracing आगे बढ़ रहा है, पर एक तेज़ आधार के तौर पर ये अब भी हर जगह हैं।

गहराई से जानें:

• Mittring, Finding Next Gen: CryENGINE 2 (SIGGRAPH 2007, मूल SSAO paper)।
• McGuire et al., Scalable Ambient Obscurance (HPG 2012, आधुनिक SSAO)।
• Stachowiak और Uludag, Stochastic Screen-Space Reflections (Frostbite, SSR reference)।
• Jimenez, Separable Subsurface Scattering (ज़्यादातर AAA engines में त्वचा के लिए इस्तेमाल होने वाली तकनीक)।
• Mara et al., Deep Screen Space (Activision, एक SSGI lineage)।

10. Temporal anti-aliasing और ML upscaling (DLSS, FSR, XeSS)

Frame को कम internal resolution पर render किया जाता है और motion vectors, depth और history का इस्तेमाल करके फिर से बनाया जाता है। ML आधारित upscalers (DLSS 3/4, FSR 3, XeSS) ऊपर से frame generation जोड़ते हैं, optical flow से बीच के frames interpolate करते हुए। ज़्यादातर AAA titles अब यह मानकर ship करते हैं कि कोई upscaler चालू है, जो बदल देता है कि आप बाकी frame का budget कैसे तय करते हैं।

गहराई से जानें:

• Karis, High Quality Temporal Supersampling (SIGGRAPH 2014, canonical TAA talk)।
• Salvi, An Excursion in Temporal Supersampling (NVIDIA, DLSS की राह पर)।
• Edelsten, Truly Next-Gen: Adding Deep Learning to Games and Graphics (GDC 2019, DLSS architecture)।
• AMD, FidelityFX Super Resolution 3 technical details और Intel, XeSS technical paper।

11. GPU-driven rendering और mesh shaders

Culling, LOD selection और draw submission सब GPU पर चलते हैं। Mesh shaders vertex/geometry/tessellation pipeline की जगह एक ज़्यादा लचीली compute-style stage ले आते हैं जो meshlets emit करती है। multi-draw indirect के साथ मिलकर, यह CPU को per-object hot loop से पूरी तरह बाहर रखता है।

गहराई से जानें:

• Haar और Aaltonen, GPU-Driven Rendering Pipelines (SIGGRAPH 2015, नींव रखने वाला Assassin's Creed Unity talk)।
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, Frostbite GPU-driven culling)।
• Kubisch, Introduction to Turing Mesh Shaders (NVIDIA, mesh shader primer)।
• Pesce, A Whirlwind Tour of Mesh Shaders (और इससे मिलते-जुलते engineering blogs, जो Adrian Courrèges के RenderDoc tear-downs पर इकट्ठा हैं)।

12. Hair, cloth और skin rendering

Hair strand आधारित geometry के साथ Marschner-style anisotropic shading इस्तेमाल करता है (NVIDIA HairWorks, AMD TressFX, या engine-native systems)। Cloth को GPU पर position-based dynamics से simulate किया जाता है और anisotropic specular के साथ render किया जाता है। Skin screen-space subsurface scattering और pre-integrated wrap lighting इस्तेमाल करती है। आमतौर पर इन्हीं तीनों में AAA और indie के बीच budget का फ़र्क़ नज़र आता है।

गहराई से जानें:

• Marschner et al., Light Scattering from Human Hair Fibers (SIGGRAPH 2003, नींव रखने वाला hair model)।
• Chiang et al., A Practical and Controllable Hair and Fur Model for Production Path Tracing (Disney 2016, real-time approximations में व्यापक रूप से इस्तेमाल)।
• Müller et al., Position Based Dynamics (standard cloth simulation reference)।
• Jimenez et al., Separable Subsurface Scattering और Real-Time Realistic Skin Translucency।

13. Decals, virtual texturing और material layering

Surface में विविधता layered decals (bullet holes, धूल, खून, मैल) से आती है जो depth buffer पर project होते हैं, साथ ही virtual textures जो high-resolution detail को ठीक समय पर stream करती हैं। Material layering masks और triplanar projection का इस्तेमाल करके per pixel कई PBR sets को blend करती है, जिससे एक ही चट्टान पाँच चट्टानों जैसी दिखती है।

गहराई से जानें:

• Pranckevičius, Deferred Decals और follow-ups (Aras की classic blog series)।
• Mittring, The Technology Behind the "Unreal Engine 4 Elemental Demo" (SIGGRAPH 2012, इसमें virtual texturing की जानकारी है)।
• van Waveren, id Tech 5 Challenges: From Texture Virtualization to Massive Parallelization (SIGGRAPH 2009, MegaTexture talk)।
• Williams, Material Layering in The Order: 1886 (GDC 2014, layered PBR materials)।

14. Order-independent transparency

Hair, foliage, particles और glass साफ़-साफ़ sort नहीं होते। AAA engines उन्हें CPU sort step के बिना सही ढंग से render करने के लिए weighted blended OIT, depth peeling, या per-pixel linked lists जैसी तकनीकें इस्तेमाल करते हैं। foliage से भरे scene में यह चुपचाप frame के सबसे महँगे हिस्सों में से एक होता है।

गहराई से जानें:

• McGuire और Bavoil, Weighted Blended Order-Independent Transparency (JCGT 2013, WBOIT paper)।
• Bavoil और Myers, Order Independent Transparency with Dual Depth Peeling (NVIDIA whitepaper)।
• Yang et al., Real-Time Concurrent Linked List Construction on the GPU (per-pixel linked list reference)।
• Wyman, Exploring and Expanding the Continuum of OIT Algorithms (HPG 2016, तुलनात्मक survey)।

15. Neural radiance caching और ML denoisers

सबसे नई परत। NVIDIA का neural radiance cache हर scene के indirect lighting को सीखता है और और rays trace करने की बजाय उसे query करता है। ML denoisers (OptiX, Intel Open Image Denoise, custom in-house) sparse ray-traced signals को मिलीसेकंड में साफ़ कर देते हैं। उम्मीद कीजिए कि यह श्रेणी अगले दो सालों में तेज़ी से बढ़ेगी।

गहराई से जानें:

• Müller et al., Real-Time Neural Radiance Caching for Path Tracing (SIGGRAPH 2021, NRC paper)।
• Schied et al., Spatiotemporal Variance-Guided Filtering: Real-Time Reconstruction for Path-Traced Global Illumination (HPG 2017, SVGF)।
• Chaitanya et al., Interactive Reconstruction of Monte Carlo Image Sequences using a Recurrent Denoising Autoencoder (SIGGRAPH 2017, पहला recurrent ML denoiser)।
• Intel, Open Image Denoise documentation (open-source production denoiser)।

browser के लिए इसका क्या मतलब है

हमने इनमें से कई तकनीकें अपने open-world browser engine में WebGPU पर ship की हैं। Cascaded shadow maps, GPU-driven instancing, triplanar PBR, screen-space fog, और clipmap आधारित virtualized terrain, ये सब एक tab में 120 FPS पर चलते हैं। बाकी (hardware ray tracing, mesh shaders, ML upscaling) web पर तब आ रहा है जब WebGPU spec इन्हें पकड़ रहा है। और गहराई से जानने के लिए, browser open-world tech और landscape generation पर हमारी guides देखें।

पूरे stack पर और पढ़ने के लिए

अगर आप एक किताब पढ़ना चाहते हैं, तो Real-Time Rendering, 4th edition standard reference है जो ऊपर बताए ज़्यादातर विषयों को कवर करती है। चलते-फिरते research के लिए, SIGGRAPH की "Advances in Real-Time Rendering in Games" course archive (advances.realtimerendering.com) में 2006 से लेकर अब तक के AAA-engine deep dives की मुफ़्त PDFs हैं। किसी खास game अपने frame को कैसे render करता है इसके production tear-downs के लिए, Adrian Courrèges के GPU profiling articles ज़रूर पढ़ें।

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? सीरीज़ गाइड का इस्तेमाल करें। इसमें बताया गया है कि spike क्या होता है और सभी भागों के लिंक दिए गए हैं।

भाग 17 ने player को एक combat-grade animation set दिया और किसी भी CC0 model को world में खींचने का तरीका दिया। यह भाग वापस creator के पक्ष पर आता है। Spike 34 का palette हर click पर एक prop रखता है, जो किसी hero object को सेट करने के लिए ठीक है और एक forest के लिए बेकार है। Spike 37 वह brush है: terrain पर drag करें और trees वहां भर जाते हैं जहां trees होने चाहिए।

बिना किसी AI के "AI-placed"

Spike 37 को नए tab में खोलें ↗ · Source देखें

यह spike जिस सवाल का जवाब देता है वह यह है कि क्या एक पूरी तरह heuristic brush इतना intelligent महसूस होता है कि LLM को छोड़ा जा सके। "AI-placed" की कसौटी ठोस है: trees cliffs से दूर रहें, rocks ढलान में झुकें, beach pebbles waterline पर रुक जाएं, और यह सब पहले ही stroke में। हम वहां slope और altitude predicates, weighted draws, और per-family spacing से पहुंचे, और एक भी model call नहीं किया।

यह brush एक 257×257 CPU heightmap पर काम करता है जिसके features हाथ से tune किए गए हैं ताकि हर preset को कहीं न कहीं landing जगह मिले: mixed-slope picks के लिए northern mountains, scree के लिए एक eastern cliff strip, beach और meadow के लिए एक southern coastal plain, और south-west में एक lake bowl। Terrain एक (altitude, slope) biome classifier से vertex colors bake करता है, इसलिए एक भी tree paint करने से पहले आप देख सकते हैं कि कोई preset कहां fire करेगा। पांच presets flat data के रूप में आते हैं, हर एक { category, weight, slopeMin, slopeMax, altMin, altMax, minSpacing, alignToSlope } जैसे picks की एक list है। Cliff और Scree slopeMin: 0.3 सेट करते हैं ताकि rocks केवल वास्तविक slopes पर ही उतरें और alignToSlope: true ताकि हर boulder का up vector surface normal का अनुसरण करे।

हर stroke के लिए scatter engine brush disc के अंदर densityPerM2 × area candidate points sample करता है, हर candidate के लिए height और slope पढ़ता है, preset के picks को उन तक filter करता है जिनके predicates pass होते हैं, एक को weighted-draw करता है, फिर एक in-radius spatial hash के खिलाफ spacing check चलाता है। पूरी चीज़ deterministic है: एक seedable Mulberry32 RNG हर draw का मालिक है, इसलिए (seed, brush events) किसी भी session को बिल्कुल वैसा का वैसा reproduce करता है। boot terrain पर flat meadow पर एक Mixed Forest stroke ने 158 में से 139 candidates 5 ms में रखे, जबकि वही preset एक cliff पर केवल 226 में से 106 ही रख पाया और HUD ने बताया कि उनमें से 81 slope की वजह से reject हुए। वह rejection breakdown ही पूरा UX है: आप देख सकते हैं कि क्यों cliff ने कुछ ही trees लिए, बजाय अनुमान लगाने के।

presets को flat data के रूप में रखने का मकसद यह है कि LLM version, जब वह आएगा, एक JSON swap होगा न कि एक rewrite। paint({ preset }) को इससे फर्क नहीं पड़ता कि preset.picks किसी हाथ से tune की गई recipe से आए या किसी ऐसे worker से जिसने "deciduous forest with mossy boulders" को weights में फैला दिया। Engine कभी किसी prop id को hardcode भी नहीं करता, इसलिए एक अलग catalog डालने के लिए engine में कोई बदलाव नहीं चाहिए।

300 draw calls से 49 तक

पहले cut ने हर placement को एक multi-mesh group के clone(true) के रूप में render किया, जो कुछ सौ props पर तो ठीक है पर 2,500 के cap पर एक दीवार बन जाता है, जहां draw calls हज़ारों में पहुंच जाते हैं। उसके आने से पहले ही हमने InstancedMesh पर switch कर लिया, हर (propId, partIndex) के लिए एक bucket के साथ। हर bucket doubling से बढ़ता है: एक बड़ा InstancedMesh allocate करो, live matrices copy करो, scene parent swap करो, पुराने attribute को dispose करो। Erase एक swap-remove है, इसलिए एक instance को हटाना bucket size चाहे जो हो O(1) रहता है। Determinism, spacing, और rejection HUD सब बिना बदले चलते रहते हैं क्योंकि यह swap पूरी तरह placement record के नीचे रहता है।

MegaKit pack पर एक diagnostic ने एक असली architecture सवाल सुलझा दिया। एक multi-primitive glTF mesh (trunk और leaves) three.js तक या तो एक mesh के रूप में array material और geometry.groups के साथ पहुंच सकता है, या अलग-अलग sibling meshes के रूप में जिनमें से हर एक के पास एक material हो। इस pack के लिए loader दूसरा रास्ता लेता है: हर part empty groups वाला एक single-material mesh है। scatter के लिए यही बेहतर shape है, क्योंकि per-primitive अलग buckets trunk bucket को leaf bucket से स्वतंत्र रूप से बढ़ने देते हैं अगर उनकी counts अलग हो जाएं। draw-call count दोनों ही तरह से एक जैसी, split के साथ बेहतर memory shape। नापी गई जीत टिकी रही: एक forest stroke जो ~300 draw calls था वह 49 बन गया, और एक पूरे multi-stroke session ने 51 draw calls में 75 FPS पर 3,221 instances तक पहुंचा, एक ऐसा cap जिस तक clone path कभी पहुंच ही नहीं सकता था इससे पहले कि frame budget ढह जाता।

Distance LOD, और उसमें छिपे चार bugs

Instancing ने draw calls काट दिए पर हर instance अब भी अपनी पूरी triangle count draw करता था, यहां तक कि 90 m दूर वाले trees भी जो leaf detail के दो pixels योगदान कर रहे थे। तो हमने meshoptimizer के साथ हर prop part के लिए तीन LOD levels bake किए (full, 50%, 15%), bucket key को (propId, partIndex, lod) तक बढ़ाया, और एक move() जोड़ा जो किसी placement को sibling buckets के बीच बिना allocation शिफ्ट करता है। Distance bands 0 से 30 m, 30 से 90 m, और उससे आगे हैं, हर boundary के आसपास ±4 m hysteresis के साथ ताकि किसी band edge के पास मंडराता camera किसी placement को बार-बार आगे-पीछे न झटके और हर frame उसकी matrix दोबारा upload न करे। Re-evaluation 4 Hz पर capped है और तभी होती है जब camera वास्तव में हिला हो, इसलिए एक स्थिर camera per frame केवल एक squared-distance compare का खर्च लेता है।

वह LOD path ही वह जगह है जहां शिक्षाप्रद bugs रहते थे। पहला bug ऐसे दिखा कि जैसे-जैसे camera orbit करता placements गायब या duplicate होने लगते, और scene भरने के साथ और बदतर होते। वजह एक shared scratch matrix थी: move() किसी placement का transform module-scoped _tmpMat में पढ़ता था, पर source bucket का swap-remove अपनी internal shuffle के लिए उसी _tmpMat का इस्तेमाल करता था, और destination के लिखने से पहले ही carry की गई matrix को मिटा देता था। यह bug केवल उस case को छोड़ता था जहां move किया गया slot पहले से ही अपने bucket में आखिरी हो, लगभग 1/count की संभावना, जो ठीक वही "दुर्लभ flicker जो scene बढ़ने के साथ बदतर होती है" है जो playtest ने देखा। Fix move() के लिए अकेले reserved एक dedicated _carryMat था। 1,274 cumulative moves पर stress-test करने पर cluster pixel-identical रहा।

दूसरा bug ज़्यादा सूक्ष्म था: हर LOD transition smooth महसूस होता था सिवाय पहले वाले के। LOD1 में जाते trees साफ़-साफ़ shading बदलते दिखते थे भले ही उनका silhouette मुश्किल से बदलता था, जबकि ladder में बाद में बड़े triangle drops ठीक लगते थे। LockBorder वाला simplifier कभी vertices को न हिलाता है न नए बनाता है, इसलिए बचे हुए vertices अपने normals बिल्कुल वैसे ही रखते हैं, पर हम फिर भी हर simplification के बाद computeVertexNormals() call कर रहे थे। LOD0 artist के बनाए मूल normals को बिना छुए लौटाता है; LOD1 और उससे ऊपर को three.js का generic face-average recompute मिलता था। 0-से-1 boundary ladder में अकेली जगह थी जहां normal regime बदलता था, इसलिए pop वहीं रहता था। उस एक defensive line को हटाने से shading ठीक हुई और, एक bonus के रूप में, per-prop bake time लगभग आधा कट गया क्योंकि हमने हर part के चार LODs पर normals दोबारा compute करना बंद कर दिया।

simplifier ने क्या produce किया उसका audit करने से एक तीसरी जीत सामने आई। हर LOD एक नए index के साथ original.clone() था, और BufferGeometry.clone() हर attribute को deep-copy करता है, इसलिए पांच LODs position, normal, UV, और color buffers की पांच स्वतंत्र copies रखते थे जिनकी values सब में bit-identical थीं। हमने attribute references share करने के लिए refactor किया और per LOD केवल एक private index buffer अपने पास रखा, एक typical tree part को 20 अलग attribute identities से घटाकर 9 कर दिया और हर vertex buffer को GPU पर एक बार upload किया। aliased storage के साथ दो contracts आते हैं: किसी एक LOD के ज़रिए attribute data को mutate मत करो, और किसी एक LOD geometry को dispose() मत करो, क्योंकि दोनों ही उस buffer को share करने वाले हर sibling पर असर डालेंगे।

चौथे bug का painting से कोई लेना-देना नहीं था। बस cursor को terrain के ऊपर हिलाने से ही frame rate गिर जाता था, बिना कोई button दबाए। pointermove handler terrain mesh के खिलाफ raycast करता था, एक 131,072-triangle plane जिसमें कोई spatial structure नहीं थी, इसलिए three.js per event पूरे index buffer पर चलता था, और वह भी प्रति सेकंड 1,000 events तक। उस lookup के लिए हमें mesh की ज़रूरत थी ही नहीं, क्योंकि terrain एक parametric heightmap है। sampleHeight के खिलाफ एक adaptive ray-march (surface से ऊपर बड़े strides, उसके पास एक 0.4 m floor, फिर sign flip पर 12 bisections) per ray लगभग 8 से 30 samples का खर्च लेता है बजाय 131,072 triangle tests के, लगभग तीन orders of magnitude सस्ता, और hover फिर से frame cap पर टिका रहता है।

Cost बस जगह बदलता है; पक्का करो कि वह click से हट जाए

spike को three r184 (production target) पर WebGPURenderer पर switch करने के बाद, एक DevTools profile ने दिखाया कि सबसे पहला paint 265 ms के लिए block हो रहा है, उसका 79% meshoptimizer WASM के अंदर। Bake असली काम था, एक cold preset के लिए लगभग 180 simplify calls, पर वह click handler के अंदर चल रहा था क्योंकि preloadProps केवल scenes fetch और parse करता था, कभी LOD bake trigger नहीं करता था। Fix यह था कि preset selection को background में पूरा bake कराया जाए: preloadProps अब part-resolution path call करता है, in-flight promise को cache करता है ताकि एक तेज़ click उसमें शामिल हो जाए बजाय एक duplicate fork करने के, और per-geometry preprocessing को memoize करता है जिसे simplifier per part चार बार दोबारा कर रहा था। HUD में first paint 209 ms से घटकर 4 ms हो गया। WASM time गायब नहीं हुआ, वह बस user के critical path से निकल गया और तब चलता है जब वे terrain को देखते हुए तय कर रहे होते हैं कि कहां paint करना है।

यही इस spike का बार-बार आने वाला सबक है। इनमें से लगभग किसी fix ने यह नहीं बदला कि brush क्या करता है। उन्होंने यह बदला कि cost कब उतरता है: click से हटकर, hover से हटकर, उस boundary से हटकर जिसके पास camera मंडरा रहा है। एक scatter tool जो instant महसूस होता है वह कम काम नहीं कर रहा होता, वह काम वहां कर रहा होता है जहां user उसका इंतज़ार नहीं कर रहा होता।

इस अध्याय में संदर्भित technology

Heuristic suitability scatter. एक brush एक disc में candidate points sample करता है, हर point के लिए एक CPU heightmap से (height, slope) पढ़ता है, slope और altitude predicates से एक preset के picks को filter करता है, एक को weighted-draw करता है, और उसे reject कर देता है अगर वह एक spatial hash में tracked per-family minimum spacing का उल्लंघन करता है। Slope-aligned picks अपने up vector को surface normal की ओर rotate करते हैं। यह ऐसा placement produce करता है जो इरादतन पढ़ा जाता है (trees cliffs से दूर, rocks ढलानों में झुके, pebbles waterline पर रुके) बिना किसी learned weights के, और preset को flat data के रूप में रखता है ताकि एक LLM-generated pick list एक drop-in swap हो।

Async loads के तहत deterministic placement. एक seedable Mulberry32 RNG हर draw का मालिक है, इसलिए (seed, brush events) एक session को बिल्कुल वैसा reproduce करता है। RNG draws किसी भी await से पहले होते हैं, और spacing reservations glTF clone के resolve होने से पहले spatial index में डाल दी जाती हैं, इसलिए concurrent candidates एक-दूसरे का सम्मान करते हैं और async asset loading sequence को गड़बड़ नहीं कर सकती।

O(1) edits के साथ bucketed InstancedMesh. हर (propId, partIndex, lod) के लिए एक InstancedMesh, मांग पर live matrices को एक बड़े buffer में copy करके capacity दोगुनी की जाती है। Erase और FIFO-evict swap-remove हैं जिसमें एक back-reference array move किए गए instance का index patch करता है, इसलिए एक removal bucket size चाहे जो हो O(1) है। एक diagnostic ने पुष्टि की कि glTF parts single-material meshes के रूप में आते हैं, जिससे one-bucket-per-primitive active path बनता है और हर primitive को एक स्वतंत्र रूप से बढ़ने वाला bucket मिलता है।

Hysteresis और shared attribute buffers के साथ distance LOD. हर part के लिए तीन meshopt-simplified levels, ±4 m hysteresis वाले distance bands से चुने जाते हैं ताकि किसी boundary के पास का camera न झटके, एक capped rate पर re-evaluate किए जाते हैं और असली camera motion पर gated। चूंकि LockBorder simplification कभी vertices नहीं हिलाता, सभी LODs position/normal/UV/color buffers का एक set share करते हैं और केवल अपने private index buffer में फर्क रखते हैं, distinct GPU vertex buffers को लगभग आधा काट देते हैं। एक defensive computeVertexNormals को छोड़ने से artist normals सभी LODs में एक जैसे रहते हैं और ladder में अकेली shading discontinuity हट जाती है। देखें LOD और meshoptimizer।

High-frequency lookups के लिए analytic heightmap raycast. एक 131k-triangle plane mesh के खिलाफ pointermove-rate cursor lookup per event पूरे index buffer पर चलता है। इसे analytic height function के खिलाफ एक adaptive ray-march से बदलना (surface से दूर बड़े strides, उसके पास एक छोटा floor, $({\text{ray}}_y-{\text{terrain}}_y)$ के sign flip पर bisection) हज़ारों triangle tests के बजाय दर्जनों samples का खर्च लेता है, लगभग तीन orders of magnitude सस्ता, और एक pre-allocated output vector hot path को allocation-free रखता है।

Interaction के critical path से काम हटाओ. महंगा one-time काम (meshopt LOD bakes, WGSL pipeline compiles) idle gaps के दौरान चलना चाहिए, click handler के अंदर नहीं। preset selection पर active preset का पूरा bake preload करना, in-flight promise को cache करना ताकि एक तेज़ click fork करने के बजाय उसमें शामिल हो जाए, और per-geometry preprocessing को memoize करना, इन सबने कुल काम कम किए बिना first-paint latency 209 ms से 4 ms तक गिरा दी।

29 में से भाग 18। पिछला: भाग 17 - ऐसी animations जिन्हें retargeting की ज़रूरत नहीं पड़ी, और एक live asset search अगला: भाग 19 - वह imposter जिसे एक forest में टिकना है सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? सीरीज़ गाइड का इस्तेमाल करें। इसमें बताया गया है कि spike क्या होता है और सभी भागों के लिंक दिए गए हैं।

भाग 16 ने हमें एक ऐसा world दिया जिसमें आप objects रख सकते हैं। यह भाग player को उसमें करने के लिए कुछ बेहतर देता है: एक combat-grade animation set, और एक तरीका जिससे आप search टाइप करके हज़ारों CC0 models में से कोई भी world में खींच सकते हैं।

262 clips, एक skeleton, तीन retargeting fixes

Spike 35 को नए tab में खोलें ↗ · View source

Player rig एक CC4-style 3MIKE skeleton है जिसमें 213 bones हैं, जिनमें एक 80 से ज़्यादा bones वाला facial rig और पूरे finger joints शामिल हैं। Animation sources इससे मेल नहीं खाते। पहली कोशिश में हाथ से चुने हुए Mixamo combat clips को retarget किया गया था, लेकिन source pool पतला था और locomotion Mixamo और कुछ Kimodo BVH idles के बीच अजीब तरह से बंटा हुआ था। असली जीत तब मिली जब हमने source library को Quaternius के दो Universal Animation Library packs पर शिफ्ट किया, कुल 262 clips एक ही consistent UE5-style 65-bone mannequin पर: sword combos, bow archery, climbs, wallruns, dodges, hit reactions, emotes, और एक कहीं ज़्यादा साफ-सुथरा locomotion set।

यह एक 65-bone source से 213-bone target तक का मामला है, जिसमें न कोई shared bone names हैं, न T-pose orientations, न limb proportions। हर clip तीन steps में remap होता है: एक bone-name map, एक bind-pose alignment ताकि दोनों rigs एक reference orientation साझा करें, और position-track scaling ताकि छोटा source rig character को फर्श में घुटनों तक न धंसा दे। इसे सही करने का मतलब था bugs की एक श्रृंखला का पीछा करना, जिनमें से हर एक ने कुछ खास सिखाया।

Character ज़रूरत से ज़्यादा मुड़ा हुआ निकला, हर shoulder और elbow करीब 30° ज़्यादा घूमा हुआ। वजह थी एक pose mismatch: UAL source एक सच्चा T-pose देता है, CC4 का bind एक A-pose है, और retargeter ने मान लिया कि दोनों rigs मेल खाते reference poses में बैठे हैं, इसलिए A-to-T का फर्क हर per-frame delta में जुड़ गया। Fix CC4 के arm chain को एक सच्चे T-pose में मजबूर करता है ताकि bind को capture किया जा सके, फिर retarget करता है, ताकि deltas छोटे रहें।

फिर body translate होना बंद हो गई। Knockbacks ऊपरी body को पीछे झटक देते थे लेकिन पैर जमे रहते थे। UAL displacement को root bone पर रखता है, pelvis पर नहीं, इसलिए pelvis position पढ़ने से लगभग शून्य motion मिलती थी। Fix root.position और pelvis.position को जोड़ता है, horizontal हिस्से को scale करता है, और एक single hip-position track लिखता है। यह करते वक्त हमें पता चला कि vertical offsets करीब 12% गलत थे, क्योंकि हमने Y axis के लिए global limb-proportion ratio का इस्तेमाल किया था जबकि pelvis height को hip-to-floor ratio चाहिए। दो ratios, दो axes: Y के लिए $\text{verticalRatio}=|\text{targetHipY}/\text{sourceHipY}|$, horizontal के लिए proportion ratio। Overshoot खत्म। और RL_BoneRoot.position NaN warnings की एक झड़ी इस बात से जुड़ी थी कि UAL के root (जो $Y=0$ पर है) को एक ऐसे target bone पर map किया जा रहा था जिसका position track उसके bind Y से भाग देकर normalize होता है। शून्य से भाग, NaN, चुपचाप गिरा हुआ track। Fix था root mapping को पूरी तरह हटा देना, क्योंकि उसका translation पहले से ही hip track में मौजूद है।

सबसे छोटा fix देखने में सबसे संतोषजनक था। Character तलवार को limp bind-pose उंगलियों से पकड़ता था क्योंकि bone map में कोई finger entries नहीं थीं, और retargeter सिर्फ mapped bones के लिए tracks लिखता है। 30 finger bones जोड़ने (पांच उंगलियां, तीन segments, दो हाथ, UAL के चौथे tip helper को छोड़कर जो deform नहीं करता) से हाथ grip पर बंद हुआ और release पर खुला।

262 clips को 262 clips देखे बिना साबित करना

आप 262-clip library को आंखों से verify नहीं कर सकते, इसलिए हमने एक offline trajectory parity test बनाया: एक headless Node script जो हर pack को load करता है, source skeleton को 60Hz पर sample करता है, retargeting pipeline चलाता है, और scaling के बाद per-bone world positions और rotations की तुलना source से करता है। Pelvis Y drift अधिकतम 0.003 m आई। हाथों ने एक स्थिर 2.5° offset दिखाया जो पहले "उंगलियां track नहीं हो रहीं" जैसा लगा, लेकिन एक स्थिर offset flat UAL hand और CC4 के थोड़े cupped bind के बीच का bind delta है, और यह पूरे clip में invariant रहता है। असली animation errors उस drift के रूप में दिखती हैं जो frame दर frame बदलती है। एक बार यह साफ हो गया, तो test एक one-shot regression check बन गया: अगर किसी clip का drift उस स्थिर baseline को पकड़े रखना बंद कर दे, तो किसी हालिया बदलाव ने retargeting तोड़ दी है।

एक side-by-side reference mannequin ने debugging के visual हिस्से को निर्णायक बना दिया। Backslash दबाने पर जो भी source rig मौजूदा clip का मालिक है वह player के बगल में दिखता है, इसलिए "मुड़ा हुआ shoulder" वाला सवाल बन जाता है "क्या मुड़ाव source में है, या retargeting ने जोड़ा?" Numerical tests regressions पकड़ते हैं, visual reference उन bind-pose गलतियों को पकड़ता है जो numbers सामने नहीं लातीं, और दोनों ने मिलकर अनुमान लगाने का खेल खत्म कर दिया।

Pipeline ठोस होने के बाद, WASD/jump/swim baseline को Mixamo से UAL पर बदलना एक पतला alias map था: FSM अब भी idle और walk जैसे generic state names बोलता है, जो playback के वक्त UAL clip names में resolve होते हैं। Swimming को per-clip rig offsets चाहिए थे क्योंकि freestyle और tread-water poses pelvis को अलग-अलग anatomical heights पर anchor करते हैं, इसलिए हम active swimming के लिए rig को आधा मीटर डुबाते हैं और treading के लिए और गहरा, उनके बीच एक smooth 5Hz पर blend करते हुए।

एक शब्द टाइप करें, एक model पाएं

Spike 36 को नए tab में खोलें ↗ · View source

Spike 34 ने एक CC0 pack हाथ से curate करने में एक दिन खा लिया। लंबे समय का जवाब एक search box है। Polyhaven एक permissive JSON API और एक deterministic CDN के पीछे करीब 1,100 CC0 models publish करता है, और यह spike पूरे path (query, thumbnails, load, render) को एक static page से बिना किसी build step के जोड़ता है, करीब 300 lines vanilla JS plus three.js में।

Boot पर यह पूरा catalog एक बार fetch करता है, करीब 600 KB। Search पूरी तरह client-side scoring है (name id को हराता है, id category को, category tag को) एक 120 ms debounce के साथ, top 60 cards render करता है। Thumbnails एक IntersectionObserver के ज़रिए lazy-load होते हैं ताकि typing एक साथ 60 requests न दागे। दिलचस्प हिस्सा loading है। Polyhaven का file endpoint multi-file glTF देता है, GLB नहीं, जिसमें textures resolutions के बीच साझा होते हैं और अलग files में बंटे होते हैं, और यह relative path से absolute CDN URL का एक include map लौटाता है। JSON को खुद download और patch करने के बजाय, हम उस map को LoadingManager.setURLModifier के ज़रिए feed करते हैं, जो loader को जिस भी dependency की ज़रूरत हो (वह .bin, हर texture) उसके लिए fire होता है और उसे CDN के ज़रिए resolve करता है। एक click, एक प्रतीत होने वाली file। API और CDN दोनों permissive CORS set करते हैं, जिसे किसी client code से पहले curl से verify किया गया, इसलिए कोई proxy नहीं। PBR materials RoomEnvironment और ACES tone mapping defaults के साथ बिना किसी per-asset fix-up के सही render होते हैं, और 1k textures एक typical model को 4k पर 20 से 40 MB के बजाय 2 से 5 MB पर रखते हैं।

एक meshoptimizer WASM pass इसे एक non-destructive reducer के साथ पूरा करता है: हर mesh अपनी original geometry का एक clone रख लेता है, और ratio बदलने पर उस clone से एक index buffer फिर बनाता है, बजाय इसके कि cumulatively simplify करे। Multi-material geometry per group simplify होती है और geometry.groups फिर बनाती है ताकि material slots न ढहें। एक armchair full पर 5,626 triangles से half पर 2,812 तक जाती है।

इस अध्याय में संदर्भित technology

Bind-pose alignment के साथ skeleton retargeting। एक skeleton से दूसरे पर animation map करने के लिए, जब bone names, proportions और reference poses अलग हों, तीन corrections चाहिए: एक bone-name map, एक bind-pose alignment ताकि दोनों rigs एक reference orientation साझा करें (target के A-pose arm chain को source के T-pose में मजबूर करते हुए), और position-track scaling। एक pose mismatch हर per-frame delta में A-to-T rotation जोड़ देता है, joint rotation को दोगुना करता है। Unmapped helper bones को हटाना ज़रूरी है, क्योंकि $Y=0$ पर एक root bone position-track normalization में एक चुपचाप होने वाला divide-by-zero trigger करता है।

एक rig के लिए दो scale ratios। Horizontal displacement global limb-proportion ratio (समग्र skeleton size) इस्तेमाल करता है, लेकिन vertical pelvis offset hip-to-floor ratio $|\text{targetHipY}/\text{sourceHipY}|$ इस्तेमाल करता है, क्योंकि leg-to-torso proportion rigs के बीच अलग होता है। दोनों axes के लिए एक ही ratio इस्तेमाल करने से climbs overshoot करते हैं और recoveries फर्श के नीचे धंसते हैं। UAL displacement भी root bone पर रहता है, pelvis पर नहीं, इसलिए knockback, climb और locomotion clips में motion बनाए रखने के लिए दोनों को एक single hip-position track में जोड़ना ज़रूरी है।

Offline trajectory parity testing। एक headless script source skeleton को 60Hz पर sample करता है, retargeting pipeline चलाता है, और per-bone world transforms की तुलना source से करता है। एक स्थिर per-frame offset हानिरहित bind delta है, जबकि frame दर frame बदलने वाला drift एक असली error है, इसलिए test एक regression check बन जाता है जो तब fire होता है जब कोई बदलाव किसी track को गिरा या विकृत कर दे। Per-pack GLB isolation (नया load, अगले से पहले मुक्त) पूरे sweep में cache contention से बचाता है।

CDN glTF graphs के लिए LoadingManager.setURLModifier। जब कोई CDN glTF को एक relative-URI graph के रूप में एक साथ include map (relative path से absolute URL) के साथ देता है, तो setURLModifier loader द्वारा मांगी गई हर dependency को JSON को फिर लिखे बिना CDN के ज़रिए resolve करता है। यह एक multi-file, multi-resolution distribution को एक single-click load में ढहा देता है। अगले load से पहले हर पिछले model की geometry, materials और texture maps को dispose करना एक browsing session में सैकड़ों MB GPU memory जमा होने से रोकता है।

Non-destructive mesh simplification। हर mesh की original geometry का एक clone store करना और per simplification ratio सिर्फ index buffer फिर बनाना बदलावों को तेज़ रखता है और बार-बार simplification से होने वाले cumulative नुकसान से बचाता है। Per geometry.groups slice चलाना और groups को फिर बनाना multi-material assignments को बनाए रखता है। यह distance-based LOD को कैसे feed करता है, इसके लिए LOD and meshoptimizer देखें।

29 में से भाग 17। पिछला: भाग 16 - एक ऐसे world के लिए structure जो बढ़ता रहता है अगला: भाग 18 - एक scatter brush जो AI-placed महसूस होता है सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide

Mariana Muntean द्वारा, Cinevva की CEO

अजनबी Cinevva के बारे में सबसे आम बात यही कहते हैं कि यह एक AI wrapper है। वे homepage पर आते हैं, "Describe your game" लिखा एक अकेला input box देखते हैं, और तय कर लेते हैं कि उन्होंने product को समझ लिया। उन्होंने सामने का दरवाज़ा समझा है। Product वह सब कुछ है जो उस वाक्य को टाइप करते वक़्त आपको दिखाई नहीं देता, और इस हफ़्ते से, एक open world भी जिसमें आपके players घूमते हुए आपके game तक पहुँचते हैं।

उस input के पीछे एक पूरा game engine है, 26 typed tools वाला एक orchestrator, generative models का एक बेड़ा, ग्यारह providers में फैली हुई aggregated asset search, एक live game iframe जिसे agent पढ़ और लिख सकता है, और एक storefront जहाँ वही agent आपके तैयार game को एक swipe होने वाली gameplay reel के तौर पर ship करता है। इसमें से कुछ भी अजूबा नहीं है। यह सब plumbing है। दिलचस्प काम यह तय करना था कि किसको किससे जोड़ें।

यह post मशीन को ऊपर से नीचे तक घुमाकर दिखाती है। यही वह समझाइश है जो हम technical investors को देते हैं और यही वह समझाइश है जो हम contribute करने की सोच रहे developers को देते हैं। उन्हें एक ही जवाब चाहिए।

1. Prompt सतह है, system नहीं

पहला design फ़ैसला यह था कि जब तक user का इसमें कुछ दाँव पर न लगे, तब तक सब कुछ छिपाकर रखें। Homepage का एक ही काम है, एक वाक्य लेकर उसे एक project में बदल देना। हमने अनुभव को एक public तरफ़ (prompt, showcases, storefront feed) और एक creator तरफ़ (IDE, asset tools, publish flow) में बाँट दिया, ताकि जो लोग बस खेलना चाहते हैं उन्हें cockpit देखना ही न पड़े।

इसीलिए placeholder "Make a snake game with neon graphics" और "Top-down zombie shooter" जैसी चीज़ों के बीच घूमता रहता है। ये tutorials नहीं हैं। ये एक इजाज़तनामा हैं। User देखता है कि वह "अजीब arcade idea" एक जायज़ input है।

जिस पल आप submit करते हैं, तीन चीज़ें होती हैं। System एक stable ID के साथ एक नया game project बनाता है। यह एक खाली file tree बोता है (index.html, game.js, style.css, assets/, GDD.md)। और यह आपके वाक्य को एक project context window के साथ orchestrator में भेजता है जो उन खाली files की ओर इशारा करता है। यहाँ से आगे आप एक ऐसे agent से बात कर रहे हैं जिसके हाथ हैं।

2. Input के पीछे, एक पूरा browser IDE

Creator workspace एक तीन-panel वाला IDE है जो पूरी तरह browser में चलता है। बाईं ओर file tree, बीच में code editor, दाईं ओर live game iframe, और नीचे की ओर चलता हुआ एक chat input। हमने यह layout जानबूझकर चुना। जो लोग पहले से code लिखते हैं वे इसे तुरंत पहचान लेते हैं। जो नहीं लिखते वे बीच वाले panel को नज़रअंदाज़ कर सकते हैं और सिर्फ़ chat से बात करते रह सकते हैं।

File tree कोई रूपक नहीं है। हर project सचमुच HTML, JS, CSS, generated images, GLB models और audio files की एक छोटी static site है, जो R2 से सीधे एक Cloudflare Worker के ज़रिए serve होती है। कोई build step नहीं है। इसकी वजह मायने रखती है। इसका मतलब है कि agent वही files पढ़ और लिख सकता है जो आप असल में ship करेंगे, और इसका मतलब है कि वही artifact iframe में चलता है, Capacitor में लिपटे एक phone पर चलता है, Tauri में लिपटे Steam पर चलता है, और Discord के अंदर एक Embedded Activity के तौर पर चलता है। एक filesystem, छह distribution targets।

हमारे बनाए हर game के लिए ज़रूरी है कि वह window पर दो functions expose करे। getGameState() एक सादा object लौटाता है जो चल रहे game का वर्णन करता है (player position, score, lives, enemies, timers)। setGameState(patch) एक partial update वापस live game पर लगाता है। यह छोटा सा API वह अनुबंध है जो agent को game को reload किए बिना उसे inspect और modify करने देता है। हम section 6 में इसकी वजह पर लौटेंगे।

3. Orchestrator, जहाँ असल engine रहती है

जब लोग इसे "एक AI wrapper" कहते हैं तो वे यह बात चूक जाते हैं कि AI इतना code नहीं लिखता जितना कि वह एक छोटे orchestra का संचालन करता है। Orchestrator एक tool-calling loop है जो एक frontier model के ख़िलाफ़ चलता है, जिसका system prompt क़रीब एक हज़ार लाइन लंबा है और 26 functions की एक typed tool surface है। Tool definitions ही engine हैं। Model conductor है।

26 tools पाँच परिवारों में बँटते हैं। Filesystem tools (list_game_files, read_files, search_game_file, edit_files, write_files, delete_files, rename_files) agent को आपके game को किसी भी दूसरे codebase की तरह बरतने देते हैं। Project tools (create_new_game, list_games, open_game, ask_user, game_ready) एक project के जीवनचक्र और इंसान को वापस सौंपने का काम संभालते हैं। Generative tools (generate_image, generate_skybox, generate_music, generate_sfx, rig_model, apply_animation, list_animations, list_skybox_styles) उन specialized models को call करते हैं जिन्हें हम आगे cover करेंगे। Knowledge tools (search_fonts, list_library_docs, search_library_docs, list_generations) agent को hallucinated APIs के बजाय भरोसेमंद, indexed सच्चाई के स्रोत देते हैं। और runtime tools (read_console_logs, execute_js) agent को live game देखने और छूने देते हैं।

एक आम पहली turn कुछ ऐसी दिखती है। User टाइप करता है "Make a neon space shooter"। Model एक write_files call निकालता है जिसमें GDD.md design का वर्णन करता है, फिर दोबारा write_files जिसमें index.html, game.js और style.css होते हैं। यह generate_music को prompt="synthwave space shooter, 120 BPM, driving bassline" के साथ call करता है जो ElevenLabs Music के ख़िलाफ़ एक job शुरू करता है और R2 के अंदर एक MP3 URL लौटाता है। यह starfield के लिए एक Blockade Labs model 3 style के साथ generate_skybox call करता है। यह iframe को नए build पर पलटने के लिए game_ready(title, message) call करता है, और आख़िर में यह पुष्टि करने के लिए कि game बिना errors के boot हुआ, read_console_logs call करता है। अगर इसे कोई stack trace दिखता है, तो user के कुछ बताने से पहले ही यह edit_files पर लौटकर उसे ठीक कर देता है।

इस design की दिलचस्प बात यह है कि system prompt और tool schemas ही एकमात्र ऐसी चीज़ें हैं जो product-specific हैं। Model बदल दीजिए, फिर भी सब कुछ चलता है। हमने पिछले साल तीन frontier models के बीच migrate किया है बिना surface बदले, क्योंकि surface हमारी है।

4. Asset वाली तरफ़: एक model fan-out

Agent images, music, sound या 3D ख़ुद नहीं बनाता। यह specialists को call करता है। Cinevva की asset वाली तरफ़ best-in-class models में एक fan-out है, जिसे इस तरह जोड़ा गया है कि एक का output अगले का जायज़ input बन जाए।

Images और sprites के लिए, generate_image Flux Pro 1.1 को एक ऐसी width और height के साथ call करता है जो हमेशा 32 का गुणक होती है, और एक output format के साथ जो prompt में transparency माँगने पर PNG में पलट जाता है। पूरे गानों के लिए agent एक stylistic prompt और seconds में एक duration के साथ ElevenLabs Music को call करता है। इक्का-दुक्का effects के लिए, ElevenLabs SFX "laser gun firing, sci-fi blaster" जैसे text से पाँच से पंद्रह seconds में एक clip बना देता है। 360 degree environments के लिए, generate_skybox Blockade Labs को लगभग नब्बे styles में से किसी एक के साथ call करता है, default में model 3 Digital Painting। 3D characters के लिए, rig_model एक GLB को Tripo को भेजता है ताकि उसे biped, quadruped, hexapod, octopod, serpentine या aquatic creature के रूप में skin और rig किया जाए, फिर apply_animation पंद्रह presets में से कोई भी चला देता है (idle, walk, run, jump, climb, dive, slash, shoot, hurt, fall, turn, साथ ही non-biped marches)।

इनमें से हर एक एक job है, sync call नहीं। इन्हें seconds से लेकर minutes लगते हैं। Orchestrator इन्हें launch करता है, तुरंत एक jobId के साथ लौटता है, और जब asset तैयार हो जाता है तो एक अलग channel नतीजे को वापस conversation में भेज देता है। इससे एहसास पूरी तरह बदल जाता है। Agent game logic बनाता रह सकता है जबकि background में एक 3D model rigging पूरी कर रहा होता है। User को कभी किसी एक critical path पर रुकना नहीं पड़ता।

सारे artifacts एक ही जगह आ गिरते हैं। R2, cdn.cinevva.com के पीछे, सादे URLs की तरह addressable। यानी agent का अगला write_files call बस <audio src="https://cdn.cinevva.com/audio/abc.mp3"> embed कर सकता है और game बस चल पड़ता है। कोई SDK नहीं, कोई asset bundler नहीं, कोई manifest नहीं।

5. ग्यारह providers में asset search

जब आपको कुछ ख़ास चाहिए तो generation बढ़िया है। जब कुछ पहले से मौजूद है तो search ज़्यादा तेज़ है। Asset Library ग्यारह मुफ़्त और licensed providers में फैली एक federated search है, जो एक ही ranked feed में लौटती है।

Provider registry worker में बैठती है और हर query को PolyHaven, Sketchfab, Freesound, Kenney, AmbientCG, Quaternius, OpenGameArt, Smithsonian 3D collection, TurboSquid, Synty और Jamendo के ख़िलाफ़ समानांतर में चलाती है। हर provider एक साझा interface लागू करता है (search, getMetadata, isBrowsable, getSupportedTypes), इसलिए नया जोड़ना सिर्फ़ एक TypeScript file है। Aggregation layer अलग-अलग तरीक़े से paginate करने वाले providers में cursor-based pagination संभालती है, licenses को deduplicate करती है, asset types को एक साझा taxonomy (model, texture, audio, hdri, sprite) में normalize करती है, और हर asset को उसके license के साथ tag कर देती है ताकि agent कभी ऐसा कुछ न चुने जिसे वह redistribute न कर सके।

जब पिछली तिमाही ChatGPT ने इस tool को game devs के लिए बेहतरीन मुफ़्त asset finders में से एक के रूप में सुझाया, तो हमने वह सिफ़ारिश पढ़ी। जो बात मायने रखती है, उस बारे में वह सही था। बात यह नहीं है कि हमारे पास एक अकेली library के ऊपर एक search bar है। बात यह है कि "stone wall texture" खोज रहे एक indie developer को PolyHaven और AmbientCG के नतीजे, साथ-साथ Kenney के stylized version और Smithsonian के एक photogrammetry option के साथ मिलते हैं, एक query में, एक जैसी license metadata के साथ। Agent उसी endpoint को hit कर सकता है और assets वैसे ही चुन सकता है जैसे एक इंसान चुनता है।

Engine का यही हिस्सा अक्सर कम आँका जाता है। ज़्यादातर game-AI demos सब कुछ शून्य से generate करते हैं और एक एक-सी, चमकीली, थोड़ी अटपटी सी शक्ल पर आकर रुक जाते हैं। Cinevva पर दिलचस्प games generated assets को Smithsonian की असली CC0 photogrammetry और Quaternius के एक हाथ से बने low-poly पेड़ के साथ मिलाते हैं। Orchestrator यह एक ही turn में कर सकता है।

6. Agent game खेलता है

जब हम इसे दिखाते हैं तो यही हिस्सा ज़्यादातर engineers को चौंकाता है। Agent सिर्फ़ files में code नहीं लिखता। यह game को एक sandboxed iframe में चलाता है, उसका console पढ़ता है, UI बनाम 3D scene के लिए layered screenshots लेता है, और state को inspect या बदलने के लिए live runtime के अंदर JavaScript execute करता है।

read_console_logs iframe से console.log, console.warn, console.error और uncaught exceptions की आख़िरी पचास लाइनें लौटाता है। हर game_ready call के बाद, system prompt के मुताबिक़ agent के लिए ज़रूरी है कि वह read_console_logs call करे और user को वापस सौंपने से पहले कोई भी errors ठीक करे। वह एक नियम ज़्यादातर ऐसी विफलताओं को ख़त्म कर देता है जैसे "AI ने कहा कि हो गया पर screen काली है", जो दूसरे tools में होती हैं।

execute_js ज़्यादा ताक़तवर वाला है। यह game के global scope के अंदर मनमाना JavaScript चलाता है। चूँकि हर game के लिए getGameState और setGameState लागू करना ज़रूरी है, इसलिए agent चल रहे game की पूरी state पढ़ने के लिए JSON.stringify(getGameState()) चला सकता है, फिर player को teleport करने के लिए setGameState({player: {x: 500, y: 100}}), invincibility देने के लिए setGameState({lives: 99}), या आगे skip करने के लिए setGameState({level: 3})। यह नीचे के स्तरों पर भी हाथ डाल सकता है, जैसे Three.js scene graph inspect करने के लिए scene.children.map(c => c.type) या renderer mount हुआ या नहीं यह पुष्टि करने के लिए document.querySelectorAll('canvas').length।

आप देख सकते हैं कि यह क्यों मायने रखता है। जब कोई user कहता है "level दो पर player दीवार में फँस जाता है", तो agent को अंदाज़ा नहीं लगाना पड़ता। यह level दो खोलता है, getGameState() चलाता है, collision data जाँचता है, एक fix test करने के लिए एक execute_js patch चलाता है, और तभी fix को disk पर लिखता है। यह उसी तरह debug करता है जैसे आप debug करते हैं। हम iframe को एक साथी मानते हैं, निशाना नहीं।

7. Library docs, सच्चाई का उबाऊ स्रोत

जिन libraries को games असल में इस्तेमाल करते हैं (Three.js, Tone.js, Cannon, और बढ़ती जा रही सूची) उनके official documentation को हम एक structured, searchable JSON store में index करते हैं। Agent खुले web की ओर जाने से पहले search_library_docs("threejs", "Mesh") की ओर हाथ बढ़ाता है। यह तेज़ है, यह versioned है, और यह कभी ऐसा method नहीं गढ़ता जिसका नाम दो minor releases पहले बदल दिया गया था।

यह चमक-दमक वाली बात नहीं है। यही वह फ़र्क़ है जो एक ऐसे AI के बीच है जो चलने वाला code बनाता है और एक ऐसे AI के बीच जो देखने में भरोसेमंद लगने वाला code बनाता है जो लाइन चालीस पर crash कर जाता है। Cinevva से बने games की दिखाई देने वाली गुणवत्ता का ज़्यादातर हिस्सा इसी एक फ़ैसले से आता है।

8. खेलने योग्य से खोजने योग्य तक: reels और storefront

जिस game को कोई नहीं खेलता वह एक निजी शौक़ है। Indie development में सबसे कठिन अनसुलझी समस्या अब games बनाना नहीं रह गई। वह distribution है। तो engine "खेलने योग्य" पर आकर नहीं रुकती। यह "players के सामने" पर रुकती है।

Cinevva पर हर project एक stable share URL साथ रखता है जैसे play.cinevva.com/{game-id}, जो game का नवीनतम build एक full-page iframe में खोलता है, साथ में likes और shares के लिए एक नन्हा overlay। जब agent game_ready call करता है, तो यह सिर्फ़ IDE के अंदर वाला preview नहीं पलटता। यह Cinevva storefront पर एक 15-second की gameplay reel publish करने की पेशकश भी करता है। Reel game को खेले जाने की असली recording है, जो सीधे iframe से capture की जाती है (हम एक छोटा recorder script ship करते हैं जिसे agent game runtime में inject करता है), इसलिए viewer जिसके आगे से scroll करता है वह असली gameplay है, कोई marketing edit नहीं।

इससे वह loop बदल जाता है जिसमें एक developer जीता है। पुराना loop था code करो, build करो, package करो, upload करो, एक Steam page लिखो, एक algorithm से लड़ो, एक wishlist counter देखो। नया loop है एक वाक्य टाइप करो, agent को बनाते हुए देखो, publish दबाओ, और अपने game को बाक़ी सब के साथ उसी swipe feed में आते हुए देखो। Discovery उसी product में होती है जहाँ creation होती है, उसी URL पर, उसी login के साथ।

dev community के पाठकों के लिए, यही हिस्सा जाँचने लायक है। Distribution हमेशा वह खाई रही है जो game engines साथ लेकर नहीं आतीं। Unity एक editor ship करता है, game आप Steam पर ship करते हैं। Unreal एक editor ship करता है, आप Epic Store पर ship करते हैं। Cinevva दोनों हिस्से ship करता है। Engine और storefront उसी orchestrator के ज़रिए आपस में बात करते हैं जिसने game बनाया।

9. Top Performers: discovery flywheel

Reels feed flywheel का एक आधा हिस्सा है। Top Performers chart दूसरा है। यह games को trending, recent और all-time top के हिसाब से रैंक करता है, जो raw clicks के बजाय completion rate (क्या player ने एक session पूरा किया) से weighted होता है। Completion को installs के मुक़ाबले गेम करना ज़्यादा मुश्किल है। एक ऐसा game जो साठ seconds तक ध्यान बाँधे रखता है, उस game से बेहतर है जिसे खोलकर बंद कर दिया जाता है।

हर signal वापस orchestrator की अगली turn में feed होता है। जब agent कहता है "चलो एक power-up जोड़ते हैं", तो यह किसी तय pattern library से नहीं उठा रहा। यह एक ऐसे model से उठा रहा है जिसने देखा है कि इस महीने Cinevva पर कौन-से mechanics असल में players को रोके रखते हैं। Flywheel page के नीचे लगा कोई chart नहीं है। यह पूरी engine के लिए training signal है।

investors के लिए, यही data वाली खाई है। हमारे पास सिर्फ़ generated games नहीं हैं। हमारे पास असली session-level engagement metrics वाले generated games हैं, जो उन prompts से जुड़े हैं जिन्होंने उन्हें बनाया, जो उन asset choices से जुड़े हैं जो agent ने कीं, जो उन players से जुड़े हैं जिन्होंने उन्हें like किया। हर loop अगले को कसता जाता है।

10. Engine एक game बन जाती है

यहाँ वह हिस्सा है जिसके बारे में मैं महीनों से social पर इशारे करती रही हूँ। Sections 1 से 9 तक सब कुछ एक ऐसे system का वर्णन करता है जो games बनाता है। जिसे वर्णन करना ज़्यादा कठिन है, जब तक आप देख न लें, वह यह है कि क्या होता है जब system ख़ुद एक जगह बन जाती है।

Game बनाना कठिन काम है, हमारे ship किए हर चीज़ के बावजूद। अगर आपने पहले कभी game नहीं बनाया, तो अचानक आप plot, characters, world, mechanics, कौन क्या और कब करता है, light कैसे बरतती है, special effects कैसे layer होते हैं, music, sound effects, camera की चालें, इन सब के ज़िम्मेदार बन जाते हैं। यह बहुत कुछ है। और इन सब के ऊपर आप चाहते हैं कि नतीजा आपका अपना लगे, किसी और के tool से उगले गए template जैसा नहीं। Prompt और orchestrator आपके लिए ज़्यादातर यांत्रिक काम कर देते हैं। जो वे अकेले नहीं कर सकते वह है आपकी तैयार चीज़ को खड़े होने के लिए एक मंच देना जहाँ और लोग देख रहे हों।

तो हमने मंच बनाया। इस साल के ज़्यादातर समय में Oleg और engine team browser में एक open world रखने के बारे में एक 14-भाग की श्रृंखला में काम publish करते रहे हैं। ऐसा sculpted terrain जिसे आप real time में तराश सकते हैं। ऐसे biomes जो slope और altitude के आधार पर ख़ुद को rock या grass रंग लेते हैं। compute-generated terrain के ऊपर 80,000 grass blades जो हवा में झुकते हैं। एक ऐसा character जो एक ही चाल में heightmap और volumetric terrain के पार चलता, दौड़ता, कूदता और सरकता है। इनमें से कुछ भी अपने आप में एक tech demo नहीं था। यह इसी के लिए आधार था।

आज open world शुरुआती रूप में live है। आप एक avatar पहनते हैं और अंदर चल पड़ते हैं। आपके published games आपके आसपास घूमने लायक जगहों के तौर पर दिखते हैं, ठीक वैसे ही जैसे storefront reels और Top Performers chart उन्हें अभी दिखाते हैं, बस इस बार आप swipe करके नहीं बल्कि पैदल पहुँचते हैं। आप world से ही किसी अजनबी के game में, world छोड़े बिना, उतर सकते हैं। आप उस इंसान के बगल में खड़े हो सकते हैं जिसने वह चीज़ बनाई जो आपने अभी खेली और उसे बता सकते हैं कि आप आगे क्या जोड़ते। आप किसी अभी-अभी मिले इंसान के साथ terrain का एक टुकड़ा तराश सकते हैं और उसे एक नए project का बीज बना सकते हैं। Discovery एक feed होना बंद कर देती है। यह एक सैर बन जाती है।

हमारी engine हमेशा से तकनीकी अर्थ में एक game engine रही है। आज यह शाब्दिक अर्थ में भी एक बन जाती है। जो चीज़ आपका game बनाती है वह अब ख़ुद एक game है, और section 3 का वही orchestrator, section 4 के वही asset rails, section 6 का वही getGameState अनुबंध, section 8 की वही reels, और section 9 का वही chart, सब मिलकर उस एक जगह में बन जाते हैं जहाँ आपके players घूमते हैं। बनाने और खेलने के बीच की दीवार हमेशा से बनावटी थी। अब वह चली गई है।

जो हमें लगता है हमने सही किया

पहली चीज़ जो हमने सही की वह थी prompt को एक product के बजाय एक UI affordance की तरह बरतना। Product है orchestrator, tool surface, asset rails और storefront। Prompt एक user को system में लाने का सबसे सस्ता संभव तरीक़ा है।

दूसरी थी बिना build step वाले एक flat, browser-native filesystem पर अड़े रहना। इसी वजह से एक Cinevva game एक ही सच्चाई के स्रोत से mobile, desktop, Steam और Discord पर ship होता है। इसी वजह से agent जो उसने लिखा वह पढ़ सकता है।

तीसरी थी वह अनुबंध कि हर generated game getGameState और setGameState लागू करता है। System prompt में वह एक लाइन ही agent को एक code generator के बजाय एक सहयोगी जैसा महसूस कराती है। Agent खेल सकता है, और जो system खेल सकता है वह debug कर सकता है।

चौथी थी storefront को engine के उसी loop में जोड़ना। हम raw model quality पर नहीं जीतने वाले। एक open-weights generator से दो महीने आगे रहने में कोई बचाव लायक फ़ायदा नहीं है। हम तब जीतते हैं जब वही agent जो आपका game बनाता है उसे publish भी करता है, मापता भी है, और इससे सीखता भी है कि अजनबियों ने उसे कैसे खेला।

अगर आप पूरी मशीन को चलते हुए देखना चाहते हैं, तो homepage का prompt अब भी सामने का दरवाज़ा है। एक वाक्य टाइप करिए। देखिए इसके पीछे क्या होता है। फिर यहाँ वापस आकर हमें बताइए कि engine का कौन सा टुकड़ा अगला लिखें।

लिखा है Oleg Sidorkin ने, Cinevva के CTO और को-फाउंडर

यहाँ नए हैं? सीरीज़ गाइड देखिए। यह बताती है कि spike क्या होता है और सारे भागों के लिंक देती है।

भाग 13 के बाद से हर spike एक ही नुस्खे पर चल रहा था: पिछले monolith को copy करो, एक feature जोड़ो। spike 32 के आते-आते वह monolith एक ही <script type="module"> के अंदर 6,285 लाइनों का index.html बन चुका था। Code search शोरगुल भरा था, किसी feature को कहाँ जोड़ना है यह ढूँढने में उसे लिखने से ज़्यादा वक़्त लगता था, और कोई भी architectural बदलाव एक ऐसी file को छूता था जो इतनी बड़ी थी कि उसे दिमाग में diff करना मुमकिन नहीं था। अगला feature जोड़ने से पहले हमने structure का कर्ज़ चुकाया।

व्यवहार में बिना किसी बदलाव के monolith को तोड़ना

Spike 33 को नए tab में खोलिए ↗ · सोर्स देखिए

शर्त सख़्त थी: हर split एक pure refactor होना चाहिए, redesign नहीं। Monolith 19 .mjs files और एक 151-line वाले host shell में बदल गया। scene, water, grass, character, physics, multiplayer और UI के लिए top-level modules, एक wgsl.mjs जो हर WGSL source string को GPU सच के इकलौते स्रोत के रूप में रखता है, और heightmap, SDF, chunks, GPU buffer wrappers, brush, LOD और persistence के लिए एक terrain/ subtree। कुल code 6,555 लाइनों का निकला, मोटे तौर पर monolith जमा import boilerplate। मात्रा में कोई शुद्ध बदलाव नहीं, navigability में बड़ा बदलाव।

फिर page load हुआ और एक काली स्क्रीन दिखी। दो error messages, दो बिल्कुल अलग root causes। पहला एक zero-byte buffer binding को लेकर WebGPU की शिकायत थी। Monolith में SDF brush buffer तब lazily allocate होता था जब पहला marching-cubes chunk आता था, और bind-group factory संयोग से बाद में चलती थी, buffer के बन जाने के बाद। terrain/gpu.mjs को terrain/brush.mjs से अलग करने पर module evaluation का क्रम बदल गया, इसलिए अब factory पहले चली और एक null placeholder को bind करने की कोशिश की। इसका हल था bind-group creation को पहले dispatch तक टाल देना, एक getOrCreateBindGroup(chunk) helper के ज़रिए। "सब कुछ पहले से बना लो" वाला pattern monolith के इकलौते init path की एक देन था।

दूसरा message एक डरावना दिखने वाला FBX skeleton warning था जो असल में एक झाँसा निकला। यह spike 25 से छप रहा था और बेज़रर था। Character सिर्फ़ इसलिए गायब था क्योंकि पहले bug का सिलसिला चल पड़ा: हर compute dispatch fail हुआ, heightmap कभी लिखा ही नहीं गया, height samples 0 लौटाने लगे, और character origin पर spawn होकर दुनिया के बीच से नीचे गिर गया। Buffer ठीक करो, तो character ठीक से animate करता है, warning समेत।

यही इस refactor का असली सबक है। Monolith ने हर "X को Y बनने से पहले मौजूद होना चाहिए" वाले रिश्ते को top-to-bottom script order के अंदर छुपा रखा था। Modularize करने पर वह क्रम बदल गया और तीन और छुपे हुए ordering bugs सामने आए: heightmap upload से पहले grass scatter होना, environment map के decode पूरा होने से पहले water plane जुड़ना, और पहले frame के बाद persistence load पूरा होना। तीनों एक-लाइन के fixes थे, और split के बिना इनमें से एक भी नहीं पकड़ा जाता।

बिना किसी चीज़ को बढ़ाए सौ props

Spike 34 को नए tab में खोलिए ↗ · सोर्स देखिए

Spike 34 इस बात की परीक्षा थी कि structure का फ़ायदा मिला या नहीं। मक़सद था एक first-person palette, जिससे एक CC0 model pack से trees, rocks, bushes, mushrooms और paths रखे जा सकें, terrain-aware alignment, persistence, multiplayer sync और physics colliders के साथ, और यह सब controls छोड़े बिना। नए code की हर लाइन src/props/ के नीचे पाँच नई files में आई, और कोई भी मौजूदा module दस hook-up लाइनों से ज़्यादा नहीं बढ़ा।

Asset वाला सफ़र एक ऐसा चक्कर ले बैठा जो दर्ज करने लायक है, क्योंकि यह उस तरह की चीज़ है जो पूरा दिन खा जाती है। हमने Quaternius के Ultimate Nature pack से शुरुआत की, एक FBX library जिसमें embedded textures नहीं थीं। FBX materials बिना map के MeshPhong के रूप में आए, इसलिए हमने एक manual material-name-to-PNG table जोड़ी, Phong को Standard में बदला, और color spaces हाथ से set किए। करीब 30% materials का कोई matching PNG नहीं था और कई नाम एक जैसे trees के बीच confusing थे। एक दूसरे FBX pack में भी वही कमी थी। हल और mapping tables नहीं था, हल एक बेहतर तरीके से authored pack था: Quaternius का Stylized Nature MegaKit 116 पूरे glTFs के साथ आता है, जिनमें embedded PBR materials और baked normals हैं। FBXLoader की जगह GLTFLoader लाने से cm-to-meters scaling, texture table और Phong conversion मिट गए, और library.mjs करीब 80 लाइन छोटा हो गया। सीख यह: जो CC0 packs glTF के साथ PBR भेजते हैं, उनके लिए वही सही pipeline है, और manual texture mapping वाला FBX दोगुना code था आधी quality के लिए।

glTF के रास्ते के साथ कुछ नुकीले किनारे भी आए। Palette 116 thumbnails render करती है, और WebGPU का canvas.toDataURL() एक GPUCanvasContext surface के लिए खाली लौटाता है, इसलिए thumbnails एक RenderTarget में render होती हैं, readRenderTargetPixelsAsync से वापस पढ़ी जाती हैं, और एक 2D canvas में blit होती हैं, WebGPU के 256-byte row alignment का ध्यान रखते हुए। Ghost previews हर material को clone करके उन्हें हरा रंग देती हैं, जो उन meshes पर टूट गया जिनका material एक array है, और इसे एक Array.isArray branch से ठीक किया गया। और जो 16-bit normal maps ~200 MB पर आए थे, उन्हें एक बार के mogrify -depth 8 से ~32 MB तक घटाया, और वे देखने में एक जैसे ही रहे, क्योंकि browsers वैसे भी upload पर downsample कर देते हैं।

जब rendered geometry सिर्फ़ GPU पर मौजूद हो

सबसे सिखाने वाला bug यह था कि cursor के हिलने पर ghost preview 1 से 2 meter की छलाँगों में snap कर रहा था। Terrain meshes अपने vertex positions एक StorageBufferAttribute में रखते हैं क्योंकि compute pipeline उन्हें सीधे GPU पर लिखता है, इसलिए three.js का CPU Raycaster उन्हें देख नहीं पाता और कुछ नहीं लौटाता। Fallback analytic heightmap के ख़िलाफ़ एक मोटा 1.5 m ray-march था, और वही तय stride वह grid था जो user को दिखता था। हमने उसकी जगह एक adaptive march लगाया: surface से काफ़ी ऊपर रहते हुए stride 2.5 m, उसके 5 m के भीतर आने पर घटकर 0.4 m, और फिर $({\text{ray}}_y-{\text{terrain}}_y)$ का चिह्न पलटने पर 14 बार bisect। इससे प्रति cast करीब 30 चौड़े steps जमा 14 bisections में sub-millimeter precision मिलती है। जब rendered geometry सिर्फ़ GPU पर बसती हो, raycaster से मत लड़िए, analytic source के ख़िलाफ़ march कीजिए।

ऐसे colliders जो edits के दौरान ईमानदार रहें

हमने convex hulls या mesh colliders के बजाय primitive proxies चुने। Quaternius props गोल-मटोल और low-poly हैं, बिना किसी मायने रखने वाली concavities के, इसलिए hulls उसी gameplay के लिए करीब 50 गुना code और 10 गुना runtime cost होते। हर prop अपने bounding box से निकले एक shape में सिमट जाता है: trees और cacti एक vertical capsule में, rocks एक sphere में, logs लंबी axis के साथ एक horizontal capsule में, और सजावटी bushes और flowers किसी चीज़ में नहीं। Rocks और logs walkable हैं (सिर्फ़ vertical push, ताकि आप उन पर खड़े हो सकें), trees और cacti blocking हैं (पूरा 3D push, ताकि आप किसी trunk पर चढ़ न सकें)। एक 8 m spatial hash प्रति-frame test को player के 3×3 neighborhood तक सीमित रखता है, आम तौर पर शून्य से छह props तक।

दो design फ़ैसलों ने system को संगत रखा। Terrain alignment code में hard-code किया हुआ कोई category enum नहीं, बल्कि एक manifest flag है, इसलिए ghost preview और committed placement एक ही placement.alignToTerrain value पढ़ते हैं और आपस में असहमत नहीं हो सकते। और रखे गए props terrain edits पर एक helper के ज़रिए react करते हैं: किसी brush stroke के बाद (local हो या किसी peer से replay हुआ), refreshPlacementsInRadius प्रभावित disc के अंदर हर prop के नीचे की ज़मीन फिर से sample करता है, alignment दोबारा लगाता है, और collider endpoints दोबारा निकालता है। किसी tree के नीचे एक पहाड़ी sculpt कीजिए और tree उसके साथ ऊपर चढ़ जाता है। Persistence और multiplayer spike 31 के pattern को हूबहू दोहराते हैं, {uid, propId, x, y, z, rotY, scale} की एक flat list रखते हैं और place, remove तथा nudge events को BroadcastChannel पर mirror करते हैं।

इस अध्याय में संदर्भित तकनीक

WebGPU के अंदर ES module decomposition। एक monolithic <script type="module"> को bare-path .mjs imports में तोड़ने के लिए किसी bundler की ज़रूरत नहीं होती, जब modules static assets के रूप में serve होते हैं, और three.js TSL module boundaries के आर-पार ठीक चलता है। छुपी हुई लागत है initialization order: एक monolith "Y से पहले X बनाओ" को top-to-bottom script order में दर्ज करता है, जबकि modules import order में evaluate होते हैं, जो किसी GPU bind-group factory को उसके buffer के मौजूद होने से पहले चला सकता है। Fix का pattern है lazy initialization (पहली बार इस्तेमाल पर getOrCreate...) और declaration order पर भरोसा करने के बजाय सही promise का इंतज़ार करना।

embedded PBR वाला glTF बनाम manual mapping वाला FBX। glTF meters में आता है, अपनी ही textures को reference करता है, और सीधे MeshStandardMaterial देता है, इसलिए glTF के रूप में authored कोई CC0 pack सीधा PBR pipeline में गिर जाता है। texture-binding metadata के बिना FBX packs को एक हाथ से संभाली गई material-name-to-PNG table चाहिए जो हर pack update पर खिसक जाती है, साथ में एक Phong-to-Standard conversion और manual color-space tagging। एक foliage safety net बिना alphaTest वाले transparent materials को alphaTest: 0.5 cutout cards में बढ़ा देता है ताकि वे opaque geometry के पीछे ठीक से sort हों।

WebGPU offscreen thumbnails। canvas.toDataURL() किसी GPUCanvasContext-backed canvas के लिए खाली लौटाता है क्योंकि presentation surface से वापस किसी 2D context तक कोई रास्ता नहीं है। एक RenderTarget में render करना, readRenderTargetPixelsAsync से pixels पढ़ना, और एक 2D canvas में blit करना काम करता है, जब तक कि blit WebGPU के 256-byte-aligned read-back stride पर चले। नतीजे localStorage में एक version-bumped key के नीचे cache होते हैं ताकि pack बदलने पर पुराने renders रद्द हो जाएँ।

analytic heightmap के ख़िलाफ़ adaptive ray-march। जब terrain vertices एक GPU StorageBufferAttribute में बसते हैं, तो CPU raycaster उन्हें नहीं देख पाता। analytic height function के साथ march करना, surface से दूर बड़े stride के साथ, उसके पास छोटे stride के साथ, और $({\text{ray}}_y-{\text{terrain}}_y)$ के चिह्न पलटने पर एक binary-search refinement के साथ, samples की एक सीमित संख्या में sub-millimeter cursor precision देता है। यही primitive brush cursor और prop ghost दोनों को चलाती है।

spatial hash के साथ primitive capsule colliders। हर prop अपने bounding box से एक category-derived capsule या sphere में सिमटता है, {kind, walkable, radius, p1, p2} के रूप में दर्ज होता है, और हर 8 m hash bucket में register होता है जिससे वह overlap करता है। प्रति frame player सिर्फ़ अपने 3×3 bucket neighborhood के props test करता है, हर एक के लिए एक capsule-vs-capsule resolution। Walkable proxies (rocks, logs) को सिर्फ़ vertical push मिलता है, blocking proxies (trees) को पूरा 3D push। जिस capsule गणित पर यह टिका है उसके लिए SDF terrain collisions देखिए।

29 में से भाग 16। पिछला: भाग 15 - Baseline बदलिए, फिर उसे sync कीजिए अगला: भाग 17 - वे animations जिन्हें retargeting की ज़रूरत नहीं पड़ी, और एक live asset search सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide

Mariana Muntean द्वारा, Cinevva की CEO

मई 2022 में मैं Ted Harrington के Tech Done Different podcast के लिए एक इंटरव्यू में बैठी थी। उसका मूल लेख अब भी Medium पर मौजूद है। तब तक मैं करीब दो साल से Cinevva चला रही थी। हमारे पास पाँच लोग थे, $200K जुटाया हुआ था, दीवार पर एक Mozilla Builders अवॉर्ड था, और game development किस ओर जा रहा है इसको लेकर बहुत सारी राय थीं।

उनमें से ज़्यादातर राय 2022 में फैशन में नहीं थीं। Web3 का शोर था, AAA studios बातचीत के मालिक थे, GPT-3 एक रिसर्च खिलौना था, और WebGL वह चीज़ थी जिससे शौकिया लोग jam games बनाते थे। "कोई भी क्रिएटिव game developer बन सकता है" ज़ोर से कहने पर सिर्फ़ शिष्टाचार में सिर हिलते थे, एक भी चेक नहीं मिलता था।

पिछले हफ़्ते मैंने वह इंटरव्यू फिर से पढ़ा। मैंने जो कुछ कहा था, उसका कुछ हिस्सा अब केवल मन की कामना जैसा लगता है। कुछ हिस्सा ऐसा लगता है जैसे मेरे पास टाइम मशीन रही हो। यहाँ वे चार दांव हैं जो सबसे अच्छे ढंग से टिके, और हर एक के साथ 2026 असल में कैसा दिखता है।

दांव 1: Game engines की जगह browser में है

2022 में मैंने यह कहा था:

WebGL technology को mobile devices समेत कई platforms पर इस्तेमाल किया जा सकता है, उन दूसरे APIs के उलट जो शायद सिर्फ़ PCs तक सीमित हों। तो चाहे आप घर के आराम में हों या चलते-फिरते, आप फिर भी बना और पब्लिश कर सकते हैं। WebGL games एक पारंपरिक PC game की ज़रूरत के मुक़ाबले CPU और GPU की सिर्फ़ एक छोटी सी मात्रा इस्तेमाल करते हैं।

2022 में यह एक उलटा दांव था। बड़े engines सब के सब downloads, installs और patch cycles मानकर चलते थे। Browser games का मतलब था Flash की पुरानी यादें और Friv।

2026 में हमारा open-world engine एक browser tab में 120 FPS पर चलता है। Terrain, पेड़, physics, multiplayer sync, सब एक ही URL में। कोई download नहीं, कोई app store नहीं, कोई install नहीं।

Browser ने इसलिए रफ़्तार पकड़ी क्योंकि तीन चीज़ें एक साथ आ गईं। WebGPU हर बड़े browser में आ गया। SharedArrayBuffer और cross-origin isolation भरोसेमंद हो गए। WebAssembly इतना तेज़ हो गया कि Rust से compile हुए असली physics engines चला सके। हमारी टीम ने इनमें से हर कदम की असल लागत पर 12 हिस्सों की एक फ़ील्ड जर्नल पब्लिश की। इसका सार यह है कि browser अब एक असली game runtime है, न कि वह जगह जहाँ आप असली game का demo रखते हैं।

इस दांव के अंदर एक दांव मुझसे छूट गया: मैंने यह कम आँका कि कितना काम engineering culture वाले हिस्से पर होगा। Browser game engines को अब browsers नहीं रोकते। उन्हें यह मान्यता रोकती है कि एक असली game का एक launcher होना चाहिए।

दांव 2: AI pipeline का हिस्सा है, कोई साइड फ़ीचर नहीं

2022 में मैंने यह कहा था:

हमारा platform बेहतरीन तरीके से काम करे इसके लिए हम open source game tools इस्तेमाल करते हैं, लेकिन Natural Language Processing, Computer Vision और Open AI solutions, जैसे संवादों के लिए GPT3 और text to image generation के लिए DALL:E, का उपयोग करते हुए अपनी तकनीक भी बनाते हैं।

मई 2022 में GPT-3 एक paid API था जिसे ज़्यादातर लोगों ने कभी इस्तेमाल नहीं किया था। DALL·E मुश्किल से एक साल पुराना था और wait-list पर था। यह कहना कि हम इन्हें production game-dev tools की तरह इस्तेमाल करेंगे, बेहतर से बेहतर मानें तो एक महत्वाकांक्षी नाटक था।

2026 में हर गंभीर क्रिएटिव pipeline में language models और image generation मौजूद हैं, हमारी भी। आज Cinevva के अंदर: soundtracks के लिए ElevenLabs Music, effects के लिए ElevenLabs SFX, assets के लिए Hunyuan3D और SAM3D, visuals के लिए Flux, adaptive audio के लिए Mubert, instrumentation के लिए AceStep। Prompts अंदर जाते हैं, काम लायक assets बाहर आते हैं, और यह सब editor के अंदर ही होता है।

इसके सबूत GDC 2026 की State of the Game Industry रिपोर्ट में हैं। 52% game companies कहती हैं कि generative AI production में इस्तेमाल हो रहा है। वही 52% developers कहते हैं कि AI का इस्तेमाल इंडस्ट्री पर नकारात्मक असर डाल रहा है। दोनों आँकड़े सच हैं। बात यह है कि अंदरूनी तकनीक इतनी तेज़ी से ज़रूरी बन गई जितना कोई मानना नहीं चाहता था।

मुझसे जो ग़लत हुआ: मैंने सोचा था कि विरोध उन engineers से आएगा जो क्वालिटी को लेकर चिंतित हैं। ज़्यादातर विरोध उन artists से आया जो नौकरियों को लेकर चिंतित थे। वह बातचीत मेरी उम्मीद से कहीं ज़्यादा उलझी हुई है, और जो लोग इसे एक साफ़-सुथरी जीत मानते हैं वे ध्यान नहीं दे रहे।

दांव 3: Game development को Google-Docs जैसी collaboration चाहिए

2022 में मैंने यह कहा था:

Source control और app versions के साथ काम अक्सर remote collaboration से जुड़ा होता है। आज ऐसा करने के लिए आपको पता होना चाहिए कि कहाँ जाना है, application का कौन सा version download करना है, सबके साथ in sync रहना है, भगवान न करे कि टीम का कोई सदस्य app के ग़लत version पर हो, तो यह एक समस्या बन जाती है। हमारा लक्ष्य Google doc जैसी क़रीब-क़रीब रियल-टाइम वाली अनुभूति है: सरल, आसान लेकिन मज़ेदार।

Code tools में रियल-टाइम collaboration 2022 में एक हाशिये का विचार था। Replit के पास यह था। VS Code Live Share मौजूद था। ज़्यादातर professional engines के लिए Perforce, एक VPN और एक senior engineer चाहिए था जो आपकी branch की देखभाल करे।

2026 में रियल-टाइम collab हर उस क्रिएटिव tool के लिए डिफ़ॉल्ट है जो गंभीरता से लिया जाना चाहता है। Figma ने इसे design के लिए सामान्य बना दिया। Cursor और Bolt ने इसे code के लिए सामान्य बना दिया। Lovable ने इसे app prototyping के लिए सामान्य बना दिया। Game engines अगुआ नहीं, पिछड़ने वाले थे।

अपने ही engine के अंदर हमारे पास अब multiplayer sync एक first-class spike के रूप में काम कर रहा है, जिसमें chunk streaming, presence और browser में shared state है। अनुभव "लिंक खोलो, अंदर कूदो" के ज़्यादा क़रीब है, बजाय "Perforce सेट करो, Slack पर सही version पूछो, launcher install करो" के।

जो हिस्सा मैंने कम आँका: games में रियल-टाइम collab का सबसे मुश्किल हिस्सा networking नहीं है। यह क्रिएटिव इरादे पर conflict resolution है। एक ही level को एक ही समय पर दो लोगों का एडिट करना sync की समस्या से पहले एक UX समस्या है, और ज़्यादातर tools ने इसे अभी तक हल नहीं किया है।

दांव 4: भविष्य indie है

2022 में मैंने यह कहा था:

जो क्रिएटिव लोग game content नहीं बना पा रहे थे, वे बना पाएँगे। हम इसके भरपूर नए तरीके खोजेंगे कि लोग क्रिएटिविटी को कैसे देखते और व्यक्त करते हैं। इस बार यह प्रक्रिया सिर्फ़ corporations या बड़े AAA studios के हाथ में नहीं होगी। भविष्य indie है।

यह इंटरव्यू की सबसे रोमानी पंक्ति थी, और 2022 में सबसे आसानी से खारिज की जाने वाली। AAA बजट कभी इतने ऊँचे नहीं रहे थे। Indie projects को दिखाई देने में कभी इतनी मुश्किल नहीं हुई थी। गणित ऐसा लग रहा था जैसे वह दूसरी तरफ़ जा रहा हो।

2026 में गणित पलट गया। हमने A Breaker Belt तीन दिन में, दो लोगों ने, एक ही codebase से web, mobile और PC पर बनाया। पहले इसमें एक छोटी टीम को एक तिमाही लगती थी। Solo developers सिर्फ़ vibing नहीं, शिप कर रहे हैं, और Steam Next Fest 2026 में एक-एक व्यक्ति की टीमों से रिकॉर्ड entries आईं।

यह पता लगाने की लागत कि कोई अजीब विचार काम करता है या नहीं, ढह गई है। यही असली बदलाव है, और बाकी सब, pipeline में AI, runtime के रूप में browser, रियल-टाइम collab, इसी की सेवा में है। सही tooling वाले एक solo developer के पास अब वह production क्षमता है जो 2018 में एक 20 लोगों के studio के पास थी।

2022 में जो बात मैंने काफ़ी साफ़ ढंग से नहीं देखी: रुकावट production से discovery की ओर खिसक जाती है। जब हर कोई शिप कर सकता है, तो ढूँढा जाना मुश्किल समस्या बन जाती है। यही दांवों का अगला समूह है, और हम उन्हें लगाने के बीच में हैं।

जो मैंने जानबूझकर ग़लत रखा

2022 के कुछ दांव अब भी लंबित हैं या उनमें सुधार की ज़रूरत है।

उस इंटरव्यू में Web3 वाला कोण जितना होना चाहिए था उससे ज़्यादा ज़ोरदार था। Encryption और zero-knowledge proof वाला हिस्सा एक content-rights primitive के तौर पर टिकता है। Token-and-marketplace वाला ढाँचा ख़राब ढंग से टिका, और 2022 में मैंने इसे जितनी ऊर्जा दी, वह AI tooling पर बेहतर लगती, जहाँ असली फ़ायदा था।

मैंने यह भी कम आँका कि "कोई भी game बना सकता है" का कितना हिस्सा एक discovery और distribution की समस्या है, न कि tooling की समस्या। बनाना अब आसान है। ढूँढा जाना और पैसा कमाना अब भी मुश्किल हैं, और आज हमारा ज़्यादातर काम वहीं जाता है।

यही वह दांव है जो हम अभी लगा रहे हैं। हमने अभी-अभी cinevva.com/play पर एक TikTok-जैसी reels feed शिप की है। असली gameplay की वर्टिकल-स्वाइप क्लिप्स, हर एक पंद्रह सेकंड की, कोई trailers नहीं और कोई marketing footage नहीं। अगर कुछ आपकी नज़र में आता है, तो एक tap और आप उसे अपने browser में खेल रहे होते हैं। कोई download नहीं, कोई install नहीं, आपके और game के बीच कोई tutorial खड़ा नहीं।

indie developers के लिए यह क्यों मायने रखता है इसका कारण कठोर गणित है। Steam Next Fest 2026 में रिकॉर्ड संख्या में entries आईं, जो शानदार लगता है जब तक आप per-game attention budget न जोड़ें। ज़्यादातर demos को एक हज़ार से कम impressions मिले। AI के इसे और ख़राब करने से पहले ही store-page funnel टूटा हुआ था। एक scroll-and-swipe सतह, जहाँ gameplay ही विज्ञापन है, discovery loop को एक ही गति में समेट देती है। यह solo developers को players के सामने उसी तरह रखती है जैसे TikTok अनजान संगीतकारों को श्रोताओं के सामने रखता है। यही वह छूटा हुआ टुकड़ा है जो "कोई भी शिप कर सकता है" और "कोई भी सफल हो सकता है" के बीच में है।

अगर आप मूल इंटरव्यू पूरा पढ़ना चाहते हैं, तो वह यहाँ है। उसे फिर से पढ़ना काम का रहा। 2022 में हमने ज़ोर से जो कुछ कहा था, उसका ज़्यादातर हिस्सा एक काम करने वाला roadmap निकला, बस हमारी सोच से तेज़ रफ़्तार पर।

लिखा है Oleg Sidorkin ने, Cinevva के CTO और को-फाउंडर

यहाँ नए हैं? सीरीज़ गाइड देखिए। यह बताती है कि spike क्या होता है और सारे भागों के लिंक देती है।

बारह भागों तक हमने एक terrain engine बनाया जिसे आप देख सकते थे। उसके ऊपर उड़ सकते थे। seams को न फटते देख तारीफ़ कर सकते थे। इस बार हम उसे छूना चाहते थे।

लक्ष्य आसान लग रहा था: एक player को real time में brush से terrain sculpt करने दो, और उन सिस्टम्स में से किसी को न तोड़ो जिन्हें बनाने में हमने 24 spikes लगाए। इसमें तीन कोशिशें लगीं, दो ऐसे bugs जो rendering failures जैसे दिखते थे पर असल में data model failures थे, और इस पर एक बुनियादी फिर से सोच कि terrain data को कैसे काम करना चाहिए।

तीन झूठी शुरुआतें

Spike 25 आसान वाला होना चाहिए था। production codebase में पहले से एक raycaster था जो terrain meshes को hit करता है। placement tool उसे objects गिराने के लिए इस्तेमाल करता है। एक brush tool उसी shape को follow करता है, बस वह heightmap values को बदलता है, prefab spawn करने के बजाय। आसान।

कोशिश एक: मैंने इसे सीधे production world/client/ TypeScript code में बनाया। नया terrain-brush.ts, chunk.ts में बदलाव, protocol changes, Vue component updates. एक घंटे के भीतर मेरे पास एक brush था जो कुछ-कुछ काम करता था, पर chunk boundaries पर दिखने वाली normal discontinuities थीं। मैं बता नहीं सकता था कि bug मेरे brush code में था, मौजूदा chunk stitching में, या full render loop के साथ किसी interaction में। यह ठीक वही स्थिति है जिसे रोकने के लिए spike methodology मौजूद है। मैंने नियम छोड़ दिया था और तुरंत उसकी कीमत चुकाई। सब कुछ revert कर दिया।

कोशिश दो: standalone spike, पर मैंने Three.js 0.170.0 और WebGL की तरफ़ हाथ बढ़ाया। production code WebGL इस्तेमाल करता है, तो यह natural लगा। पर Spikes 13-24 सब WebGPU पर शिफ़्ट हो चुके थे। एक WebGL brush spike बनाना यह साबित करता कि वह legacy renderer पर काम करता है, उस वाले पर नहीं जिसकी तरफ़ हम migrate कर रहे हैं। ग़लत दिशा। फिर से शुरू।

कोशिश तीन: WebGPU, WebGPURenderer, vertex generation के लिए compute shader, Spike 22 stack से मेल खाता हुआ। इस बार architecture सही था। पाँच brush operations काम कर रहे थे: raise, lower, smooth, flatten, noise. M1 पर brush cycle P95 4ms से कम।

और seam bug अब भी वहीं था।

Spike 25 को नए tab में खोलें ↗ · सोर्स देखें

वह seam bug जो मरता ही नहीं था

cross-chunk normal computation का standard fix है border overlap: हर chunk अपने neighbors से data का एक extra ring स्टोर करता है, ताकि boundary पर normal calculation दोनों तरफ़ से sample कर सके। मैंने वह किया। neighbor edge data को एक expanded buffer में copy किया। seams फिर भी फटते रहे।

मैंने math में गहराई से देखा। chunk A (cx=-1) और chunk B (cx=0) के बीच की boundary पर, दोनों chunks को shared vertex पर एक ही normal compute करनी थी। chunk A के shader ने mix(own_col31, own_col32, 0.85) sample किया। chunk B ने mix(neighbor_edge, own_col0, 0.85) sample किया। ये अलग-अलग data के ज़रिए अलग-अलग bilinear interpolation paths हैं। सही border data के बावजूद, दोनों chunks एक ही point के लिए अलग normals compute करते हैं।

यही वह पल था जब मुझे समझ आया कि असली bug border copy नहीं था। असली bug data model था।

1 से 24 तक का हर spike height_at() नामक एक procedural math function इस्तेमाल करता था। उसे world coordinates दो, height पाओ। साफ़, global, stateless. brush एक math function को बदल नहीं सकता था, इसलिए मैंने ऊपर एक displacement buffer जोड़ा था। terrain अब height_at(x,z) + displacement[i] था। GPU shader में base terrain के लिए 30 lines के noise functions plus displacement overlay के लिए bilinear interpolation code embedded था। flatten brush को यह पता करने के लिए height_at() घटाना पड़ता था कि कौन-सी displacement value target height बनाएगी। दो सिस्टम, एक के ऊपर एक रखे हुए, अलग sampling strategies के साथ अलग चीज़ें compute करते हुए।

असली game ऐसे काम नहीं करता। production में, authored terrain buffers में स्टोर किया गया sampled data होता है। procedural function शुरुआती spikes से एक सुविधाजनक stand-in थी। उसने अपना काम कर दिया था। अब वह सक्रिय रूप से bugs पैदा कर रही थी।

मैंने उसे मार दिया।

अब हर chunk के पास असली height values वाला एक heightmap Float32Array है। creation पर, procedural noise उसे भरता है। उसके बाद, noise function फिर कभी call नहीं होता। brush stored heights को सीधे बदलता है। GPU shader एक buffer से एक function का इस्तेमाल करके पढ़ता है: hm_at(i,j). Normals उसी data पर grid-aligned central differences इस्तेमाल करते हैं। कोई bilinear interpolation ambiguity नहीं। कोई two-system mismatch नहीं। shader 90 lines से 40 lines पर आ गया।

seams ख़ुद ठीक हो गए। shared edge पर दोनों chunks अब अपने-अपने buffers से एक ही discrete height values पढ़ते हैं (border overlap में सही neighbor interior points के साथ)। एक ही data अंदर, एक ही normals बाहर।

यह brush का सबक़ नहीं था। यह data architecture का सबक़ था जिसे brush ने उजागर कर दिया।

फटता हुआ mesh

Spike 26 इसका volumetric समकक्ष था। एक 64-cubed SDF volume को brush से बदलो, फिर marching cubes से re-mesh करो। Spike 25 जैसा ही सवाल, पर 3D में।

जब मैंने इसे पहली बार चलाया, mesh फट गया। हर दिशा में लंबे spikes निकल रहे थे, जैसे एक sea urchin का दिन ख़राब चल रहा हो।

Spike 26 को नए tab में खोलें ↗ · सोर्स देखें

मैंने जो MC case table generate की थी उसमें 4096 के बजाय 3840 entries थीं। पूरी table है $256\text{cases}\times 16\text{slots}=4096$, पर मेरे पास $256\times 15=3840$ थीं, case 112 से शुरू होकर सोलह missing rows. उस index के बाद हर lookup shift हो गई, इसलिए case number अब triangulation data से मेल नहीं खाता था। जब marching cubes ग़लत entry पढ़ता है, तो वह ऐसी edges बनाता है जहाँ दोनों endpoints surface के एक ही तरफ़ होते हैं। असली crossing edge पर interpolation parameter

$[0,1]$ में आता है क्योंकि $v_a$ और $v_b$ के signs उल्टे होते हैं। एक fake edge पर उनके signs एक जैसे होते हैं, इसलिए $v_b-v_a$ शून्य के पास होता है या sign पलट देता है और $t$ $[0,1]$ के बाहर निकल जाता है, vertex को volume से काफ़ी दूर रखते हुए। इसे कुछ सौ ग़लत cells से गुणा करो और तुम्हें एक hedgehog मिल जाता है।

fix बेवक़ूफ़ी की हद तक आसान था: Spike 12 से proven table byte-for-byte copy कर लो। सबक़ सीखा। जब एक proven copy मौजूद हो तो lookup table कभी दोबारा generate मत करो।

दूसरा bug ज़्यादा सूक्ष्म था। smooth brush को terrain features को नरम करना था। उसके बजाय उसने तेज़ creases बना दिए। समस्या: मैं हर SDF value को शून्य (isosurface) की तरफ़ खींच रहा था। यह सुनने में लगता है कि इससे चीज़ें smooth होनी चाहिए, पर इससे distance field collapse हो जाता है। surface के ऊपर और नीचे दोनों के voxels शून्य की तरफ़ दौड़ते हैं, brush radius में सब कुछ flatten करते हुए। boundary पर, smoothed voxels एक hard step के साथ unsmoothed voxels से मिलते हैं। "smooth" brush एक crease generator था।

fix था proper Laplacian smoothing. हर value को शून्य की तरफ़ खींचने के बजाय, उसे अपने 6 direct neighbors के average की तरफ़ खींचो:

कोष्ठक में जो term है वह एक discrete Laplacian है, और $\lambda \in (0,1]$ smoothing strength है। यह पास की geometry का average लेता है, surface shape को नरम करता है जबकि distance field gradient को collapse करने के बजाय बनाए रखता है।

सब कुछ एक साथ

Spike 27 integration gate था। Spike 24 की पूरी pipeline (heightmap patches, MC chunks, Transvoxel seams, geomorph LOD) लो और उसे Spike 25 के sampled data model और दोनों brush types के साथ मिलाओ।

Spike 27 को नए tab में खोलें ↗ · सोर्स देखें

सबसे पहले मैंने हर shader से height_at() को निकाल फेंका। तीनों compute shaders (SDF fill, heightmap patch, Transvoxel seam) अब एक ही 129x129 heightmap GPU buffer से bind होते हैं और एक shared WGSL preamble के ज़रिए एक ही hm_sample() bilinear interpolation function इस्तेमाल करते हैं। एक data source, कई consumers. वो procedural noise functions जो Spike 1 से हर shader में रहे थे, ख़त्म हो गए।

फिर दिलचस्प समस्याएँ शुरू हुईं।

जब एक SDF brush किसी chunk को MC mode में lock करता है, तो उस chunk और उसके heightmap neighbor के बीच के Transvoxel seam को heightmap नहीं, बल्कि SDF volume से sample करना होता है। मैंने seam shader को अतिरिक्त storage buffer bindings और per-chunk MC flags के साथ बढ़ाया। संभालने के लिए चार boundary combinations: HM-HM, HM-MC, MC-HM, MC-MC.

LOD एक और पहेली थी। पहले के spikes में, किसी MC chunk को lower LOD पर switch करने का मतलब था SDF को एक coarser resolution पर फिर से भरना। मैंने उसे stride-based sampling से बदल दिया: SDF data full resolution (65 grid points) पर रहता है। MC shader grid size और cell count के ratio से एक stride compute करता है। LOD0 पर stride 1 है। LOD1 पर stride 2 है, हर दूसरे voxel को sample करते हुए। chunks अपने SDF data को छुए बिना आज़ादी से LOD बदल सकते हैं।

सबसे संतोषजनक fix था dynamic vertical chunk spawning. किसी chunk के top से ऊपर तक sculpt करो, और उसके ऊपर एक नया MC-only chunk दिखाई देता है जिसका SDF नीचे के chunk के boundary face से initialize होता है। नीचे की तरफ़ sculpt करो, वही बात। world edits के हिसाब से बढ़ता है।

आख़िरी गोचा यह था कि heightmap brush MC-locked chunks के साथ चुपचाप कुछ नहीं करता था। HM brush heightmapCPU को बदलता है और उसे फिर से upload करता है। MC chunks अब heightmap से नहीं पढ़ते क्योंकि उनका SDF उससे भरा गया था और फिर अलग हो गया था। मैंने syncHeightmapToSdf() जोड़ा: heightmap बदलने के बाद, brush radius में किसी भी MC chunk के लिए SDF columns फिर से derive करो और नई values upload करो। दोनों brush types अब दोनों chunk types पर काम करते हैं।

हमने असल में क्या सीखा

brush spikes को एक performance सवाल का जवाब देना था: क्या sculpting frame budget के भीतर चल सकती है? चल सकती है। वह आसान हिस्सा था।

मुश्किल हिस्सा यह पता लगाना था कि 24 spikes तक height_at() को terrain की सच्चाई के रूप में इस्तेमाल करने से एक अदृश्य dependency बन गई थी जो उसी पल टूट गई जब हमने कुछ भी edit करने की कोशिश की। procedural function साफ़, global और stateless थी, ठीक उस पल तक जब तक वह terrain नहीं रही।

जो नियम हमने लिख लिए और भूलेंगे नहीं:

1. Terrain height sampled data से आती है। chunks अपने buffers के मालिक होते हैं।
2. Procedural generation initial data भरता है। यह runtime की सच्चाई नहीं है।
3. brush chunk data को सीधे बदलता है। कोई displacement overlays नहीं।
4. Normals उसी data से grid-aligned central differences के ज़रिए आती हैं।
5. Border overlap (neighbor interior से 1 cell) cross-chunk normals संभालता है।
6. जब एक proven copy मौजूद हो तो lookup table कभी दोबारा generate मत करो।

भाग 14 में हम debug geometry sculpt करना बंद करते हैं और उसे एक असली जगह जैसा दिखाने और महसूस कराने लगते हैं।

इस chapter में संदर्भित technology

Sampled heightmap architecture. Terrain को runtime पर किसी procedural function से evaluate करने के बजाय per chunk owned data के रूप में स्टोर किया जाता है। हर chunk के पास असली height values का एक Float32Array होता है। creation time पर procedural noise initial data भरता है, फिर function कभी call नहीं होता। इससे math-based terrain और edit overlays के बीच का dual-system mismatch ख़त्म होता है, brush operations सरल होते हैं (stored values को सीधे edit करो), और GPU shader बेहद सरल हो जाता है (buffer से पढ़ो, grid-aligned central differences के ज़रिए normals compute करो)। streaming वाले open world के लिए, neighbors से 1-cell border overlap के साथ per-chunk ownership standard तरीक़ा है। हमारी landscape generation guide देखें।

SDF brush operations. Terrain sculpt करने के लिए एक signed distance field को बदलना। Add (inflate) एक sphere के चारों ओर smooth-step falloff इस्तेमाल करता है। Subtract (carve) उसी shape को negated इस्तेमाल करता है। Smooth, Laplacian averaging इस्तेमाल करता है: 6 direct neighbors पढ़ो, उनका mean compute करो, mean की तरफ़ खींचो। शून्य की तरफ़ खींचने का naive तरीक़ा distance field को collapse करता है और तेज़ edges बनाता है। Laplacian smoothing field gradient को बनाए रखता है जबकि features को नरम करता है। SDF terrain representation देखें।

Transvoxel with mixed data sources. एक MC chunk और एक heightmap chunk के बीच की boundary पर transition cells को हर तरफ़ अलग data sample करना होता है। seam shader per-chunk flags और buffer bindings रखता है ताकि चारों combinations (HM-HM, HM-MC, MC-HM, MC-MC) संभाले जा सकें। जब एक तरफ़ MC-locked होती है, तो shader heightmap sample करने के बजाय SDF buffer को trilinearly interpolate करता है।

Stride-based LOD for marching cubes. SDF data chunk के मौजूदा LOD level की परवाह किए बिना full resolution पर स्टोर किया जाता है। MC shader SDF grid points और MC cells के ratio से एक sampling stride compute करता है। full resolution पर stride 1 है, half resolution पर stride 2 है। इससे SDF data, LOD changes से decouple हो जाता है, तो chunks SDF को rebuild किए बिना आज़ादी से LOD transition कर सकते हैं।

14 में से भाग 13. पिछला: भाग 12 - Rings, sky fog, और जो हम दोबारा करेंगे अगला: भाग 14 - The world comes alive सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? series guide का इस्तेमाल करें। यह बताती है कि spike क्या होता है और सभी भागों को जोड़ती है।

भाग 13 के बाद हमारे पास sculpting थी। terrain उठाओ, caves काटो, cliffs को smooth करो, सब कुछ real time में, seams सलामत। लेकिन दुनिया एक tech demo जैसी दिखती थी। debug रंगों वाली flat shading, wireframe overlays, चंक्स को अलग बताने के लिए LOD रंगों वाली grey geometry। आप इसे edit कर सकते थे। आप इसे महसूस नहीं कर सकते थे।

तीन spikes ने यह बदल दिया। architecture नहीं। बिल्कुल वही pipeline, buffers, और seam stitching जो भाग 13 से थी। हमने बस वे layers जोड़ीं जो terrain को एक जगह जैसा महसूस कराती हैं: ऐसी surfaces जो आकार पर react करती हैं, उन surfaces पर उगता जीवन, और एक शरीर जो उन पर चलता है।

"तकनीकी रूप से काम कर रहा है" और "मैं यहां रहना चाहता हूं" के बीच का फर्क हैरानी की हद तक छोटा निकला।

एक cliff sculpt करो और उसे चट्टान में बदलते देखो

Spike 28 ने एक सीमित सवाल पूछा: क्या triplanar mapping वाला 4-layer material, compute से बने terrain पर frame budget को मारे बिना चल सकता है? जवाब हां था, पर दिलचस्प हिस्सा यह था कि उसके बाद क्या हुआ।

Spike 28 को नए tab में खोलें ↗ · source देखें

startup पर FBM noise से बनी चार procedural textures (grass, rock, sand, snow)। कोई बाहरी files नहीं, कोई asset pipeline नहीं, बस math और एक DataTexture। material के weights surface से ही आते हैं: slope और altitude। treeline के नीचे की flat जगहों को grass मिलती है। तीखी faces को rock मिलती है। नीची ज़मीन को sand मिलती है। ऊंची चोटियों को snow मिलती है। हर raw weight slope और altitude पर एक smoothstep से आता है, फिर उन्हें per-fragment normalize किया जाता है ताकि $\sum _i{w}_i=1$ हो और अंतिम रंग बस weighted blend $\sum _i{w}_i{c}_i$ हो। normalizing ही वह चीज़ है जो surface को वहां dark या blown-out होने से रोकती है जहां biomes आपस में overlap करती हैं। triplanar mapping उन MC chunks के लिए UV projection संभालती है जहां triangles के पास कोई सार्थक UV coordinates नहीं होतीं।

वह पल जिसने इसे बेच दिया: एक तीखी cliff बनाने के लिए brush से terrain उठाओ, और rock texture उसी frame में नई face पर आ जाती है। उसे वापस flat करो, और grass surface पर फिर से कब्जा कर लेती है। material को brush के बारे में पता नहीं होता। वह बस world position और surface normal पढ़ता है, वही data जिससे geometry बनी थी। sculpting-से-visual feedback loop तुरंत और unscripted है।

Spike 8 ने डेढ़ महीने पहले WebGL पर एक static mesh के साथ terrain material की लागत का test किया था। Spike 28 साबित करता है कि यह नीचे चलते पूरे sculpting pipeline के साथ dynamic compute से बने terrain पर काम करता है। हमने इसके लिए budget रखा था, पर सब कुछ चलते हुए इसे 60fps पर टिकते देखना फिर भी राहत की बात थी।

80,000 grass clumps और एक cave की छत

Spike 29 वही जगह है जहां gamedev instincts ने कमान संभाल ली।

Spike 29 को नए tab में खोलें ↗ · source देखें

हम Breath of the Wild वाली grass चाहते थे। poly count नहीं, वह feel। ऐसी grass जो सही जगहों को ढके, हवा के साथ हिले, और आपका उसमें से दौड़ने का मन कर दे।

हर grass clump 60-degree के कोणों पर तीन एक-दूसरे को काटते quads होते हैं, झुकने के लिए चार vertical segments के साथ। यह एक cross आकार है जो हर angle से billboard tricks के बिना volumetric दिखता है। हर chunk पर एक InstancedMesh, पूरी दुनिया में 80,000 clumps, कुल मिलाकर लगभग 2.4 million grass vertices।

जो हिस्सा मायने रखता है वह placement है। CPU हर chunk पर एक jittered grid पर चलता है और वही slope/altitude logic evaluate करता है जो GPU material shader इस्तेमाल करता है। जहां material system कहता है "grass," वहां grass उगती है। जहां rock या sand हावी होती है, density शून्य पर गिर जाती है। falloff smooth होती है क्योंकि नीचे के smoothstep weights biome किनारों पर continuous gradients पैदा करते हैं। आपको कोई सीमा नज़र नहीं आती क्योंकि कोई है ही नहीं।

फिर हमने कुछ ऐसा किया जिसके काम करने पर मुझे यकीन नहीं था। SDF surfaces पर grass। scatter function SDF volume के हर column पर चलता है और साथ वाले voxels के बीच zero-crossings ढूंढता है। जहां SDF negative से positive में crossover करता है, वहां एक surface है। surface normal बस field का normalized gradient है, $\hat{n}=\frac{\mathrm{\nabla }\varphi }{\Vert \mathrm{\nabla }\varphi \Vert }$, जो voxel differences से निकाला जाता है, और slope $\arccos (\hat{n}\cdot \hat{y})$ है, vertical से कोण। अगर वह काफी कोमल है, तो grass रखो।

Spike 27 में SDF brush से एक cave काटो। Spike 29 में वापस आओ और cave की छत के ऊपर grass उग रही होती है। scatter code को पता नहीं होता कि cave क्या होती है। वह बस सही altitude पर सही slope वाली एक surface देखता है। यही वह तरह का emergent behavior है जो open-world systems को बनाने में संतोषजनक बनाता है।

हवा TSL vertex shader में एक sine wave है, जो blade के V coordinate से modulate होती है ताकि tips झूलें और जड़ें टिकी रहें। gentle, strong, और off के बीच घूमने के लिए V toggle करें। हवा सभी 80K clumps पर एक साथ शून्य CPU लागत के साथ चलती है क्योंकि यह पूरी तरह vertex shader में है।

Spike 7 ने 50K grass instances का test किया था और हम limit छूने को लेकर घबराए हुए थे। Spike 29 compute terrain, seam stitching, multi-material texturing, और brushes के ऊपर 80K चलाता है। कम InstancedMesh draws में batch करना अब भी per-blade vertex count घटाने से ज़्यादा मायने रखता है। Spike 7 का सबक टिका रहा।

एक चीज़ हमने टाल दी: जब आप grass के नीचे sculpt करते हैं तो वह update नहीं होती। instance matrices scatter के समय set होती हैं। एक पहाड़ी को घाटी में sculpt करो और grass हवा में लटकती रहती है जब तक आप दोबारा scatter करने के लिए G toggle न करें। एक spike के लिए काफी अच्छा। production को dirty-chunk re-scatter चाहिए होगा।

पहला कदम

Spike 30 वही है जिस पर मैं बार-बार लौटता रहता हूं।

Spike 30 को नए tab में खोलें ↗ · source देखें

कोई physics library नहीं। 120Hz fixed timestep पर custom capsule। production codebase एक web worker में Rapier इस्तेमाल करता है (Spike 2 ने साबित किया कि latency ठीक है), पर इस spike को collision queries को ही साबित करना था। क्या एक character heightmap terrain पर चल सकता है, sculpt किए SDF terrain पर कदम रख सकता है, और नीचे से न गिरे?

मूल हिस्सा terrainQuery(x, y, z) नाम का एक function है। यह जांचता है कि position किसी MC-locked chunk के अंदर पड़ती है या नहीं। अगर हां, तो यह CPU SDF mirror को trilinearly interpolate करता है और gradient को surface normal के रूप में लौटाता है। वरना, central-difference normal के साथ heightmap lookup। character को पता नहीं होता कि वह किस terrain system पर खड़ा है। वह बस ज़मीन मांगता है और एक जवाब पा जाता है।

SDF collision वह हिस्सा था जिसके मुश्किल होने की मुझे उम्मीद थी। capsule के चारों ओर सात probe points (नीचे, बीच, ऊपर, चार cardinal offsets)। position $\mathbf{x}$ पर एक probe तब penetrate कर रहा होता है जब $\varphi (\mathbf{x})<r$, penetration depth $p=r-\varphi (\mathbf{x})$ के साथ, और push-out दिशा field gradient $\hat{n}=\frac{\mathrm{\nabla }\varphi }{\Vert \mathrm{\nabla }\varphi \Vert }$ होती है। capsule को surface में दोबारा घुसने से रोकने के लिए, velocity को उसके inward component को रद्द करने के लिए project किया जाता है:

जो केवल surface के साथ slide करने वाला component छोड़ देता है। यह कोई physics engine नहीं है। यह geometry queries और साधारण response है। पर यह caves, overhangs, और sculpt किए tunnels को प्रति आकार शून्य special-case code के साथ संभालता है। आप एक ऐसी cave में चलते हैं जो आपने दस सेकंड पहले काटी थी और capsule छत के contour का बिल्कुल पीछा करता है।

movement model practical शुरू हुआ और मज़ेदार बन गया। walk, run, sprint, jump, 45 degrees से ऊपर slope sliding। फिर मैंने एक BotW paraglider जोड़ा और spike कुछ ऐसा बन गया जिसे मैं बंद नहीं करना चाहता था।

हवा में रहते हुए Space दबाएं। gravity -30 से -4 पर गिर जाती है। गिरने की रफ्तार -3 पर थम जाती है। scale interpolation के साथ capsule से एक delta-wing mesh खुलता है। बाएं bank करें और wing झुक जाता है। capsule का facing velocity vector की ओर अपने आप align हो जाता है ताकि आप हमेशा वहीं देख रहे हों जहां आप जा रहे हैं। गिरने के लिए Space छोड़ दें। ज़मीन पर पहुंचो और आप फिर से दौड़ रहे होते हैं।

camera पीछे हटकर third-person में चली जाती है (P toggle)। यह yaw smoothing के साथ player के पीछे चलती है। player से camera तक एक ray-march 20 steps पर terrain test करता है। एक cave में उड़ो और camera arm rock में से गुज़रने के बजाय smoothly छोटी हो जाती है। दूसरी तरफ निकलो और यह वापस बाहर फैल जाती है।

यह रहा वह पल जिसने spike को सार्थक बनाया: heightmap brush से एक ऊंची cliff sculpt करो। third-person camera पर switch करो। किनारे तक दौड़ो। कूदो। glider deploy करो। उसी terrain के ऊपर बाएं bank करो जो आपने अभी sculpt किया, Spike 29 में आपकी उगाई grass नीचे लहराते हुए, cliff face पर Spike 28 की rock texture, हर chunk सीमा पर टिके Transvoxel seams। दूसरी तरफ land करो। सब कुछ एक browser tab में एक साथ काम कर रहा।

अपने ही पैरों के नीचे sculpting

एक चीज़ को लेकर मुझे यकीन नहीं था: क्या होता है जब आप उस terrain को sculpt करते हैं जिस पर character खड़ा है? heightmap के बदलाव terrainQuery() के ज़रिए तुरंत propagate होते हैं क्योंकि यह सीधे CPU buffer पढ़ता है। SDF बदलाव CPU SDF mirror के ज़रिए propagate होते हैं। capsule अगले physics tick पर penetration हल कर लेता है, जो 120Hz पर $\frac{1}{120}\approx 8.3$ ms के भीतर होता है।

यह बस काम करता है। player के नीचे ज़मीन उठाओ और वे उसके साथ उठते हैं। ज़मीन काट दो और वे गिरते हैं। कोई special handling नहीं। physics इतनी तेज़ चलती है कि single-frame terrain बदलाव कभी बड़ी penetrations नहीं पैदा करते। यह timestep के लिए 120Hz चुनने का एक सुखद इत्तेफाक था। हमने इसे smooth movement के लिए चुना था, और इसने terrain editing को मुफ्त में सुरक्षित बना दिया।

30 spikes बाद

हमने इस series की शुरुआत एक flat heightmap और 500 cubes से की थी। अब हमारे पास volumetric caves के साथ sculpt किया terrain है, Transvoxel seam stitching, surface के आकार पर react करती multi-material texturing, हवा में झूलते 80,000 grass clumps, और एक character जो इन सब पर चलता, sprint करता, कूदता, और glide करता है।

इसमें से कुछ भी अभी production में नहीं है। world/client/ codebase अब भी साधारण heightmap chunks के साथ WebGL चलाता है। इन 30 spikes का सब कुछ standalone HTML pages में रहता है। integration का काम अगला है: WebGPURenderer पर migrate करना, hybrid HM/MC policy को chunk manager में wire करना, brush और material systems को multiplayer से जोड़ना।

पर rendering system अब जोखिम नहीं है। खुले सवाल data flow के बारे में हैं: edit persistence, brush strokes का network sync, collaborative sculpting। वह चीज़ें जो players के बीच होती हैं, triangles के बीच नहीं।

अगर आपने इस series को भाग 1 से follow किया है, बिखरे हुए हिस्सों के साथ टिके रहने के लिए शुक्रिया। अगर आपने इसे अभी पाया है, भाग 1 पर वापस जाएं। गलत मोड़ ही वह जगह हैं जहां सबक रहते हैं।

इस अध्याय में जिन तकनीकों का ज़िक्र हुआ

TSL (Three Shading Language). WebGPU renderer के लिए Three.js का node-आधारित shader system। Materials, JavaScript में function composition का इस्तेमाल करते हुए nodes (positionWorld, normalWorld, smoothstep, triplanarTexture) से बनती हैं। shader graph runtime पर WGSL में compile होती है। TSL, WebGPU targets के लिए raw GLSL ShaderMaterial की जगह लेता है और standard Three.js material features (lights, shadows, fog) और custom per-fragment logic के बीच interop देता है।

Triplanar mapping. एक texture projection तकनीक जो एक texture को तीन बार (XY, XZ, YZ planes) sample करती है और surface normal दिशा के आधार पर blend करती है। यह मनमानी mesh geometry पर UV stretching खत्म कर देती है, जो marching cubes output के लिए ज़रूरी है जहां triangles के पास कोई सार्थक UV coordinates नहीं होतीं। TSL एक built-in node के रूप में triplanarTexture() देता है।

Cross-quad blades के साथ instanced vegetation. हर grass clump 60-degree कोणों पर 3 एक-दूसरे को काटते quads होते हैं, जो हर view दिशा से एक volumetric दिखावट बनाते हैं। प्रति quad 4 vertical segments wind animation के लिए smooth bending की अनुमति देते हैं। पूरा field हर chunk पर एक अकेले InstancedMesh के रूप में render होता है। capacity को 25% ज़्यादा allocate किया जाता है ताकि जब terrain edit हो तो नई instances GPU buffer को दोबारा allocate किए बिना reserved slots भर सकें। vegetation पर हमारी landscape generation guide देखें।

Capsule बनाम SDF collision. physics engine के बिना volumetric terrain के खिलाफ character collision। capsule को SDF के खिलाफ कई points पर probe किया जाता है। जहां field value capsule radius से कम होती है, gradient बाहरी normal देता है और अंतर penetration depth देता है। यह caves, overhangs, और tunnels को बिना किसी shape-specific code के संभालता है। SDF terrain collisions देखें।

Fixed-timestep character controller. Physics, frame rate की परवाह किए बिना 120Hz पर step करती है, real time जमा करते हुए और उसे fixed-size steps में खपाते हुए। एक max substep count धीमी frames पर spiral-of-death रोकता है। Ground snapping slope traversal के दौरान capsule को जुड़ा रखता है। fixed timestep भविष्य के multiplayer replay के लिए deterministic behavior सुनिश्चित करता है।

29 में से भाग 14। पिछला: भाग 13 - Terrain sculpting और math function की मौत अगला: भाग 15 - baseline को बदलो, फिर उसे sync करो Series guide: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? series guide का इस्तेमाल करें। यह बताती है कि spike क्या होता है और सभी भागों को जोड़ती है।

पहले चौदह भागों ने spikes 1 से 30 तक को कवर किया। वह सिलसिला एक ऐसे terrain system के साथ खत्म हुआ जिसे real time में sculpt किया जा सकता था, साथ ही एक character जो उस पर चल सकता था, glide कर सकता था, और गिर सकता था। यह भाग series को spike 31 से फिर शुरू करता है, और सबसे पहली चीज जो हमें तय करनी थी वह तकनीकी नहीं थी। वह यह थी कि उस सारे spike code का क्या किया जाए।

"replace करो, backport नहीं" वाला फैसला

हमारे पास 30 standalone HTML files थीं, हर एक एक अलग-थलग concept साबित करती हुई, और शून्य integration। production वाला world/client/ अभी भी पुराना stack था: WebGL, एक सरल heightmap, एक 75-line का character controller, नौ message types वाला एक MessagePack protocol। कोई editing नहीं, कोई WebGPU नहीं, कोई materials नहीं, कोई vegetation नहीं।

साफ-सीधा plan यह था कि spike के नतीजों को एक-एक करके उस production codebase में backport किया जाए। हमने उसे फेंक दिया। spike 30 के पास पहले से ही world/client/ से कहीं बेहतर terrain, physics, materials, vegetation, और camera था। पुराने WebGL code में backport करने का मतलब था पूरे रास्ते उससे लड़ना। तो हमने यह फैसला लिया कि world implementation को सबसे सफल spike से बदल दें और आगे बनाएं। spike 30 नया baseline बन गया, और world/client/ dead code बन गया।

इसने बाकी काम को नए सिरे से परिभाषित किया। "शानदार single-player tech demo" से "product" तक पहुंचने के लिए हमें multiplayer, persistence, infinite-world streaming, और object placement चाहिए था। multiplayer terrain sync पहले आया, क्योंकि यही वह है जो architecture को मजबूर करता है। यह जिस सवाल का जवाब देता है वह पूछना आसान है और गलत होने पर महंगा पड़ता है: जब Player A sculpt करता है, तो असल में wire पर क्या जाता है?

brush-param replay, pixel sync नहीं

Spike 31 को नए tab में खोलें ↗ · source देखें

network code की एक line लिखने से पहले, हमने ठीक-ठीक यह पता लगाया कि एक brush stroke क्या करता है। heightmap brush cursor के चारों ओर एक radius में एक CPU Float32Array में घूमता है, एक smoothstep falloff लगाता है, और या तो add, subtract, smooth, या flatten करता है। SDF brush वही चीज voxels के एक sphere पर 3D में करता है। दोनों paths शुद्ध CPU array math हैं। loop में कोई GPU compute नहीं, कोई randomness नहीं, कोई nondeterministic floating point नहीं। वही input array और वही params हर machine पर वही output देते हैं।

बस यही पूरी तरकीब है। हम edit किया गया terrain नहीं भेजते। हम brush parameters भेजते हैं, प्रति stroke tick 56 bytes, और हर client वही deterministic function फिर से चलाता है। sync protocol में चार message types हैं: peer discovery, brush message {op, wx, wy, wz, radius, strength, flattenTarget}, और 20Hz पर एक player-position message।

spike के लिए हमने server को पूरी तरह छोड़ दिया और BroadcastChannel इस्तेमाल किया, जो same-origin cross-tab messaging के लिए browser API है। दो tabs खोलें, वे बात करते हैं, शून्य infrastructure। यह sync वाले सवाल को latency, auth, और Durable Object wiring से अलग कर देता है। अगर param replay tabs के बीच converge करता है, तो यह WebSocket के पार भी converge करेगा।

एक ही जगह है जहां replay diverge हो सकता है, वह है order-dependent operations। Raise और lower commutative हैं, तो val + strength * falloff एक जैसा ही उतरता है चाहे किसने पहले लगाया हो। Smooth और flatten neighbor values पढ़ते हैं, तो ठीक उसी spot को ठीक उसी पल में smooth करते दो clients प्रति tick एक millimeter के अंशों जितना drift कर सकते हैं। व्यवहार में यह कभी नहीं होता, और production fix पहले से ही साफ है: edits को DO के जरिए route करें, उसे एक monotonic sequence number assign करने दें, client पर optimistically apply करें, और अगर authoritative sequence असहमत हो तो order ठीक कर दें। classic optimistic concurrency, और DO वैसे भी एक स्वाभाविक serialization point है।

वह peer capsule जो बार-बार गायब होती रही

Edits पहली ही कोशिश में sync हो गए। remote player का capsule नहीं हुआ। यह दूसरे tab पर अस्तित्व में आता-जाता टिमटिमाता रहा, और इसे ठोस बनाए रखने में तीन अलग bugs लगे।

capsule world origin पर spawn हुआ, जो terrain के नीचे दबा है, क्योंकि join message किसी भी position data से पहले आता है। Fix: इसे hidden शुरू करें और पहले position update पर इसे दिखाएं। position broadcast render loop के भीतर रहता था, और Chrome unfocused tabs पर requestAnimationFrame को throttle करता है, तो दूसरे tab का staleness check peer को हटा देता और अगला message उसे फिर बना देता। Fix: broadcast को setInterval पर ले जाएं, जो visible tabs के लिए throttle नहीं होता। और staleness timeout बहुत ज्यादा aggressive 5 seconds था, किसी भी GC pause से trip हो जाता था। Fix: इसे 30 seconds तक बढ़ाएं और normal closes के लिए साफ leave message पर भरोसा करें।

persistence और late-join, एक ही format

हमने persistence को एक नया spike शुरू करने के बजाय उसी spike में मोड़ दिया, क्योंकि serialization format एक जैसा है चाहे destination IndexedDB हो या कोई दूसरा tab। एक snapshot में पूरा heightmap (एक 129×129 Float32Array, करीब 66 KB) होता है, साथ केवल edit किए गए SDF chunks (हर एक ${65}^3$, करीब 1.1 MB) और marching-cubes mode में locked chunk IDs की list। एक debounced save आखिरी edit के दो seconds बाद IndexedDB में लिखता है। load पर, procedural terrain synchronously generate होता है और फिर saved state पहले meaningful frame से पहले उसे overwrite कर देता है। late-join बिल्कुल वही bytes दोबारा इस्तेमाल करता है: जब कोई नया tab join करता है, तो edits वाला एक मौजूदा tab अपनी state serialize करके नए आने वाले को targeted भेजता है, और जो पहाड़ आपने पांच मिनट पहले sculpt किया था वह उनकी screen पर दिखता है।

पहले persistence test ने एक बढ़िया ordering bug सामने ला दिया। घास init पर procedural heights का इस्तेमाल करके synchronously बिखेरी जाती है, लेकिन IndexedDB restore async है और बाद में heightmap को overwrite कर देता है, जिससे हर blade floating या धंसी रह जाती है। fix एक refreshAllGrass() pass है जो हर instance के नीचे की height को फिर से sample करता है और किसी भी ऐसी blade को छिपा देता है जो अब किसी खराब slope या altitude पर है। यही function load और late-join दोनों के लिए काम आता है।

slope की दास्तान

Sculpt किया गया terrain smooth procedural baseline से ज्यादा rough होता है, और इसने तीन physics bugs उजागर कर दिए जो पुराना terrain कभी नहीं कर पाता था। सीधे ऊपर की ओर चढ़ते हुए capsule बगल में slide करने लगता था। वजह एक velocity projection थी जो movement को ground के tangent बनाए रखने के लिए थी, लेकिन normal के केवल horizontal components के साथ लिखी गई थी। normal $(-0.3,0.9,-0.3)$ वाली एक diagonal slope पर, उत्तर की ओर चलने से कहीं से sideways velocity inject हो जाती थी। ground snap पहले से ही player को surface पर रखता है, तो हमने बस projection को delete कर दिया।

drift एक दूसरे स्रोत से बना रहा। SDF collision probes body को gradient के साथ penetration depth जितना बाहर धकेलते हैं। किसी भी slope पर gradient के horizontal components होते हैं, तो 15° slope पर 0.1 m penetration प्रति step करीब 0.026 m बगल में धकेलता है, और 120Hz पर यह करीब 3 m/s का अदृश्य drift है। Fix: response को slope के हिसाब से बांटें। walkable ground पर (${\text{grad}}_y$ walk threshold से ऊपर) push केवल vertical होता है। walls और cliffs पर पूरा 3D push रहता है, क्योंकि ठीक वहीं आप deflect होना चाहते हैं। हमने walkable limit को भी $\cos 45°$ से बढ़ाकर $\cos 60°$ कर दिया ताकि brush से बनी पहाड़ियां वैसी climbable महसूस हों जैसी Breath of the Wild में होती हैं।

तीसरे bug ने chunk boundaries पर capsule को freeze कर दिया, क्योंकि collision probes एक ही chunk के SDF को sample करते थे और जब कोई probe neighbor में पार जाता तो "deep in air" sentinel मिलता था। fix था sdfSampleWorld(wx, wy, wz) और sdfGradientWorld(...), जो किसी भी world position के लिए सही chunk ढूंढते हैं और जहां कोई SDF मौजूद नहीं वहां एक heightmap distance estimate पर fall back करते हैं। SDF-से-heightmap collision transition अब continuous है।

पानी दुनिया को पूरा करता है

Spike 32 को नए tab में खोलें ↗ · source देखें

यहां तक हर spike "पानी के ऊपर जमीन" था। Spike 32 ने एक ocean जोड़ा, और उसके साथ एक नया movement verb। हमने एक ऐसे terrain में water level 22 पर सेट किया जो करीब 8 से 58 तक फैला है, जो निचली घाटियों को भर देता है, shoreline पर beaches छोड़ देता है, और खेलने के लिए काफी सूखी जमीन रखता है।

surface एक MeshStandardNodeMaterial है जो TSL में बना है, terrain जैसा ही node approach। अलग-अलग frequencies पर तीन overlapping sine waves vertices को displace करती हैं, और surface normal mesh normals के बजाय उन waves के analytic cosine derivatives से आता है। Color एक depth estimate $(\text{level}-y+\text{wave})\times 0.12$ का इस्तेमाल करके turquoise shallows से dark teal depths तक blend होता है, जो $[0,1]$ तक clamp किया गया है, foam वहां उठता है जहां वह estimate shoreline पर शून्य के करीब आता है, और alpha depth का अनुसरण करता है तो shallow water transparent पढ़ता है और deep water लगभग opaque।

Swimming एक buoyancy spring है। player swim mode में आता है जब feet water level से नीचे गिरते हैं और body center surface से एक capsule half-height के भीतर होता है। एक spring body को surface के ठीक नीचे एक target की ओर खींचता है, और 4 की water damping के खिलाफ 12 के buoyancy constant के साथ player अपना सिर बाहर रखकर stably bob करता है, कोई oscillation नहीं। Swim speed floaty acceleration और drag के साथ walking से धीमी है, surface के पास jump करने पर आप normal jump velocity के 60% पर बाहर launch होते हैं, और entry downward velocity को -5 m/s पर cap करता है ताकि आप plunge न करें। Terrain collision अभी भी underwater चलता है, तो आप lake bed पर चल सकते हैं जहां वह swim target से ऊपर उठता है। swimming flag position broadcast के साथ चलता है तो peers आपको swim करते देखते हैं, और एक HTML gradient overlay view को tint करता है जब camera surface से नीचे डुबकी लगाता है।

इस अध्याय में संदर्भित तकनीक

Deterministic brush-param replay. Edit किया गया terrain stream करने के बजाय, हर client केवल brush parameters भेजता है और वही CPU function फिर से चलाता है। यह इसलिए काम करता है क्योंकि heightmap और SDF दोनों brushes बिना किसी randomness या GPU nondeterminism के शुद्ध Float32Array math हैं, तो एक जैसे inputs हर जगह bit-identical outputs पैदा करते हैं। Payload प्रति stroke tick 56 bytes है। Commutative operations (raise, lower) order की परवाह किए बिना converge होते हैं, जबकि neighbor पढ़ने वाले operations (smooth, flatten) को convergence की गारंटी के लिए एक serialization point चाहिए, जो production Durable Object monotonic sequence numbers के जरिए देता है।

WebSocket के विकल्प के रूप में BroadcastChannel. शून्य server के साथ same-origin cross-tab messaging के लिए एक browser API। यहां इसे sync protocol को network latency और authentication से अलग करके test करने के लिए इस्तेमाल किया गया। serialization format (raw Float32Array heightmap साथ edit किए गए SDF chunks साथ MC-locked chunk IDs) वही bytes हैं जो IndexedDB persistence और late-join state transfer के लिए इस्तेमाल होते हैं, तो एक format तीन काम संभालता है।

Slope-split SDF collision response. जब कोई capsule probe volumetric terrain में penetrate करता है, तो भोला-भाला fix body को SDF gradient के साथ penetration depth जितना बाहर धकेलता है। slopes पर उस gradient के horizontal components होते हैं, जो lateral drift inject करते हैं। response को इस तरह बांटना कि walkable surfaces (${\text{grad}}_y$ threshold से ऊपर) को केवल vertical push मिले, जबकि steep surfaces पूरा 3D push साथ velocity projection रखें, wall collision खोए बिना drift हटा देता है। देखें SDF terrain collisions।

Analytic wave normals के साथ TSL water. ocean एक node material है जिसके vertices तीन जोड़ी गई sine waves से displace होते हैं। displacement के बाद mesh normals फिर से compute करने के बजाय, surface normal wave functions के cosine derivatives से analytically निकाला जाता है, जो सस्ता है और एक coarse grid पर finite-difference normals के artifacts से बचता है। Depth-driven color, shoreline foam, और depth-driven transparency सब एक ही depth estimate पर key करते हैं।

Buoyancy-spring swimming. Swim physics body को surface के ठीक नीचे एक target की ओर खींचे गए एक damped spring के रूप में model करता है। buoyancy constant 12 और damping 4 के साथ, player बिना oscillate किए surface पर settle हो जाता है। अलग movement constants (धीमी speed, floaty acceleration, भारी drag) swimming को walking से एक अलग feel देते हैं, और मौजूदा capsule-vs-terrain collision underwater काम करता रहता है।

29 में से भाग 15। पिछला: भाग 14 - दुनिया जीवंत हो उठती है अगला: भाग 16 - एक ऐसी दुनिया के लिए structure जो बढ़ती रहती है Series guide: /hi/blog/2026-02-25-open-world-browser-series-guide

स्केच-से-वीडियो-से-3D pipeline और Kali the Kitty (Cubcoats) पर आधारित। licensing, blog, या partner pitch के लिए।

PDF के रूप में शेयर करने के लिए: यह पेज खोलें, फिर अपने browser के File → Print → Save as PDF का इस्तेमाल करें।

Golden Tree — पूरा वन-पेजर

Tagline: एक दुनिया जो आपके साथ बढ़ती है। आएँ, पानी दें, देखें। कोई levels नहीं। कोई दबाव नहीं।

यह क्या है

एक शांत, इकट्ठा करने लायक दुनिया जो असली दुनिया के समय में आगे बढ़ती है। एक साझा "season" (जैसे Spring Island): एक अकेला 3D द्वीप जिसमें बच्चे घूम-फिर सकते हैं (खेलने लायक Kali demo की तरह)। यहाँ पारंपरिक levels या scores नहीं हैं। Progression यह है कि आपके पेड़ में एक नई शाखा आई, आपने 12 moments देखे, किसी ने आपके बीज को पानी दिया।

हर बार आने पर एक बच्चा यह कर सकता है: एक पौधे को पानी देना, एक wish छोड़ना (text या emoji), एक छिपे हुए Cubcoats किरदार को ढूँढना, या एक 30-सेकंड का "moment" देखना (जैसे सुनहरे पेड़ के नीचे Kali)। नए moments और छोटी कहानी की कड़ियाँ हर हफ्ते आती हैं (एपिसोडिक)। वैकल्पिक रूप में हल्की-फुल्की भाषा: "आज Kali ने कहा: [EN और ZH में एक लाइन]।"

सीखना और बढ़ना अवचेतन रहता है: themes (दयालुता, धैर्य, फिर से कोशिश करना) लेखन और आर्ट में बसते हैं, पाठों में नहीं। यह अनुभव किसी खिलौने या साझा जगह जैसा लगता है, स्कूल जैसा नहीं।

Core loop

1. द्वीप पर आएँ (browser या app)।
2. हर बार आने पर एक कोमल काम करें: पानी दें, wish छोड़ें, किसी किरदार को ढूँढें, या एक moment देखें।
3. दिनों/हफ्तों में दुनिया को बदलते देखें (नए फूल, किरदारों के नए poses, नई छोटी clips)।
4. किसी दोस्त को एक बीज शेयर करें या "किसी दोस्त के द्वीप पर जाएँ" ताकि growth सामाजिक लगे।

यह लेख वाली pipeline और किरदारों का इस्तेमाल कैसे करता है

• 3D खेलने लायक दुनिया: Kali demo वाली ही pipeline: T-pose → 3D Model Generator → rigging → Cinevva Engine। द्वीप और किरदार घूमने लायक हैं, third-person, कम जोखिम वाले।
• सुनहरा पेड़: सीधे लेख से (Kali का "डर से उम्मीद" वाला पल और जादुई सुनहरा पेड़)। पेड़ इस season का भावनात्मक और दृश्य केंद्र है।
• छोटे "moments": लेख वाले वर्टिकल शॉर्ट की तरह बनाए गए: start frame + end frame + motion prompt → Video Generator (Kling 3.0 Pro), 9:16, ~15 s। हर हफ्ते की एक drop एक छोटी कहानी की कड़ी है।
• Cubcoats IP: Kali और बाकी सात किरदार, द्वीप वाली दुनिया, और गर्म, गोलाई लिए हुए आर्ट style। यह एक डिजिटल, एपिसोडिक product के साथ licensing-first relaunch (2026) में बिलकुल फिट बैठता है।

यह viral क्यों हो सकता है

• कम झंझट: एक link, कोई भारी onboarding नहीं। "अपने दोस्त को एक बीज भेजें" एक आसान share है।
• शांत, ख़ूबसूरत clips: छोटे moments अपने आप में शेयर करने लायक हैं (social, "ये 15 सेकंड देखो")। अच्छे तरीके से meme-friendly।
• एपिसोडिक: "इस हफ्ते नया क्या है?" बार-बार आने और बातचीत को बढ़ावा देता है।
• अवचेतन: माता-पिता देखते हैं "शांत, रचनात्मक, कोई ads नहीं, कोई तनाव नहीं"; बच्चों को routine, धैर्य, और कोमल आश्चर्य मिलता है बिना किसी सीधे पाठ के।

Cinevva blog के लिए संभावित angle

"हमने Kali को एक स्केच से वीडियो तक और फिर एक ऐसे किरदार तक पहुँचाया जिसके इर्द-गिर्द आप घूम सकते हैं। Golden Tree अगला कदम है: एक दुनिया जो असली समय में बढ़ती है, जहाँ बच्चे आते हैं, पानी देते हैं, और छोटे moments देखते हैं—कोई levels नहीं, कोई दबाव नहीं। वही pipeline। नया format।"

Kali's Word Island — एक नज़र में

Core idea: Cubcoats द्वीप किरदार-zones में बँटा है (Kali का जंगल, किसी और का समुद्र-तट)। बच्चे छोटे tasks करके किरदारों की मदद करते हैं जिनमें EN/ZH समझना और बोलना पड़ता है। Progression = "Seeds → Saplings → Trees → Golden Tree" (जब zone का पेड़ भर जाए तो अगला zone unlock हो)। रोज़ की "lantern" run, इकट्ठा करने लायक phrase cards, किरदारों के "mood" bars, वैकल्पिक parent dashboard। कोई zone पूरा होने पर छोटे कहानी moments (start/end frame style) खुलते हैं। Pipeline: किरदारों और भावनात्मक कड़ियों के लिए वही 3D + video pipeline।

Cubcoats: Island Stories — एक नज़र में

Core idea: एपिसोडिक कहानियाँ जहाँ बच्चे branches चुनते हैं (Kali क्या कहती है? वह कहाँ जाती है?)। मुख्य गतिविधि है remixing: किरदार, जगह, 2–3 beats चुनें → एक छोटा "episode" तैयार करें (script + सरल visuals, या बाद में AI-जनरेटेड शॉर्ट)। सीखना अवचेतन रहता है (संवाद और चुनावों में शब्दावली और patterns)। Social: अपना episode शेयर करें, किसी और का version खेलें, "kind / funny / surprising" rate करें। Pipeline: user-जनरेटेड "moments" के लिए वही किरदार look + two-frame video pipeline; किरदार/दुनिया की एकरूपता के लिए 3D।

संदर्भित Cinevva tools: Image Generator, Video Generator (Kling 3.0 Pro), 3D Model Generator, auto-rigging, Cinevva Engine। "From sketch to video and playable 3D" (2026-03-04) में बताई गई pipeline को दर्शाता है।

लेखक Mariana Muntean, Cinevva की CEO

Cinevva की टीम ने हाल के game-dev इतिहास की सबसे पारदर्शी engineering डायरियों में से एक प्रकाशित की है: एक 12-भाग वाली सीरीज़ जो एक ऐसा multiplayer open world बनाने की हमारी कोशिश को दर्ज करती है जो पूरी तरह ब्राउज़र में चलता है। कोई download नहीं। कोई app store नहीं। बस एक URL।

यह प्रोजेक्ट 24 तकनीकी प्रयोगों तक फैला था जिन्हें हम "spikes" कहते हैं, यानी छोटे और केंद्रित prototypes जो हर एक किसी एक जोखिम भरे सवाल का जवाब देने के लिए बनाए गए। हर spike के साथ live सोर्स कोड आता है जिसे आप अभी अपने ब्राउज़र में खोलकर चला सकते हैं। सीरीज़ को Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक, ने लिखा है, और यह marketing से कम और 2026 में ब्राउज़र असल में क्या कर सकते हैं इसके मोर्चे से लिखी एक फील्ड डायरी जैसी ज़्यादा पढ़ने में आती है।

सीरीज़ को पढ़ने लायक बनाने वाली बात, चाहे आप कभी terrain systems बनाने की योजना न भी रखते हों, इसके नीचे छिपा तरीका है। यह इस बात का केस स्टडी है कि किसी महत्वाकांक्षी प्रोजेक्ट को महंगी किसी चीज़ पर प्रतिबद्ध होने से पहले कैसे de-risk किया जाए।

सबसे मुश्किल सवाल से शुरुआत

ज़्यादातर open-world प्रोजेक्ट एक तय क्रम में नाकाम होते हैं। पहले आपको एक खूबसूरत concept मिलता है। फिर एक सुंदर scene। फिर आपको पता चलता है कि gameplay के अस्तित्व में आने से पहले ही आपका frame budget खर्च हो चुका था।

हमारी टीम ने क्रम को उलट दिया। पहला spike जानबूझकर भद्दा था: एक 512 मीटर का terrain mesh, 500 instanced objects, procedural height noise, एक water plane और fog। न shadows, न beauty pass। इकलौता सवाल यह था कि क्या ब्राउज़र camera के उसमें घूमते वक्त एक स्थिर frame rate बनाए रख सकता है।

रख सकता था। और उस "हां" ने एक ऐसी चीज़ स्थापित की जिसे Oleg "baseline contract" कहते हैं, यानी एक न्यूनतम scene के लिए एक मापा गया reference cost जिसके सामने हर अगले feature को खुद को सही ठहराना होता था। अगर कोई नया effect शानदार दिखता था पर frame budget को उड़ा देता था, तो वह ship नहीं होता था। कम से कम अभी नहीं।

इस तरह का अनुशासन साफ नज़र आने वाली बात लगती है। हकीकत में, तेज़ी से बदलते prototype माहौल में यह दुर्लभ है, जहां हर कोई अगली visual जीत को लेकर उत्साहित रहता है।

physics वाला दांव

दूसरे प्रयोग ने एक architectural बहस को सुलझाया जो ब्राउज़र game developers को बांटती है: क्या physics को main thread पर चलना चाहिए, जहां यह आसान है, या एक Web Worker में, जहां यह rendering को block नहीं कर सकती?

Worker-आधारित physics कागज़ पर ज़्यादा साफ-सुथरी है। हकीकत में, डर latency का है। हर input event को एक message boundary दो बार पार करनी पड़ती है: एक बार worker तक पहुंचने के लिए, एक बार result वापस लाने के लिए। अगर यह आना-जाना बहुत धीमा हो, तो कोई key दबाने और अपने character को हिलते देखने के बीच चीज़ें सुस्त महसूस होंगी।

टीम ने Rapier physics engine (Rust से WebAssembly में compile किया गया) को एक dedicated worker में जोड़ा, message pipeline तैयार किया, और मापा। overhead नगण्य था। controls अब भी तुरंत महसूस होते थे। लेकिन हमने सावधानी से यह नोट किया कि हमने एक खास scenario को verify किया था, कोई सार्वभौमिक नियम नहीं। जब बाद में GPU दबाव और streaming की जटिलता बदली, तो धारणाओं को फिर से जांचना ज़रूरी होगा।

वे उबाऊ spikes जिन्होंने प्रोजेक्ट को बचाया

सीरीज़ के तीसरे भाग में कोई screenshots नहीं हैं। इसमें तीन ऐसे प्रयोग शामिल हैं जो दिखने में साधारण लगते थे पर जिनके product स्तर के नतीजे थे।

पहले ने यह जांचा कि क्या Cloudflare Durable Objects game जैसे tick rates पर real-time position broadcasts संभाल सकते हैं, यानी multiplayer की रीढ़। अगर यह नाकाम होता, तो पूरे network architecture को single-island ownership के बजाय शुरुआती sharding की ज़रूरत पड़ती।

दूसरे ने एक mobile quality profile को verify किया: कोई desktop preset का नाम बदलकर नहीं, बल्कि उसी terrain baseline से एक स्पष्ट कम-लागत वाला rendering path। सवाल यह था कि क्या renderer को दोबारा लिखे बिना world mobile GPU की पाबंदियों के तहत पठनीय और responsive बना रह सकता है।

तीसरे ने यह आंका कि क्या creator workflows के लिए AI-generated behavior scripts production इस्तेमाल के लिए भरोसेमंद हो पाएंगे।

इनमें से किसी ने demo reels नहीं बनाई। तीनों ने ऐसी सख्त सीमाएं तय कीं जिन्होंने उसके बाद के हर architectural फैसले को आकार दिया। Oleg लिखते हैं कि इन "साधारण दिखने वाले spikes ने visual spikes के मुकाबले architecture को ज़्यादा तेज़ी से बदला।"

streaming: जहां सुंदर प्रोजेक्ट बिखर जाते हैं

आप एक स्थिर frame में बहुत कुछ छिपा सकते हैं। दौड़ते वक्त किसी chunk boundary को पार करते समय की 40-millisecond की stutter आप नहीं छिपा सकते।

टीम ने advanced terrain बनाने से पहले streaming की जांच की, जानबूझकर चिंताओं को अलग रखते हुए। Spike 6 ने सरल content के साथ neighborhood chunk loading को verify किया। उस साफ signal के बाद ही Spike 11 ने progressive refinement के साथ compressed heightmap streaming पेश किया, यानी terrain को पहले 17-sample resolution पर load करना, फिर 33, फिर पूरा 65-sample grid।

यह क्रम हमारी उम्मीद से ज़्यादा मायने रखता था। अगर हमने सीधे compressed height chunks से शुरुआत की होती, तो हर hitch अस्पष्ट होती। क्या यह कोई decode समस्या थी, कोई texture upload stall, या कोई geometry update दिक्कत? पहले सरल streaming की जांच ने अनिश्चितता की एक पूरी श्रेणी को खत्म कर दिया।

एक व्यावहारिक सबक उभरा: upload stalls को सीधे मापें, average FPS के ज़रिए नहीं। averages frame spikes को छिपा देते हैं, और frame spikes ही वह चीज़ हैं जो players को असल में महसूस होती हैं।

visual budget की लड़ाइयां

तीन अलग-अलग प्रयोगों ने rendering costs पर एक साथ बंडल करने के बजाय अलग-अलग हमला किया। Vegetation घनत्व और wind animation। cliff faces के लिए triplanar mapping के साथ multi-layer terrain materials। वास्तविक terrain load के तहत cascaded shadow maps।

vegetation spike ने दिखाया कि instances को कम meshes में batch करना प्रति-blade polygon count घटाने से ज़्यादा मायने रखता था। material spike ने पाया कि vertical surfaces पर triplanar projection GPU cost के लायक थी, पर पांचवीं texture splat layer जोड़ना नहीं। shadow spike ने तय किया कि 1024 resolution पर तीन cascades 2 milliseconds से ज़्यादा GPU time लिए बिना स्वीकार्य contact shadows देते थे।

टीम ने एक सीधा नियम अपनाया: कोई feature तभी आगे बढ़ता है जब वह मापे गए frame-time data के साथ अपनी लागत समझा सके। शुरू में तय की गई इस पाबंदी ने volumetric terrain और clipmaps के इर्द-गिर्द बाद के architectural फैसलों को काफी साफ-सुथरा बना दिया।

वह मोड़ जिसने प्रोजेक्ट की दिशा बदल दी

Spike 10 से पहले, हमारा मानसिक मॉडल था "बड़ा world यानी ज़्यादा geometry।" Spike 10 के बाद, यह बन गया "स्थिर geometry budget, camera-केंद्रित ring updates।"

Geometry clipmaps, यानी camera पर केंद्रित terrain के संकेंद्रित rings जिनमें हर ring उत्तरोत्तर मोटा होता जाता है, का मतलब था कि draw distance चाहे जो हो, triangle count लगभग स्थिर रहता था। व्यावहारिक तरकीब ring boundaries पर geomorphing की थी: shader में vertex heights को सहजता से blend करना ताकि resolution levels के बीच का बदलाव गति में अदृश्य रहे।

एक सूक्ष्म सबक testing methodology से आया। Clipmaps screenshots में ठीक लगते हैं। वे अपने artifacts केवल ring boundaries से होकर लगातार camera गति के तहत ही दिखाते हैं। टीम ने स्थिर गति से traversals चलाने और temporal noise पर नज़र रखने में समय लगाया। "Screenshots ने झूठ बोला," Oleg लिखते हैं। "गति ने सच बताया।"

ज़मीन के नीचे जाना

Heightmaps गुफाओं को नहीं दर्शा सकते। वे एक grid पर हर बिंदु के लिए एक elevation मान संग्रहित करते हैं। जिस पल आपको tunnels, overhangs, या तराशी हुई चट्टानें चाहिए, उसी पल आपको volumetric terrain चाहिए।

Spike 12 ने WebGPU compute shaders का इस्तेमाल करके GPU पर marching cubes लागू किया, एक 3D signed distance field से triangle meshes निकालते हुए। चार 64-cubed chunks animated SDF edits से प्रति-frame mesh updates के साथ एक साथ चले। compute shader ने सब कुछ संभाला, यानी field का मूल्यांकन, cells का वर्गीकरण, vertices का उत्सर्जन, बिना किसी CPU readback के।

चुनौती इसे काम करवाना नहीं थी। चुनौती इसे बाकी सब चीज़ों के साथ काम करवाना थी। Three.js के scene graph के साथ एकीकरण, buffer lifecycle management (WebGPU buffers का आकार नहीं बदला जा सकता), अब भी in flight GPU resources को नष्ट होने से बचाने के लिए fence handling, इस सबके लिए सीरीज़ दो पूरे भाग समर्पित करती है, जिसे हम "incremental hardening" कहते हैं, यानी एक बार में एक क्षमता जोड़ने और हर जोड़ के बाद यह जांचने की साधारण प्रक्रिया कि पिछली layer अब भी काम करती है।

seam का दुःस्वप्न

सीरीज़ का तकनीकी रूप से सबसे डरावना हिस्सा भाग 9 से 11 तक फैला है, जो उस बात को कवर करता है जो तब होती है जब अलग-अलग resolutions वाले terrain chunks मिलते हैं।

जब एक high-detail chunk एक low-detail chunk के बगल में होता है, तो उनके स्वतंत्र रूप से बनाए गए meshes boundary पर मेल नहीं खाते। नतीजा होते हैं दिखने वाले cracks, झिलमिलाते edges, और T-junctions जहां से light रिसती है। Transvoxel algorithm इसे खास transition cells से हल करता है जो resolution अंतर को पाटते हैं, पर इसे सभी chunk configurations में सही ढंग से लागू करना, सही winding order, उचित buffer management और सटीक draw ranges के साथ, छह अलग-अलग प्रयोगों में खर्च हुआ।

टीम की सबसे यादगार debugging कहानी: एक seam artifact का दो दिन पीछा करना जिसका दोष हमने transition logic पर मढ़ा। असली अपराधी stale data था। GPU compute shader ने एक buffer में N vertices लिखे, पर draw call अब भी पिछले frame के N+M vertices को render करने के लिए configured था। उन अतिरिक्त vertices में कचरा था जो झिलमिलाते, उस्तरे जैसे पतले triangles पैदा करता था। एक line का fix: draw range को atomic counter की active vertex count तक clip करना।

"Rendering bugs अक्सर meshing bugs का भेस धारण कर लेते हैं," Oleg कहते हैं। "Geometry पूरे समय सही थी।"

अराजकता से शासन तक

seam की लड़ाई के बाद, टीम ने तदर्थ chunk व्यवहार को एक स्पष्ट policy system से बदला। अब एक central function ने हर chunk का LOD स्तर, rendering mode (heightmap या marching cubes), और किन faces को transition cells की ज़रूरत थी, यह तय किया। Distance rings ने base LOD तय किया। एक adjacency constraint ने यह सुनिश्चित किया कि कोई भी दो पड़ोसी chunks एक से ज़्यादा resolution स्तर से अलग न हों। एक edit bitmap ने volumetric chunks को distance चाहे जो हो, marching-cubes mode में रखा अगर उनमें creator संशोधन हों।

रंग-कोडित debug overlays, यानी heightmap chunks के लिए हरा, marching cubes के लिए नीला, transition faces के लिए नारंगी, ने "मैंने उस ridge के पास कहीं एक bug देखा" को "bug position (142, 12, -67) पर उत्तर-पश्चिम की ओर दिखता है" में बदल दिया।

"Policy ने जटिलता घटाई नहीं," Oleg लिखते हैं। "इसने जटिलता को व्यवस्थित किया।"

इन सबका कुल जोड़

आखिरी spike ने clipmap rings, प्रति-fragment sky fog (हर terrain fragment की दिशा में असल skybox रंग को sample करते हुए), और Three.js module wiring को एक एकीकृत प्रदर्शन में मिलाया। नतीजा एक ऐसा terrain system है जो near-field volumetric editing, mid-field heightmap chunks, और far-field clipmap rings को एक policy layer के तहत परत-दर-परत रखता है जो mode, LOD और transitions को नियंत्रित करती है।

सीरीज़ उन सबकों के साथ समाप्त होती है जिन्हें Oleg कहते हैं कि वे किसी भी भविष्य के प्रोजेक्ट पर दोहराएंगे:

• feature काम से पहले risk spikes से शुरुआत करें। content pipelines में निवेश करने से पहले "क्या हम यह कर भी सकते हैं?" वाले सवालों को खत्म करें।
• integration छलांगों से पहले known-good baselines को freeze करें। एक साफ checkpoint स्थापित करने में बिताया गया दिन बाद में regressions को bisect करने के कई दिन बचाता है।
• optimization marathons से पहले policy और observability को अनिवार्य करें। trigger rules वाली नामित परिस्थितियां हर बार रहस्यमय bugs को मात देती हैं।
• गति के तहत जांचें, screenshots से नहीं। Pops, flicker, और streaming hitches सब स्थिर frames में छिप जाते हैं।
• प्रति-feature frame time मापें, average FPS नहीं। averages उन spikes को छिपा देते हैं जो users को असल में महसूस होती हैं।
• गड़बड़ हिस्सों को प्रकाशित करें। गलत मोड़, भूत का पीछा, गलत system को दोष देने के दो दिन। ये वही हिस्से हैं जिनसे लोग असल में सीख सकते हैं।

Cinevva से परे यह क्यों मायने रखता है

सीरीज़ तीन वजहों से महत्वपूर्ण है जो एक कंपनी की terrain pipeline से आगे जाती हैं।

पहली, यह दिखाती है कि WebGPU compute shaders, WebAssembly physics, और edge पर deploy किए गए Durable Objects एक दहलीज़ पार कर चुके हैं। volumetric terrain, real-time editing, और streaming LOD वाला एक multiplayer open world 2026 में एक ब्राउज़र tab में architecturally व्यावहारिक है। दो साल पहले यह सच नहीं था।

दूसरी, spike methodology, यानी छोटे और केंद्रित प्रयोग जिनमें हर एक live, मापने योग्य नतीजों के साथ किसी एक जोखिम भरे सवाल का जवाब देता है, किसी भी ऐसी टीम के लिए एक template देती है जो ऐसा कुछ करने की कोशिश कर रही है जो शायद काम न करे। प्रतिबद्ध होने से पहले मापने का, एकीकृत करने से पहले baselines स्थापित करने का, optimize करने से पहले edge cases को नाम देने का अनुशासन terrain systems से कहीं आगे लागू होता है।

तीसरी, आमूल पारदर्शिता ही असल बात है। सभी 24 प्रयोगों के लिए सोर्स कोड प्रकाशित करना, dead ends और दो-दिन वाले debugging चक्करों समेत, इसे एक तकनीकी blog से कहीं ज़्यादा बना देता है। यह एक सार्वजनिक engineering नोटबुक है जो पाठक को ग्राहक के बजाय एक सहकर्मी की तरह मानती है।

पूरी सीरीज़ हमारी सीरीज़ गाइड में उपलब्ध है, जिसमें हर spike ब्राउज़र में live चल रहा है।

यह लेख मूल रूप से Medium पर प्रकाशित हुआ था।

Oleg Sidorkin द्वारा, Cinevva के CTO

किसी किरदार को एक सपाट स्केच से लेकर खेलने लायक 3D game तक पहुंचाने के लिए पहले एक concept artist, एक 3D modeler, एक rigger, एक animator और किसी ऐसे इंसान की ज़रूरत होती थी जो इन सबको engine में जोड़ सके। हम देखना चाहते थे कि इस पूरी pipeline का कितना हिस्सा Cinevva के creative tools अकेले संभाल सकते हैं। यहां हमें जो मिला, वो बता रहे हैं।

किरदार है Kali the Kitty, जो Cubcoats का है, एक बच्चों का ब्रांड जिसने Nordstrom, Amazon और Disney Store के ज़रिए दस लाख से ज़्यादा स्टफ्ड-एनिमल hoodies बेचे। Cubcoats के आठ ओरिजिनल किरदार हैं जिनकी अपनी तय शख्सियत है, एक काल्पनिक द्वीप की दुनिया है और 14 patents हैं। वे 2026 में एक लाइसेंसिंग-फर्स्ट platform के रूप में फिर से लॉन्च हो रहे हैं, और हम दिखाना चाहते थे कि वो IP कैसा दिखता है जब वो भौतिक प्रोडक्ट्स से आगे जाता है: एक वर्टिकल वीडियो शॉर्ट और एक रिग किया हुआ 3D किरदार जिसे आप browser में घुमा-फिरा सकते हैं। नीचे जो कुछ भी है, वो उसी खोज का असली नतीजा है।

3D viewers को घुमाने के लिए ड्रैग करें। यह देखने के लिए कि वर्टिकल शॉर्ट पहले फ्रेम से आखिरी फ्रेम तक कैसे आगे बढ़ता है, फिल्म स्ट्रिप को स्क्रॉल करें।

सपाट किताबी आर्ट से एक ऐसे किरदार तक जिसे आप घुमा सकें

Cubcoats के पास पहले से ही खूबसूरत 2D इलस्ट्रेशन थे। Mimi Chao के art direction ने हर किरदार को एक गर्मजोश, गोल, हाथ से बनी हुई शक्ल दी जो hoodies पर और कहानी की किताबों में बिल्कुल फिट बैठती है। लेकिन सपाट आर्ट 3D pipeline को नहीं चलाता। हमें एक हाई-फिडेलिटी किरदार चाहिए था जो वीडियो जनरेशन, mesh बनाने और rigging के लिए एक reference के तौर पर टिक सके, वो भी एक ही चेहरे से।

हमने शुरुआत किताब के ओरिजिनल इलस्ट्रेशन को अपने Image Generator में डालकर की और उससे उसी किरदार का 3D रेंडर किया हुआ वर्ज़न बनाने को कहा।

प्रोपोर्शन सही रहे, शख्सियत झलकती रही, और नरम 3D कार्टून लुक ने आगे की हर tool को एक जैसी चीज़ पर सहमत होने का आधार दिया। वहां से हमने सही pose और फ्रेमिंग पर तब तक काम किया जब तक हमारे पास एक तय हीरो reference नहीं आ गया।

T-pose इसलिए मायने रखता है क्योंकि rigging यह उम्मीद करती है कि बाहें धड़ से दूर हों। इसे छोड़ दें तो auto-rigger बाहों को शरीर से जोड़ देता है और हार मान लेता है। हमने T-pose उसी तय किरदार लुक से बनाया ताकि सिल्हूट और प्रोपोर्शन हर कदम पर एक जैसे रहें।

कुछ भी जनरेट करने से पहले कहानी लिखें

वीडियो tools को छूने से पहले हमने सीधी-सादी भाषा में एक बीट शीट लिखी। Cubcoats की दुनिया में Kali की शख्सियत की खासियत है "पॉज़िटिव"। वो वही है जो सबको साथ महसूस कराती है, और मुश्किल वक्त में भी हौसला बनाए रखती है। तो हमने उसी के इर्द-गिर्द एक दस-सेकंड का arc बनाया:

Kali रात में एक अंधेरे, धुंध भरे जंगल में एक छोटी सी चमकती लालटेन हाथ में लिए हुए घुसती है। वो डर जाती है, अकेली बैठ जाती है, लगभग हार मान लेती है। फिर उसे अपने पीछे रोशनी से जगमगाता एक जादुई सुनहरा पेड़ दिखता है। हैरानी, खुशी, सुनहरे कण बरसते हुए। एक ही सांस में डर से उम्मीद तक।

यही पूरी कहानी है। इसे जटिल होने की ज़रूरत नहीं। इसे एक भावनात्मक मोड़ को एक लगातार चलने वाले शॉट में फिट करना होता है ताकि शुरुआती फ्रेम और आखिरी फ्रेम वाकई आपस में जुड़ सकें।

दो फ्रेम जो पूरी चीज़ के दोनों सिरे संभालते हैं

हमने उस कहानी से दो अहम स्टिल अपने Image Generator से बनाए। वर्टिकल शॉर्ट से मेल खाने के लिए पोर्ट्रेट aspect। prompts ठीक उसी किरदार को दो अलग-अलग पलों में बयान करते हैं।

शुरुआती फ्रेम का prompt:

3D animated Pixar-style render of Kali, a small pink kitty character with large round dark eyes, pink pointed ears, a light pink belly, and a cheerful round face. She is standing at the edge of a dark misty forest at night, holding a tiny glowing lantern in both paws. Her ears are slightly flattened and her expression is nervous but determined. Cinematic lighting with cool blue moonlight from above and warm orange glow from the lantern. Dense fog between dark tree trunks in the background. Camera angle: medium shot, slightly low looking up at her. No text, no watermark.

आखिरी फ्रेम का prompt:

3D animated Pixar-style render of Kali, a small pink kitty character with large round dark eyes, pink pointed ears, and a light pink belly. She is standing in front of a massive magical tree covered in glowing golden flowers, arms outstretched wide, beaming with a huge joyful smile. Golden petals float in the air around her. The tree radiates warm golden light that illuminates the entire forest clearing. Starry night sky visible above. Camera angle: wide shot from slightly below, epic reveal composition. No text, no watermark.

Seedance इन दोनों सिरों के बीच interpolate करता है। किरदार का बयान दोनों prompts में एक जैसा रहता है ताकि model को पता रहे कि यह वही इंसान है। सिर्फ़ सीन, भावना और camera बदलते हैं।

वीडियो उम्मीद से बेहतर निकला

हमने दोनों फ्रेम Cinevva के Video Generator में लोड किए, Seedance 1.5 Pro चुना, 9:16 aspect और 15 सेकंड सेट किए, motion prompt में कहानी टाइप की, और Generate दबा दिया।

क्लिप दोनों सिरों के बीच interpolate करती है। नेटिव audio उसी पास में जनरेट हुआ। यहां timeline के साथ-साथ लिए गए कुछ फ्रेम हैं।

बाएं से दाएं: जनरेट किए गए वर्टिकल शॉर्ट के दौरान आगे बढ़ता क्रम।

जब हमें एक तय आखिरी pose पर सटीक पहुंचने की परवाह थी, तो शुरुआती और आखिरी फ्रेम वाला मोड सही रहा। लंबे भावनात्मक arcs के लिए, सिंगल reference और prompt वाला तरीका Video Generator के Kling 3.0 Pro storyboard मोड के साथ अच्छा चला। अलग-अलग कामों के लिए अलग-अलग settings।

वही किरदार, अब 3D में

यहीं से बात दिलचस्प होती है। वीडियो references के उसी परिवार का T-pose स्टिल हमारे 3D Model Generator में image-to-3D जनरेशन के लिए गया। आप game mesh को वीडियो से पिक्सल-दर-पिक्सल मिला नहीं रहे होते। आप खिलाड़ी की याददाश्त से मिला रहे होते हैं। game में किरदार reel जैसी ही शख्सियत का महसूस होना चाहिए। और क्योंकि हमने शुरुआत में ही एक विज़ुअल पहचान तय कर ली थी, वैसा ही हुआ।

3D Model Generator एक textured GLB देता है। game के लिए तैयार नहीं, लेकिन पहचान में आने लायक Kali। सिल्हूट मेल खाया। materials करीब थे। आगे बढ़ने के लिए काफी अच्छा।

इन्हें घुमाकर देखें

3D Model Generator से सीधा निकला आउटपुट। कोई rig नहीं, बस एक textured mesh। उसके बगल में, वही किरदार auto-rigging के बाद, एक बेक की हुई walk animation के साथ।

Rigging और animation

3D Model Generator आपको एक mesh देता है। उस mesh को हिलाने-डुलाने के लिए उसे एक skeleton और animations चाहिए। हमारा platform rigging अपने आप संभालता है: GLB अपलोड करें, और एक रिग किया हुआ model पूरी animation library के साथ वापस पाएं। walk cycles, idle सांस लेना, jumps, वो सब कुछ जो एक game किरदार को चाहिए।

डिफ़ॉल्ट walk animation लगभग सही लगती थी, पर पूरी तरह नहीं। Kali की बाहें उसके शरीर के बहुत करीब थीं और उसका सिर थोड़े गलत कोण पर झुका हुआ था। दोनों चीज़ें एक आम humanoid के लिए ठीक थीं पर एक गोल कार्टून kitty पर अटपटी लगती थीं। तो हमने game code में runtime bone corrections जोड़े: एक shoulder offset जो बाहों को बाहर की ओर धकेलता है और एक head rotation fix जो झुकाव को सीधा करता है। छोटे बदलाव, बड़ा फर्क। इनके बिना वो अकड़ी हुई और रोबोट जैसी दिखती थी। इनके साथ वो फिर से Kali जैसी दिखी।

किरदार को browser में खेलना

हमने रिग किए हुए model को Cinevva Engine में डाल दिया। थर्ड-पर्सन camera, WASD मूवमेंट, इधर-उधर बिखरे collectibles, और idle होने पर orbit camera। animation blending सही बैठाने में थोड़ी मेहनत लगी: idle और walk के बीच crossfading, height नॉर्मलाइज़ करना, forward axis ठीक करना, bone offsets में फेरबदल। किरदार के पीछे थर्ड-पर्सन camera स्केच से लेकर एक ऐसी चीज़ तक का घेरा पूरा करता है जिसमें आप घूम-फिर सकें।

खुद आज़माएं। हिलने-डुलने के लिए WASD।

कल यही करने वाले किसी को मैं क्या कहूंगा

किसी भी जनरेशन tool को छूने से पहले एक किरदार लुक तय कर लें। उस reference को सही करने में आप जो भी एक-एक मिनट लगाते हैं, वो बाद में consistency के पीछे भागने के एक-एक घंटे बचाता है।

पहले एक छोटी सी कहानी लिखें। फिर अपने शुरुआती और आखिरी फ्रेम Image Generator से बनाएं। reference images को API साइज़ की सीमा के अंदर रखें। जब आप 3D Model Generator को चलाएं तो उसी डिज़ाइन सिस्टम का T-pose इस्तेमाल करें।

दोनों फ्रेम Video Generator को दें और उसे interpolate करने दें। game mesh के लिए, model को platform के ज़रिए रिग करें और अगर डिफ़ॉल्ट animations आपके किरदार के प्रोपोर्शन पर पूरी तरह फिट न बैठें तो runtime पर bone offsets में फेरबदल करें।

दो साल पहले यह pipeline मौजूद नहीं थी। आपको एक टीम और एक बजट चाहिए होता। अब आपको एक स्केच और Cinevva के creative tools चाहिए। मुझे लगता है कि यह इस बात में एक अहम बदलाव है कि किसी किरदार में जान फूंकने का मौका किसे मिलता है।

इस्तेमाल किए गए Cinevva tools: Image Generator, Video Generator, 3D Model Generator, auto-rigging, और Cinevva Engine। 2026 की शुरुआत को दर्शाता है।

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? सीरीज़ गाइड का इस्तेमाल करें। इसमें बताया गया है कि spike क्या होता है और सभी भागों के लिंक दिए गए हैं।

हम एक multiplayer open world बना रहे हैं जो पूरी तरह ब्राउज़र में चलता है। कोई install नहीं, कोई app store नहीं, बस एक URL। सबसे बड़ा risk शुरू से ही साफ था: क्या एक ब्राउज़र खेलने लायक frame rates पर एक persistent 3D world को render कर सकता है और साथ ही gameplay, physics और networking के लिए भी जगह छोड़ सकता है?

ज़्यादातर open world प्रोजेक्ट एक तय क्रम में नाकाम होते हैं। पहले आपको एक अच्छा concept मिलता है। फिर आपको एक खूबसूरत scene मिलता है। फिर आपको एहसास होता है कि gameplay के अस्तित्व में आने से पहले ही आपका frame budget खत्म हो चुका है।

हम बाकी किसी भी चीज़ में निवेश करने से पहले render budget वाले सवाल का जवाब चाहते थे। इसलिए Spike 1 ने खूबसूरत trailer को छोड़कर सीधे मापने का काम किया।

Spike 1 को नए tab में खोलें ↗ · सोर्स देखें

सेटअप जानबूझकर सरल था। एक 512 मीटर का terrain mesh, island falloff के साथ layered sine noise से बनी procedural height, एक water plane, atmospheric fog, और 500 instanced objects। हमने plain WebGL का इस्तेमाल Three.js के साथ किया, ACES tone mapping, और कोई shadows नहीं।

हमें इस बात की परवाह नहीं थी कि यह कैसा दिखता है। हमें इस बात की परवाह थी कि camera को इसमें घुमाते वक्त scene स्थिर रहता है या नहीं।

इस spike से दो चीज़ें निकलीं जिन्होंने पूरे प्रोजेक्ट को आकार दिया।

पहली, हमने पुष्टि की कि अगर हम पहले pass को अनुशासित रखें तो desktop पर हमारे पास सचमुच जगह बची हुई थी। इससे हमें बाद में मुश्किल terrain architecture आज़माने का भरोसा मिला।

दूसरी, हमने एक baseline contract बनाया। आने वाले हर spike को इस scene के मुकाबले अपनी लागत समझानी थी। अगर कोई नया feature अच्छा दिखता था लेकिन उसकी लागत बहुत ज़्यादा थी, तो उसे आगे नहीं बढ़ाया जाता था।

वह baseline अनुशासन बाद में बहुत अहम बन गया जब हम seam artifacts, mixed LOD transitions, और compute driven meshing से टकराए। एक स्थिर reference के बिना, हर bug असल से बड़ा दिखता है।

भाग 2 में हम rendering से आगे बढ़कर input feel पर जाते हैं। Worker physics architecture docs में बढ़िया लगती है। यह सिर्फ़ तभी मायने रखती है जब आप कोई key दबाएं और character अब भी तुरंत प्रतिक्रिया देता महसूस हो।

इस अध्याय में बताई गई technology

Heightmap terrain. एक 2D grid जहां हर cell एक अकेला elevation value रखता है। GPU vertex shader में एक flat mesh को विस्थापित करके terrain की सतह बनाता है। Heightmaps compact होते हैं (16-bit पर एक 65x65 chunk ~8 KB का होता है), GPU-friendly होते हैं, और render करने में तेज़ होते हैं। इसकी सीमा यह है कि ये गुफाओं, overhangs, या किसी भी ऐसी सतह को नहीं दिखा सकते जो खुद पर वापस मुड़ जाती है। heightmap की सीमाओं और उनके बाद क्या आता है, इसकी पृष्ठभूमि के लिए, हमारी landscape generation गाइड देखें।

Three.js. वह rendering library जो हमने इस पूरे प्रोजेक्ट में इस्तेमाल की। Three.js, WebGL 2 (और बाद में WebGPU) को cameras, lights, materials, और geometry objects वाले एक scene graph में बदल देती है। यह एक ही draw call में एक ही geometry की कई copies render करने के लिए InstancedMesh देती है, साथ ही frustum culling, PBR materials, और post-processing भी। GitHub पर Three.js देखें। Three.js एक ब्राउज़र open world stack में कैसे फिट होती है, इसके लिए हमारी browser 3D tech गाइड देखें।

InstancedMesh. Three.js का एक feature जो एक ही geometry की N copies को एक ही draw call से render करता है, हर एक अलग position/rotation/scale पर। प्रति-instance transforms एक matrix attribute buffer में रखे जाते हैं। इसी तरह हमने Spike 1 में 500 objects को 500 अलग draw calls के बिना render किया। बड़े पैमाने पर vegetation के लिए, GPU-driven instanced culling इसे और आगे ले जाती है। हमारी GPU vegetation culling पर landscape गाइड देखें।

Frame budget. 60 fps पर, हर frame के पास हर चीज़ के लिए $\frac{1000\text{ms}}{60}\approx 16.7$ ms होते हैं: JavaScript logic, physics, rendering, और compositing। एक "budget check" spike मापता है कि एक baseline scene इसमें से कितना खपाता है, ताकि बाद में आप जो कुछ भी जोड़ें उसके लिए बची हुई जगह $t_{\text{features}}=16.7-t_{\text{baseline}}$ हो। अगर baseline पहले ही 12 ms खा जाता है, तो gameplay, physics, और networking सबके लिए मिलाकर सिर्फ़ ~4.7 ms बचते हैं। यह तरीका AAA open world development से आता है जहां GTA V, Skyrim, और Elden Ring सभी तय frame budgets के अंदर रहने के लिए aggressive LOD और streaming का इस्तेमाल करते हैं।

12 में से भाग 1।
आगे: भाग 2 - Worker physics और input lag का डर
सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? सीरीज़ गाइड का इस्तेमाल करें। इसमें बताया गया है कि spike क्या होता है और सभी भागों के लिंक दिए गए हैं।

अगर आप काफी समय तक ब्राउज़र multiplayer बनाते रहें, तो आखिरकार आपको यह बहस सुनने को मिलती है।

"Worker में physics साफ-सुथरा architecture है। Main thread पर physics ज़्यादा सुरक्षित महसूस होता है।"

दोनों सच हो सकते हैं। जो मायने रखता है वह है control का एहसास और असली input के तहत latency।

Spike 2 इसी का जवाब देने के लिए बनाया गया था, राय से नहीं बल्कि माप से।

Spike 2 को नए tab में खोलें ↗ · सोर्स देखें

हमने Spike 1 का terrain दोबारा इस्तेमाल किया और Rapier को एक समर्पित module worker में जोड़ा। Input state हर frame पर worker को भेजा जाता था, simulation वहीं step होती थी, और authoritative position वापस renderer के पास आती थी।

मुख्य metrics थे input से दिखने वाले movement तक की latency और physics step की timing। हमने सामान्य movement, sprint bursts, और jump cadence के दौरान jitter पर भी नज़र रखी।

नतीजा उम्मीद से बेहतर रहा। हमारे message shape और cadence के साथ, worker boundary latency पर हावी नहीं हुई। Controls अब भी तुरंत महसूस होते थे, और players को बस यही चीज़ मायने रखती है।

इस चरण की एक चुनौती थी interpretation का risk। एक सफल नतीजे के बाद, teams अक्सर बहुत ज़्यादा सामान्यीकरण कर लेती हैं और मान लेती हैं कि architecture का सवाल हमेशा के लिए बंद हो गया। ऐसा नहीं है। हमने सिर्फ एक ठोस scenario और hardware profile को validate किया था। बाद के spikes को भी अपनी धारणाओं की दोबारा जांच करनी पड़ी जब GPU और streaming का दबाव बदला।

इस spike ने हमें एक process upgrade भी दिया। हमने interactive spikes के लिए HUD में timing telemetry को by default दिखाना शुरू किया। इससे team की बातचीत "यह कुछ गड़बड़ महसूस होता है" से बदलकर "इस path ने 1.2 ms जोड़े" हो गई।

भाग 3 में हम उन कम चमक-दमक वाले experiments को देखेंगे जिन्होंने बाद में महंगे झटकों से बचाया। Broadcast load, mobile की पाबंदियां, और behavior generation की भरोसेमंदी।

इस अध्याय में संदर्भित technology

Rapier. Rust में लिखा गया एक physics engine जो ब्राउज़र में इस्तेमाल के लिए WebAssembly में compile होता है। यह rigid bodies, colliders, joints, character controllers, और raycasting को native से 2-3x performance पर संभालता है। Open worlds के लिए, Rapier player character controllers (terrain पर चलना, steps चढ़ना, slopes पर फिसलना), object collision, interactions के लिए raycasting, और trigger volumes देता है। देखें Rapier documentation और हमारी physics पर browser 3D tech guide।

Web Workers. ब्राउज़र threads जो JavaScript (या Wasm) को main thread से अलग चलाते हैं। Worker में physics simulation का मतलब है कि एक भारी world.step() call rendering को block नहीं करती। Main thread हर frame पर postMessage के ज़रिए worker को input state भेजता है और बदले में authoritative positions पाता है। Latency की कीमत है दो message hops (desktop पर हर एक ~0.1-0.5 ms)। फायदा यह है कि render thread कभी collision detection पर अटकता नहीं। Transferable objects (ArrayBuffer transfer) बड़े position arrays के लिए copy overhead को खत्म कर देते हैं।

WebAssembly (Wasm). एक binary instruction format जो ब्राउज़र में near-native speed पर चलता है। Rapier, Havok, और Recast सभी Wasm में compile होते हैं। Rapier-Wasm में physics step कुछ सौ bodies के लिए आमतौर पर 0.5-2 ms होता है, जबकि बराबर के JavaScript के लिए 5-15 ms। Wasm modules .wasm files के रूप में JavaScript glue code के साथ load होते हैं। देखें WebAssembly specification।

Input-to-visual latency. एक keypress और स्क्रीन पर उसके फलस्वरूप होने वाले visual बदलाव के बीच का समय। Movement को "तुरंत" महसूस होने के लिए, यह ~80 ms से नीचे रहना चाहिए। Worker physics setup में यह chain जुड़ती जाती है:

keydown event (main thread), worker को postMessage और वापस ($2t_{\text{msg}}$), physics step, renderer द्वारा नई position लागू करना, फिर अगला vsync। हर term अपने आप में छोटा है (desktop पर हर message hop ~0.1-0.5 ms), लेकिन ये जुड़ते जाते हैं, इसीलिए हमने architecture diagram पर भरोसा करने के बजाय $L$ को सीधे नापा।

12 में से भाग 2।
पिछला: भाग 1 - हमने इसे तोड़ने की कोशिश से शुरुआत की
अगला: भाग 3 - वे बेरंग spikes जिन्होंने हमें बचाया
सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? series guide का इस्तेमाल करें। यह बताती है कि spike क्या होता है और सभी भागों को जोड़ती है।

इस भाग में चमकदार screenshots कम हैं और architecture का बीमा ज़्यादा।

Spike 1 और 2 के बाद, हमने तीन risk checks किए जो छोटे लगते थे लेकिन उनका असर product के स्तर पर था।

पहला था Durable Objects के साथ broadcast fan out। हमने game जैसी tick rates पर multi client position distribution को टेस्ट किया और latency distribution, हर tick पर CPU, और delivery integrity को ट्रैक किया। अगर यह fail होता, तो हम single island ownership के बजाय जल्दी sharding की तरफ चले जाते।

दूसरा था mobile constraint validation। ये कोई desktop preset को mobile नाम देकर रखना नहीं था, बल्कि उसी baseline terrain से बना एक साफ़ low-cost profile था।

mobile profile को नए tab में खोलें ↗ · source देखें

हमने segment density, object count, render resolution का दबाव, और fog range को घटाया। सवाल आसान था। क्या यह world mobile जैसी सीमाओं पर पढ़ने लायक और responsive रह सकता है, बिना पूरे renderer को दोबारा लिखे।

तीसरा था creator workflows के लिए behavior generation की विश्वसनीयता। हमने valid JSON rate, अपेक्षित primitives के मुकाबले semantic सटीकता, और response latency का आकलन किया। अगर यह fail होता, तो हम strict form आधारित behavior authoring की तरफ चले जाते।

इस अध्याय की मुख्य सीख यह है कि इन साधारण spikes ने architecture को visual spikes से भी तेज़ बदला। इन्होंने network topology, mobile के वादों, और tool UX पर पक्की सीमाएं तय कर दीं।

भाग 4 में हम दिखने वाले terrain के काम पर लौटते हैं और सिर्फ़ static loading screenshots नहीं, बल्कि movement-time streaming behavior को टेस्ट करते हैं।

इस अध्याय में जिन technologies का ज़िक्र हुआ

Cloudflare Durable Objects. Edge पर deploy होने वाले stateful serverless instances जिनमें built-in persistence और WebSocket support होता है। हर Durable Object एक world shard (या chunk) के लिए authoritative state रखता है। Players WebSocket के ज़रिए जुड़ते हैं और उसी shard के दूसरे players से position broadcasts पाते हैं। जब player किसी adjacent chunk में जाता है, तो वह उस chunk के Durable Object से जुड़ जाता है। Durable Objects state को अपने आप disk पर persist करते हैं और हज़ारों concurrent instances तक scale करते हैं। देखें Cloudflare Durable Objects docs और हमारी multiplayer networking पर browser 3D tech guide।

Spatial sharding. World को geographic region के हिसाब से server instances पर बांटना। हर shard, world grid के एक rectangular इलाके का मालिक होता है। जैसे-जैसे player density बदलती है, shards बंट सकते हैं या जुड़ सकते हैं। किसी shard boundary के पास के players cross-shard visibility queries के ज़रिए दोनों shards का content देखते हैं। इसी तरह EVE Online एक ही universe में हज़ारों players को संभालता है।

WebSocket broadcast fan-out. एक server से कई जुड़े हुए clients तक real-time position updates पहुंचाना। हर client का downstream bandwidth उस भीड़ के साथ linearly बढ़ता है जो आप देख सकते हैं:

game जैसी tick rates (20-30 Hz) पर हर player करीब $b_{\text{player}}\approx 800$ bytes/second का position data बनाता है, तो नज़र में 200 players का खर्च हर client के लिए $200\times 800=160$ KB/s होता है। naive all-to-all server cost इससे भी बुरी होती है, जो $N^2$ की तरह बढ़ती है, और ठीक इसीलिए relevance filtering (spatial interest management) हर connection पर tick budget के अंदर push करने से पहले $N_{\text{visible}}$ पर एक सीमा लगा देता है। delta compression और update frequency के तालमेल के लिए हमारी networking guide देखें।

Mobile rendering की सीमाएं. Mobile GPUs में desktop GPUs के मुकाबले 1/5 से 1/10 throughput होती है, करीब 1 GB memory की सीमा (desktop पर 2-4 GB के मुकाबले), और लगातार load पर thermal throttling होती है। एक mobile quality profile segment density, object count, render resolution, draw distance, और shadow quality को घटाता है। मकसद desktop की बराबरी नहीं, बल्कि पढ़ने लायक और responsive बने रहना है। असली GPU benchmarks के लिए browser 3D performance numbers देखें।

12 में से भाग 3.
पिछला: भाग 2 - Worker physics और input lag का डर
अगला: भाग 4 - Fancy terrain से पहले streaming
Series guide: /blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? series guide का इस्तेमाल करें। यह बताती है कि spike क्या होता है और सभी भागों को जोड़ती है।

streaming वही जगह है जहां "दिखने में अच्छे" projects आमतौर पर बिखर जाते हैं।

एक still frame में आप बहुत कुछ छिपा सकते हैं। लेकिन chunk boundary पार करते समय होने वाली 40 ms की hitch को आप नहीं छिपा सकते।

हमने जानबूझकर advanced terrain representation बनाने से पहले streaming को टेस्ट किया। इससे हमें load और unload behavior पर साफ signal मिला।

Spike 6 ने साधारण chunk content के साथ neighborhood churn को verify किया।

Spike 6 को नए tab में खोलें ↗ · View source

फिर हम Spike 11 में असली terrain path की तरफ बढ़े। worker side decode के साथ height chunk streaming और 17 से 33 से 65 sample grids तक progressive refinement।

Spike 11 को नए tab में खोलें ↗ · View source

यह क्रम हमारी उम्मीद से ज़्यादा मायने रखता था। अगर हमने सीधे compressed height chunks से शुरुआत की होती, तो हर hitch अस्पष्ट होती। decode का issue, texture upload का issue, या geometry update का issue। Spike 6 ने Spike 11 के complexity जोड़ने से पहले एक uncertainty layer हटा दी।

इस chapter से एक व्यावहारिक सबक आगे के spikes में काम आया। Upload stalls को सीधे मापना चाहिए, average FPS से अंदाज़ा नहीं लगाना चाहिए। average FPS frame spikes को छिपा देता है, और frame spikes ही वो चीज़ हैं जो users असल में महसूस करते हैं।

भाग 5 में हम visual cost chapter में जाएंगे, जहां vegetation, terrain shaders, और cascaded shadows एक ही frame budget के लिए मुकाबला करते हैं।

इस chapter में संदर्भित technology

Chunk-based streaming. दुनिया को independent chunks की एक grid में बांटा जाता है (आमतौर पर 64x64 मीटर)। जैसे-जैसे player आगे बढ़ता है, पीछे के किनारे के chunks unload होते हैं और सामने के किनारे के chunks stream in होते हैं। Skyrim का cell system इसी तरह काम करता है: player के चारों ओर 5x5 cells की grid load रहती है, जो उसके चलने पर swap होती रहती है। browser version इस समीकरण में network latency जोड़ता है, जिससे player velocity के आधार पर predictive pre-fetching ज़रूरी हो जाती है। हमारी streaming architecture guide देखें।

Progressive heightmap refinement. terrain पहले low resolution पर भेजें, फिर refine करें। grid sizes मनमाने नहीं हैं: हर level एक $(2^k+1)\times (2^k+1)$ grid होता है, इसलिए $17=2^4+1$, $33=2^5+1$, $65=2^6+1$। $+1$ हर boundary पर एक shared sample रखता है ताकि neighbors सही ढंग से मिलें, और हर step लगभग sample count को चार गुना कर देता है ($n^2$ तब बढ़ता है जब side दोगुनी होती है)। एक 17x17 grid (4m spacing पर 64m chunk के लिए न्यूनतम) compressed होने पर ~200 bytes का होता है और तुरंत एक दिखने वाली surface render करता है। फिर 33x33 refinement stream करें, फिर पूरी 65x65 resolution। हर level पिछले data को बदले बिना samples जोड़ता है। यह सीधे geometry clipmap LOD rings से मेल खाता है जहां दूर का terrain low-resolution data इस्तेमाल करता है और पास का terrain full resolution। progressive chunk loading देखें।

Delta encoding और compression. heightmap data अच्छे से compress होता है क्योंकि आसपास के cells की values मिलती-जुलती होती हैं। delta encoding हर cell और उसकी predicted value (neighbors का average) के बीच का अंतर store करता है, जिससे values zero के पास इकट्ठा हो जाती हैं। zlib या brotli के साथ मिलकर, एक 65x65 chunk 8.4 KB raw से 1-2 KB compressed तक गिर जाता है। दूर के chunks के लिए कम precision पर (16-bit के बजाय 8-bit): 0.5-1 KB। terrain data compression देखें।

Predictive pre-fetching. player के पहुंचने से पहले chunks load करना। lead distance को उतना cover करना होता है जितनी दूरी player एक chunk load होने के दौरान तय करता है, $d_{\text{prefetch}}=v\cdot t_{\text{load}}$, इसलिए यह speed के साथ scale करता है: walking speed (5 km/h) पर 2 chunks आगे pre-fetch करें (128m), running speed (15 km/h) पर 4। load ring velocity direction के साथ शिफ्ट होती है। एक priority queue pending requests को urgency के हिसाब से sort करता है और उन chunks के requests cancel कर देता है जिनसे player दूर चला गया है। predictive pre-fetching देखें।

भाग 4, कुल 12 में से।
पिछला: भाग 3 - वे साधारण spikes जिन्होंने हमें बचाया
अगला: भाग 5 - खूबसूरत चीज़ों का budget तय करना
Series guide: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? सीरीज़ गाइड का इस्तेमाल करें। इसमें बताया गया है कि spike क्या होता है और सभी भागों के लिंक दिए गए हैं।

यह वह अध्याय था जहां visual महत्वाकांक्षा का सामना गणित से हुआ।

हमने rendering की लागत को अलग-अलग spikes में बांटा क्योंकि एक साथ मिले हुए नतीजों की जांच करना मुश्किल होता है। अगर आप सब कुछ एक ही बार में चालू कर देते हैं, तो आपको सिर्फ इतना पता चलता है कि frame धीमा है। यह पता नहीं चलता कि किस feature ने बजट खा लिया।

Spike 7 का निशाना vegetation density और animation की लागत थी। तरीका यह था कि हर terrain chunk के लिए 32x32 density maps से runtime scattering की जाए, जो बड़े InstancedMesh sets को feed करे। हर घास की पत्ती और झाड़ी के cluster को एक scrolling noise texture से चलने वाला vertex-shader wind मिला। हम जिस मुख्य आंकड़े पर नज़र रखते थे वह triangle count नहीं बल्कि mid-range GPUs पर draw call overhead और vertex throughput था। हमें पता चला कि instances को कम meshes में batch करना, हर पत्ती के polygon count को घटाने से ज़्यादा मायने रखता है।

Spike 7 को नए tab में खोलें ↗ · सोर्स देखें

Spike 8 ने terrain material की जटिलता को आगे बढ़ाया। slope angle और altitude के हिसाब से weighted multi-layer blending, cliff faces के लिए optional triplanar projection, और per-layer normal maps। shader चार texture layers के साथ slope-based splatting कर रहा था, और हर layer को एक diffuse और एक normal sample की ज़रूरत थी। यानी lighting जोड़ने से पहले ही हर fragment पर $4\times 2=8$ texture fetches, और यह count layers के साथ रैखिक रूप से बढ़ता है, इसलिए पांचवीं layer का मतलब है हर pixel पर 10 fetches। हमने floor ढूंढने के लिए खासतौर पर integrated Intel GPUs पर profile किया। निष्कर्ष यह निकला कि vertical surfaces पर triplanar projection लागत के लायक था, लेकिन पांचवीं splat layer जोड़ना नहीं।

Spike 8 को नए tab में खोलें ↗ · सोर्स देखें

Spike 9 का फोकस वास्तविक terrain और object load के तहत cascaded shadow map की लागत पर था। तीन cascades वाला CSM baseline था। हमने खासतौर पर low-angle sun positions के साथ टेस्ट किया क्योंकि cascade pressure सबसे बुरी वहीं होती है। दूर वाला cascade frustum के एक बहुत बड़े हिस्से को कवर करता है, और shadow detail texel density से तय होती है, $\rho \approx \frac{R^2}{A}$ (एक shadow map जिसका resolution $R$ है, ground area $A$ पर खींचा हुआ)। पूरी view distance पर एक ही map लगाने से $A$ बहुत बड़ा हो जाता है और $\rho$ गिर जाता है। Cascades इसे ठीक करते हैं क्योंकि वे frustum को इस तरह बांटते हैं कि हर slice को एक छोटे $A$ पर अपना $R\times R$ map मिले, जिससे $\rho$ पास से दूर तक लगभग एक जैसा बना रहता है। हमने दो और चार cascades के बीच GPU time का अंतर मापा, फिर 1024 और 2048 shadow map resolution के बीच। नतीजा यह रहा कि 1024 पर तीन cascades ने हमें target hardware पर 2ms GPU time से ज़्यादा खर्च किए बिना camera के पास स्वीकार्य contact shadows दिए।

Spike 9 को नए tab में खोलें ↗ · सोर्स देखें

इस चरण में सबसे मुश्किल हिस्सा product discipline था। कुछ effects बेहद शानदार दिखते थे फिर भी उन्हें सीमित करना पड़ा क्योंकि वे अपने visual असर के मुकाबले frame budget का बहुत बड़ा हिस्सा खा रहे थे।

हमारा नियम सीधा बन गया। कोई feature तभी आगे बढ़ता है जब वह मापे गए frame-time data के साथ अपनी लागत को सही ठहरा सके।

यह सुनने में स्पष्ट लगता है। लेकिन तेज़ prototype cycles में यह आम नहीं है, जहां हर कोई अगली visual जीत को लेकर उत्साहित रहता है। इस नियम को शुरू से बनाए रखने से बाद में clipmaps और volumetric zones को लेकर लिए गए architecture फैसले काफी साफ-सुथरे रहे, क्योंकि हमें पहले से पता था कि उसी 16ms के लिए होड़ करने वाली हर चीज़ की per-feature लागत क्या है।

भाग 6 में हम geometry clipmaps के साथ पहले बड़े terrain architecture pivot तक पहुंचे।

इस अध्याय में संदर्भित तकनीक

InstancedMesh और GPU vegetation. Three.js का InstancedMesh एक ही geometry की N copies को एक draw call में render करता है। vegetation के लिए, एक density map (हर chunk में 32x32) घास की पत्तियों और झाड़ी के clusters का runtime scattering instance buffers में चलाता है। Wind animation vertex shader में एक scrolling noise texture का इस्तेमाल करके चलता है। scale पर, WebGPU का ComputeInstanceCulling rasterization से पहले off-screen और दूर के instances को हटा देता है, और IndirectBatchedMesh कई vegetation types को एक ही buffer में पैक करता है जो multi-draw indirect से draw होता है। हमारी GPU vegetation culling पर landscape गाइड देखें।

Triplanar mapping. सामान्य UV-mapped textures steep slopes पर खिंच जाते हैं क्योंकि UV coordinates सिकुड़ जाते हैं। Triplanar mapping textures को तीनों axes (X, Y, Z) के साथ project करती है और surface normal के आधार पर blend करती है। Cliff faces को X या Z projection मिलता है (कोई खिंचाव नहीं), flat ground को Y projection। blending बिना किसी UV unwrapping के अपने आप और smooth होती है। PBR terrain के लिए, वही blending weights albedo, normal, roughness, और ambient occlusion channels पर लागू होते हैं। triplanar mapping की जानकारी देखें।

Slope और altitude आधारित material splatting. हाथ से बनाए गए splat maps के बजाय, materials को terrain properties के आधार पर fragment shader में procedurally assign किया जाता है। कम altitude पर flat ground को घास मिलती है, steep slopes को चट्टान, high altitude को बर्फ (सिर्फ उन्हीं surfaces पर जो जमाव के लिए काफी flat हों), sea level के पास रेत। transitions smooth blending के लिए smoothstep का इस्तेमाल करते हैं। हमारे implementation में, हर terrain chunk चार texture layers को हर layer पर diffuse और normal samples के साथ evaluate करता है, जिससे lighting से पहले हर fragment पर आठ texture fetches होते हैं। slope और altitude material assignment देखें।

Cascaded Shadow Maps (CSM). CSM camera के view frustum को 3-4 distance ranges (cascades) में बांटता है। हर cascade sun के नज़रिए से एक shadow map render करता है, जिसका resolution उसकी distance के हिसाब से होता है। पास वाले cascades को high-resolution shadows मिलती हैं (पेड़ों और इमारतों के नीचे विस्तृत contact shadows), दूर वाले cascades को कम resolution (चौड़ी पहाड़ी shadows)। terrain shader सभी cascades को sample करता है और हर fragment के लिए उपयुक्त एक चुनता है। Performance लागत: 1024x1024 पर 3-4 cascades shadow map rendering के लिए ~0.5-1 ms और sampling के लिए ~0.2-0.3 ms जोड़ते हैं। terrain के लिए shadows देखें।

भाग 5, कुल 12 में से।
पिछला: भाग 4 - फैंसी terrain से पहले streaming
अगला: भाग 6 - Clipmaps ने कहानी बदल दी
सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide

लिखा है Oleg Sidorkin ने, Cinevva के CTO और को-फाउंडर

यहाँ नए हैं? सीरीज़ गाइड देखिए। यह बताती है कि spike क्या होता है और सारे भागों के लिंक देती है।

Spike 10 से पहले हमारे दिमाग़ में मॉडल अब भी यही था कि "बड़ी दुनिया का मतलब ज़्यादा geometry।" Spike 10 के बाद मॉडल बन गया "constant geometry budget, camera पर केंद्रित ring updates।" इस बदलाव ने प्रोजेक्ट की दिशा बदल दी।

Geometry clipmaps के पीछे का विचार सीधा है। आप terrain को camera पर केंद्रित concentric rings के एक सेट के रूप में render करते हैं। सबसे अंदरूनी ring में सबसे ज़्यादा vertex density होती है। बाहर की तरफ़ हर ring $k$ vertex spacing को दोगुना कर देती है, $s_k=s_0\cdot 2^k$, इसलिए वह अपने अंदरूनी ring से $4\times$ ज़मीन के इलाक़े को कवर करती है।

यही दोगुना करना पूरा खेल है। View distance rings की संख्या के साथ geometrically बढ़ती है, $d_{\text{view}}\approx s_0\cdot 2^L$, जबकि vertex की cost सिर्फ़ linearly बढ़ती है:

जहाँ $L$ rings हैं और हर एक में $N\times N$ vertices हैं। आप जितनी दूर देख सकते हैं उसे दोगुना करने की कीमत एक और ring है, geometry का चार गुना नहीं। Triangle count दुनिया के आकार चाहे जो हो, लगभग constant रहता है, क्योंकि आप हमेशा वही $L$ rings उसी resolution पर render करते हैं।

Spike 10 को नए tab में खोलें ↗ · सोर्स देखें

असली काम का तरीक़ा ring boundaries पर geomorphing था। जब कोई vertex एक LOD ring से अगले में जाता है, तो उसकी height को high-res और low-res sample के बीच smoothly blend होना ज़रूरी है। इसके बिना, जब भी camera हिलती है और rings खिसकती हैं, आपको हर बार दिखने वाले pops मिलते हैं। हमने इसे vertex की ring edge से दूरी पर आधारित एक blend factor से संभाला, और vertex shader में height को interpolate किया:

जहाँ $d$ camera से vertex की दूरी है। ring के अंदर ($d\le d_{\text{near}}$) vertex अपनी पूरी-resolution height इस्तेमाल करता है; जब तक यह अगली ring तक पहुँचता है ($d\ge d_{\text{far}}$) तब तक यह उस coarse height पर पहुँच चुका होता है जिसे वह ring इस्तेमाल करेगी, इसलिए pop होने को कुछ बचता ही नहीं।

एक बारीक सबक़ camera movement testing से आया। Static screenshots में clipmaps को परखना आसान है और transition artifacts से चूक जाना भी। हमने ring boundaries के आर-पार constant-speed traversals चलाने और temporal noise पर नज़र रखने में समय लगाया। Screenshots ने झूठ बोला। Motion ने सच बताया।

इस spike ने हमें एक साफ़ architectural boundary भी दी। Near-field terrain समय के साथ dynamic और महँगा बन सकता था, volumetric editing, ज़्यादा material complexity, और physics interaction के साथ। Far-field terrain stable, अंदाज़ा लगाने लायक़, और सस्ता रह सकता था। वह अलगाव इस बिंदु से आगे के हर architectural फ़ैसले की रीढ़ बन गया।

अगर आप अपने प्रोजेक्ट के लिए clipmaps को परख रहे हैं, तो stress loops test कीजिए, beauty shots नहीं। लंबे traversal paths, बदलती camera altitude, और बार-बार boundary crossings ही असली समस्याओं को उजागर करते हैं।

भाग 7 में हम volumetric meshing जोड़ते हैं और "terrain एक surface के रूप में" से "terrain एक editable volume के रूप में" की ओर बढ़ते हैं। यही वह बिंदु था जहाँ यह प्रोजेक्ट एक renderer होना बंद हुआ और एक world editor बनना शुरू हुआ।

इस अध्याय में बताई गई technology

Geometry clipmaps. Losasso और Hoppe ने SIGGRAPH 2004 में पेश की (paper), geometry clipmaps terrain को camera पर केंद्रित concentric square rings के रूप में render करती हैं। हर ring पिछली से दोगुने इलाक़े की होती है, आधी vertex resolution पर। कुल vertex count constant होता है: लगभग $N^2\cdot L$। $N=256$ और $L=8$ levels के साथ, यह ${256}^2\times 8\approx \mathrm{524,000}$ vertices है, दुनिया का आकार चाहे जो हो। camera हिलने पर CPU हर ring के लिए heightmap data update करता है। vertex shader एक texture से height पढ़ता है और flat grid को displace करता है। हमारी geometry clipmaps पर landscape गाइड और GPU Gems 2, Chapter 2 देखिए।

Geomorphing. Terrain LOD में सबसे बड़ा visual artifact popping है: जब कोई patch LOD level बदलता है तो vertices अचानक कूद जाते हैं। Geomorphing इसे एक transition zone के दौरान LOD levels के बीच vertex positions को blend करके ख़त्म कर देता है। हर vertex अपनी current-LOD height और अपनी coarser-LOD height, दोनों स्टोर करता है। camera की दूरी पर आधारित एक morph factor उनके बीच smoothly interpolate करता है: morphedHeight = mix(fineLodHeight, coarseLodHeight, smoothstep(lodNear, lodFar, distance))। transition zone आम तौर पर हर ring का बाहरी 20% होता है। सामान्य camera speeds पर, transition अदृश्य रहता है। geomorphing की बारीकियाँ देखिए।

CDLOD (Quadtree-Adaptive Clipmaps). Strugar (2014, paper) द्वारा fixed-ring clipmaps में एक सुधार। एक समान resolution वाली concentric rings के बजाय, CDLOD एक quadtree इस्तेमाल करता है जो terrain की complexity के मुताबिक़ ढल जाता है। समतल इलाक़े coarse nodes इस्तेमाल करते हैं, जबकि ज़्यादा detail वाले इलाक़ों (cliffs, ridges) को बारीक subdivision मिलता है। यह creator worlds के लिए मायने रखता है जहाँ अलग-अलग chunks की complexity बहुत अलग होती है। हमारी landscape गाइड में CDLOD देखिए।

12 में से भाग 6।
पिछला: भाग 5 - सुंदर चीज़ों का बजट बनाना
अगला: भाग 7 - Marching cubes और पहली असली गुफाएँ
सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? series guide का इस्तेमाल करें। यह बताती है कि spike क्या होता है और सभी भागों को जोड़ती है।

Heightmaps तब तक बढ़िया हैं जब तक आपको overhangs की ज़रूरत नहीं पड़ती।

जिस पल आप कटे हुए tunnels, हवा में लटकते चट्टान के किनारे, या गुफा की छतें चाहते हैं, एक शुद्ध heightfield pipeline आपको रोकने लगती है। एक heightmap हर XZ coordinate के लिए सिर्फ एक Y value रखता है। यह physically किसी भी ऐसी surface को दिखाने में असमर्थ है जो खुद के ऊपर मुड़ती हो। हमें एक volumetric representation की ज़रूरत थी।

Spike 12 ने WebGPU compute shaders का इस्तेमाल करके GPU पर marching cubes लागू किया। यह algorithm एक 3D grid पर signed distance field (SDF) का मूल्यांकन करता है और zero-crossing surface पर एक triangle mesh निकालता है। हर cell के 8 corners होते हैं, हर corner या तो surface के अंदर होता है या बाहर, जिससे $2^8=256$ संभव sign patterns बनते हैं। एक lookup table हर pattern को triangles के एक set से जोड़ता है। Vertices cell के edges पर उस बिंदु पर बैठते हैं जहां field zero को पार करती है। corners $a$ और $b$ के बीच के एक edge के लिए जिनके field values $f_a$ और $f_b$ हैं, linear interpolation vertex को यहां रखता है

जो edge के साथ वह fraction है जहां field zero पर पहुंचती है। चूंकि एक crossing edge पर $f_a$ और $f_b$ के opposite signs होते हैं, $t$ हमेशा $[0,1]$ में आता है। हमने इसे एक साथ चार active 64-cubed chunks पर चलाया और per-frame remesh के साथ animated SDF edits का परीक्षण किया।

Spike 12 को एक नए tab में खोलें ↗ · Source देखें

पहली जीत खुद compute pipeline पर भरोसा थी। एक ही dispatch बिना किसी CPU readback के SDF का मूल्यांकन कर सकता था, cells को classify कर सकता था, और vertices को एक GPU buffer में emit कर सकता था। दूसरी जीत यह पता चलना थी कि "यह काम करता है" कितनी जल्दी artifact hunting में बदल जाता है। गायब triangles शायद ही कभी marching cubes की theory की समस्या होते थे। वे table index के mismatches थे, गलत draw ranges जो active vertex count से आगे पढ़ रहे थे, या chunk boundaries के पास edge-case interactions थे जहां पड़ोसी SDF samples उपलब्ध नहीं थे।

इस spike ने हमें zones में सोचने पर मजबूर किया। Camera के पास, आप volumetric आज़ादी चाहते हैं ताकि players carve कर सकें, खुदाई कर सकें और गुफाएं देख सकें। Camera से दूर, आप clipmap की efficiency चाहते हैं जहां एक flat heightmap सस्ता और पूरी तरह पर्याप्त होता है। यह duality उस architecture की रीढ़ बन गई जिसे हम Spike 13 से आगे लगातार बेहतर करते रहे।

मेरे पसंदीदा debugging पलों में से एक था edits चलते समय wireframe toggle। real time में topology को बनते और घुलते देखना quality के tradeoffs को तुरंत दिखा देता था। आप देख सकते थे कि vertex density कहां काफी ऊंची थी, कहां यह बहुत मोटी हो गई, और ठीक कहां LOD transitions को आगे चलकर cracks से बचने के लिए Transvoxel support की ज़रूरत पड़ेगी।

भाग 8 में हम integration की चुनौती को देखते हैं। raw compute-driven meshes और Three.js scene graph logic को एक स्थिर rendering pipeline में रखना उस isolated demo की तुलना में ज़्यादा मुश्किल था जितना लगा था।

इस अध्याय में बताई गई तकनीक

Marching cubes. एक 3D scalar field से triangle mesh निकालने का algorithm (Lorensen और Cline, 1987)। एक नियमित 3D grid में हर cell को उसके 8 corners पर field sample करके classify किया जाता है। sign pattern एक case index (0-255) बनाता है, और एक lookup table हर case को triangles के एक set से जोड़ता है। दो corners के बीच interpolate करके vertices को grid edges पर रखा जाता है। यह algorithm embarrassingly parallel है क्योंकि हर cell स्वतंत्र रूप से process होता है, जो इसे GPU compute के लिए आदर्श बनाता है। हमारी SDFs और marching cubes पर landscape guide देखें।

Signed Distance Fields (SDFs). एक volumetric representation जो 3D space में हर बिंदु पर सबसे पास की surface तक की signed distance रखती है। Positive values बाहर हैं, negative अंदर हैं, और zero-crossing surface है। SDFs किसी भी 3D shape को दिखा सकते हैं: गुफाएं, arches, overhangs, और हवा में लटकती geometry जिसे heightmaps नहीं दिखा सकते। Editing field पर natural set algebra है। Material जोड़ना (दो shapes का union) $d=min(d_1,d_2)$ है, हटाना (खुदाई) carve shape को negate करके $d=max(d_1,-d_2)$ है, और एक smooth blend एक soft minimum का इस्तेमाल करता है जैसे

जहां $k$ blend radius को नियंत्रित करता है। जैसे-जैसे $k\to 0$ होता है, यह वापस एक hard $min$ में सिमट जाता है। SDF terrain representation देखें।

WebGPU compute shaders. GPU programs जो general-purpose computation चलाते हैं, rasterization pipeline से बंधे नहीं होते। एक compute shader threads के workgroups dispatch करता है जो parallel में execute होते हैं। Marching cubes के लिए, हर thread एक grid cell process करता है: SDF sample करना, cell classify करना, triangulation देखना, edge vertices interpolate करना, और atomic counters का इस्तेमाल करके एक mesh buffer में append करना। किसी CPU readback की ज़रूरत नहीं होती क्योंकि output buffer सीधे rendering के लिए vertex data के रूप में इस्तेमाल होता है। Will Usher का webgpu-marching-cubes browser में real-time 256^3 grid processing दिखाता है। हमारी WebGPU-driven LOD पर landscape guide देखें।

Hybrid heightmap + SDF architecture. Browser terrain के लिए व्यावहारिक तरीका: heightmaps पूरी दुनिया को ढकते हैं (सस्ते, compact), जबकि SDF volumes सिर्फ उन chunks में मौजूद होते हैं जिन्हें गुफाओं, overhangs, या creator-carved features की ज़रूरत होती है (5-10% chunks)। Camera के पास, volumetric आज़ादी carving और गुफाओं की अनुमति देती है। दूर, heightmaps efficient flat terrain देते हैं। hybrid terrain representation देखें।

भाग 7, कुल 12 में से।
पिछला: भाग 6 - Clipmaps ने कहानी बदल दी
अगला: भाग 8 - अपना baseline खोए बिना integration
Series guide: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? series guide का इस्तेमाल करें। यह बताती है कि spike क्या होता है और सभी भागों को जोड़ती है।

Integration वही जगह है जहां projects उलझ जाते हैं। आपके पास अलग-अलग चलते हुए हिस्से होते हैं। आप उन्हें जोड़ते हैं और अचानक हर bug ऐसा लगता है जैसे वह कहीं भी हो सकता है।

Spikes 13 और 14 इसी जाल का हमारा जवाब थे। Spike 13 ने एक साफ Three.js WebGPU baseline तैयार की। बस एक renderer, एक scene, एक camera, और एक सरल mesh। न terrain, न compute, न effects। हमने पक्का किया कि Three.js का WebGPU backend सही तरह से initialize हुआ, कि render loop स्थिर था, और कि TSL (Three.js Shading Language) node materials उम्मीद के मुताबिक काम कर रहे थे। यह checkpoint पास होने के बाद ही हमने layers जोड़ना शुरू किया।

Spike 13 को नए tab में खोलें ↗ · Source देखें

Spike 14 क्रमिक रूप से मज़बूत करने का काम था। हमने एक बार में एक क्षमता जोड़ी: पहले camera controls, फिर lighting, फिर marching cubes pipeline से आया compute-generated mesh, फिर buffer plumbing ताकि GPU output सीधे Three.js geometry attributes में जाए। हर जोड़ के बाद हमने पक्का किया कि पिछली layer अब भी सही तरह से काम कर रही है।

Spike 14 को नए tab में खोलें ↗ · Source देखें

यह सुनने में धीमा लगता है। यह ठीक एक दिन के लिए धीमा था, और इसने हमें थोड़ी देर बाद कई दिन बचाए जब seam logic और policy switching जटिल हो गए।

जिस खास तरह के bug ने इस discipline को सही ठहराया वह था hairline artifacts। पतली-पतली परतें जो geometry corruption जैसी दिखती थीं पर असल में पुराना data थीं। Compute shader एक buffer में N vertices लिखता, लेकिन draw call अब भी पिछले frame के N+M vertices render करने के लिए सेट रहता। वे अतिरिक्त vertices पुराने dispatch का कूड़ा रखते थे। दिखने में नतीजा था झिलमिलाते रेज़र-पतले triangles जो बेतरतीब ढंग से आते और गायब होते थे।

इस तरह के bug को आप intuition से नहीं हराते। आप इसे controlled deltas से हराते हैं जहां आपको ठीक-ठीक पता होता है कि आखिरी चलते हुए state और मौजूदा टूटे हुए state के बीच क्या बदला।

WebGPU integration ने हमें buffer lifecycle के बारे में भी सिखाया। WebGPU में GPU buffers एक बार किसी खास usage के लिए map हो जाने पर immutable होते हैं। अगर marching cubes output बढ़ने की वजह से आपको vertex buffer का आकार बदलना हो, तो आपको एक नया buffer बनाना होता है और binding को update करना होता है। यहां कोई realloc नहीं है। उस lifecycle को सही करना, यानी in-flight GPU काम से टकराए बिना पुराने buffers को नष्ट करना, ऐसे explicit fence management की मांग करता था जो WebGL में मौजूद नहीं है।

भाग 9 में हम Transvoxel seam के काम में उतरते हैं। वह chapter जानबूझकर एक scaffold से शुरू होता है। इस मुकाम तक आते-आते हमने यह सबक पूरी तरह अपना लिया था कि integration में जल्दबाज़ी रहस्य पैदा करती है, और सोच-समझकर किया गया setup ऐसे problems पैदा करता है जिन्हें debug किया जा सके।

इस chapter में बताई गई technology

WebGPU. WebGL का उत्तराधिकारी, जो browser में compute shaders और indirect rendering के साथ low-level GPU access देता है। Open worlds के लिए WebGPU की दो अहम खूबियां: compute shaders GPU की तरफ terrain generation, foliage placement, और culling को मुमकिन बनाते हैं; indirect rendering GPU को compute output के आधार पर तय करने देता है कि क्या draw करना है, जिससे घने scenes में CPU की अड़चनें खत्म हो जाती हैं। Desktop पर Chrome, Edge, और Firefox में उपलब्ध है। देखें WebGPU performance की बढ़त के तौर पर।

Three.js Shading Language (TSL). Three.js का node-आधारित shader system जो कच्चे GLSL/WGSL की जगह composable JavaScript expressions लाता है। texture(), positionWorld, smoothstep(), और fog() जैसे TSL nodes runtime पर एक shader graph बनाते हैं जो उपयुक्त backend (WebGL GLSL या WebGPU WGSL) में compile होता है। TSL की वजह से material logic एक बार लिखकर दोनों renderers के लिए चलाना मुमकिन है। Node graph हर frame पर evaluate होता है, इसलिए dynamic uniforms और conditional branching सहज रूप से काम करते हैं।

WebGPU में GPU buffer lifecycle. WebGPU buffers खास usage flags (VERTEX, STORAGE, COPY_DST, आदि) के साथ बनते हैं और बनने के बाद इनका आकार नहीं बदला जा सकता। अगर कोई marching cubes dispatch buffer की क्षमता से ज़्यादा vertices पैदा करता है, तो आपको एक नया buffer बनाना होगा, binding update करना होगा, और पुराने को नष्ट करना होगा। ऐसा buffer नष्ट करना जिसका अब भी किसी in-flight GPU command में reference है, errors पैदा करता है। Explicit fence management (device.queue.onSubmittedWorkDone() के ज़रिए) यह पक्का करता है कि पुराना buffer तब तक नष्ट न हो जब तक GPU उसका इस्तेमाल पूरा न कर ले। यह lifecycle discipline WebGL में मौजूद नहीं है, जहां driver memory को अपने आप संभालता है।

Incremental hardening. Integration के लिए एक process discipline: एक known-good baseline तैयार करो, एक बार में एक क्षमता जोड़ो, और हर जोड़ के बाद पक्का करो कि पिछली layer अब भी काम कर रही है। यह तरीका एक दिन के लिए धीमा होता है और बाद की debugging में कई दिन बचाता है क्योंकि हर regression को एक खास, controlled बदलाव तक ढूंढा जा सकता है। यह baseline-फिर-increment pattern AAA open world development में आम है जहां risk संभालने के लिए systems को एक खास क्रम में integrate किया जाता है।

12 में से भाग 8।
पिछला: भाग 7 - Marching cubes और पहली असली caves
अगला: भाग 9 - Transvoxel एक scaffold से शुरू हुआ
Series guide: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? series guide का इस्तेमाल करें। यह बताती है कि spike क्या होता है और सभी भागों को जोड़ती है।

Seams वही जगह हैं जहां आपका भरोसा दम तोड़ देता है।

जब तक दो resolutions नहीं मिलतीं, तब तक सब कुछ स्थिर दिख सकता है। LOD 0 का एक chunk LOD 1 के chunk के बगल में बैठता है। उनके meshes अलग-अलग generate होते हैं। जहां वे एक boundary साझा करते हैं, वहां vertex positions मेल नहीं खातीं क्योंकि कम-resolution वाले chunk में grid density आधी होती है। इसका नतीजा होता है दिखने वाली दरारें, T-junctions, और झिलमिलाते किनारे।

Transvoxel algorithm इसे दो अलग resolutions वाले chunks के बीच की boundary face पर खास transition cells generate करके हल करता है। ये cells high-res और low-res दोनों grids से एक साथ sample लेती हैं और ऐसे triangles बनाती हैं जो दोनों surfaces को आपस में जोड़ देते हैं। यह algorithm अपनी ही lookup tables इस्तेमाल करता है, जो सामान्य marching cubes tables से अलग होती हैं, और इसमें 512 transition cell cases होते हैं।

इस मुकाम तक हमारे पास इतने integration के घाव थे कि हम implementation में जल्दबाजी न करने की समझ रखते थे।

Spike 15 का एक ही काम था: पूरे algorithm को छूने से पहले एक ऐसा seam test rig बनाना जिस पर हम भरोसा कर सकें। हमने एक नियंत्रित माहौल तैयार किया जहां ज्ञात SDF data के दो chunks अलग-अलग resolutions पर अगल-बगल बैठे थे, और main mesh, seam mesh, wireframe, और normals को अलग-अलग toggle करने के लिए visualization controls थे।

Spike 15 को नए tab में खोलें ↗ · Source देखें

जब test rig स्थिर हो गया, तो Spike 16 ने एक ही face पर table-driven transition cell generation को validate किया। हमने एक axis-aligned face चुनी (+X boundary), सिर्फ़ उसी face के लिए transition cell evaluation को implement किया, और output की तुलना Transvoxel paper के reference data से की।

Spike 16 को नए tab में खोलें ↗ · Source देखें

हमने जानबूझकर एक बार में एक ही face टेस्ट की, क्योंकि transition table की wiring में कई स्वतंत्र failure modes होते हैं। Case index की गणना दोनों grids से सही vertices sample करने पर निर्भर करती है। एक transition cell के अंदर vertex indexing सामान्य marching cubes cells से अलग numbering scheme इस्तेमाल करती है। Winding order को main mesh के साथ एक जैसा रखना पड़ता है वरना backface culling आपके seam triangles को खा जाएगा। अगर आप एक साथ छहों faces टेस्ट करें, तो हर लक्षण random लगता है। अगर आप एक face को अच्छी तरह टेस्ट करें, तो आपको सार्थक और debug करने लायक failures मिलते हैं।

इस चरण की एक और सूक्ष्म जीत थी tooling में निवेश। हमने visibility toggles, seam-only rendering, और color-coded LOD indicators पहले ही बना लिए थे। उस समय ये controls फालतू बोझ जैसे लगते थे। बाद में, जब corner cases बिगड़े, तो इन्होंने बार-बार अपनी कीमत वसूल कर दी क्योंकि हम ठीक-ठीक अलग कर सकते थे कि कौन-सी seam cells गड़बड़ कर रही थीं।

इस अध्याय के अंत तक हम "seams से निपट चुके" नहीं थे। हम ऐसी स्थिति में थे जहां seam bugs से डरने के बजाय उन पर तर्क किया जा सकता था।

भाग 10 में असली roller coaster शुरू होती है। Mixed LOD corners, winding flips, partial overdraw ghosts, और वे पल जहां आप पक्का मान बैठते हैं कि algorithm गलत है और फिर पता चलता है कि bug दरअसल एक draw range है जो active vertex count से आगे पढ़ रहा था।

इस अध्याय में जिस technology का ज़िक्र हुआ

The Transvoxel algorithm. Eric Lengyel द्वारा डिज़ाइन किया गया (transvoxel.org), Transvoxel volumetric terrain LOD की सबसे कठिन समस्या को हल करता है: अलग-अलग resolutions वाले chunks के बीच seams। जब एक high-res chunk एक low-res chunk के बगल में बैठता है, तो marching cubes meshes boundary पर align नहीं होते, जिससे दिखने वाली दरारें बनती हैं। Transvoxel boundary faces पर खास transition cells डालता है जो resolution के अंतर को अतिरिक्त triangles से पाटते हैं, जो दोनों तरफ़ से मेल खाते हैं। यह algorithm अपनी ही lookup tables इस्तेमाल करता है (सामान्य marching cubes से अलग) जिनमें 512 transition cell cases होते हैं, जो 73 equivalence classes में सिमट जाते हैं। यह patent-free है और इसका इस्तेमाल रिलीज़ हुई games में हुआ है (Space Engineers, Astroneer)। हमारी Transvoxel पर landscape guide देखें।

Transition cells. दो LOD levels के बीच की face पर generate होने वाली खास cells। सामान्य marching cubes cells के उलट, जो एक grid से 8 corners sample करती हैं, transition cells high-res और low-res दोनों grids से एक साथ sample लेती हैं। High-res face में $3\times 3=9$ sample points होते हैं, जबकि low-res face में $2\times 2=4$। यही 9 samples algorithm को इसके $2^9=512$ raw cases देते हैं, जो rotations और reflections को मोड़ देने पर 73 अलग triangulations में सिमट जाते हैं। Cell classification और triangulation समर्पित tables इस्तेमाल करती हैं जो दोनों resolutions के vertices को जोड़ने वाले triangles बनाती हैं। Vertex numbering scheme सामान्य MC cells से अलग है, जो implementation bugs का एक आम स्रोत है।

LOD transition seams. दो mesh resolutions के बीच की boundary जहां topology mismatch visual artifacts पैदा करता है। बिना stitching के, एक LOD 0 chunk (1m grid) एक LOD 1 chunk (2m grid) के बगल में T-junctions पैदा करता है: fine mesh में boundary पर ऐसे vertices होते हैं जिन्हें coarse mesh साझा नहीं करता, जिससे दरारें बनती हैं जहां से रोशनी छनकर आती है। Transvoxel, geomorphing, और skirt geometry इन seams को ठीक करने के तीन तरीके हैं। Volumetric terrain के लिए Transvoxel मानक समाधान है क्योंकि geomorphing सिर्फ़ heightmaps के लिए काम करता है। Volumetric terrain के लिए LOD देखें।

भाग 9, कुल 12 में से।
पिछला: भाग 8 - अपनी baseline खोए बिना integration
अगला: भाग 10 - Seam अफरातफरी और corner की boss fight
Series guide: /hi/blog/2026-02-25-open-world-browser-series-guide

लिखा है Oleg Sidorkin ने, जो Cinevva के CTO और Co-Founder हैं

यहाँ पहली बार आए हैं? series guide देखें। यह समझाता है कि spike क्या होता है और सभी भागों को link करता है।

अगर पहले के भाग व्यवस्थित से लगते थे, तो यह अध्याय combat जैसा लगा।

Spikes 17 से 22 हमारा corner-case वाला दौर था। Dual-LOD marching cubes, heightmap-to-MC boundary seams, mixed-resolution corner chunks जहाँ तीन या चार LOD levels मिलते हैं, GPU seam generation, और fallback mode का व्यवहार। हर spike किसी एक खास failure scenario को संभालता था जिससे हम टकरा चुके थे या जिसका हमें अंदेशा था।

Spike 17 ने dual marching cubes को दो LOD levels एक साथ active रखकर test किया। चुनौती यह थी कि एक ही chunk के neighbors अलग-अलग faces पर अलग-अलग resolutions पर हो सकते थे। Spike 16 का transition cell logic एक समय में एक face के लिए काम करता था, लेकिन जब एक chunk को कई faces पर transition cells चाहिए होती थीं, तो vertex buffer का प्रबंधन उलझ जाता था। हर face की transition cells को इस तरह generate और append करना पड़ता था कि बाकी की पर असर न पड़े।

Spike 19 को नई tab में खोलें ↗ · Source देखें

पहला बार-बार आने वाला खलनायक था winding order। कई बार हमें लगा कि हमारे पास topology की समस्याएँ हैं, फिर पता चला कि वे orientation की समस्याएँ थीं। Backface culling valid seam triangles को खा रहा था क्योंकि winding main mesh के मुकाबले उल्टा हो गया था। एक ही असली वजह, पर camera angle के हिसाब से अलग-अलग दिखने वाला लक्षण। हल यह था कि transition cell emission code में एक तय winding convention लागू की जाए और उसे double-sided material toggle से verify किया जाए।

दूसरा खलनायक था आंशिक सहीपन से पैदा हुआ झूठा भरोसा। एक seam किसी एक camera angle से perfect दिख सकता था और तब टूट जाता था जब LOD roles higher और lower resolution वाले chunks के बीच आपस में बदल जाते थे। Transition cell asymmetric होती है। यह high-res side और low-res side से अलग-अलग तरीके से sample लेती है। अगर किसी एक configuration के लिए "कौन सा side high-res है" वाला logic उल्टा हो जाए, तो आपको bug सिर्फ तभी दिखता है जब camera किसी खास position पर जाता है।

फिर आया हमारी सबसे पसंदीदा recoveries में से एक। हम heightmap tiles पर एक seam cutoff artifact का पीछा कर रहे थे और इल्ज़ाम transition logic पर लगा रहे थे। इस पर दो दिन फूँक दिए। असली दोषी था stale overdraw। पिछले frame की higher-resolution geometry अब भी buffer tail में जीवित थी, उस chunk के lower LOD पर downscale हो जाने के बाद भी। Draw range अब भी पुराने, बड़े vertex count पर सेट था। जैसे ही हमने draw range को compute shader के atomic counter से रिपोर्ट किए गए active vertex count तक clip किया, वह "रहस्यमयी seam issue" गायब हो गया।

यह एक बढ़िया याद दिलाने वाली बात थी कि rendering bugs अक्सर meshing bugs का भेस धर लेते हैं। Geometry पूरे समय सही थी। Draw call बस valid data के अंत के पार पढ़ रहा था।

Spike 22 तक हम hybrid fallback test कर रहे थे, जहाँ chunks खास परिस्थितियों में marching cubes से heightmap mode में switch हो सकते थे, जैसे जब chunk में कोई volumetric edits न हों और वह camera से काफ़ी दूर बैठा हो। इससे हमें एक all-or-nothing policy के मुकाबले ज़्यादा व्यावहारिक रास्ता मिला। पास के edited chunks volumetric आज़ादी के लिए MC इस्तेमाल करते हैं। दूर के unedited chunks efficiency के लिए heightmaps इस्तेमाल करते हैं।

Spike 22 को नई tab में खोलें ↗ · Source देखें

यह अध्याय roller coaster की वह तीखी ढलान था। निराश करने वाला और productive, दोनों एक साथ। अलग-अलग fixes में से कई छोटे थे, कभी-कभी एक ही line जो किसी comparison operator या offset को बदल देती थी। लेकिन उन fixes से जो समझ बनी कि LOD transitions, buffer management, और draw ranges आपस में कैसे interact करते हैं, वह बिलकुल छोटी नहीं थी।

भाग 11 में हम उस stabilization layer को देखते हैं जो इस अफरा-तफरी के बाद आई: policy-based chunk modes और reactive bug-fixing से explicit system rules की ओर बदलाव।

इस अध्याय में जिस technology का ज़िक्र हुआ

Dual-LOD marching cubes. Marching cubes को दो resolution levels पर एक साथ चलाना, जहाँ transition cells boundary को सिल देती हैं। चुनौती यह है कि एक ही chunk के neighbors अलग-अलग faces पर अलग-अलग resolutions पर हो सकते हैं, जिसके लिए हर face के लिए अलग transition cell generation चाहिए। हर face की transition cells vertex buffer में इस तरह append होती हैं कि बाकी की पर असर न पड़े। Atomic counters सभी faces में मिलाकर कुल active vertex count track करते हैं।

Winding order. हर triangle के अंदर vertex का क्रम तय करता है कि कौन सा side "front" face है। Backface culling के लिए एक तय winding (आमतौर पर बाहर से देखने पर counter-clockwise) ज़रूरी है। जब transition cells triangles emit करती हैं, तो winding को main mesh की convention से मेल खाना चाहिए। इसे उल्टा कर देने पर backface culling valid seam triangles को खा जाता है, जो कुछ camera angles से गायब surfaces जैसा दिखता है। एक आम debugging तकनीक है material पर side: THREE.DoubleSide को toggle करना, ताकि यह पुष्टि हो सके कि artifacts winding की समस्याएँ हैं या असली topology gaps।

Heightmap-to-MC fallback. एक hybrid chunk mode जहाँ दूर या unedited chunks heightmap terrain (सस्ता, सपाट surface) इस्तेमाल करते हैं जबकि पास के या edited chunks marching cubes (volumetric, caves को support करता है) इस्तेमाल करते हैं। Fallback का फ़ैसला camera से दूरी पर और इस पर निर्भर करता है कि chunk में SDF edits हैं या नहीं। एक heightmap chunk और एक MC chunk के बीच के seam को अपनी खुद की transition geometry चाहिए, Transvoxel जैसी ही, पर दो अलग representations को जोड़ती हुई न कि दो LOD levels को। देखें hybrid heightmap + volumetric overlays।

Draw range और atomic counters. GPU-driven mesh generation में, compute shader vertices को एक buffer में लिखता है और एक atomic counter बढ़ाता है ताकि track हो सके कि कितने vertices emit हुए। Draw call को इस counter को vertex count के तौर पर इस्तेमाल करना चाहिए, buffer capacity को नहीं। अगर draw range active count तक clip नहीं हुआ, तो पिछले frames के stale vertices (जो अब भी buffer tail में जीवित हैं) ghost geometry पैदा करते हैं: पतले sliver और झिलमिलाते triangles जो topology errors जैसे दिखते हैं पर असल में valid data के पार पढ़ने से बने rendering artifacts होते हैं।

12 में से भाग 10।
पिछला: भाग 9 - Transvoxel की शुरुआत एक scaffold से हुई
अगला: भाग 11 - Policy mode, hardcoded mode नहीं
Series guide: /hi/blog/2026-02-25-open-world-browser-series-guide

लेखक Oleg Sidorkin, Cinevva के CTO और सह-संस्थापक

यहां नए हैं? series guide का इस्तेमाल करें। यह बताती है कि spike क्या होता है और सभी भागों को जोड़ती है।

Seam की उथल-पुथल वाले भाग के बाद, हमें reacting बंद करके governing शुरू करनी थी।

Spike 23 ने ad-hoc behavior की जगह explicit policy rules रख दिए। Chunks अपने local state के मुताबिक जो मन में आए वो करने के बजाय, अब एक central policy system फैसले लेता था। इस chunk को कौन सा LOD level मिलेगा? यह heightmap के रूप में render होगा या marching cubes के रूप में? इसे transition cells की ज़रूरत है, और किन faces पर? जवाब एक policy function से आते थे जो camera से distance, edit history, और neighbor resolution states को परखता था।

Spike 23 को नए tab में खोलें ↗ · Source देखें

Distance-based LOD assignment camera के चारों ओर concentric rings का इस्तेमाल करती थी, जो clipmap concept जैसी ही है पर chunk grid पर लागू होती है। Ring 0 के chunks को full-resolution MC मिलता है। Ring 1 को half-resolution MC मिलता है। Ring 2 और उससे आगे को heightmap mode मिलता है। Adjacency constraint बेहद ज़रूरी था: किन्हीं दो पड़ोसी chunks के लिए हमें $|L_i-L_j|\le 1$ चाहिए। एक face के आर-पार resolution ratio $2^{|L_i-L_j|}$ होता है, और Transvoxel transition tables सिर्फ 2:1 case के लिए परिभाषित हैं ($|L_i-L_j|=1$)। 2 levels की छलांग के लिए 4:1 transition चाहिए होगा जिसे ये tables व्यक्त नहीं कर सकतीं, इसलिए policy lower-detail chunk को तब तक upgrade करने पर मजबूर करती है जब तक constraint पूरी न हो जाए।

HM/MC switching logic हर chunk के edit bitmap को जांचता था। अगर किसी chunk में कोई भी volumetric edits थीं (caves, tunnels, terrain sculpts), तो वह distance की परवाह किए बिना MC mode में ही रहता था। बिना edit वाले chunks काफी दूर चले जाने पर heightmap mode में आ सकते थे। इस hybrid approach ने हमें वहां volumetric freedom दी जहां वह मायने रखती थी और वहां efficiency दी जहां नहीं रखती थी।

यह spike बाहर से पहले के कुछ spikes के मुकाबले छोटा लगा। असल में यह development के लिए quality-of-life में एक बड़ा सुधार था।

जब आपका system यह बता सकता है कि किसी chunk ने mode क्यों बदला, तो आप अंदाज़ा लगाने में कम समय बिताते हैं। हमने color-coded overlays जोड़े: heightmap chunks के लिए हरा, MC chunks के लिए नीला, transition-active faces के लिए नारंगी। जब seam visibility के लिए dedicated render controls होते हैं, तो visual debugging की उलझन घट जाती है। जब draw ranges को policy system से मिले active vertex counts से साफ़ तौर पर जोड़ा जाता है, तो stale geometry ghosts आपकी दोपहर बर्बाद करना बंद कर देते हैं।

हमने इस spike में camera behavior को भी पूरी तरह बदल दिया। पहले के spikes में simple orbit controls थे जो screenshots के लिए ठीक थे पर bugs को reproduce करने के लिए बेकार थे। Spike 23 ने configurable speed, altitude lock toggle, और position readout के साथ WASD fly camera जोड़ा। यह छोटी बात लगती है। इसका मतलब था "मैंने उस ridge के पास कहीं एक bug देखा" और "bug position (142, 12, -67) पर northwest की ओर मुंह करके दिखता है" के बीच का फर्क।

इस भाग की सबसे अहम बात यह है कि policy ने complexity घटाई नहीं। उसने complexity को व्यवस्थित किया। edge cases की संख्या वही रही। पर अब हर edge case का एक नाम था, एक trigger condition थी, और code में एक जगह थी जहां आप breakpoint लगा सकते थे। यह एक अलग तरह की जीत है, और यही तय करता है कि कोई system विकसित होता रह सकता है या अपने ही बोझ तले बैठ जाता है।

Spike 23 के अंत तक, हमारे पास एक near-field behavior layer था जो इतना predictable था कि उसे interaction bugs के लगातार डर के बिना far-field clipmap ring strategy से जोड़ा जा सके।

भाग 12 में हम Spike 24 को देखेंगे, जहां ring transitions, skybox fog, और Three.js version-level shader integration project के इस अध्याय को समाप्त करते हैं।

इस अध्याय में संदर्भित technology

Distance-based LOD policy. एक central function जो हर chunk को camera से distance, edit history, और neighbor states के आधार पर LOD level और rendering mode देती है। Concentric distance rings base LOD तय करते हैं: ring 0 = full-res MC, ring 1 = half-res MC, ring 2+ = heightmap mode। जैसे-जैसे camera हिलता है, policy function हर frame चलती है और chunk transitions को trigger करती है। यह ad-hoc per-chunk फैसलों की जगह एक predictable, debuggable rule system रख देती है। compute shader के समकक्ष के लिए GPU-driven LOD selection देखें।

Adjacency constraints. Transvoxel algorithm सिर्फ 2:1 resolution ratios संभालता है। अगर दो पड़ोसी chunks एक LOD level से ज़्यादा का फर्क रखते हैं (जैसे LOD 0 के बगल में LOD 2), तो transition tables valid seam geometry नहीं बना सकतीं। Policy system इसे तब लागू करता है जब LOD फर्क 1 से ज़्यादा हो जाने पर lower-detail chunk को upgrade कर देता है। यह constraint propagation cascade कर सकता है: एक chunk को upgrade करने से उसके पड़ोसियों को भी upgrade करना पड़ सकता है। Implementation एक simple iterative pass है जो typical grid configurations के लिए 2-3 iterations में converge हो जाता है।

Mode selection के लिए edit bitmap. हर chunk एक bitmap रखता है जो दर्ज करता है कि उसमें volumetric SDF edits (caves, tunnels, sculpts) हैं या नहीं। किसी भी edit वाले chunks distance की परवाह किए बिना marching cubes mode में रहते हैं, जिससे creator के बदलाव सुरक्षित रहते हैं। बिना edit वाले chunks camera से काफी दूर होने पर heightmap mode में आ जाते हैं, जिससे compute और memory बचती है। Bitmap हर chunk के लिए एक ही flag है पर इसे edit density track करने के लिए बढ़ाया जा सकता है ताकि mode के और बारीक फैसले लिए जा सकें।

Debug visualization overlays. Color-coded chunk rendering जहां हरा = heightmap mode, नीला = MC mode, नारंगी = transition-active faces। LOD level numbers, mode labels, और wireframe toggles के साथ per-chunk overlays। ये development tools हैं, shipped features नहीं, पर LOD transitions और seam artifacts को debug करते समय ये बार-बार अपनी कीमत वसूल कर लेते हैं। exact world position बताने वाले WASD fly camera के साथ मिलकर ये "मैंने कहीं एक bug देखा" को "bug (142, 12, -67) पर इस LOD configuration के साथ दिखता है" में बदल देते हैं।

भाग 11, कुल 12 में से।
पिछला: भाग 10 - Seam की उथल-पुथल और corner का बॉस फाइट
अगला: भाग 12 - Rings, sky fog, और हम फिर से क्या करेंगे
Series guide: /hi/blog/2026-02-25-open-world-browser-series-guide

लिखा है Oleg Sidorkin ने, Cinevva के CTO और को-फाउंडर

यहाँ नए हैं? सीरीज़ गाइड देखिए। यह बताती है कि spike क्या होता है और सारे भागों के लिंक देती है।

Spike 24 को बस "terrain में clipmap rings जोड़ना" होना था। यह एक पूरा finale बन गया जिसने rendering, shaders, module infrastructure, और visual integration सबको एक साथ छुआ।

Core terrain task vertex shader में concentric clipmap rings generate करना था। हर ring एक flat grid mesh है जो camera पर centered है, और जिसके vertices heightmap samples से displace होते हैं। Inner ring full resolution इस्तेमाल करता है। हर अगला ring vertex spacing को दोगुना करता है और बड़े area को cover करता है। मुश्किल हिस्सा rings के बीच की boundary है: जहाँ एक high-resolution ring एक low-resolution ring से मिलता है, वहाँ finer mesh के edge vertices को coarser mesh के edge के midpoint पर snap करना पड़ता है। हमने 2:1 edge morphing किया, जिसमें boundary vertices (वे जिनका grid coordinate ring edge के साथ odd होता है) को detect करके उनकी height को उनके दो even neighbors के midpoint पर snap किया, $h=\frac{1}{2}(h_{\text{left}}+h_{\text{right}})$। यह ठीक वही point है जहाँ coarse ring का single edge बैठेगा, इसलिए fine और coarse edges एक ही line describe करते हैं। इससे transition geometry के बिना watertight seams बनते हैं।

Spike 24 को नए tab में खोलें ↗ · Source देखें

फिर आया fog और sky integration। हम चाहते थे कि दूर का terrain असली sky color में fade हो, किसी flat constant में नहीं। इसका मतलब था कि fog shader को पता होना चाहिए कि हर fragment की direction में sky किस color का होगा। हमने एक equirectangular HDR skybox texture load किया और इसे fragment shader में camera से fragment तक की view direction से sample किया, जिसे TSL के equirectUV node के ज़रिये equirectangular UV coordinates में convert किया। Fog factor distance-based था, जो camera-space depth के लिए positionView.z.negate() इस्तेमाल करता था, और एक near और far distance के बीच smoothstep से blend होता था।

Module wiring किसी भी geometry से ज़्यादा परेशान करने वाला निकला। हमने Three.js 0.183.1 में upgrade किया, जिसने build outputs को restructure कर दिया। three/tsl import को three.tsl.js पर resolve होना था, और TSL internally three/webgpu को एक bare specifier के तौर पर import करता था। दोनों mappings को HTML import map में explicit होना पड़ा। इनमें से एक भी छूटने पर "does not provide an export" या "failed to resolve module specifier" जैसी cryptic errors आती थीं, जिनमें यह कोई संकेत नहीं होता था कि कौन सी mapping गलत है। एक बार दोनों import map में आ जाने पर, shader graph सही से load हो गया।

हमें एक skybox orientation issue भी था जहाँ texture उल्टा render हो रहा था। इसका fix था equirectangular texture पर flipY = true, जो loaded textures के लिए Three.js का default है पर हमारे शुरुआती code में false set था।

मूल fog implementation sky को एक लगभग-constant direction पर sample करता था, जिससे natural gradient की जगह एक पतली horizon-color वाली पट्टी बनती थी। इसका fix था per pixel असली camera-to-fragment world direction compute करना, positionWorld.sub(cameraPosition).normalize() से, और उसे fog color lookup के लिए equirectUV में pass करना। इससे terrain fragments उस sky color में fade होने लगे जो असल में उनके पीछे है, और यह किसी भी camera angle से सही दिखता है।

इन सारे individual fixes के नीचे, core outcome बना रहा। अब हमारे पास एक terrain system है जो near-field volumetric editing (Transvoxel seams के साथ marching cubes), mid-field heightmap chunks, और far-field clipmap rings को मिलाता है, और इन सबको एक policy layer govern करती है जो mode, LOD, और transition behavior तय करती है।

अगर मुझे उन patterns के नाम बताने हों जो मैं अगले project में दोहराऊँगा, तो ये होंगे:

Feature work से पहले risk spikes से शुरू करें। Spike 1 ने "क्या हम इतनी तेज़ render भी कर सकते हैं" वाले सवाल को content pipelines में invest करने से पहले ही खत्म कर दिया।

Integration jumps से पहले known-good baselines को freeze करें। Spikes 13 और 14 ने regressions bisect करने के हमारे कई दिन बचाए।

Optimization marathons से पहले policy और observability को force करें। Spike 23 ने mystery bugs को trigger rules वाली named conditions में बदल दिया।

Screenshots नहीं, motion के तहत test करें। Clipmap pops, seam flicker, और streaming hitches सब still frames में छुप जाते हैं।

Average FPS नहीं, हर feature की frame-time cost measure करें। Averages उन spikes को छुपा देते हैं जो users असल में महसूस करते हैं।

और बेतरतीब हिस्से publish करें। गलत मोड़, stale-buffer ghost hunts, वे दो दिन जब draw range गलत था और हम transition logic को दोष दे रहे थे। यही वे हिस्से हैं जिनसे लोग असल में सीख सकते हैं।

External reality check: Vuntra City devlogs

यह सीरीज़ खत्म करने के बाद, हमने अपनी open-world assumptions के against एक external implementation check के तौर पर @VuntraCity devlogs को review किया। यह एक native UE5 project है, browser stack नहीं, पर system patterns इतने अच्छे से map हो जाते हैं कि comparison काम का रहता है।

पहला signal यह है कि traversal speed को सिर्फ़ gameplay नहीं, बल्कि एक streaming control के तौर पर लेना होगा। Vuntra City में high-speed transit को जानबूझकर ज़्यादातर interiors के ऊपर से route किया जाता है, और detail range movement speed के साथ scale होता है ताकि spawn churn और stalls से बचा जा सके (transport system, performance techniques)। यह हमारी policy-layer direction से मेल खाता है: movement mode को chunk radius, interior activation, और per frame allowed work पर सीधे असर डालना चाहिए।

दूसरा signal architecture है। उनके maps और address system को world topology को rendered objects से अलग करना पड़ा ताकि unloaded regions के लिए भी global queries चल सकें (maps and addresses)। यह वही separation है जो हमें browser में world search, quest routing, moderation scans, और POI indexing के लिए चाहिए, render-bound data paths को force किए बिना।

तीसरा signal simulation tiering है। उनका million-NPC design coarse schedule state को सस्ता और global रखता है, और महँगा behavior budget सिर्फ़ player के पास खर्च करता है (million-NPC overview, system deep dive)। यह हमारे अपने AOI-first simulation model को मज़बूत करता है, जहाँ near-field fidelity और far-field determinism अलग-अलग concerns हैं जिनके budgets भी अलग हैं।

और चौथा signal design quality है, raw scale नहीं। उनके सबसे मज़बूत exploration moments constant UI overlays की जगह weighted distributions, rare outliers, और diegetic navigation clues से आते हैं (procedural environment notes, no minimap loop)। हमारे लिए यह एक याद दिलाने वाली बात है कि technical systems को सिर्फ़ maximal throughput के लिए नहीं, बल्कि discoverable variation पैदा करने के लिए tune करना चाहिए।

इस चैप्टर में referenced technology

Clipmap ring geometry. हर ring एक flat grid mesh है जो camera पर centered है और जिसके vertices heightmap samples से displace होते हैं। Inner ring full resolution इस्तेमाल करता है। हर अगला ring vertex spacing दोगुना करता है और बड़े area को cover करता है। मुश्किल हिस्सा boundary है: जहाँ एक high-res ring एक low-res ring से मिलता है, वहाँ finer mesh के edge vertices coarser mesh के edge के midpoint पर snap होते हैं। यह technique Losasso और Hoppe के SIGGRAPH 2004 paper (PDF) से आती है और GPU Gems 2, Chapter 2 में detail में बताई गई है। हमारी geometry clipmaps वाली landscape guide देखें।

2:1 edge morphing. दो clipmap rings के बीच की boundary पर, finer ring के पास उन positions पर vertices होते हैं जो coarser ring share नहीं करता। जिन boundary vertices का grid coordinate ring edge के साथ odd होता है उन्हें detect किया जाता है और उनकी height दो पड़ोसी even vertices के बीच interpolate की जाती है। इससे dedicated transition geometry के बिना watertight seams बनते हैं। Interpolation vertex shader में चलता है: boundary vertices के लिए morphedHeight = mix(heightLeft, heightRight, 0.5), और इसमें वही geomorphing framework इस्तेमाल होता है जो हमारी guide में बताया गया है।

Equirectangular skybox mapping. एक single 2D image जो longitude-latitude projection से sky directions के पूरे sphere को map करती है। Horizontal axis 0-360 degrees cover करती है, vertical axis 0-180 degrees। एक normalized view direction $\hat{d}=(d_x,d_y,d_z)$ अपने longitude और latitude को पढ़कर UV coordinates में convert होती है:

Three.js में, texture.mapping = EquirectangularReflectionMapping को SRGBColorSpace के साथ set करने से यह scene background के तौर पर enable हो जाता है। TSL में, equirectUV(direction) वही conversion apply करता है, और एक 3D view direction को texture sampling के लिए 2D UV coordinates में बदल देता है।

Per-fragment fog color from sky. Standard fog fragments को एक single constant color की तरफ़ blend करता है। एक detailed skybox वाले scene के लिए यह गलत दिखता है क्योंकि sky color direction के हिसाब से बदलता है। इसका fix है per pixel camera-to-fragment world direction compute करना (positionWorld.sub(cameraPosition).normalize()) और fog color के लिए skybox को उस direction पर sample करना। हर fragment उस sky color की तरफ़ fade होता है जो असल में उसके पीछे है, जिससे किसी भी camera angle से सही blending बनती है। Fog factor camera-space depth के लिए positionView.z.negate() के साथ smoothstep(nearDist, farDist, viewDepth) इस्तेमाल करता है।

Import maps for ES modules. एक browser-native mechanism (<script type="importmap">) जो bare module specifiers (जैसे three/tsl) को असली URLs पर map करता है। जब Three.js 0.183.1 ने अपने build outputs restructure किए, तो three/tsl को three.tsl.js पर resolve होना था और TSL internally three/webgpu को एक bare specifier के तौर पर import करता था। दोनों mappings को import map में explicit होना पड़ा, वरना browser "does not provide an export" या "failed to resolve module specifier" errors देता था।

आगे पढ़ें

इस सीरीज़ में इस्तेमाल हुई technologies की गहरी जानकारी के लिए, हमारी companion guides देखें:

• Landscape Generation with Dynamic LOD and Streaming for Browser Open Worlds heightmaps, SDFs, marching cubes, Transvoxel, geometry clipmaps, geomorphing, streaming architecture, terrain materials, और vegetation rendering को cover करती है।
• Browser 3D Open World Tech for Multiplayer Creator Worlds rendering stacks, WebGPU, physics, networking, multiplayer architecture, और Skyrim, The Witcher 3, Breath of the Wild, और GTA V से सीखे सबकों को cover करती है।

इस बारह-भाग वाली सवारी में हमारे साथ चलने के लिए शुक्रिया।

भाग 1: हमने इसे तोड़ने की कोशिश से शुरू किया
भाग 2: Worker physics और input lag का डर
भाग 3: वे unflashy spikes जिन्होंने हमें बचाया
भाग 4: Fancy terrain से पहले streaming
भाग 5: खूबसूरत चीज़ों का budget बनाना
भाग 6: Clipmaps ने कहानी बदल दी
भाग 7: Marching cubes और पहली असली caves
भाग 8: Baseline खोए बिना integration
भाग 9: Transvoxel एक scaffold से शुरू हुआ
भाग 10: Seam chaos और corner boss fight
भाग 11: Policy mode, hardcoded mode नहीं

भाग 12, कुल 14 में से।
पिछला: भाग 11 - Policy mode, hardcoded mode नहीं
अगला: भाग 13 - Terrain sculpting और math function की मौत
सीरीज़ गाइड: /hi/blog/2026-02-25-open-world-browser-series-guide

लिखा है Oleg Sidorkin ने, जो Cinevva के CTO और सह-संस्थापक हैं

यह पेज पूरी सीरीज़ का नेविगेशन हब है।

अगर आप किसी एक रैंडम भाग से यहाँ पहुँचे हैं, तो यहीं से शुरू करें।

मार्च 2026 अपडेट: हमने Part 12 में Vuntra City devlogs से एक बाहरी इम्प्लीमेंटेशन क्रॉस-चेक जोड़ा और उन्हीं निष्कर्षों के साथ साथी browser open world tech guide को बढ़ाया।

अप्रैल 2026 अपडेट: Parts 13-14 में terrain sculpting (Spikes 25-27) और visual/gameplay लेयर शामिल है: multi-material texturing, instanced vegetation, और HM+SDF collision वाला एक character controller (Spikes 28-30)।

मई 2026 अपडेट: सीरीज़ 29 भागों तक पहुँची। Parts 15-29 में build का लंबा बीच का हिस्सा शामिल है, multiplayer terrain और water, एक code-structure refactor, animations और AI scattering, imposters और parallax, वह visibility buffer जिसका फायदा नहीं हुआ, clouds और meshlet culling, batched avatars और proximity voice, world persistence और GPU wind, universal characters, water के तीन तरीके, एक procedural island, grass और occlusion, और एक pluggable character controller जो किसी भी body को चलाता है (Spikes 31-60)।

जून 2026 अपडेट: Part 30 में एक collision-aware camera जोड़ा गया, एक spring-arm boom जिसमें pluggable collider contract है और एक signed-distance probe जो view को overhangs और cave ceilings के सामने रोकती है, सिर्फ पहाड़ियों के सामने नहीं।

इस सीरीज़ में "spike" का क्या मतलब है

एक spike एक छोटा, केंद्रित प्रयोग है।

हर spike एक जोखिम भरे सवाल को टेस्ट करता है। हम scope को कसा हुआ रखते हैं, जो मायने रखता है उसे मापते हैं, और तय करते हैं कि आगे क्या करना है। इसे एक सीखने का उपकरण समझें, कोई पॉलिश किया हुआ feature नहीं।

इस प्रोजेक्ट में, spikes ज़्यादातर /spikes/* के नीचे स्टैंडअलोन पेज हैं जिन्हें आप लाइव चला सकते हैं।

सीरीज़ को क्रम में पढ़ें

1. Part 1: We started by trying to break it
2. Part 2: Worker physics and the input lag fear
3. Part 3: The unflashy spikes that saved us
4. Part 4: Streaming before fancy terrain
5. Part 5: Budgeting the pretty stuff
6. Part 6: Clipmaps changed the plot
7. Part 7: Marching cubes and the first real caves
8. Part 8: Integration without losing our baseline
9. Part 9: Transvoxel started with a scaffold
10. Part 10: Seam chaos and the corner boss fight
11. Part 11: Policy mode, not hardcoded mode
12. Part 12: Rings, sky fog, and what we would do again
13. Part 13: Terrain sculpting and the death of the math function
14. Part 14: The world comes alive
15. Part 15: Replace the baseline, then sync it
16. Part 16: Structure for a world that keeps growing
17. Part 17: Animations that didn't need retargeting, and a live asset search
18. Part 18: A scatter brush that feels AI-placed
19. Part 19: The imposter that has to survive a forest
20. Part 20: Faking depth on a flat plane
21. Part 21: A faster renderer that wasn't faster
22. Part 22: Clouds you can light, and culling that has to be fed
23. Part 23: Fifty avatars and a voice in the room
24. Part 24: Saving a world, and wind you can see
25. Part 25: One skeleton, every outfit
26. Part 26: Three ways to make water
27. Part 27: An island from noise, ground that looks like ground
28. Part 28: Grass to the horizon, and ground that hides itself
29. Part 29: One controller, any body
30. Part 30: A camera that respects walls

लाइव spike मैप

अगर आप सीधे तकनीकी टाइमलाइन में क्लिक करके जाना चाहते हैं तो इनसे शुरू करें।

Spike 1 terrain और instancing · source
Spike 2 worker physics · source
Spike 3 Durable Object broadcast लोड टेस्ट एक सर्विस स्क्रिप्ट के रूप में चला, स्टैंडअलोन पेज के रूप में नहीं
Spike 4 mobile quality constraints, Spike 1 query param के ज़रिए टेस्ट किया गया
Spike 5 LLM behavior reliability, एक स्क्रिप्ट के रूप में चला, स्टैंडअलोन पेज के रूप में नहीं
Spike 6 chunk load और swap · source
Spike 7 density maps से vegetation · source
Spike 8 terrain material cost · source
Spike 9 cascaded shadows budget · source
Spike 10 clipmaps और geomorphing · source
Spike 11 heightmap chunk streaming · source
Spike 12 WebGPU marching cubes · source
Spike 13 WebGPU integration baseline · source
Spike 14 incremental hardening · source
Spike 15 seam scaffold · source
Spike 16 पहला Transvoxel face · source
Spike 17 dual MC LOD · source
Spike 18 heightmap seam · source
Spike 19 mixed-resolution corner · source
Spike 20 GPU corner seam · source
Spike 21 GPU MC corner seam · source
Spike 22 MC से HM fallback · source
Spike 23 policy-based chunk modes · source
Spike 24 clipmap rings और sky fog · source
Spike 25 sampled data पर heightmap brush · source
Spike 26 GPU compute के ज़रिए SDF brush · source
Spike 27 HM + MC + brush integration · source
Spike 28 multi-material texturing · source
Spike 29 vegetation और shader grass · source
Spike 30 terrain physics और character controller · source
Spike 31 multiplayer terrain sync · source
Spike 32 water और swimming · source
Spike 33 code structure refactor · source
Spike 34 in-world authoring · source
Spike 35 combat animations और retargeting · source
Spike 36 लाइव Poly Haven asset search · source
Spike 37 AI-assisted prop scattering · source
Spike 38 octahedral imposters · source
Spike 39 parallax occlusion mapping · source
Spike 40 visibility buffer renderer · source
Spike 41 एक forest में imposters · source
Spike 42 imposter flicker fix · source
Spike 43 atmosphere और volumetric clouds · source
Spike 44 meshlet Hi-Z culling · source
Spike 45 batched avatar skinning और network sync · source
Spike 46 proximity voice chat · source
Spike 47 server-authoritative world persistence · source
Spike 48 avatar rig integration, बाद के spikes ने shared code के रूप में दोबारा इस्तेमाल किया (कोई स्टैंडअलोन पेज नहीं)
Spike 49 props और foliage पर GPU wind · source
Spike 50 universal characters और wearables · source
Spike 51 screen-space reflection water · source
Spike 52 planar mirror water · source
Spike 53 production water library · source
Spike 54 procedural island generation · source
Spike 55 terrain shading और tiling breakup · source
Spike 56 GPU cross-quad grass · source
Spike 57 terrain occlusion culling · source
Spike 58 pluggable character controller · source
Spike 59 एक असली avatar के साथ controller · source
Spike 60 Synty polygon animations · source

Mariana Muntean द्वारा, Cinevva की CEO

हमने एक ऐसा game बनाया जहाँ आपका snake ही paddle है और bricks पलटवार करती हैं। यह web, mobile और PC पर ship हुआ। हम दो लोगों को इसमें लगभग तीन दिन लगे। बीच-बीच में काम किया, कोई crunch नहीं। और इसे खेलना सच में मज़ेदार है।

ध्यान देने लायक बात आखिरी वाली है।

वह मेल जो किसी ने माँगा नहीं था

Snake बढ़त और spatial awareness के बारे में है। Arkanoid reflexes और angle अंदाज़े के बारे में है। ये दोनों बिल्कुल अलग design सोच से आते हैं, और इन्हें आपस में मिलाने का ख्याल ऐसा pitch लगता है जिसे शिष्टता से ठुकरा दिया जाए।

लेकिन A Breaker Belt इसे चला देता है। आप एक cosmic serpent हैं, neon current का एक जीवित चाप, जो drift-metal कशेरुकाओं और comet silk से बुना है, और टूटने वाले blocks के एक asteroid field से गुज़रता है। आपका सिर paddle है। आपकी बढ़ती पूँछ ही आपका सबसे बड़ा हथियार है और सबसे लगातार बना रहने वाला ख़तरा भी। Orbs आपके शरीर से टकराकर bricks चकनाचूर करते हैं, पर अपनी ही पूँछ में एक गलत मोड़ और आपका खेल खत्म।

यह उस तरह का अजीब cross-genre प्रयोग है जो आमतौर पर किसी के खेलने से पहले ही दम तोड़ देता है, क्योंकि किसी अजीब idea के चलने की जाँच करने की development लागत परंपरागत रूप से महीनों में नापी जाती रही है। यहाँ यह दोपहरों में नापी गई।

असल में जो ship हुआ

scope ही इसे दिलचस्प बनाता है। यह placeholder rectangles और बिना sound वाला कोई game jam prototype नहीं है।

Game 50 waves गहरा चलता है। यह एक ही brick wall की 50 variations नहीं हैं। Formations हल्के onboarding arcs से बदलकर ऐसे fortress rings बन जाती हैं जो side gaps से angled shots माँगती हैं, फिर एक-tile चौड़े खुलाव वाली परतदार diagonal भूलभुलैयाँ बन जाती हैं जिनमें सटीक steering चाहिए। Explosive bricks अपने पड़ोसियों को उड़ा देती हैं। Phantom bricks आती-जाती झिलमिलाती हैं। Regenerating bricks तोड़ने के बाद फिर ठीक हो जाती हैं, जिससे आपको बाएँ से दाएँ साफ़ करने के बजाय targets को प्राथमिकता देनी पड़ती है। Portal bricks आपके orbs को arena के पार teleport कर देती हैं। Gravity wells आपके shots को धीमे, मुड़ते भजनों में मोड़ देते हैं। Laser emitters शून्य के पार लाल रेखाएँ खींचते हैं। Mimic bricks तब तक हानिरहित दिखती हैं जब तक वे तय न कर लें कि वे नहीं हैं। Wave 15 तक, आप किसी ऐसी चीज़ में चल रहे होते हैं जो किसी puzzle से कम और आपकी आदतें सीख रहे एक जीवित system से ज़्यादा लगती है।

Music कोई loop नहीं है। यह एक reactive soundtrack है जो आपके gameplay के साथ बनती जाती है। नीचे का system E minor में 140 BPM पर एक bass line, lead synth, pad, kick, snare और hi-hat चलाता है, और जैसे-जैसे action तेज़ होता है, अतिरिक्त percussion और synth layers fade in होती जाती हैं। Waves के बीच जब चीज़ें शांत होती हैं, ambient pads संभाल लेते हैं। Music आपके साथ साँस लेती है। एक समर्पित composer उस तरह की responsiveness को tune करने में हफ़्ते लगा देता। यहाँ यह creative flow का हिस्सा थी।

Sound effects किसी free pack से खींचे गए samples नहीं हैं। हर brick का चकनाचूर होना, power-up उठाना, orb का उछाल और टक्कर real time में synthesize होती है। सिर की टक्कर बनाम पूँछ की टक्कर के लिए अलग pitch। अंतरिक्षी एहसास के लिए गर्म reverb। चीज़ों को कठोर हुए बिना संतोषजनक रखने के लिए lowpass filtering। जब आप एक combo जोड़ते हैं, audio आपको screen से पहले बता देती है।

और फिर है storytelling। हर wave AI-generated आवाज़ में दिए गए एक narrative beat से खुलती है। लेखन में सच्चा व्यक्तित्व है। Wave one: "They call it the Breaker Belt: a ribbon of engineered debris that circles the old star like a warning." Wave 38 तक: "The Belt stops feeling like a wall and starts feeling like a mind. It tests not your reflexes, but your habits. You break the habit. The Belt notices." यह cosmic पुराणकथा के 50 अध्याय हैं जो आपको इस बात की परवाह करवाते हैं कि आप अंतरिक्ष में bricks तोड़ता एक snake क्यों हैं।

Backgrounds भी बदलते हैं। शुरुआती waves शांत indigo starfields हैं जिन पर हल्की meteor बारिश होती है। Mid-game तक, aurora bands और nebula बादल दिखने लगते हैं। Late game पूरा Ion Storm बन जाता है, लगभग काले अंतरिक्ष के सामने तीखी cyan धारियाँ। Wave 15 और उसके आगे, आप Event Horizon वाले इलाके में हैं: धीमे चलते nebula तंतुओं और मद्धम black hole lensing से बिंधा गहरा शून्य। Game अपनी प्रगति को difficulty जितना ही माहौल के ज़रिए भी बताता है।

यह सब keyboard, gamepad या touchscreen पर चलता है। एक ही codebase से web, mobile और PC पर publish किया गया। कोई अलग builds नहीं। कोई porting नहीं।

वह team जिसकी ज़रूरत नहीं पड़ी

यह वह हिस्सा है जिस पर किसी भी game developer को रुककर सोचना चाहिए।

इतनी content गहराई वाले game को आमतौर पर एक game designer, दो प्रोग्रामर, एक 2D artist, एक sound designer, एक music composer, एक level designer, एक narrative writer और QA चाहिए होता है। यह आठ या नौ लोग हुए। एक मध्यम indie रफ़्तार पर, आप तीन से छह महीने के समन्वित काम की बात कर रहे हैं। Standups, Jira tickets, asset pipelines, platform-specific debugging।

हम दो लोगों ने यह एक लंबे weekend में Cinevva Engine पर बनाया।

ज़रूरी प्रतिभा नहीं बदली। creative इरादे और implementation के बोझ के बीच का अनुपात बदला। समय इस बात पर तय करने में लगा कि game कैसा महसूस होना चाहिए, न कि उसे बनाने के लिए tools से जूझने में।

अगर आप चीज़ें बनाते हैं तो यह क्यों मायने रखता है

दिलचस्प सवाल यह नहीं है कि AI tools games को तेज़ी से बनाने में मदद कर सकते हैं या नहीं। इसका जवाब मिल चुका है। दिलचस्प सवाल यह है कि उन ideas का क्या होता है जिन्हें आज़माना पहले बहुत जोखिम भरा था।

"Snake पर आप ही Arkanoid arena में paddle हैं" ऐसी कोई चीज़ नहीं जिसे कोई producer हरी झंडी दे। कुछ indie devs ने itch.io पर इस मेल की variations आज़माई हैं (BreakSnake, SnakeOut, Snake Break), पर वे सब छोटे game jam प्रयोग हैं। इस genre fusion को reactive music, AI narration, दर्जनों brick types और बढ़ते level design की 50 waves के साथ कभी असली production में नहीं उतारा गया। परंपरागत development में, किसी जोखिम भरे concept पर उस तरह की चमक किसी के एक line कोड लिखने से पहले ही एक meeting में मार दी जाती है।

जब कुछ अजीब आज़माने में एक तिमाही के बजट के बजाय एक दोपहर लगती है, तब अजीब ideas बनते हैं। उनमें से कुछ सच में अच्छे निकलते हैं। A Breaker Belt उन्हीं में से एक है।

इसे खेलें। या अपना बनाएँ।

A Breaker Belt अभी web, mobile और PC पर खेलने योग्य है। अगर यह आपको कुछ बनाने का मन कराता है, तो Cinevva Engine मुफ़्त है। बताएँ कि आप क्या चाहते हैं, जो वापस आए उस पर iterate करें, तैयार होने पर ship करें। music, sound effects, art और 3D models सब built in हैं।

आपका अजीब game idea शायद बनने से सिर्फ़ तीन दिन दूर है।

A Breaker Belt खेलें | अपना game बनाएँ | community games देखें

संबंधित:

• Vibe coding नया game jam है — AI tools idea और prototype के बीच की दूरी कैसे मिटा देते हैं
• Game Jams और Hackathons — वह jam format जो अजीब मेल को मुमकिन बनाता है
• Web Game Engines की तुलना — web, mobile और PC पर ship करने के engines

Mariana Muntean द्वारा, Cinevva की CEO

Cinevva प्लेटफ़ॉर्म पर हमारे पास एक म्यूजिक जनरेटर है ताकि game creators लाइसेंसिंग की झंझट के बिना गेम साउंडट्रैक और SFX बना सकें। इसके बाद जो हुआ, उसकी हमने योजना नहीं बनाई थी। लोग म्यूजिक बनाने लगे क्योंकि वे म्यूजिक बनाना चाहते थे। गेम या प्रोजेक्ट के लिए नहीं। सिर्फ म्यूजिक प्रोडक्शन के लिए।

Bella Bay ने दो हफ़्तों में 100 से ज़्यादा ट्रैक बनाए

मैं बढ़ा-चढ़ाकर नहीं कह रही। हमारी एक creator, Bella Bay, ने करीब दो हफ़्तों में 100 से ज़्यादा ट्रैक बनाए। जब आप उन्हें Cinevva Radio पर सुनते हैं, तो आपको प्रगति सुनाई देती है। शुरुआती ट्रैक प्रयोग हैं। बाद वाले ऐसे लगते हैं जैसे किसी ने अपना अंदाज़ पा लिया हो। ऐसी रचनात्मक तेज़ी तब नहीं आती जब आप अपने टूल्स से जूझ रहे होते हैं। यह तब आती है जब टूल्स रास्ते से हट जाते हैं।

Bella Bay भावना के मामले में कोई अपवाद नहीं है, बस मात्रा के मामले में है। पूरे प्लेटफ़ॉर्म पर लोग म्यूजिक जनरेटर को गेम असेट्स के लिए एक उपयोगिता की तरह नहीं, बल्कि एक रचनात्मक वाद्य की तरह बरतने लगे। प्रोड्यूसर ऐसी विधाओं के साथ प्रयोग कर रहे हैं जो उन्होंने पहले कभी नहीं आज़माईं। लोग किसी आवाज़ पर तब तक काम करते रहे जब तक वह सही नहीं बैठ गई। ऐसे बेडरूम आर्टिस्ट जिनके पास कभी पूरा प्रोडक्शन टूलकिट नहीं था, उनके पास अचानक एक आ गया और वे पूरी तरह डूब गए।

तो हमने एक रेडियो बनाया

यह करना ही था।

हमारे पास ये सारे ट्रैक लोगों के अकाउंट में पड़े थे, बिना किसी साझा जगह के। दूसरे क्या बना रहे हैं, यह जानने का कोई तरीका नहीं था। किसी ऐसे ट्रैक से टकराने का कोई तरीका नहीं था जो आपकी दोपहर बदल दे।

Cinevva Radio अब लाइव है। आठ स्टेशन। 362 community-created ट्रैक और हर दिन बढ़ते जा रहे हैं। हर एक गाना प्लेटफ़ॉर्म पर किसी न किसी ने बनाया है। आप इसे खोलते हैं और कुछ बज रहा होता है। आपको खोजना नहीं पड़ता। आपको तय नहीं करना पड़ता। आप बस सुनते हैं।

Soundstage हमारा सबसे बड़ा स्टेशन है। सिनेमैटिक और एपिक स्कोर के 111 ट्रैक। सच कहूं तो मुझे इसका अंदाज़ा नहीं था। लोगों को नाटकीय, फिल्मी अंदाज़ का म्यूजिक बनाना बहुत पसंद है।

Discovery ने वह सब समेट लिया जो किसी एक विधा में ठीक से फिट नहीं बैठता। 78 ट्रैक। लैटिन बीट्स के बगल में Afrobeats, उसके बगल में country, और उसके बगल में कुछ ऐसा जिसे बयान करना मुश्किल है। यह स्टेशन बेहद रंगीन है।

Main Stage पॉप और वोकल ट्रैक हैं। पूरे बोल और वोकल्स के साथ 56 ट्रैक। लोग प्रेम गीत, ब्रेकअप गीत, भक्ति संगीत, और ग़ज़लनुमा गीत लिख रहे हैं। इनमें से कुछ वाकई कानों में बस जाने वाले हैं।

Voltage रॉक और मेटल है। 53 ट्रैक। गिटार रिफ़, पंक एनर्जी, grunge, हार्ड रॉक। काम करते वक़्त मैं इसे चलाए रखती हूं।

Lo-Fi Cafe बिल्कुल वैसा ही है जैसा नाम से लगता है। पढ़ाई, काम, या यूं ही माहौल बनाने के लिए 25 शांत ambient ट्रैक।

Electric Dreams में 22 इलेक्ट्रॉनिक और synth ट्रैक हैं। Synthwave, techno, EDM, drum and bass।

Ivory Tower क्लासिकल और ऑर्केस्ट्रल है। 10 ट्रैक। पियानो की रचनाएं, string अरेंजमेंट, सिम्फनी जैसा संगीत। छोटा है पर बढ़ रहा है।

The Cipher हिप-हॉप और रैप है। अब तक 7 ट्रैक। सबसे नया स्टेशन, अभी अपनी आवाज़ तलाश रहा है।

जब आप सुनते हैं तो आपको क्या दिखता है

जब आप Cinevva Radio खोलते हैं, तो यह एक लाइव स्ट्रीम है। इसे प्लेलिस्ट ऐप से कम और असल रेडियो स्टेशन से ज़्यादा मिलता-जुलता समझिए। ट्रैक लगातार बजते रहते हैं। आप रियल टाइम में प्रतिक्रिया दे सकते हैं, दूसरे श्रोताओं से चैट कर सकते हैं, और देख सकते हैं कि हर ट्रैक किसने बनाया।

ट्रैक बजते वक़्त creators को स्क्रीन पर श्रेय मिलता है। उनका नाम, उनका prompt, विधा। अगर आपको कुछ पसंद आता है, तो आपको पता होता है कि उसे किसने बनाया। यह community-created कंटेंट है जिसके ऊपर एक discovery परत है। कोई एल्गोरिदम तय नहीं करता कि क्या लायक है। कोई द्वारपाल नहीं। आपने एक ट्रैक बनाया, वह उस स्टेशन पर जाता है जो उसकी विधा से मेल खाता है, और लोग उसे सुनते हैं।

यह एक फीचर से कहीं बड़ी बात है

दशकों तक, म्यूजिक प्रोडक्शन के लिए महंगा सॉफ़्टवेयर, सालों की ट्रेनिंग, और ऐसे उपकरण चाहिए होते थे जिन्हें ज़्यादातर लोग खरीद नहीं सकते थे। हम जो देख रहे हैं वह एक अलग किस्म का creator है। ऐसे लोग जो नोट्स और टाइम सिग्नेचर के बजाय वर्णनों और भावनाओं में सोचते हैं।

"टूटे हुए पियानो के साथ बरसाती रात का jazz" एक रचनात्मक दिशा है। जिसने वह prompt लिखा, उसने एक कलात्मक चुनाव किया। उसने मूड, वाद्य-संयोजन, और भावनात्मक स्तर को दिशा दी। बस इतना है कि वह पियानो नहीं बजाता।

मुझे नहीं लगता कि इससे उनकी रचना कम मान्य हो जाती है। मुझे लगता है इसका मतलब है कि "संगीतकार" की परिभाषा फैल रही है। और Bella Bay जैसे किसी को दो हफ़्तों में शून्य से सौ ट्रैक तक पहुंचते देखना मुझे बताता है कि रचनात्मक प्रेरणा हमेशा से थी। बस टूल्स नहीं थे।

आगे क्या

हम community profiles पर काम कर रहे हैं जहां प्रोड्यूसर अपना कैटलॉग दिखा सकेंगे और एक फॉलोइंग बना सकेंगे। charts पेज पहले से ही सभी टूल्स में community की रचनाएं दिखाता है, और हम वही जोश ख़ास तौर पर म्यूजिक के लिए लाना चाहते हैं।

लेकिन अभी, रेडियो लाइव है। जाकर सुनिए। और अगर आप अपने ट्रैक बनाना चाहते हैं, तो म्यूजिक जनरेटर मुफ़्त इस्तेमाल के लिए है। हो सकता है आपका ट्रैक भी हवा में बजने लगे।

Cinevva Radio सुनें | म्यूजिक बनाएं | community की रचनाएं देखें

संबंधित:

• Frontier Open-Source Gen AI Models — पर्दे के पीछे काम करने वाले AI म्यूजिक और ऑडियो मॉडल
• गेम्स के लिए Web Audio API — browser में इंटरैक्टिव ऑडियो बनाना
• Vibe coding नया game jam है — कैसे इरादे का वर्णन करना प्राथमिक रचनात्मक इनपुट बन जाता है

लिखा है Mariana Muntean ने, Cinevva की CEO

AI ने मूल रूप से कच्चे logic और गणना करने की क्षमता को एक commodity बना दिया है। जिन हुनरों की हम पहले पूजा करते थे, mental math, pattern को पहचानना, जटिल algorithms को घिसते हुए हल करना, अब वह सब AI करता है। तेज़। बेहतर। बिना थके। क्या हमें अब भी यह जानना ज़रूरी है? बिलकुल, पर नज़रिया बदल जाता है। अब हर किसी को एक नए दौर के हिसाब से ढलना होगा - सहज interaction और नतीजों का दौर।

NVIDIA के CEO Jensen Huang के मुताबिक, अब जो चीज़ मायने रखती है वह है एक "vibe" को भाँप लेने की और data सामने आने से पहले ही मोड़ के पार देख लेने की क्षमता। technical समझ और गहरी empathy का मेल। वह सहज समझ जिसे silicon छू भी नहीं सकता।

उसकी जैसी साख रखने वाले किसी इंसान को मैंने पहले कभी ऐसी बात कहते नहीं सुना जो मेरी पूरी ज़िंदगी की राह को इतने सीधे तौर पर सही ठहरा दे।

SAT और वह सिस्टम जो मेरे लिए बना ही नहीं था

कुछ साल पहले मैंने SAT दी और फ़ेल हो गई। मुझे इस पर गर्व नहीं है, पर मैंने दोबारा कोशिश भी नहीं की। पूरी बात में कुछ बुनियादी तौर पर गलत लग रहा था, और लोग चाहे जितना कहें कि बस और मेहनत करो और दोबारा दे दो, मैं उस एहसास से पीछा नहीं छुड़ा पाई।

पीछे मुड़कर देखती हूँ तो लगता है मैं सही थी।

SAT अमेरिकी शिक्षा व्यवस्था के लिए बनाई गई है। यह बात ज़ाहिर सी लगती है, पर इसके असर बहुत गहरे हैं। अमेरिकी हाई स्कूल खास तरह के pattern, सवालों के प्रकार, और समस्याओं को रखने के तरीकों के हिसाब से पढ़ाते हैं। बच्चे प्राथमिक स्कूल से ही उसी अंदाज़ की standardized testing में पगे हुए बड़े होते हैं। जब तक वे SAT तक पहुँचते हैं, उन्होंने उस लय को अपने भीतर उतार लिया होता है।

International students के पास यह फ़ायदा नहीं होता। हम अलग शैक्षिक सोच वाली व्यवस्थाओं से आते हैं। यूरोपीय स्कूल अक्सर चौड़ाई से ज़्यादा गहराई पर, multiple choice से ज़्यादा निबंध-आधारित परीक्षा पर, bubble sheets से ज़्यादा मौखिक परीक्षा पर ज़ोर देते हैं। एशियाई व्यवस्थाओं की अपनी standardized tests हैं, पर वे अलग चीज़ों को अलग तरीकों से मापती हैं। दक्षिण अमेरिकी, अफ़्रीकी, मध्य पूर्वी शैक्षिक परंपराओं की हर एक की अपनी समझ है।

जब आप एक international student को SAT में डालते हैं, तो आप सिर्फ़ उसका ज्ञान नहीं जाँच रहे होते। आप यह जाँच रहे होते हैं कि वह एक पराई testing संस्कृति के साथ कितनी तेज़ी से ढल सकता है, और साथ-साथ विषय पर अपनी पकड़ भी दिखा सकता है। आप शैक्षिक क्षमता जितनी ही सांस्कृतिक रवानगी भी जाँच रहे होते हैं।

मुझसे उम्मीद की गई कि मैं एक गर्मी की छुट्टियों में इसकी तैयारी करूँ और इसमें छा जाऊँ। एक पूरी testing संस्कृति सीखूँ, अपनी ही शैक्षिक सहज समझ को भुला दूँ, और उस स्तर पर performance दूँ जो अमेरिकी admissions अधिकारियों को प्रभावित कर दे। और यह सब बस कुछ महीनों में।

मैंने ऐसा न करना चुना।

जब आप जवान होते हैं, तो आप अलग तरीकों से होशियार होते हैं। सहज तरीकों से। मैं अपने लिए एक राह बना रही थी, भले उस समय मैं ठीक-ठीक यह न बता पाती कि क्यों। मेरे भीतर कुछ जानता था कि यह सिस्टम मेरा नहीं है।

इसके बजाय रचनात्मक धागे का पीछा करना

मैंने game development और design पढ़ा क्योंकि मुझे यह विचार पसंद था कि creativity और visual effects का इस्तेमाल करके ऐसी virtual दुनियाएँ बनाई जाएँ जिनमें लोग खेल सकें और घुलमिल सकें। मुझे art और technology का, कहानी कहने और interactivity का मेल बहुत भाता था।

जो मैंने पाया उसने मुझे चौंका दिया।

Games के लिए गंभीर technical गहराई चाहिए। Physics simulations, collision detection, vector math, lighting calculations, optimization। यह मैं पहले से जानती थी। math और engineering game development में रुकावट नहीं हैं। वे उसी का हिस्सा हैं जो games को चलाती है।

समस्या रचनात्मक vision और उसे असल में बनाने के बीच की खाई थी। industry पर हावी engines और tools engineers ने engineers के लिए डिज़ाइन किए थे। सब कुछ "ifs" और "thens" और node-based blueprints पर चलता था। आपको एक vortex effect चाहिए? shader programming सीखो। कोई खास lighting वाला माहौल? material graphs में घुसो। ऐसी character movement जो सही महसूस हो? character controller या physics parameters को घंटों debug करो।

अगर आप एक visual इंसान हैं, अगर आप चटख रंगों और चलती तस्वीरों में सोचते हैं, अगर विचार आपके पास आवाज़, बनावट और भावनात्मक वज़न के साथ पूरे-पूरे दृश्यों की तरह आते हैं, तो उनमें से कुछ भी बनाने से पहले आपको यह सब technical भाषा में अनुवाद करना पड़ता था। आप अपने दिमाग में एक दुनिया देखते हैं, lighting और माहौल और किरदारों के अंतरिक्ष में चलने के तरीके समेत मुकम्मल। फिर आप अपने computer पर बैठते हैं और अगले छह घंटे यह debug करने में बिताते हैं कि आपका किरदार फ़र्श के पार नीचे क्यों गिर जाता है।

technical बुनियाद मायने रखती है। पर tools ने creators को उस जटिलता को अलग करने के बजाय implementation की बारीकियों में जीने पर मजबूर कर दिया। game बनाना एक कहानी कहने या ऐसी फ़िल्म डायरेक्ट करने जैसा लगना चाहिए जिसमें लोग हिस्सा ले सकें। यही इस माध्यम का जादू है। इसके बजाय यह ऐसा लगता था जैसे शुरुआत करने से पहले ही आपको एक engineering परीक्षा देनी हो।

फ़िल्म डायरेक्टर अपना vision व्यक्त करने से पहले बरसों physics engines सीखने में नहीं बिताते। उन्हें एक budget और एक टीम मिलती है जो technical अमल को संभालती है। पर indie game development में आपके पास शायद ही कभी budget होता है। आपके पास होता है वक़्त और tools तक पहुँच। और अगर आप technical इंसान हैं, तो आप एक ज़बरदस्त game बना सकते हैं। पर तभी अगर।

इसी तरह हमें Limbo जैसे titles मिले, जो एक छोटी टीम ने एक अकेले कलात्मक vision और उसे अमल में लाने की technical काबिलियत के साथ बनाया। या Undertale, जो काफ़ी हद तक एक ही इंसान ने बनाया जिसके पास संयोग से रचनात्मक सहज समझ और programming क्षमता का सही मेल था। या Stardew Valley, जहाँ Eric Barone ने pixel art से लेकर music composition और C# programming तक सब कुछ खुद को सिखाने में बरसों लगाए।

ये games भारी मुश्किलों के बावजूद कामयाब हुए। पर हर एक Limbo के बदले ऐसे लाखों रचनात्मक vision मरे जिन्हें इसलिए दम तोड़ना पड़ा क्योंकि tools ने ऐसी technical रवानगी माँगी जो उनके creators दे नहीं सकते थे। 3% से भी कम indie game developers कभी सार्थक कामयाबी हासिल कर पाते हैं। न जाने कितने शानदार games कभी बने ही नहीं क्योंकि उनके creators "ifs" और "thens" की दीवार से टकराए और हार मान गए।

प्रवेश की रुकावट creativity नहीं थी। वह tools के भीतर ही बना हुआ technical gatekeeping था।

जो होना चाहिए था, उसे बनाना

तो 5 साल पहले मैंने कुछ अलग बनाना शुरू किया।

बात सीधी सी थी: game development किसी भी रचनात्मक vision रखने वाले इंसान के लिए सुलभ होना चाहिए। interactive media के ज़रिए खुद को व्यक्त करने के लिए आपको computer science की डिग्री की ज़रूरत नहीं होनी चाहिए। tools को इस हिसाब से ढलना चाहिए कि रचनात्मक लोग असल में कैसे सोचते हैं, न कि इसका उल्टा।

Sequoia, Pear, Draper और दर्जनों दूसरी firms के VCs ने मुझसे कहा कि यह काम नहीं करेगा। यह B2C है। बाज़ार है ही नहीं। Indies किसी चीज़ के पैसे नहीं देते। आप काबिलियत की कुर्बानी दिए बिना game development को आसान नहीं बना सकते। Gamers जटिल games चाहते हैं, और जटिल games के लिए जटिल tools चाहिए। बाज़ार के विश्लेषण के लिबास में लिपटे लाखों बहाने।

लोगों ने मुझसे कहा कि मैं पागल हूँ। शायद थी भी। पर मैं बार-बार उसी सवाल पर लौट आती: रचनात्मक अभिव्यक्ति के लिए करोड़ों डॉलर के budget एक ज़रूरी शर्त क्यों हों? फ़िल्म डायरेक्टर और मशहूर game producer के पास टीमें और संसाधन होते हैं। बाक़ी सबको एक code editor और एक दुआ मिलती है। मैं वह चीज़ बनाना चाहती थी जो उस खाई को पाट दे। आप बताते हैं कि आप क्या चाहते हैं, और वह आपकी आँखों के सामने हो जाता है। मेरा कण-कण जानता था कि यह सही है। मैं इसे अपने शरीर की हर कोशिका में महसूस कर सकती थी।

आज हज़ारों लोग रोज़ Cinevva का इस्तेमाल 3D game assets, games, music, levels और experiences के लिए करते हैं। अब तक बने projects पर लाखों views। हर एक दिन के साथ बढ़ता हुआ। Sand Hill Road को दी जाने वाली दो मिनट की pitch ठीक "मैं SAT में फ़ेल हो गई पर मेरी सहज समझ पर भरोसा करो" का format तो नहीं है।

सहज समझ का असल में क्या मतलब है

Huang सिर्फ़ कोई दार्शनिक बात नहीं कह रहे थे। वे एक असली बदलाव की बात कर रहे थे कि किसे कीमती intelligence माना जाए।

दशकों तक हमने गलत चीज़ों के लिए optimize किया। हमने ऐसी शिक्षा व्यवस्थाएँ बनाईं जो रटने और गणना करने को इनाम देती थीं। हमने ऐसी standardized tests डिज़ाइन कीं जो पहले देखी हुई समस्याओं से pattern-matching को मापती थीं। हमने लोगों को ऐसी credentials के आधार पर भर्ती किया जो साबित करती थीं कि वे चार साल के शैक्षिक gatekeeping में टिक सकते हैं। AI ने बस यह सब कम खास बना दिया।

AI जो नहीं कर सकता, कम से कम अभी तक, वह है यह भाँपना कि क्या कमी है। यह महसूस करना कि कुछ गड़बड़ है। यह सहज समझ लेना कि लोगों को क्या चाहिए, इससे पहले कि वे खुद उसे बता पाएँ। माहौल को पढ़ लेना। ऐसे संदर्भ को समझना जो किसी dataset में दर्ज नहीं है।

मैंने अपना वक़्त, अपना international जीवन का अनुभव, पैसा, और सहज समझ Cinevva बनाने में उँडेल दी। यह ऐसा मेल है जो college में पाना मुश्किल है। SAT में जिसे जाँचना मुश्किल है। किसी भी ऐसे credential सिस्टम में जिसे पकड़ना मुश्किल है जो AI के कच्ची cognitive ताकत को आम बनाने से पहले डिज़ाइन हुआ था।

सोलह या बीस साल पहले, computer scientists ने तय किया कि tools कैसे दिखने और कैसे काम करने चाहिए। उन्होंने अपने लिए बनाया, उन लोगों के लिए जो उनकी तरह सोचते थे। हम बाक़ी सबसे उम्मीद की गई कि हम ढल जाएँ। वह दौर खत्म हो रहा है। आगे जो आने वाला है उसे वही लोग गढ़ेंगे जो समझते हैं कि इंसान असल में क्या चाहते हैं। जो महसूस कर सकते हैं कि कब कुछ गलत है और कब कुछ सही। जो technical सुंदरता के बजाय लोगों के लिए बनाते हैं।

मैंने अपने भीतर की एक चीज़ पर भरोसा किया जिसे सिस्टम ने बेकार बताया था। और मैं सही थी।

इससे जुड़ा हुआ:

• नौकरी का बाज़ार बदल रहा है — डिग्री से स्किल्स की ओर
• Online Game Development Courses — skills-first राहें जो परंपरागत gatekeeping को दरकिनार कर देती हैं
• अब हर कोई AI game engine बनना चाहता है — उन tools की ओर industry का झुकाव जो लोगों की सोच के हिसाब से ढलते हैं

Oleg Sidorkin द्वारा, Cinevva के CTO

games में AI 2024 के मध्य के आसपास एक सच्चा बारूदी मैदान बन गया। नौकरियाँ गायब हो रही हैं। लोग यकीन कर बैठे हैं कि अगला नंबर उन्हीं का है। Copyright के सवाल जिन्हें वकील तक नहीं सुलझा पाते। अंतहीन सौंदर्य-संबंधी बहसें जो घूम-फिरकर वहीं लौट आती हैं। Steam ऐसी चीज़ों से भरा पड़ा है जो किसी ने माँगी ही नहीं थीं। और इन सबके नीचे, हर creator को अब यह चिंता खाए जा रही है: "क्या मैं सच में यहाँ कुछ बना रहा हूँ, या बस... prompts टाइप कर रहा हूँ?"

हम एक platform चलाते हैं। यह करते-करते एक बात जल्दी समझ आ जाती है।

किसी को भी ठगा हुआ महसूस करना अच्छा नहीं लगता।

इन आँकड़ों ने हमें चौंका दिया

हमें लगा था कि AI को अपनाना बढ़ेगा। पर ऐसे नहीं। 2025 के अंत तक हालात यहाँ पहुँचे:

स्रोत: Tom's Hardware / Totally Human Media विश्लेषण, GDC 2025 Developer Survey, Unity 2025 Gaming Report

आख़िर हुआ क्या जिसने players को इतना शक्की बना दिया

यह कहीं से अचानक नहीं आया। सच में चीज़ें गलत हुईं। और लोगों को याद है।

Voice actors को पता चला कि उनकी आवाज़ की नकल बना दी गई थी, वो भी launch day पर

Tomb Raider 4-6 Remastered मूल voice performances के AI से बनाए गए संस्करणों के साथ रिलीज़ हुआ। actors को इसकी खबर ठीक उसी पल मिली जब बाकी सबको मिली। launch day। कानूनी दबाव बढ़ने के बाद publisher ने आखिरकार patch देकर वो आवाज़ें हटा दीं। वो ग्यारह महीने की SAG-AFTRA हड़ताल? ठीक यही स्थिति उसकी वजह थी।

"AI slop" अब एक ऐसा शब्द बन गया जो लोग बोलते हैं

Call of Duty: Black Ops 6 ने चुपचाप अपने Steam page पर AI का खुलासा जोड़ दिया। तब, जब वो पहले ही रिलीज़ हो चुका था। players ने अजीबपन भाँप लिया था, हर तरफ बिखरी हुई visual गड़बड़ियाँ। एक loading screen के किरदार की छह उंगलियाँ थीं। "AI slop" किसी भी ऐसी चीज़ के लिए शॉर्टहैंड बन गया जो... गड़बड़ दिखती हो। खोखली। जैसे किसी ने ठीक से जाँचने की परवाह ही न की हो।

एक award nomination गायब हो गया

Clair Obscur: Expedition 33 का Indie Game Awards में Game of the Year nomination वापस ले लिया गया। हालाँकि रिलीज़ हुए game में AI का इस्तेमाल हुआ ही नहीं था। दिक्कत development के दौरान इस्तेमाल हुए AI placeholders की थी, अंदरूनी सामान जो कभी players तक पहुँचा ही नहीं। आखिरी assets पूरी तरह इंसानों के बनाए हुए थे। फर्क नहीं पड़ा। हफ्तों तक इस पर बहस होती रही कि लाइन ठीक कहाँ खींची जाए।

जिन teams ने AI को छुआ तक नहीं था, उन्हें यह साबित करना पड़ा

Chessplus और Peak दोनों पर AI के आरोप लगे। किसी ने भी AI इस्तेमाल नहीं किया था। दोनों award के लिए नामित थे। दोनों development teams को आखिरकार पुराने screenshots और layer files खंगालने पड़े बस यह दिखाने के लिए कि उनका काम हाथ से बना था। Peak की team ने इसे बखूबी कहा: "हम शायद slop हों, पर हम इंसानों के बनाए, स्थानीय रूप से तैयार, हस्तनिर्मित slop हैं।"

Studios बिल्कुल विपरीत दिशाओं में चले गए

SNK — एक Fatal Fury: City of the Wolves trailer में AI जैसे दिखने वाले visuals आने के बाद Discord moderators काम छोड़कर चले गए। Games Workshop — सभी Warhammer properties में AI पर पूरी तरह रोक लगा दी। Larian Studios — कहा कि उन्होंने Baldur's Gate 3 में AI का इस्तेमाल सिर्फ बहुत शुरुआती concept रेखाचित्रों के लिए किया, आखिरी game में कुछ नहीं। Tim Sweeney — Steam के AI labels को बेकार बताया और कहा कि इन्हें हटा देना चाहिए। Valve — पलटकर जवाब दिया कि AI labels की शिकायत करने वाले devs अक्सर इस बात से परेशान रहते हैं कि उनका काम "low effort" दिखता है।

games ढूँढना एक भरोसे की समस्या बन गया

अब चीज़ें इतनी तेज़ी से बनती हैं कि कोई उन्हें ठीक से परख ही नहीं पाता। सवाल बदल गए:

मैं आख़िर यहाँ देख क्या रहा हूँ? इसे बनाया किसने? क्या इस पर बिताए वक्त का मुझे पछतावा होगा? क्या इसमें से कुछ भी उस trailer के वादे से मेल खाता है?

शायद कोई बड़ा समाधान आने वाला नहीं है। AI बनाम इंसान के बनाए पर कोई आखिरी फैसला नहीं।

ज़्यादा संभावना इसकी है: filters, असली पारदर्शिता, और ऐसे incentive ढाँचे जो ईमानदारी की ओर धकेलें।

छोटे studios इस सब के बीच फँसे हुए

Indie developers एक अजीब जगह आ खड़े हुए।

फायदा वाकई नज़रअंदाज़ करना मुश्किल है: आप तेज़ी से iterate करते हैं। जब चार लोग सब कुछ बना रहे हों तो लागत घटती है। Solo devs अब सच में चीज़ें पूरी कर सकते हैं। Localization आपके पूरे budget को निगलना बंद कर देता है।

नुकसान भी उतना ही असली है: ऐसा output जो generic लगता है। Training data और IP की चिंताएँ जिन्हें वकील अभी छूना नहीं चाहते। ऐसे systems रिलीज़ करना जिन्हें आप पूरी तरह समझते नहीं, कुछ लोग इसे comprehension debt कहते हैं। low-effort releases की बाढ़ के साथ एक ही खाने में गिने जाना। सर्वे किए गए लगभग आधे developers मानते हैं कि AI से games कुल मिलाकर बदतर बनते हैं।

Unity की 2025 रिपोर्ट कहती है कि 79% developers AI tools को लेकर सकारात्मक महसूस करते हैं। सुनने में काफी पक्का लगता है। हकीकत ज़्यादा उलझी हुई है। जो teams इसे अच्छे से करती हैं, वे AI को उबाऊ हिस्सों के लिए इस्तेमाल करती हैं, मेहनती काम, खुरदुरे draft, QA की झंझट। Creative direction? वो इंसान के हाथ में ही रहती है।

Cinevva कहाँ खड़ा है: AI पर तटस्थ, ईमानदारी पर सख्त

हम AI इस्तेमाल करने पर games को ठुकराते नहीं। हम उन्हें कोई खास रियायत भी नहीं देते।

नियम सीधा है: अगर AI शामिल था, तो बता दो। players तय करते हैं कि उन्हें किस बात की परवाह है। तब filters सच में काम करते हैं।

• AI-generated content policy

filters बहसों से बेहतर काम करते हैं

games में AI की बहस जल्दी किसी सहमति तक नहीं पहुँचने वाली। शायद कभी नहीं पहुँचेगी। पर हर किसी की अपनी पसंद? वो काफी साफ है।

कुछ players खासतौर पर इंसान-निर्देशित art चाहते हैं। ऐसा लेखन जो किसी इंसान से आया हो। दिखती हुई मेहनत।

कुछ को सच में परवाह नहीं। मज़ा तो मज़ा है।

filters दोनों समूहों को वो ढूँढने देते हैं जो वे चाहते हैं। किसी को जीतना नहीं पड़ता।

payment models किसी की राय से ज़्यादा मायने रखते हैं

जब revenue playtime से जुड़ता है, यूनिट sales से नहीं, तब आप पैसा ऐसे कमाते हैं:

players को जल्दी बाँध लेना। उनका ध्यान बनाए रखना। वही देना जो आपकी marketing ने कहा था।

quality अपने आप ज़ाहिर रास्ता बन जाती है। आपने इसे कैसे बनाया, यह कम मायने रखता है।

अपने trailer में हद से ज़्यादा वादे किए? players फौरन निकल जाते हैं। Retention गिर जाता है। उन्हें ठीक वही दिखाओ जो वे पा रहे हैं? वे टिके रहते हैं। playtime बढ़ता है। revenue आता है। अर्थशास्त्र अपने आप संभल जाता है।

2026 शायद क्या लेकर आएगा

ज़्यादा नियम — EU AI Act फैलता ही जा रहा है। आवाज़ और छवि के लिए अमेरिकी सुरक्षाएँ बढ़ रही हैं, खासकर SAG-AFTRA के बाद।

खास tools — छोटी teams के लिए खासतौर पर बना AI। इस तरह डिज़ाइन किया गया कि इंसान ही स्टीयरिंग पर रहें।

ज़्यादा समझदार labels — "Made with AI" बहुत मोटा है। AI-सहायता वाले workflows और AI से बने आखिरी assets के बीच फर्क की उम्मीद रखिए।

दर्शकों का बँटना — कुछ players जानबूझकर पारंपरिक तरीके से बने games ढूँढेंगे। कुछ इस पर सोचेंगे तक नहीं। दोनों समूह इतने बड़े हैं कि उनके लिए बनाया जा सके।

Platform की प्रतिस्पर्धा — storefronts पारदर्शिता और discovery को कैसे संभालते हैं, यह एक असली फर्क पैदा करने वाली बात बन जाती है।

असल में चीज़ें आगे क्या बढ़ाता है

बहस से AI का सवाल नहीं सुलझेगा। जो सुलझाता है, वो है:

1. players उस आधार पर चुनें जो उनके लिए सच में मायने रखता है
2. creators इस बारे में ईमानदार रहें कि वे कैसे काम करते हैं
3. platforms ऐसे tools बनाएँ जो दोनों समूहों को एक-दूसरे तक पहुँचने में मदद करें

यही है post-AI economy। लड़ते हुए खेमे नहीं। भरोसा जो पूरी चीज़ को बाँधे रखता है।

संबंधित:

• AI-generated content policy
• For game creators
• FAQ
• Frontier Open-Source Gen AI Models — वे खास models और वे कैसे काम करते हैं
• Open source has an AI pollution problem — जब AI का output open-source projects में बाढ़ की तरह भर जाता है, तब क्या होता है

लिखा है Oleg Sidorkin ने, Cinevva के CTO

2023 में मैंने अपने चचेरे भाई को honours के साथ ग्रेजुएट होते देखा। एक अच्छे state school से computer science की डिग्री। ठीक-ठाक GPA। नौकरी पाने में उसे चौदह महीने लग गए, और तब जाकर एक मिली। उधर मेरा एक दोस्त, जो दूसरे साल में पढ़ाई छोड़कर indie games बनाने लगा था, उसे ढूँढना शुरू करने के एक महीने के अंदर तीन offers मिल गए।

यह अब कोई अपवाद नहीं है। यही अब आम बात है।

आख़िरकार आँकड़े उस बात से जा मिले जो हम महसूस करते आ रहे थे

2025 तक 90% HR leaders ने बताया कि वे पारंपरिक चार साल की डिग्री के बाहर से लोगों को हायर कर रहे हैं (Fortune)। अमेरिका की एक चौथाई कंपनियों ने bachelor's की शर्त पूरी तरह हटा दी (HR Dive)। और जो बात अभी-अभी loan चुकाने वालों को चुभेगी वो ये है: 94% नियोक्ता कहते हैं कि स्किल्स के आधार पर हायर किए गए लोग डिग्री के आधार पर हायर किए गए लोगों से बेहतर परफॉर्म करते हैं (Forbes)।

Verizon अब कहती है कि उसकी 99% भूमिकाओं के लिए डिग्री ज़रूरी नहीं है। Sergey Brin ने माना कि Google "बहुत सारे" ऐसे लोगों को हायर करती है जिनके पास bachelor's डिग्री नहीं है। IBM ने अपने "New Collar" प्रोग्राम के ज़रिए अमेरिका की आधी openings को डिग्री-वैकल्पिक बना दिया।

ऐसा नहीं है कि कंपनियाँ दरियादिली दिखा रही हैं। उन्हें समझ आ गया कि डिग्री इस बात का अंदाज़ा नहीं देती थी कि कौन सचमुच काम में अच्छा निकलेगा।

पुराना सिस्टम क्यों टूटा

सच क्या है? डिग्री एक आलसी filter बन गई थी।

जब आप हायर कर रहे हों और आपके पास 400 application हों, तो bachelor's डिग्री माँगने भर से ढेर आधा हो जाता है। इससे ये पता नहीं चलता कि काम कौन कर सकता है। इससे बस ये पता चलता है कि किसके पास चार साल classrooms में बैठने के लिए पैसा, समय और घर की स्थिरता थी। काबिलियत के साथ इसका रिश्ता हमेशा से उतना मज़बूत नहीं था जितना हम मान बैठे थे।

और अब तीन चीज़ें एक साथ हो गईं:

स्किल्स बहुत तेज़ी से बदलने लगीं। Game engines, AI tools, web frameworks। जब तक कोई curriculum committee किसी चीज़ पर कोर्स मंज़ूर करती है, तब तक वो चीज़ पुरानी पड़ चुकी होती है। चार साल की डिग्री आपको चार साल पुरानी theory सिखाती है। टेक में यह बीते ज़माने की बात है।

Portfolios को नकारा नहीं जा सकता। जब किसी का GitHub देखा जा सकता है तो अंदाज़ा क्यों लगाएँ कि वो code कर सकता है या नहीं? जब किसी के itch.io page पर player reviews के साथ पाँच पूरे हो चुके projects हों, तो ये सोचना क्यों कि वो कोई game ship कर सकता है या नहीं?

कंपनियाँ बेबस हो गईं। टैलेंट की कमी सच में है। डिग्री न रखने वाले हर इंसान को बाहर कर देने का मतलब है ऐसे लोगों को बाहर करना जो शायद ठीक वही हों जिनकी आपको ज़रूरत है। कुछ hiring managers को यह कड़वे तरीके से समझ आया, जब उन्होंने खुद से सीखे डेवलपर्स को अपने डिग्री वाले हायर्स से कहीं आगे निकलते देखा।

game industry ने इसे पहले ही भाँप लिया था

मुझे लगता है कि games इस मामले में बाकियों से आगे रहे हैं, और यह समझना ज़रूरी है कि क्यों।

Studios को कभी इस बात की परवाह नहीं रही कि आप किस स्कूल से पढ़े। उन्हें इसकी परवाह थी कि आपने क्या ship किया। 48 घंटे के jam में बनाया गया एक निखरा हुआ game किसी hiring manager को चार साल की game design डिग्री से कहीं ज़्यादा बताता है। यह साबित करता है कि आप दबाव में चीज़ें पूरी कर सकते हैं। यह साबित करता है कि आपने scope को लेकर मुश्किल फ़ैसले लिए। यह साबित करता है कि game खेलने लायक है, सिर्फ़ कागज़ी नहीं।

अगर आप 2026 में games में घुसने की कोशिश कर रहे हैं, तो असल में जो मायने रखता है वो ये है (Dice, CombineGR): दो या तीन निखरे हुए, खेलने लायक demos। यह बताने वाले case studies कि आपने क्या किया और क्यों। इस बात का सबूत कि आप चीज़ें पूरी करते हैं। कम से कम एक बड़े engine में महारत, जो असल projects के ज़रिए दिखे।

Hiring managers संभावनाएँ नहीं ढूँढ रहे। वे सबूत ढूँढ रहे हैं।

वो असहज बात जिसके बारे में कोई बात नहीं करता

एक बात जिसने मुझे झुँझला दिया जब मैंने research में गहराई से देखा।

Harvard/Burning Glass की एक स्टडी में पाया गया कि डिग्री की शर्त हटाने वाली कंपनियों ने अक्सर असल में बिना-डिग्री वाले उम्मीदवारों को ज़्यादा हायर नहीं किया। बढ़ोतरी सिर्फ़ करीब 3.5 percentage point की रही (Forbes)। नीति बदल गई। हायरिंग की आदतें पीछे रह गईं।

इसका मतलब है कि अगर आप गैर-पारंपरिक रास्ता चुन रहे हैं, तो आपको अब भी ज़्यादा मेहनत करनी होगी। दरवाज़ा पहले से ज़्यादा खुला है, पर आप अभी बराबरी से अंदर नहीं चल रहे। आपका portfolio ऐसा होना चाहिए जिसे नकारा न जा सके। आपके projects को किसी और की डिग्री से ऊँची आवाज़ में बोलना चाहिए।

यह ठीक नहीं है। पर यह जानना आपको तैयारी में मदद करता है।

अभी शुरुआत करने वाले किसी इंसान से मैं क्या कहूँगा

अगर आप पढ़ाई कर रहे हैं, तो रुकिए मत। पर समझिए कि अकेली डिग्री अब काफ़ी नहीं है। साथ-साथ चीज़ें बनाइए। game jams कीजिए। कोई Google Career Certificate या Unity certification ले लीजिए। डिग्री को कई credentials में से एक समझिए, सबसे बड़ी credential नहीं।

अगर आप डिग्री नहीं कर रहे, तो आपका रास्ता अलग है पर ज़रूरी नहीं कि मुश्किल हो। जमकर बनाइए। चीज़ें ship कीजिए। सब कुछ document कीजिए। आपका GitHub, आपका itch.io page, आपकी personal site। यही अब आपकी credential है।

चाहे जो भी हो, अपने काम को समझाने की प्रैक्टिस कीजिए। सिर्फ़ ये नहीं कि आपने क्या बनाया, बल्कि ये भी कि आपने जो फ़ैसले लिए वो क्यों लिए। आप क्या अलग करते। आपने क्या सीखा। Interviewers उन लोगों को याद रखते हैं जो अपनी सोच को साफ़ शब्दों में रख पाते हैं।

यह सिर्फ़ हायरिंग से बड़ी बात है

यहाँ जो हो रहा है वो सिर्फ़ इस बदलाव तक सीमित नहीं कि कंपनियाँ भूमिकाएँ कैसे भरती हैं। यह इस बात का बदलाव है कि हम सब मिलकर किस चीज़ को अहमियत देते हैं।

दशकों तक credentials एक filter का काम करते रहे। महँगे, समय खाने वाले, पर समझ में आने वाले। अगर किसी के पास डिग्री होती, तो आप कुछ बातें मान लेते थे। यह एक संकेत था, सीधी नाप नहीं, पर इतना काफ़ी था।

अब वो संकेत टूट रहा है। तकनीक से अब यह देखना मुमकिन है कि कोई इंसान असल में क्या कर सकता है। Remote work ने साबित कर दिया कि नतीजे इस बात से ज़्यादा मायने रखते हैं कि आप कहाँ बैठे थे। AI theoretical knowledge को practical application के मुकाबले कम कीमती बना रहा है।

मुझे यह सचमुच उम्मीद से भरा लगता है, भले ही यह बदलाव अभी उलझा हुआ है। पहले सवाल होता था "आपने कहाँ से पढ़ाई की?" अब सवाल है "आप क्या बना सकते हैं?"

यह बेहतर सवाल है।

स्रोत

• Fortune: 90% of HR leaders hiring outside traditional degrees
• Forbes: 90% of companies make better hires based on skills
• Forbes: Companies dropping degree requirements but hiring few non-degreed workers
• HR Dive: Employers eliminating degree requirements
• Computerworld: Tech firms move away from college requirement
• Dice: Aspiring video game designers in 2025
• CombineGR: 2025 Global Gaming Employment Outlook

संबंधित:

• game jams में सफल कैसे हों
• Online Game Development Courses — हर बजट के लिए स्किल्स-फ़र्स्ट learning paths
• Agentic AI code tools — वे tools जो बदल रहे हैं कि कौन सी स्किल्स मायने रखती हैं
• सहज मन — क्यों credentials से ज़्यादा intuition मायने रखता है