भू-आकृति पर पानी का सिमुलेशन

 (lisyarus.github.io)
2 पॉइंट द्वारा GN⁺ 2025-02-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • जिन खेलों में भू-आकृति को खोदा और भरा जा सकता है, उनमें झील, नदी और गड्ढों का पानी नई सीमाओं की ओर बहना चाहिए, इसलिए तेज़ और स्थिर grid-based water simulation की ज़रूरत होती है
  • लक्ष्य लगभग 1m scale पर भू-आकृति के साथ वही grid इस्तेमाल करने वाला 2D heightfield model है, जो जल-संरक्षण, नियंत्रित की जा सकने वाली स्थिरता और linear update cost को पूरा करे
  • Smoothed Particle Hydrodynamics और Stable Fluids क्रमशः high-resolution particle fluid और बंद fluid volume के लिए अधिक उपयुक्त हैं, इसलिए भू-आकृति पर free surface को तेज़ी से संभालने की इस आवश्यकता से मेल नहीं खाते
  • अपनाई गई virtual pipes विधि staggered grid पर water height और cells के बीच flow को स्टोर करती है, और flow acceleration, outflow scaling तथा water column update को कुछ 2D array loops में प्रोसेस करती है
  • उचित dt और g पर यह पानी जैसा दिखने वाला परिणाम देती है, लेकिन inertia और velocity diffusion न होने से तेज़ पानी की धारा झील के भीतर लगातार आगे नहीं बढ़ती और फैलकर रुक जाती है

terrain-editing गेम्स में पानी कठिन क्यों है

  • strategy games या city/village simulation में पानी प्राकृतिक सीमा, navigation, fishing, trade, naval combat, drinking water, transport और aesthetics जैसी भूमिकाएँ निभा सकता है
  • अगर भू-आकृति को सीधे बदला जा सके तो पानी को संभालने की कठिनाई बहुत बढ़ जाती है
    • मिट्टी, रेत और clay जैसे संसाधनों को ज़मीन से खोदकर निकालना हो तो भू-आकृति का साथ में हटना स्वाभाविक लगता है
    • पत्थर और metal ore भी surface object की तरह नहीं, बल्कि ज़मीन खोदकर निकाले जाएँ तो अधिक उपयुक्त लगते हैं
    • अगर ढलान पर building नहीं बनाई जा सकती, तो निर्माण से पहले terrain flattening करनी होगी
    • terrain editing को खुद एक creative expression tool के रूप में दिया जा सकता है
  • मुख्य स्थिति यह है कि जब झील या गड्ढे की सीमा खोदकर पानी के लिए रास्ता खुलता है, तब पानी कहाँ और कितना बहेगा

सरल उपाय कहाँ कम पड़ते हैं

  • संभावित workaround में पानी को शुरुआती स्थान पर स्थिर रखना, किसी निश्चित ऊँचाई से नीचे सबको पानी मान लेना, बहुत गहराई तक खोदने पर रोक लगाना, या Minecraft/Dwarf Fortress जैसे सरल flow model का उपयोग करना शामिल है
  • ये तरीके विकल्प के रूप में चल सकते हैं, लेकिन मुख्य मॉडल के रूप में या तो बहुत सरल हैं या बहुत blocky महसूस होते हैं
  • Dwarf Fortress मॉडल बाकी उदाहरणों से अधिक नज़दीक है, लेकिन वह 3D को ध्यान में रखकर बना है, जबकि यहाँ की समस्या मुख्यतः 2D terrain पर पानी की है
  • Timberborn इसी तरह का मॉडल इस्तेमाल करता है जैसा यहाँ चर्चा में है

वांछित simulation शर्तें

  • लक्ष्य water model को निम्न शर्तें पूरी करनी चाहिए
    • भू-आकृति वाली ही grid पर काम करना बेहतर है
    • औसत scale लगभग 1m है, और छोटे water splashes तक simulate करने की ज़रूरत नहीं है
    • पानी को terrain के ऊपर एक heightfield माना जाता है, और vertical flow या vertical cross-section की खाली जगहों पर विचार नहीं किया जाता
    • पानी को बहना चाहिए, और simulation error के कारण गायब नहीं होना चाहिए
    • स्थिरता को नियंत्रित किया जा सकना चाहिए
    • हर step की cost simulation size के साथ linear होनी चाहिए, और आदर्श रूप से कुछ ही loops में पूरी हो जानी चाहिए

