रियल-टाइम में fluid, fire और smoke को simulate करने की तकनीक
(andrewkchan.dev)- GPU-आधारित रियल-टाइम fire simulation fluid dynamics, grid parallel computation, combustion·buoyancy·rendering models को जोड़कर WebGL demo के रूप में लागू की जा सकती है
- बुनियादी मॉडल incompressible और inviscid flow मानता है, और dye, temperature, fuel जैसे scalar fields को velocity field के साथ ले जाने के लिए semi-Lagrangian advection का उपयोग करता है, जिससे stability और parallelism मिलते हैं
- Navier-Stokes चरण में velocity field को पहले स्वयं के द्वारा advect किया जाता है, फिर pressure projection से divergence कम किया जाता है, और Poisson equation को Jacobi iteration जैसे GPU-friendly approximate solvers से हल किया जाता है
- Grid interpolation और first-order semi-Lagrangian method turbulence vortices को कमजोर कर देते हैं, इसलिए vorticity confinement और curl noise से छोटे rotational details को फिर से उभारा जाता है
- Fire के लिए fuel density और temperature fields जोड़े जाते हैं ताकि combustion, cooling और thermal buoyancy की गणना हो सके, और Planck’s Law आधारित blackbody radiation colors से render करके smoke-like fluid को flame जैसा दिखाया जाता है
GPU से fire simulate करने का पूरा flow
- Fire graphics में एक रोचक समस्या है, लेकिन पहले इसे ज़्यादातर physics-based तरीके से नहीं बल्कि केवल नक़ल करके बनाया जाता था
- Lord of the Rings में fluid simulation की लागत अधिक होने के कारण बहुत सारे smoke sprites का उपयोग किया गया
- Video games जैसे real-time applications भी लगभग पूरी तरह non-physical approaches पर निर्भर थे
- पिछले 10 वर्षों में GPU की वजह से तेज़ fluid simulation आसान हो गया है, और बुनियादी fluid dynamics algorithms को GPU पर लागू करना सहज है
- ILM ने 2009 में Harry Potter की fire modeling और rendering में ऐसी तकनीकों का उपयोग किया
- NVIDIA ने 2014 में games के लिए fire·smoke effects system FlameWorks जारी किया
- Implementation एक WebGL demo के रूप में है, और गणितीय रूप से इसके लिए vector calculus और differential equations की पृष्ठभूमि चाहिए
- Source code GitHub पर है
पहले fluid को model किया जाता है
- Fire बनाने से पहले fluid को simulate करना ज़रूरी है, और यहाँ incompressible तथा inviscid fluid माना गया है
- 2D velocity field
u(x, t)कोN × Ngrid के रूप में व्यक्त किया जाता है, और हर grid point उस स्थान का velocity value रखता है - Dye density जैसे scalar field
ψ(x, t)का fluid velocity के अनुसार चलना advection है - यदि हर grid point को सीधे आगे बढ़ाया जाए, तो parallelization कठिन हो जाती है, कई grid points एक ही target grid point पर जा सकते हैं, और बड़ा time step होने पर instability आ सकती है
Stable advection: semi-Lagrangian method
- Mass conservation law और divergence theorem का उपयोग करने पर incompressible flow की scalar advection equation
∂ψ/∂t = -u · ∇ψके रूप में लिखी जा सकती है - Stable तरीका यह है कि हर grid point को velocity के साथ आगे भेजने के बजाय, मौजूदा grid point से velocity दिशा में पीछे ट्रेस करके पिछली स्थिति का value लिया जाए
- इस तरीके को Semi-Lagrangian advection कहते हैं, जिसे Jos Stam ने 1999 में विकसित किया था
- हर grid point हर iteration में केवल एक बार update होता है, इसलिए GPU parallelization आसान है
- कोई भी grid point मौजूदा grid points के अधिकतम value से बड़ा update नहीं होता, इसलिए यह बिना शर्त stable है
- यदि fixed velocity field incompressibility condition को संतुष्ट करता है, तो dye जैसे scalar fields को स्थिर रूप से transport किया जा सकता है
Navier-Stokes से velocity field को update किया जाता है
- Navier-Stokes equations यह परिभाषित करती हैं कि incompressible flow में fluid velocity field समय के साथ कैसे बदलता है
- Inviscid fluid मानकर viscosity term हटा दी जाती है, और बाहरी बलों को भी फिलहाल अनदेखा करने पर दो मुख्य terms बचते हैं
- velocity field द्वारा स्वयं को transport करने वाला self-advection
- incompressibility बनाए रखने के लिए pressure
- Simulation loop लगभग इस क्रम में चलता है
- velocity field
uको स्वयं के द्वारा advect किया जाता है - pressure
pकी गणना की जाती है u = u - gradient(p)के रूप में pressure gradient घटाकर incompressibility लागू की जाती है- नए velocity field से density field को advect किया जाता है
- velocity field
Pressure calculation में Poisson equation bottleneck है
- Self-advection के बाद मिला candidate velocity field
u'यह गारंटी नहीं देता कि divergence 0 condition पूरी होगी, इसलिए pressure से इसे ठीक करना पड़ता है - शर्तों को व्यवस्थित करने पर यह Poisson equation
∇²p = ∇ · u'के रूप में मिलती है - Grid पर divergence और Laplacian को discretize करने पर
N × Ngrid के लिएN²linear equations औरN²unknowns वाला linear system बनता है - सटीक linear system solvers की लागत grid size के साथ superlinear रूप से बढ़ती है, इसलिए real-time simulation में यह भारी पड़ती है
- GPU पर exact solution के बजाय पर्याप्त रूप से अच्छा approximate value बार-बार निकाला जा सकता है
- Jacobi method हर element के estimate को parallel में update करती है, इसलिए GPU implementation के लिए उपयुक्त है
- Conjugate Gradient और Multigrid जैसे तेज़ converging solvers भी GPU पर लागू किए जा सकते हैं
- Smoke और fire में water जैसी स्पष्ट volume change कम दिखती है, इसलिए pressure accuracy की तुलना में advection quality या implementation simplicity अधिक महत्वपूर्ण हो सकती है
Vortex details को फिर से वापस लाना
- Grid में velocity field store करने पर interpolation के दौरान अनचाहा numerical smoothing होता है
- First-order semi-Lagrangian advection के मोटे approximation के साथ मिलकर turbulence vortices गायब होने लगते हैं, और fluid बहुत ज़्यादा smooth और एकरस दिखने लगता है
- Resolution बढ़ाने से इसे कुछ हद तक कम किया जा सकता है, लेकिन real-time simulation में compute resources सीमित होते हैं
- Vorticity confinement हर step में गायब हो रहे छोटे details को खोजकर amplify करने का तरीका है
- यह पूरी तरह realistic तरीका नहीं है, लेकिन छोटे scale के details को मोटे तौर पर physically plausible स्थानों पर बनाए रखता है
- मूल रूप से इसे helicopter blade के आसपास के जटिल flow fields को engineering simulations में संभालने के लिए बनाया गया था
- हर grid point के curl से vorticity मापी जाती है, फिर आसपास vorticity के अधिक दिशा-परिवर्तन वाले gradient को निकाला जाता है, और confinement constant
ε > 0से नियंत्रित rotational force को velocity field में जोड़ा जाता है- लगभग
0–15जैसे कम confinement values भी बड़ा अंतर पैदा कर सकते हैं - अधिक values stylized billowing flow बना सकती हैं
- लगभग
Curl noise से turbulence synthesize करना
- Curl noise मौजूदा velocity field की vorticity को मापकर बढ़ाने के बजाय, noise function से नया scalar vorticity field बनाने का तरीका है
- गणितीय रूप से random vorticity field
φ = rand * zsynthesize करके उसे मौजूदा vorticityωमें जोड़ा जाता है, जिससे final vorticityω* = ω + φबनती है - Smoke और fire जैसे तेज़ी से चलने वाले तथा अधिक turbulent fluids पर vorticity confinement और curl noise का असर बड़ा होता है
- वास्तविक curl noise field
φसमय के साथ बदलती है और fluid flow के साथ advect भी होती है
Fire के लिए fuel और temperature जोड़े जाते हैं
- केवल बुनियादी fluid routine से smoke जैसी flow बनाई जा सकती है, लेकिन fire और smoke को simulate करने के लिए कुछ अतिरिक्त channels चाहिए
- Combustion model में fuel density
ρऔर temperature fieldTजोड़े जाते हैं0 ≤ ρ ≤ 1fuel density हैT > 0हर स्थान का temperature है
- यहाँ यह माना गया है कि system के अंदर का fuel पहले से ignited है और लगातार heat जोड़ रहा है, इसलिए unignited fuel की समस्या पर चर्चा नहीं की जाती
- हर timestep में fuel निर्दिष्ट combustion temperature के अनुसार तापमान बढ़ाता है
- temperature को
T' = max(T, ρ * T_burn)के रूप में update किया जाता है
- temperature को
- Heat गर्म जगह से ठंडी जगह की ओर फैलती है, और fluid की बड़ी flow भी heat को transport करती है
- simulation में temperature field को velocity field के साथ advect किया जाता है
- reacting molecules भी fluid के साथ चलती हैं, इसलिए fuel field को भी advect किया जाता है
- गर्म molecules Stefan-Boltzmann Law के अनुसार प्रकाश के रूप में तापमान emit करते हैं
- Physically accurate simulation में Stefan-Boltzmann constant का उपयोग किया जाता है
- Graphics simulation में artist के लिए cooling rate
σ_coolको नियंत्रित कर पाना अधिक उपयोगी होता है
- Fuel हर timestep पर combustion rate
γ_fuelके अनुसार कम होता है
Thermal buoyancy से गर्म fluid को ऊपर उठाना
- केवल temperature field की गणना करने से अभी fluid flow पर कोई असर नहीं पड़ता, इसलिए यह प्रभाव जोड़ना होता है कि गर्म हवा ऊपर उठे और ठंडी हवा नीचे जाए
- Thermal buoyancy temperature के अनुपात में ऊपर की ओर बल velocity field में जोड़ती है
- Incompressible flow मानने के कारण वास्तविक air expansion को model नहीं किया जाता
- velocity field को
u' = u + (β T Δt) jके रूप में update किया जाता है βpositive buoyancy constant है औरjऊपर की unit vector है
- Combustion model और thermal buoyancy को मिलाने पर fire जैसा दिखने वाला fluid बन सकता है
- उचित buoyancy और cooling values पर बड़ा, उभरता हुआ material column मिलता है
- इस चरण का परिणाम सटीक flame की तुलना में smoke के अधिक करीब होता है
- पूरा loop velocity self-advection, combustion, vorticity confinement, thermal buoyancy, pressure projection, density·temperature·fuel advection के क्रम से बनता है
Blackbody radiation से flame colors render करना
- Fire एक participating medium है और blackbody radiation के माध्यम से प्रकाश उत्सर्जित करती है
- Fire का नारंगी और लाल रंग blackbody radiation से आता है, और यदि burning fuel simulation को सही formula से render किया जाए तो smoke से fire में परिवर्तन दिखाया जा सकता है
- Planck’s Law किसी निश्चित temperature
Tवाले blackbody द्वारा उत्सर्जित प्रकाश की spectral density का वर्णन करती है - यदि fragment shader में blackbody rendering लागू की जाए, तो fluid, combustion और buoyancy models के ऊपर पूर्ण fire simulation बनाई जा सकती है
- कुछ विस्तार विषय अब भी बचे हुए हैं
- fixed volume के भीतर simulation हल करने वाली non-grid-based techniques
- आधे भरे कप के पानी की तरह वे variable domain problems, जहाँ fluid grid के अलग-अलग क्षेत्रों को घेरती है
- dynamic obstacles
- rendering सुधार के तरीके जैसे अधिक सटीक blackbody radiation, light scattering, और post-processing effects
1 टिप्पणियां
Hacker News की राय
मैंने CFD में PhD की है, लेकिन vorticity confinement तकनीक और curl-noise turbulence पहली बार देख रहा हूँ
industrial CFD जैसे ज़्यादा Reynolds number वाले क्षेत्रों में, numerical method के artificial dissipation को noise से offset करने वाला approach आम तौर पर पसंद नहीं किया जाता
बल्कि high Reynolds number simulations को stabilize करने के लिए अक्सर artificial dissipation चाहिए होता है, और computer graphics में physically सही होने से ज़्यादा विश्वसनीय दिखना अहम लगता है
उसे सही दिखने की भी ज़रूरत नहीं, बस cool दिखना चाहिए
physics nerd होने के नाते, arcade में physics के नियम टूटते देख इशारा करता था और लोग हँसते थे
Nintendo में Mario World पर काम करने वाले एक physicist का translated interview मज़ेदार था; उसने ज़ोर दिया कि Mario की दुनिया की physics “real” physics जैसी न सही, लेकिन real physics की तरह consistent rules रखती थी, और खिलाड़ी गेम में क्या कर सकते हैं यह समझने और puzzles सुलझाने के लिए यह अहम था
उस paper के basic idea का इस्तेमाल करके gas planet textures बनाने वाला एक काफ़ी अच्छा program बनाया था: https://github.com/smcameron/gaseous-giganticus
“Unreal Engine कुछ ही सेकंड में कर देता है, तो आपका CFD software एक simulation में कई घंटे क्यों लेता है” यह सवाल एक से ज़्यादा बार पूछा गया है
https://en.wikipedia.org/wiki/John_Steinhoff
https://en.wikipedia.org/wiki/Vorticity_confinement
संबंधित papers भी हैं:
https://www.researchgate.net/publication/239547604_Modificat...
https://www.researchgate.net/publication/265066926_Computati...
बहुत पहले कहीं एक लेख पढ़कर मैंने C में toy-level की बेहद simple fire simulation बनाई थी
हर pixel की brightness को उसके बिल्कुल पास वाले pixels की average brightness पर set कर देना होता है, और नीचे से ऊपर की ओर calculate करना होता है
नीचे की तरफ़ बाएँ-दाएँ हिलते कुछ “hot” pixels जोड़ दें तो तुरंत आग बन जाती है, code भी बहुत कम और calculus के बिना काफ़ी बढ़िया दिखती है
1D में यह बस second derivative, यानी curvature है; peak जितनी sharp होगी उतना ज़्यादा negative, trough जितना sharp होगा उतना ज़्यादा positive
value को उतना बदलने पर averaging effect आता है, और discretized form सचमुच averaging ही है
असल में आप लगातार calculus ही कर रहे थे
रास्ता जानना और उस रास्ते पर चलना अलग बातें हैं
intuitive graphics से समझाने वाला 3Blue1Brown video भी है: https://youtube.com/watch?v=ToIXSwZ1pJU
games के लिए fire और smoke simulation, GPU पर fluid simulation की बात हो रही है; लेकिन अगर ये effects game में चलें, तो GPU पहले से busy नहीं होगा क्या, ऐसा लगता है
CFD problem चलाते हुए साथ में rendering करना काफ़ी बड़ा load लगता है
जब dGPU rendering-related काम कर रहा हो, तब क्या iGPU पर ऐसी चीज़ें चलाई जा सकती हैं, या iGPU इतना कमज़ोर होता है कि CPU पर उतारना बेहतर होगा, यह भी जानना चाहूँगा
आजकल के GPU बहुत powerful हैं और physics, fancy render passes, fluid simulation, “game AI” unit pathfinding वगैरह को 100FPS से ज़्यादा पर संभाल सकते हैं
लंबा जवाब यह है कि 60FPS से ऊपर की बहुत तेज़ “slideshow” frames render करने के बीच का समय frame budget होता है, और आम तौर पर 5–30ms के भीतर अगले frame की state और rendering के लिए ज़रूरी calculations करने होते हैं
इसमें map पर units की movement, flame physics calculation, terrain texture copy, materials वाले vertices rendering आदि शामिल हो सकते हैं, और कई game engines में GPU हर frame ऐसे दर्जनों अलग calculations करता है
GPU मूल रूप से main computer से जुड़ा एक secondary computer है; हर frame कई tasks भेजें तो वह results देता है, और उन results को मिलाकर game जैसा दृश्य बनाया जाता है
iGPU लगभग कोई इस्तेमाल नहीं करता
आम तौर पर primary dGPU की तुलना में वे इतने बेकार होते हैं कि उन्हें ignore कर दिया जाता है
उसे balance करने का दौर दिलचस्प होगा, और लगता है कि धीरे-धीरे local और remote computing resources load बाँटेंगे
याद है कि Red Faction में लगातार टूटती दीवारें देखते हुए मैंने वह setting assign की थी या नोटिस की थी
लगभग Minecraft जैसा था, लेकिन Mars पर rocket launcher के साथ
GPU इस्तेमाल करने के लिए ज़रूरी नहीं कि आप गेम ही खेल रहे हों
आजकल GPU मोड वाले rendering software भी काफी हैं
हालांकि GPU algorithms बहुत ज़्यादा parallelized होते हैं, इसलिए वे अक्सर CPU simulation algorithms से अलग होते हैं
EmberGen consumer GPU पर आग और धुएँ को real time में simulate करता है, और node-based workflow भी support करता है, जिससे नए effects बनाना आसान हो जाता है—यह वाकई कमाल का software है
जो workflow पहले घंटों लेता था, उसे अब कुछ मिनटों में ठीक किया जा सकता है
https://jangafx.com/software/embergen/
मुझे लगा था यह लेख EmberGen के बारे में होगा, और सच कहूँ तो थोड़ा अफसोस है कि EmberGen को HN पर ज़्यादा attention नहीं मिला: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
EmberGen/JangaFX से मेरा कोई संबंध नहीं है, बस एक संतुष्ट ग्राहक हूँ
https://odin-lang.org/showcase/embergen/
अगर आपको ऐसी चीज़ें पसंद हैं तो Ten Minute Physics भी मज़ेदार लगेगा
खासकर chapter 17, “How to write an Eulerian Fluid Simulator with 200 lines of code”, अच्छा है
https://matthias-research.github.io/pages/tenMinutePhysics/i...
गणित background से software engineer बने किसी व्यक्ति के लिए CFD simulation में शुरुआत करने के लिए कौन-से resources अच्छे रहेंगे, यह जानना चाहता हूँ
यह topic सच में बहुत दिलचस्प है, लेकिन vector calculus या partial differential equations किए हुए बहुत समय हो गया है, इसलिए गणित काफी जंग खा चुका है
https://www.youtube.com/watch?v=zxiqA8_CiC4
मुफ्त non-commercial “Apprentice” version में सिर्फ rendering और collaboration features सीमित हैं
हालांकि यह काफी गहरा tool है
software side से इस industry में आने पर ऐसे tools सीखने का workflow बिल्कुल अलग होता है
कई लोग कहते हैं कि Houdini किसी 3D modeling program से ज़्यादा IDE जैसा है, और कई मायनों में मैं सहमत हूँ
Blender जैसे visual tools इस्तेमाल करने के बजाय लगभग सब कुछ node networks बनाकर और attributes व parameters modify करके किया जाता है
ज़्यादातर काम Python से किया जा सकता है और यह 3ds Max जैसी चीज़ों से साफ-सुथरा है, लेकिन compile नहीं होता, इसलिए बड़ी simulations में performance खराब होती है
इसकी अपनी C-family language VEX भी काम की है, और ज़्यादा जटिल गणित जैसे fine-grained कामों के लिए और भी granular node systems हैं
technical तौर पर लगभग सब कुछ data-oriented workflow है
लेकिन अगर आप “docs पढ़कर सीखने” वाले type हैं, तो आपको tutorials से जल्दी प्यार करना पड़ेगा
जिन environments या paradigms पर मैंने काम किया है, उनसे यह बहुत अलग है, और community आम तौर पर मददगार है, लेकिन curse of knowledge काफी गहरा है
अगर आप सच में करना चाहते हैं, तो उस field में नौकरी लेना अच्छा रहेगा, और Federal या Contractor side से Marshall Space Flight Center या Ames में apply किया जा सकता है
Ames में Top500 के हिसाब से Aitken [#85, 9.07 PFlops], Pleiades [#132, 5.95 PFlops], Electra [#143, 5.44 PFlops] systems हैं
GRC, LARC, JSC में भी कुछ systems हैं
कम से कम कुछ साल पहले तक Contractor/Federal integration काफी अच्छी थी, और funding allocation को छोड़ दें तो लगभग transparent थी
NASA के अंदर MSFC का Propulsion Structural, Thermal & Fluid Analysis [2][3] और Ames का Entry Systems [4] group काफी जाना-माना है
उस समय Overflow/LARC [5] या Loci/Mississippi State University [6] का इस्तेमाल करके moving overset grids, करीब 10–20 reactive combustion species, और Lagrangian evaporating particle dynamics के साथ लगभग 100 million cell scale की vehicle या vehicle+launch pad Hybrid RANS/LES simulations चलाई जाती थीं
SSME और SRB साथ में ignite होते थे, और launch के समय water suppression system भी शामिल होता था
हालांकि यह जानकारी 10 साल पुरानी है, इसलिए आज की state of the art नहीं पता, और अब तक यह इससे आगे बढ़ चुकी होगी
industry किस दिशा में दिलचस्पी रखती है, यह जानना हो तो पुरानी होने के बावजूद 2014 की CFD Vision 2030 Study खराब intro resource नहीं है [7]
Supercomputing का ticket लेकर वहाँ घूमना भी अच्छा रहेगा
इस साल यह Denver में हुआ था [8]
हालांकि focus “large-scale” side पर है, इसलिए आपको विशाल weather simulations या nebula dynamics ज़्यादा देखने को मिलेंगे
conference खुद अच्छी है, लेकिन #CPUs/#GPUs/#FPGAs++ जैसी scale achievements न हों तो attention पाना मुश्किल होता है
NASA के बाहर government side में NIST(Gaithersburg), DOE(Oak Ridge, Sandia, Los Alamos), Air Force(AF Research Lab), Huntington Beach हैं
[1] NASA Advanced Supercomputing Division: https://en.wikipedia.org/wiki/NASA_Advanced_Supercomputing_D...
[2] NASA, MSFC: https://www.nasa.gov/wp-content/uploads/2016/01/g-28367g_pst...
[3] कुछ पुराने उदाहरण: https://ntrs.nasa.gov/api/citations/20140016892/downloads/20...
[4] NASA Ames: https://www.nasa.gov/entry-systems-and-technology-division/
[5] OVERFLOW/NASA/LARC: https://overflow.larc.nasa.gov/
[6] Loci/MSU: https://simcenter.msstate.edu/
[7] CFD Vision 2030 Study: https://ntrs.nasa.gov/api/citations/20140003093/downloads/20...
[8] Supercomputing SC23: https://sc23.supercomputing.org/
इस क्षेत्र में सक्रिय Muller का दूसरा पार्ट भी है: https://matthias-research.github.io/pages/tenMinutePhysics/i...
बाद में यह किताब के रूप में आया, और अब अपने दूसरे संस्करण में Fluid Simulation for Computer Graphics बन गया है