मौजूदा fluid simulation से असंगति

  • Smoothed Particle Hydrodynamics प्रभावशाली high-resolution fluid परिणाम देता है, लेकिन यहाँ की समस्या अलग है
    • 1m आकार के water particles पानी के गुब्बारों जैसे दिख सकते हैं
    • particles को और छोटा करने पर performance cost बढ़ जाती है
    • लक्ष्य high-resolution realism नहीं, बल्कि तेज़ और भरोसेमंद दिखने वाला मॉडल है
  • Jos Stam का Stable Fluids बंद tank जैसी fluid-filled volume को संभालने वाले मॉडल के अधिक करीब है
    • यह terrain पर free surface को सीधे संभालने वाली समस्या से अलग है
    • कुछ चरणों में sparse linear system को बार-बार solve करना पड़ता है, इसलिए cost अधिक है
    • यह पूरा Navier-Stokes solve करने का तरीका है, जबकि यहाँ shallow water equations की ज़रूरत है

Shallow water equations और grid का चयन

  • Shallow water equations terrain पर पानी की परत को vertical दिशा में औसत करके 2D equations के रूप में संभालने का तरीका है
  • “Shallow” का मतलब यह मानना है कि water column का vertical आकार रुचि के horizontal scale की तुलना में बहुत छोटा है
    • जैसे नदी की गहराई कुछ m से कुछ दर्जन m हो और रुचि की दूरी km स्तर की हो
  • सामान्य collocated grid में water height और velocity को उसी cell में रखा जाता है, लेकिन fluid dynamics में इससे समस्याएँ आ सकती हैं
    • first derivative को सीधे discretize करने पर directional bias या instability आ सकती है
    • अगर बाएँ-दाएँ से flow अंदर आ रहा हो और ऊपर-नीचे की ओर बाहर जा रहा हो, तो उसी cell में कुल velocity 0 जैसी दिखने का विरोधाभास पैदा हो सकता है
  • Staggered grid में water height और density जैसे मान cells में, जबकि velocity या flow cells के बीच की edges पर स्टोर किए जाते हैं
    • N x N water height array
    • (N+1) x N X-direction flow array
    • N x (N+1) Y-direction flow array

Virtual pipes विधि

  • Virtual pipes में यह माना जाता है कि water cells काल्पनिक pipes से जुड़े हैं, और flow की गणना उसी आधार पर की जाती है
  • जिन papers का संदर्भ लिया गया, उनमें से एक multi-level water columns और vertical connections को भी संभालता है, और दूसरा मुख्यतः hydraulic erosion पर केंद्रित है, लेकिन यहाँ उन लक्ष्यों को शामिल नहीं किया गया
  • स्टोर किए जाने वाले मान 3 हैं
    • water: हर cell में water column की ऊँचाई
    • flowX: क्षैतिज रूप से सटे cells के बीच कुल water flow
    • flowY: ऊर्ध्वाधर रूप से सटे cells के बीच कुल water flow
  • velocity की जगह flow (flux) को स्टोर किया जाता है
    • flow को प्रति unit time गुजरने वाले water volume के रूप में देखा जा सकता है
    • खाली cells के बीच flow स्वाभाविक रूप से 0 परिभाषित होता है
    • velocity, flow को cross-sectional area से भाग देकर मिलती है, इसलिए पानी बहुत कम होने पर 0/0 या threshold जैसी समस्याएँ आ सकती हैं

एक step के 3 चरण

  • simulation का एक step तीन चरणों में बँटा है
    • flow acceleration: सटे cells की water surface height के अंतर के अनुसार cells के बीच flow बढ़ाया जाता है
    • outflow scaling: अगर किसी cell से बाहर जाने वाला पानी उसकी वास्तविक उपलब्ध मात्रा से अधिक हो, तो outflow घटाया जाता है
    • water column update: आस-पास के flow के आधार पर हर cell की water height जोड़ी या घटाई जाती है

  • Flow acceleration

    • यदि दो सटे cells की water height अलग है, तो ऊँचे वाले से नीचे वाले की ओर flow accelerate होता है
    • X और Y दिशा की internal edges पर flow update किया जाता है, और g, dt, dx, dy का उपयोग होता है
    • virtual pipe का cross-sectional area A सिर्फ g के साथ गुणन में आता है, इसलिए सरल उपयोग में इसे g में समाहित मान सकते हैं
    • friction को हर step में flow घटाने के रूप में जोड़ा जाता है
    • paper pow(friction, dt) coefficient की सिफारिश करता है
    • अधिक intuitive value के लिए pow(1-friction, dt) का उपयोग किया जा सकता है
    • friction=0 का मतलब पिछले flow को पूरी तरह मिटा देने वाला अधिकतम friction माना जा सकता है, और friction=1 का मतलब friction नहीं
    • dt जितना बड़ा होगा, simulation उतना तेज़ होगा लेकिन unstable भी हो सकता है
    • fluid simulation में Courant-Friedrichs-Lewy condition महत्वपूर्ण होती है
    • व्यवहार में dt को stability मिलने तक घटाना पड़ता है, और इस्तेमाल किए गए मान लगभग 0.001~0.01 थे

  • Water column update

    • हर cell अपने चारों ओर के flows को देखकर पानी जोड़ता या घटाता है
    • बाएँ और नीचे से आने वाले flowX(x,y), flowY(x,y) को जोड़ा जाता है
    • दाएँ और ऊपर की ओर जाने वाले flowX(x+1,y), flowY(x,y+1) को घटाया जाता है
    • यह वह चरण है जहाँ गणना किए गए flow के अनुसार cells के बीच पानी वास्तव में स्थानांतरित होता है

  • Outflow scaling

    • अगर flow बहुत बड़ा हो, तो update के बाद किसी cell की water height negative हो सकती है
    • हर cell के सिर्फ बाहर जाने वाले flow को जोड़कर यह जाँचा जाता है कि एक step में हटाया जाने वाला पानी उसकी वास्तविक जल-मात्रा से अधिक तो नहीं है
    • यदि हटाई जाने वाली मात्रा बहुत बड़ी हो, तो बाहर जाने वाले flow को समान अनुपात में घटाया जाता है ताकि water height 0 या उससे ऊपर रहे
    • यही चरण negative water amount को रोकने वाला मुख्य stabilization mechanism है

terrain, boundary conditions, और viscosity handling

  • terrain को flow acceleration चरण में water column height की जगह water surface height उपयोग करके शामिल किया जाता है
    • water surface height = terrain(x,y) + water(x,y)
    • अधिक ऊँचे terrain वाले cell में water column height समान होने पर भी surface अधिक ऊँची होगी, इसलिए पानी चल सकता है
  • boundary conditions boundary flow values से अप्रत्यक्ष रूप से तय होती हैं
    • flowX(0,y), flowX(N,y), flowY(x,0), flowY(x,N) सीमा से संबंधित हैं
    • इन्हें 0 रखने पर वे दीवार की तरह काम करते हैं
    • inflow value पानी जोड़ती है, और outflow value पानी हटाती है
    • terrain पर पानी के लिए map edge से पानी का गायब होना एक स्वाभाविक outflow boundary हो सकता है
    • जहाँ नदी map boundary को पार करती हो, वहाँ inflow boundary देकर नदी को बहता रखा जा सकता है
  • boundary flow को हर simulation step की शुरुआत में फिर से सेट करना पड़ता है
    • क्योंकि outflow scaling boundary flow को बदल सकती है, जिससे outflow boundary दीवार जैसी बन सकती है
  • paper में water height के आधार पर flow घटाने वाला एक viscosity term भी है
    • विचार यह है कि पानी की पतली परतें आंतरिक बलों के कारण मुश्किल से चलती हैं, जबकि मोटी परतें अधिक स्वतंत्र रूप से बहती हैं
    • magma flow जैसी स्थितियों में यह उपयोगी हो सकता है
    • पानी के लिए इसका उपयोग नहीं किया गया, और बड़े terrain scale पर viscosity का असर लगभग नगण्य है

implementation flow और performance pattern

  • पूरा code निम्न क्रम में बना है
    • boundary flow initialization
    • pow(1-friction, dt) friction coefficient का precomputation
    • X flow acceleration
    • Y flow acceleration
    • negative water amount रोकने के लिए outflow scaling
    • water column update
  • simulation का अधिकांश भाग कुछ 2D arrays पर चलने वाले 4 loops और सरल formulas से पूरा हो जाता है
  • पूरा C++ update code water_2d.cpp में देखा जा सकता है
  • वीडियो उदाहरण कुछ दिन पहले जारी किए गए WebGPU water simulator से हैं, और वीडियो के particles सिर्फ visualization के लिए हैं, simulation में भाग नहीं लेते
  • उचित dt और g मान मिलने पर यह stable दिखता है, आवश्यक शर्तें पूरी करता है, और पानी जैसा परिणाम देता है

बची हुई सीमाएँ

  • इस मॉडल में inertia और velocity diffusion नहीं है
    • तेज़ water stream झील में घुसने पर झील के भीतर आगे बढ़ती नहीं रहती, बल्कि हर दिशा में फैल जाती है
    • यदि water height समान हो, तो विपरीत दिशाओं में समानांतर बहती दो धाराएँ बिना परस्पर interaction के साथ मौजूद रह सकती हैं
  • जब पानी पहली बार किसी क्षेत्र में प्रवेश करता है, तो लहरें बनती हैं और यह कुछ अजीब दिख सकता है

hexagonal और triangular grids तक विस्तार

  • लक्षित game square grid नहीं, बल्कि regular triangular grid का उपयोग करता है
  • triangular grid को hexagonal grid का dual माना जा सकता है
    • सटे हुए hexagons के केंद्रों को रेखाओं से जोड़ने पर regular triangular grid बनती है
    • यह Red Blob Games की hexagonal grids पोस्ट में pointy-top hex directions के dual grid पर axial coordinate system के उपयोग जैसा है
  • triangular grid को भी थोड़ा झुके हुए सामान्य 2D array में स्टोर किया जा सकता है
  • water column height को grid vertices पर स्टोर किया जाता है ताकि water surface rendering आसान हो
  • flow को तीन दिशाओं में बाँटा जाता है
    • X-direction flow
    • Y-direction flow
    • Z-direction flow
  • N x N vertex grid में निम्न arrays का उपयोग होता है
    • (N+1) x N X flow array
    • N x (N+1) Y flow array
    • (N+1) x (N+1) Z flow array, जिसमें bottom-left और top-right values उपयोग नहीं होतीं
  • square grid की तुलना में boundary conditions, acceleration, outflow scaling और water update में Z flow जोड़ना होता है
  • सबसे कठिन हिस्सा indexing में गलती न करना है
  • triangular/hexagonal grids के लिए C++ code water_2d_hex.cpp में देखा जा सकता है
  • यह तरीका square grid की तुलना में थोड़ा अधिक isotropic हो सकता है

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

1 टिप्पणियां

 
GN⁺ 2025-02-08
Hacker News की राय

  • fluid simulation पर एक अलग approach के तौर पर Coding Adventure के वीडियो भी हैं
    Rendering Fluids: https://www.youtube.com/watch?v=kOkfC5fLfgE
    I Tried Putting my Fluid Simulation on a Planet: https://www.youtube.com/watch?v=8nIB7e_eds4&t=817s
    GitHub: https://github.com/SebLague/Fluid-Sim?tab=readme-ov-file

    • दूसरा वीडियो देखते हुए पूरे समय मज़ा आया, और इस तरह के high-level exploration-style वीडियो मुझे सच में बहुत पसंद हैं
    • Coding Adventure मुझे बहुत पसंद है। एक छोटा गेम Geographical Adventures भी है, जिसमें संगीत अच्छा है और वह काफ़ी relaxed लगता है
      [0] https://www.youtube.com/playlist?list=PLFt_AvWsXl0dT82XMtKAT...
      [1] https://github.com/SebLague/Geographical-Adventures

  • procedural generation वाले games में hydrology simulation मुश्किल होने की एक वजह यह है कि जब पानी जमा होता है तो वह आसपास की cells को प्रभावित करता है, और वह प्रभाव फिर दूसरी आसपास की cells तक लगातार फैलता रहता है
    procedural generation अक्सर parallelization के लिए अच्छी तरह फिट बैठता है, लेकिन जिन infinite regions में parallelization की सबसे ज़्यादा ज़रूरत लगती है, उनमें ऐसी calculations को सही तरह parallelize करना मुश्किल होता है
    मैंने इस विषय पर बहुत ज़्यादा exploration नहीं देखा है, और इस तरह का काम करने वालों में https://nickmcd.me मुझे खास तौर पर पसंद हैं। अब तक देखे procedural terrain में यह सबसे अच्छे में से एक है
    हालांकि simulation design की वजह से वह काम भी सीमित region तक बंधा हुआ है। संभावित solution के तौर पर सबसे अच्छा तरीका यह लगता है कि पहले procedural तरीके से ऐसी watershed boundaries बनाई जाएँ जिन्हें तोड़ा न जा सके, फिर पूरे watershed को एक साथ parallel simulate किया जाए
    यह बहुत दिलचस्प समस्या है, लेकिन मेरी जानकारी के दायरे से बाहर है, इसलिए मैं ज़्यादातर observer की भूमिका में हूँ

    • अगर रुचि हो, तो partial differential equations हल करने वाले क्षेत्र में कहे जाने वाले “domain of influence” और “domain of dependence” के बारे में देखना अच्छा रहेगा
      ये उन क्षेत्रों को कहते हैं जो किसी खास point की value को प्रभावित कर सकते हैं, और जिन पर उस point की value प्रभाव डाल सकती है; यह ऊपर कही गई बात से सीधे जुड़ा है। कुछ मामलों में उन क्षेत्रों को पहले से जाना जा सकता है
    • सच में, https://nickmcd.me को ज़रूर देखना चाहिए। वाकई कमाल है
    • दिलचस्प सवाल है। शायद हर region की perimeter पर boundary रखकर, effect के propagate होने की maximum speed, यानी causality, मान ली जाए तो यह संभव लगता है
      उदाहरण के लिए 10-hour step simulate करना हो तो 10 grid cells की boundary रखी जाए। हर region में 10 steps calculate करने के बाद, parallel में calculate की गई दूसरी boundary simulations के साथ boundary state synchronize करें और दोहराएँ
    • यह जानकर हैरानी हुई कि Nick सिर्फ़ 25 साल के हैं

  • थोड़ा विषय से हटकर, लेकिन लेख में resource gathering के लिए terrain manipulation की ज़रूरत वाली बात याद आई
    मुझे हमेशा लगा है कि Animal Crossing ने terrain manipulation के बिना भी इसे काफ़ी smart और efficient तरीके से संभाला। पेड़ काटने पर logs मिलते हैं, लेकिन केवल एक तय मात्रा में, और असल में एक cooldown बन जाता है
    महंगे terrain manipulation के बिना भी feedback और finite resource जैसा अहसास दिया जा सकता है। बेशक यह हर game के लिए सही नहीं है और छोटे maps में बेहतर फिट बैठता है, लेकिन सोचने लायक है। अगर game के लिए ज़रूरी न हो, तो अक्सर terrain manipulation न करना ही बेहतर होता है

    • लेख में भी आसपास रखी gold ore rocks के रूप में ऐसी strategy पर बात की गई थी
      resource देने के तरीके के रूप में यह standard है, लेकिन cooldown infinite resource वाली समस्या को खत्म नहीं करता, सिर्फ़ उसकी speed कम करता है। और यह थोड़ा boring और कम प्रभावी भी है

  • यह इस विषय में साफ़-सुथरे ढंग से गहराई में जाने वाला लेख है, और Timberborn का ज़िक्र देखकर अच्छा लगा
    मैं इन दिनों उस game में पूरी तरह डूबा हुआ हूँ, इसलिए अगर आपने अभी तक नहीं खेला है तो जोरदार recommendation है। physics-based water flow game के अंदर एक और character जैसा लगता है, और पानी रोककर उसे engines में इस्तेमाल करने और खेतों तक पहुँचाने का तरीका समझना core game loop है

  • मज़ेदार था और implementation भी वाकई बहुत अच्छा था। ऐसी चीज़ develop करते समय सबसे बड़ा risk यह है कि सुंदर results देखते-देखते parameters ही tweak करते हुए कई घंटे निकल जाएँ
    2011 में paper work के लिए खुद GPU-based fluid dynamics implement करने की याद आ गई। मैंने surface, यानी tissue पर बहने वाले fluid—blood—को handle किया था, और उसे 2D में simulate करने के बाद gravity और surface slope को ध्यान में रखते हुए mesh पर project किया था
    एक छोटा वीडियो YouTube पर भी डाला था: https://youtu.be/4vGrNc-GGW8

  • सच में शानदार
    हाल ही में o3-mini-high की मदद से मैंने एक similar idea पर experiment किया। मैंने algorithm idea समझाया, और इसने बिना manual intervention के 3D में implement और render कर दिया। हालांकि prompts कई बार देने पड़े
    https://3d-water-sim.netlify.app/
    अभी यह perfect नहीं है, क्योंकि मैंने इसे छेड़ना बंद कर दिया था, और हर iteration में यह काफ़ी बेहतर हो रहा था। दिलचस्प बात यह है कि terrain generation के लिए किसी CDN जैसी जगह से लाने के बजाय, इसने Perlin noise का working version शुरू से सही तरह implement किया

    • ऐसे experiments करते समय उद्देश्य fun है या learning, यह जानने की उत्सुकता है। अगर उद्देश्य learning है, तो क्या खुद implement न करने के बावजूद यह लेख पढ़ना अब भी value रखता है—यह भी जानना चाहूँगा
      यह journey और destination के फर्क से जुड़ा सवाल है

  • लेख में जहां कहा गया है कि “इस मॉडल में inertia और velocity diffusion नहीं है। तेज़ पानी की धारा lake में घुसने पर भी lake के अंदर आगे propagate नहीं होती और जमा हुई inertia को नज़रअंदाज़ करके सभी दिशाओं में फैल जाती है। अगर water level समान हो, तो विपरीत दिशाओं में बहने वाली दो parallel धाराएं भी शायद एक-दूसरे से interact न करें”, वह हिस्सा शायद उसी दिशा के आसपास के 6 flow arrows के साथ average निकालने से हल हो सकता है
    आगे-पीछे वाले arrows को बड़ा weight और side वाले arrows को छोटा weight देने जैसा। उदाहरण के लिए, जब ऐसे arrows हों
    -a-> -b->
    -c-> -d-> -e->
    -f-> -g->
    New_d = d * (1 - 2*.1 - 4*.01) + (c+e).1 + (a+b+f+b).01
    यहां .1 और .01 मनमाने weights हैं, इसलिए इन्हें adjust करना होगा, और vibration कम करने में इस्तेमाल किए जाने की तरह power भी डाली जा सकती है। उस coefficient तक शामिल करें तो यह कुछ इस तरह हो सकता है
    New_d = d * (1 - 2*.1 - 4*.01 - .001) + (c+e).1 + (a+b+f+b).01

    • सही समाधान मूल grid से matching second derivative grid को एक और जोड़ने जैसा लगता है
      grid 0: हर cell की water height
      grid 1: हर edge का water flow, यानी first derivative
      grid 2: हर cell का water acceleration, यानी second derivative
      यह ऐसी structure है जिसमें हर grid पिछले grid का dual grid है और उसका derivative value store करता है। असल में edge data को special-case करने की जरूरत नहीं, सिर्फ vertex data रखकर इसे पूरी तरह dual grid के रूप में handle किया जा सकता है। edge flow को उस edge के दोनों सिरों के vertex flows के sum से derive किया जा सकता है
      इसलिए flow से fluid height update करें, किस speed से कितना fluid mass cell में आया उसके आधार पर acceleration update करें, फिर acceleration और current fluid height से flow update करें। fluid dynamics के बारे में मुझे ज्यादा नहीं पता, लेकिन numerical simulation के perspective से यह सही लगता है, और diagonal flow भी संभव हो जाता है
    • वह तरीका momentum conservation को तोड़ देता है। realistic flow पाने के लिए continuity equation का इस्तेमाल करके flow की energy conserve करनी होगी, और shear को vortices के रूप में dissipate और diffuse होने देना होगा
      जैसा लेख में कहा गया है, computation काफी ज्यादा बढ़ जाता है, इसलिए पहले यह देखना चाहिए कि actual use case में उस level की realism की जरूरत है या नहीं

  • कुछ साल पहले curiosity में बनाया गया मेरा rough result: https://aperocky.com/hydrosim/
    यह personal project cold storage shelf में जाने से पहले मैं यह पता नहीं लगा पाया कि erosion को कैसे handle किया जाए। अच्छा लगा कि author ने इस हिस्से का जिक्र किया और equations भी जोड़ीं

  • हाल ही में कुछ ऐसा ही open किया है। इसमें random heightfield generation, sediment transport और erosion तक शामिल हैं: https://github.com/Ono-Sendai/terraingen

  • हमारी company के एक शानदार developer ने research project के हिस्से के रूप में बनाया educational flood simulation आप खुद try कर सकते हैं
    https://flood.concord.org/
    बड़ा असर देखने के लिए नीचे toolbar में model values बदलनी होंगी
    यह neighboring cells के आधार पर WebGL में cell values calculate करने वाला cell-based simulation है। वह calculation करने वाला shader यहां है
    https://github.com/concord-consortium/flooding-model/blob/ma...