स्क्रीन जल प्रतिपादन

तकनीकी ग्राफिक्स / रेंडरिंग में मेरा आखिरी काम पानी के प्रतिपादन के लिए एक अच्छा समाधान खोजना था। विशेष रूप से, कणों के आधार पर पानी के पतले और तेजी से बढ़ते जेट का प्रतिपादन। पिछले सप्ताह के दौरान, मैंने अच्छे परिणामों के बारे में सोचा, इसलिए मैं इस बारे में एक लेख लिखूंगा।

मैं वास्तव में पानी का प्रतिपादन करते समय स्वर / मार्चिंग क्यूब्स के दृष्टिकोण को पसंद नहीं करता (देखें, उदाहरण के लिए, ब्लेंडर में एक तरल पदार्थ अनुकरण)। जब पानी की मात्रा उसी पैमाने पर होती है जैसे कि रेंडरिंग के लिए इस्तेमाल किया जाता है, तो आंदोलन काफ़ी असतत है। ग्रिड के रिज़ॉल्यूशन को बढ़ाकर इस समस्या को हल किया जा सकता है, लेकिन वास्तविक समय में अपेक्षाकृत लंबी दूरी पर पतले जेट के लिए यह केवल अव्यावहारिक है, क्योंकि यह निष्पादन के समय और कब्जे वाली स्मृति को बहुत प्रभावित करता है। (स्थिति में सुधार के लिए विरल स्वर संरचनाओं का उपयोग करने के लिए एक मिसाल है। लेकिन मुझे यकीन नहीं है कि गतिशील प्रणालियों के लिए यह कितना अच्छा है। इसके अलावा, यह कठिनाई का स्तर नहीं है जिसके साथ मैं काम करना चाहूंगा।)

मैंने जो पहला विकल्प खोजा वह था मुलर का स्क्रीन स्पेस मेज़। वे गहराई बफर में पानी के कणों के प्रतिपादन का उपयोग करते हैं, इसे चौरसाई करते हैं, समान गहराई के जुड़े टुकड़ों को पहचानते हैं और मार्चिंग वर्गों का उपयोग करके परिणाम से मेष का निर्माण करते हैं। आज, यह विधि संभवतः 2007 की तुलना में अधिक लागू हो गई है (क्योंकि अब हम गणना shader में एक जाल बना सकते हैं), लेकिन यह अभी भी जटिलता और लागत के एक बड़े स्तर के साथ जुड़ा हुआ है जितना मैं चाहूंगा।

अंत में, मुझे जीडीसी 2010 के साथ साइमन ग्रीन की प्रस्तुति मिली, स्क्रीन स्पेस फ़्लूअर रेंडरिंग फॉर गेम्स। यह ठीक उसी तरह से शुरू होता है जैसे स्क्रीन स्पेस मेशेस: कणों को गहराई बफर में प्रस्तुत करने और इसे चौरसाई करने के साथ। लेकिन मेष के निर्माण के बजाय, परिणामी बफर का उपयोग मुख्य दृश्य में तरल को छाया देने और बनाने के लिए किया जाता है (गहराई से रिकॉर्डिंग करके।) मैंने इस तरह की प्रणाली को लागू करने का फैसला किया।

ट्रेनिंग

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

इस तरह की स्कीम का मतलब है कि मैं लिक्विड लेयर में लगभग कुछ भी रेंडर कर सकता हूं, और ऐसा लगेगा कि मैं इसके होने की उम्मीद करता हूं। मेरे डेमो दृश्य के संदर्भ में, इसका मतलब है कि उप-उत्सर्जक से कुछ जेट और स्पलैश एक साथ विलय कर सकते हैं। इसके अलावा, यह अन्य जल प्रणालियों के मिश्रण की अनुमति देगा, उदाहरण के लिए, ऊंचाई वाले क्षेत्रों के आधार पर वॉल्यूम, जो तब उसी तरह प्रदान किए जा सकते हैं। (मैंने अभी तक इसका परीक्षण नहीं किया है।)

मेरे दृश्य में पानी का स्रोत एक मानक कण प्रणाली है। वास्तव में, कोई भी तरल अनुकरण नहीं किया जाता है। यह, बदले में, इसका मतलब है कि कण एक दूसरे को पूरी तरह से भौतिक रूप से ओवरलैप नहीं करते हैं, लेकिन अंतिम परिणाम व्यवहार में स्वीकार्य लगता है।

तरल पदार्थ बफर प्रतिपादन

इस तकनीक में पहला कदम आधार द्रव बफर को प्रस्तुत करना है। यह एक ऑफ-स्क्रीन बफर है जिसमें मेरे कार्यान्वयन के वर्तमान चरण में) निम्नलिखित हैं: स्क्रीन स्पेस और शोर मूल्य में द्रव चौड़ाई, गति वेक्टर। इसके अलावा, हम एक कण के प्रत्येक चतुष्कोण को एक गोलाकार (अच्छी तरह से, अण्डाकार) गेंद "" में बदलने के लिए गहराई बफर को गहराई से रिकॉर्ड करके गहराई से बफर प्रस्तुत करते हैं।

गहराई और चौड़ाई की गणना काफी सरल है:

frag_out o; float3 N; N.xy = i.uv*2.0 - 1.0; float r2 = dot(N.xy, N.xy); if (r2 > 1.0) discard; Nz = sqrt(1.0 - r2); float4 pixel_pos = float4(i.view_pos + N * i.size, 1.0); float4 clip_pos = mul(UNITY_MATRIX_P, pixel_pos); float depth = clip_pos.z / clip_pos.w; o.depth = depth; float thick = Nz * i.size * 2; 

(बेशक, गहराई की गणना को सरल बनाया जा सकता है; क्लिप पोजीशन से हमें केवल z और w की आवश्यकता होती है।)

थोड़ी देर बाद, हम मोशन और शोर वैक्टर के लिए टुकड़े टुकड़े करने के लिए वापस आ जाएंगे।

मस्ती शीर्षासन छाया में शुरू होती है, और यह यहां है कि मैं ग्रीन तकनीक से विचलित हूं। इस परियोजना का लक्ष्य पानी के उच्च गति वाले जेट्स को प्रस्तुत करना है; इसे गोलाकार कणों की मदद से महसूस किया जा सकता है, लेकिन निरंतर जेट बनाने के लिए उनमें से एक बड़ी राशि की आवश्यकता होगी। इसके बजाय, मैं उनकी गति के आधार पर कणों के चतुष्कोणों को खींचूंगा, जो बदले में गहराई की गेंदों को फैलाते हैं, जिससे उन्हें गोलाकार नहीं, बल्कि अण्डाकार बनाते हैं। (चूंकि गहराई की गणना यूवी पर आधारित है, जो नहीं बदलती है, यह सब काम करता है।)

अनुभवी एकता उपयोगकर्ता आश्चर्यचकित हो सकते हैं कि मैं यूनिटी कण प्रणाली में उपलब्ध बिल्ट-इन स्ट्रेच्ड बिलबोर्ड मोड का उपयोग क्यों नहीं करता। स्ट्रेच्ड बिलबोर्ड दुनिया के अंतरिक्ष में वेग वेक्टर के साथ बिना शर्त स्ट्रेचिंग करता है। सामान्य मामले में, यह काफी उपयुक्त है, लेकिन यह एक बहुत ही ध्यान देने योग्य समस्या की ओर जाता है जब वेग वेक्टर को आगे-सामने वाले कैमरा वेक्टर (या इसके बहुत करीब) के साथ सह-निर्देशित किया जाता है। बिलबोर्ड स्क्रीन पर फैला है, जो इसकी दो आयामी प्रकृति को बहुत ध्यान देने योग्य बनाता है।

इसके बजाय, मैं कैमरे के उद्देश्य से एक बिलबोर्ड का उपयोग करता हूं और कण के विमान पर वेग वेक्टर को प्रोजेक्ट करता हूं, इसका उपयोग चतुष्कोण को फैलाने के लिए करता हूं। यदि वेग वेक्टर विमान के लिए लंबवत है (स्क्रीन से निर्देशित या दूर), तो कण अस्थिर और गोलाकार रहता है, जैसा कि इसे चाहिए, और जब इसे झुकाया जाता है, तो कण इस दिशा में खिंच जाता है, जो कि हमें चाहिए।

चलो एक लंबी व्याख्या छोड़ देते हैं, यहाँ एक काफी सरल कार्य है:

 float3 ComputeStretchedVertex(float3 p_world, float3 c_world, float3 vdir_world, float stretch_amount) { float3 center_offset = p_world - c_world; float3 stretch_offset = dot(center_offset, vdir_world) * vdir_world; return p_world + stretch_offset * lerp(0.25f, 3.0f, stretch_amount); } 

स्क्रीन स्पेस के मोशन वेक्टर की गणना करने के लिए, हम वैक्टर के दो सेटों की गणना करते हैं:

 float3 vp1 = ComputeStretchedVertex( vertex_wp, center_wp, velocity_dir_w, rand); float3 vp0 = ComputeStretchedVertex( vertex_wp - velocity_w * unity_DeltaTime.x, center_wp - velocity_w * unity_DeltaTime.x, velocity_dir_w, rand); o.motion_0 = mul(_LastVP, float4(vp0, 1.0)); o.motion_1 = mul(_CurrVP, float4(vp1, 1.0)); 

ध्यान दें कि चूंकि हम मुख्य मार्ग में गति वैक्टरों की गणना करते हैं और वेग वैक्टरों के पारित होने में नहीं, इसलिए यूनिटी हमें दृश्य से पूर्व या अविभाजित वर्तमान प्रक्षेपण प्रदान नहीं करती है। इसे ठीक करने के लिए, मैंने एक सरल स्क्रिप्ट को संबंधित कण प्रणालियों में जोड़ा:

 public class ScreenspaceLiquidRenderer : MonoBehaviour { public Camera LiquidCamera; private ParticleSystemRenderer m_ParticleRenderer; private bool m_First; private Matrix4x4 m_PreviousVP; void Start() { m_ParticleRenderer = GetComponent(); m_First = true; } void OnWillRenderObject() { Matrix4x4 current_vp = LiquidCamera.nonJitteredProjectionMatrix * LiquidCamera.worldToCameraMatrix; if (m_First) { m_PreviousVP = current_vp; m_First = false; } m_ParticleRenderer.material.SetMatrix("_LastVP", GL.GetGPUProjectionMatrix(m_PreviousVP, true)); m_ParticleRenderer.material.SetMatrix("_CurrVP", GL.GetGPUProjectionMatrix(current_vp, true)); m_PreviousVP = current_vp; } } 

मैं पिछले मैट्रिक्स को मैन्युअल रूप से कैश करता हूं क्योंकि Camera.prepretViewProjectionMatrix गलत परिणाम देता है।

¯ \ _ (ツ) _ / ツ

(इसके अलावा, यह विधि प्रतिपादन प्रतिपादन का उल्लंघन करती है; यह किसी भी सामग्री के लिए उपयोग करने के बजाय व्यवहार में वैश्विक मैट्रिक्स स्थिरांक स्थापित करने के लिए विवेकपूर्ण हो सकती है।)

आइए हम खंडित छाया में वापस जाएं: हम स्क्रीन स्थान की गति वैक्टर की गणना करने के लिए अनुमानित पदों का उपयोग करते हैं:

 float3 hp0 = i.motion_0.xyz / i.motion_0.w; float3 hp1 = i.motion_1.xyz / i.motion_1.w; float2 vp0 = (hp0.xy + 1) / 2; float2 vp1 = (hp1.xy + 1) / 2; #if UNITY_UV_STARTS_AT_TOP vp0.y = 1.0 - vp0.y; vp1.y = 1.0 - vp1.y; #endif float2 vel = vp1 - vp0; 

(गति वेक्टर गणना लगभग अपरिवर्तित है https://github.com/keijiro/ParticleMotionVector/blob/master/Assets/ParticleMotionVector/Shaders/Motion.cginc से लिया गया

अंत में, द्रव बफर में अंतिम मूल्य शोर है। मैं चार कणों में से एक (एकल बनावट में पैक) का चयन करने के लिए प्रत्येक कण के लिए एक स्थिर यादृच्छिक संख्या का उपयोग करता हूं। फिर इसे गति और एकता द्वारा कण आकार में घटाया जाता है (इसलिए, तेज और छोटे कण noisier होते हैं)। इस शोर मूल्य का उपयोग मानदंड को विकृत करने और फोम की एक परत को जोड़ने के लिए शेडिंग पास में किया जाता है। ग्रीन का काम तीन-चैनल सफेद शोर का उपयोग करता है, लेकिन एक नया काम (स्क्रीन स्पेस फ्लुइड रेंडरिंग विथ कर्वचर फ्लो) पेरलिन शोर का उपयोग करने का प्रस्ताव करता है। मैं विभिन्न पैमानों के साथ वोरोनोई शोर / सेल शोर का उपयोग करता हूं:

मिश्रण मुद्दे (और समाधान)

और यहां मेरे कार्यान्वयन की पहली समस्याएं दिखाई देती हैं। कणों की मोटाई की सही गणना के लिए योज्य मिलाया जाता है। चूंकि मिश्रण सभी आउटपुट को प्रभावित करता है, इसका मतलब है कि शोर और गति वैक्टर भी additively मिश्रित होते हैं। एडिटिव शोर हमें काफी सूट करता है, लेकिन एडिटिव वैक्टर नहीं, और अगर आप उन्हें छोड़ देते हैं, तो आपको घृणित समय एंटी-एलियासिंग (टीएए) और गति धुंधला हो जाता है। इस समस्या को हल करने के लिए, जब एक द्रव बफर का प्रतिपादन करते हैं, मैं बस मोशन वैक्टर को मोटाई से गुणा करता हूं और छायांकन पास में कुल मोटाई से विभाजित करता हूं। यह हमें सभी अतिव्यापी कणों के लिए एक भारित औसत गति वेक्टर देता है; काफी नहीं है कि हम क्या जरूरत है (अजीब कलाकृतियों बनाया जाता है जब कई जेट प्रतिच्छेद), लेकिन काफी स्वीकार्य।

एक अधिक जटिल समस्या गहराई है; गहराई बफ़र के सही प्रतिपादन के लिए, हमें गहराई रिकॉर्डिंग और गहराई जाँच दोनों सक्रिय करने की आवश्यकता है। यह समस्याएँ पैदा कर सकता है यदि कण छँटे नहीं जाते हैं (क्योंकि रेंडरिंग ऑर्डर में अंतर दूसरों द्वारा छोड़े जाने वाले कणों के उत्पादन का कारण बन सकता है)। इसलिए, हम एकता कण प्रणाली को कणों को गहराई से क्रमबद्ध करने का आदेश देते हैं, और फिर हम अपनी उंगलियों और आशा को पार करते हैं। यह सिस्टम गहराई से प्रस्तुत करेगा। हमारे पास ओवरलैपिंग सिस्टम के मामले * * होंगे (उदाहरण के लिए, कणों के दो जेटों का अंतर) जो सही ढंग से संसाधित नहीं होते हैं, जिससे छोटी मोटाई होगी। लेकिन यह बहुत बार नहीं होता है, और उपस्थिति को बहुत प्रभावित नहीं करता है।

सबसे अधिक संभावना है, गहराई और रंग बफ़र्स को पूरी तरह से अलग करने के लिए सही दृष्टिकोण होगा; इसके लिए पेबैक दो-पास रेंडरिंग होगा। यह सिस्टम सेट करते समय इस मुद्दे की खोज के लायक है।

गहराई का चौरसाई

अंत में, ग्रीन तकनीक में सबसे महत्वपूर्ण बात। हमने गोलाकार गेंदों का एक गुच्छा गहराई बफर में प्रदान किया, लेकिन वास्तव में, पानी में "गेंदों" शामिल नहीं हैं। तो अब हम इस अनुमान को लेते हैं और इसे एक तरल की सतह की तरह बनाने के लिए इसे धुंधला करते हैं।

भोली दृष्टिकोण बस पूरे बफर में गाऊसी शोर की गहराई को लागू करना है। यह अजीब परिणाम बनाता है - यह दूर के बिंदुओं को करीब से अधिक चिकना करता है, और सिल्हूट के किनारों को धुंधला करता है। इसके बजाय, हम धब्बा त्रिज्या को गहराई से बदल सकते हैं, और किनारों को बचाने के लिए दो तरफा धब्बा का उपयोग कर सकते हैं।

यहां केवल एक समस्या उत्पन्न होती है: इस तरह के बदलाव धब्बा को अप्रभेद्य बनाते हैं। साझा ब्लर को दो पासों में किया जा सकता है: क्षैतिज रूप से धुंधला, और फिर लंबवत। Indistinguishable blurring एक पास में किया जाता है। यह अंतर महत्वपूर्ण है क्योंकि साझा धब्बा रेखीय रूप से (O (w) + O (h)), और गैर-साझा धुंधला तराजू वर्ग (O (w * h))। बड़े पैमाने पर, गैर-साझा धुंधलापन जल्दी से अभ्यास में अनुपयुक्त हो रहा है।

वयस्कों, जिम्मेदार डेवलपर्स के रूप में, हम स्पष्ट कदम उठा सकते हैं: अपनी आँखें बंद करें, बहाना करें कि दो-तरफा शोर * साझा किया गया है, और अभी भी इसे अलग क्षैतिज और ऊर्ध्वाधर गलियारे के साथ लागू करें।

ग्रीन ने अपनी प्रस्तुति में दर्शाया कि यद्यपि यह दृष्टिकोण परिणामी परिणाम में कलाकृतियों का निर्माण करता है (विशेषकर जब मानदंडों का पुनर्निर्माण करते हुए), छायांकन चरण उन्हें अच्छी तरह से छुपाता है। जब मैं बनाने वाली पानी की संकरी धाराओं के साथ काम करता हूं, तो ये कलाकृतियां कम ध्यान देने योग्य होती हैं और विशेष रूप से परिणाम को प्रभावित नहीं करती हैं।

लकीर खींचने की क्रिया

हमने अंत में द्रव बफर के साथ काम करना समाप्त कर दिया। अब चलिए प्रभाव के दूसरे भाग पर चलते हैं: मुख्य छवि का छायांकन और संयोजन।

यहाँ हम कई एकता प्रतिपादन प्रतिबंधों के पार आते हैं। मैंने केवल सूरज और स्काईबॉक्स की रोशनी से पानी को रोशन करने का फैसला किया; अतिरिक्त प्रकाश स्रोतों का समर्थन करने के लिए या तो कई पास की आवश्यकता होती है (यह बेकार है!) या GPU पक्ष पर एक प्रकाश खोज संरचना का निर्माण (महंगा और बल्कि जटिल)। इसके अलावा, चूंकि एकता छाया मानचित्रों तक पहुंच प्रदान नहीं करती है, और दिशात्मक रोशनी स्क्रीन स्पेस की छाया का उपयोग करती है (अपारदर्शी ज्यामिति द्वारा प्रस्तुत गहराई बफर के आधार पर), हमारे पास सूर्य के प्रकाश स्रोत से छाया के बारे में जानकारी तक पहुंच नहीं है। आप विशेष रूप से पानी के लिए स्क्रीन स्पेस का एक छाया नक्शा बनाने के लिए सूर्य के प्रकाश स्रोत से एक कमांड बफर संलग्न कर सकते हैं, लेकिन अभी तक मैंने ऐसा नहीं किया है।

छायांकन का अंतिम चरण एक स्क्रिप्ट के माध्यम से नियंत्रित किया जाता है, और ड्रॉ कॉल भेजने के लिए कमांड बफर का उपयोग करता है। यह आवश्यक है क्योंकि गति वेक्टर बनावट (अस्थायी एंटी-अलियासिंग (TAA) और गति धब्बा के लिए उपयोग किया जाता है) का उपयोग ग्राफिक्स के लिए प्रत्यक्ष रेंडरिंग के लिए नहीं किया जा सकता है ।etetenderTarget () का उपयोग कर। मुख्य कैमरे से जुड़ी स्क्रिप्ट में, हम निम्नलिखित लिखते हैं:

 void Start() { //... m_QuadMesh = new Mesh(); m_QuadMesh.subMeshCount = 1; m_QuadMesh.vertices = new Vector3[] { new Vector3(0, 0, 0.1f), new Vector3(1, 0, 0.1f), new Vector3(1, 1, 0.1f), new Vector3(0, 1, 0.1f), }; m_QuadMesh.uv = new Vector2[] { new Vector2(0, 0), new Vector2(1, 0), new Vector2(1, 1), new Vector2(0, 1), }; m_QuadMesh.triangles = new int[] { 0, 1, 2, 0, 2, 3, }; m_QuadMesh.UploadMeshData(false); m_CommandBuffer = new CommandBuffer(); m_CommandBuffer.Clear(); m_CommandBuffer.SetProjectionMatrix( GL.GetGPUProjectionMatrix( Matrix4x4.Ortho(0, 1, 0, 1, -1, 100), false)); m_CommandBuffer.SetRenderTarget( BuiltinRenderTextureType.CameraTarget, BuiltinRenderTextureType.CameraTarget); m_CommandBuffer.DrawMesh( m_QuadMesh, Matrix4x4.identity, m_Mat, 0, m_Mat.FindPass("LIQUIDCOMPOSITE")); m_CommandBuffer.SetRenderTarget( BuiltinRenderTextureType.MotionVectors, BuiltinRenderTextureType.Depth); m_CommandBuffer.DrawMesh( m_QuadMesh, Matrix4x4.identity, m_Mat, 0, m_Mat.FindPass("MOTION")); } 

कलर बफ़र्स और मोशन वैक्टर को एक साथ MRT (मल्टी रेंडर टार्गेट) के साथ प्रदान नहीं किया जा सकता है। मुझे इसका कारण पता नहीं चल पाया। इसके अलावा, उन्हें अलग-अलग गहराई वाले बफ़र्स को बांधने की आवश्यकता होती है। सौभाग्य से, हम इन दोनों गहराई बफ़र्स को गहराई से लिखते हैं, इसलिए अस्थायी एंटी-अलियासिंग फिर से प्रोजेक्ट करना ठीक काम करता है (ओह, यह "ब्लैक बॉक्स" इंजन के साथ काम करने के लिए एक खुशी है)।

प्रत्येक फ्रेम में, हम OnPostRender () से एक समग्र रेंडर बाहर फेंकते हैं:

 RenderTexture GenerateRefractionTexture() { RenderTexture result = RenderTexture.GetTemporary(m_MainCamera.activeTexture.descriptor); Graphics.Blit(m_MainCamera.activeTexture, result); return result; } void OnPostRender() { if (ScreenspaceLiquidCamera && ScreenspaceLiquidCamera.IsReady()) { RenderTexture refraction_texture = GenerateRefractionTexture(); m_Mat.SetTexture("_MainTex", ScreenspaceLiquidCamera.GetColorBuffer()); m_Mat.SetVector("_MainTex_TexelSize", ScreenspaceLiquidCamera.GetTexelSize()); m_Mat.SetTexture("_LiquidRefractTexture", refraction_texture); m_Mat.SetTexture("_MainDepth", ScreenspaceLiquidCamera.GetDepthBuffer()); m_Mat.SetMatrix("_DepthViewFromClip", ScreenspaceLiquidCamera.GetProjection().inverse); if (SunLight) { m_Mat.SetVector("_SunDir", transform.InverseTransformVector(-SunLight.transform.forward)); m_Mat.SetColor("_SunColor", SunLight.color * SunLight.intensity); } else { m_Mat.SetVector("_SunDir", transform.InverseTransformVector(new Vector3(0, 1, 0))); m_Mat.SetColor("_SunColor", Color.white); } m_Mat.SetTexture("_ReflectionProbe", ReflectionProbe.defaultTexture); m_Mat.SetVector("_ReflectionProbe_HDR", ReflectionProbe.defaultTextureHDRDecodeValues); Graphics.ExecuteCommandBuffer(m_CommandBuffer); RenderTexture.ReleaseTemporary(refraction_texture); } } 

और यह वह जगह है जहां सीपीयू भागीदारी समाप्त हो जाती है, बाद में केवल शेड्स जाते हैं।

चलो गति वैक्टर के पारित होने के साथ शुरू करते हैं। यहाँ पूरा shader कैसा दिखता है:

 #include "UnityCG.cginc" sampler2D _MainDepth; sampler2D _MainTex; struct appdata { float4 vertex : POSITION; float2 uv : TEXCOORD0; }; struct v2f { float2 uv : TEXCOORD0; float4 vertex : SV_POSITION; }; v2f vert(appdata v) { v2f o; o.vertex = mul(UNITY_MATRIX_P, v.vertex); o.uv = v.uv; return o; } struct frag_out { float4 color : SV_Target; float depth : SV_Depth; }; frag_out frag(v2f i) { frag_out o; float4 fluid = tex2D(_MainTex, i.uv); if (fluid.a == 0) discard; o.depth = tex2D(_MainDepth, i.uv).r; float2 vel = fluid.gb / fluid.a; o.color = float4(vel, 0, 1); return o; } 

स्क्रीन स्पेस में गति द्रव बफर के हरे और नीले चैनल में संग्रहीत होती है। चूंकि हमने बफर को प्रतिपादन करते समय मोटाई को गति दी थी, इसलिए हम फिर से भारित औसत गति प्राप्त करने के लिए कुल मोटाई (अल्फा चैनल में स्थित) को विभाजित करते हैं।

यह ध्यान देने योग्य है कि जब पानी की बड़ी मात्रा के साथ काम करते हैं, तो गति बफर के प्रसंस्करण की एक और विधि की आवश्यकता हो सकती है। चूंकि हम मिश्रण के बिना प्रस्तुत करते हैं, पानी के पीछे सब कुछ के लिए गति वैक्टर खो जाते हैं, इन वस्तुओं के टीएए और गति धुंधला को नष्ट करते हैं। पानी की पतली धाराओं के साथ काम करते समय, यह कोई समस्या नहीं है, लेकिन पूल या झील के साथ काम करते समय यह हस्तक्षेप कर सकता है जब हमें सतह के माध्यम से स्पष्ट रूप से दिखाई देने के लिए टीएएए या गति धुंधला वस्तुओं की आवश्यकता होती है।

अधिक दिलचस्प मुख्य छायांकन पास है। तरल की मोटाई के साथ मास्किंग के बाद हमारी पहली प्राथमिकता देखने की जगह (व्यू स्पेस) की स्थिति और सामान्य का पुनर्निर्माण करना है।

 float3 ViewPosition(float2 uv) { float clip_z = tex2D(_MainDepth, uv).r; float clip_x = uv.x * 2.0 - 1.0; float clip_y = 1.0 - uv.y * 2.0; float4 clip_p = float4(clip_x, clip_y, clip_z, 1.0); float4 view_p = mul(_DepthViewFromClip, clip_p); return (view_p.xyz / view_p.w); } float3 ReconstructNormal(float2 uv, float3 vp11) { float3 vp12 = ViewPosition(uv + _MainTex_TexelSize.xy * float2(0, 1)); float3 vp10 = ViewPosition(uv + _MainTex_TexelSize.xy * float2(0, -1)); float3 vp21 = ViewPosition(uv + _MainTex_TexelSize.xy * float2(1, 0)); float3 vp01 = ViewPosition(uv + _MainTex_TexelSize.xy * float2(-1, 0)); float3 dvpdx0 = vp11 - vp12; float3 dvpdx1 = vp10 - vp11; float3 dvpdy0 = vp11 - vp21; float3 dvpdy1 = vp01 - vp11; // Pick the closest float3 dvpdx = dot(dvpdx0, dvpdx0) > dot(dvpdx1, dvpdx1) ? dvpdx1 : dvpdx0; float3 dvpdy = dot(dvpdy0, dvpdy0) > dot(dvpdy1, dvpdy1) ? dvpdy1 : dvpdy0; return normalize(cross(dvpdy, dvpdx)); } 

यह देखने की जगह की स्थिति को फिर से संगठित करने का एक महंगा तरीका है: हम क्लिप स्पेस में स्थिति लेते हैं और प्रक्षेपण के रिवर्स ऑपरेशन करते हैं।

हमें पदों को फिर से बनाने का एक तरीका मिल जाने के बाद, मानदंड सरल हो गए हैं: हम गहराई से बफर में पड़ोसी बिंदुओं की स्थिति की गणना करते हैं और उनसे एक स्पर्शरेखा का निर्माण करते हैं। सिल्हूट के किनारों के साथ काम करने के लिए, हम दोनों दिशाओं में नमूना लेते हैं और सामान्य को फिर से संगठित करने के लिए दृश्य स्थान के निकटतम बिंदु का चयन करते हैं। यह विधि आश्चर्यजनक रूप से अच्छी तरह से काम करती है और केवल बहुत पतली वस्तुओं के मामले में समस्याओं का कारण बनती है।

इसका मतलब है कि हम प्रति पिक्सेल पांच अलग-अलग रिवर्स ऑपरेशन करते हैं (वर्तमान बिंदु और चार पड़ोसी के लिए)। कम खर्चीला तरीका है, लेकिन यह पोस्ट पहले से बहुत लंबी है, इसलिए मैं इसे बाद में छोड़ दूंगा।

परिणामी मानदंड हैं:


मैं द्रव बफर से शोर मूल्य के डेरिवेटिव का उपयोग करके इस गणना को सामान्य रूप से विकृत करता हूं, बल पैरामीटर द्वारा बढ़ाया जाता है और जेट की मोटाई (गति के लिए उसी कारण के लिए) द्वारा विभाजित करके सामान्यीकृत किया जाता है:

 N.xy += NoiseDerivatives(i.uv, fluid.r) * (_NoiseStrength / fluid.a); N = normalize(N); 

हम अंत में छायांकन के साथ ही आगे बढ़ सकते हैं। वॉटर शेडिंग में तीन मुख्य भाग होते हैं: स्पेक्युलर रिफ्लेक्शन, स्पेक्युलर अपवर्तन और फोम।

प्रतिबिंब एक मानक GGX है जो पूरी तरह से मानक एकता shader से लिया गया है। (एक सुधार के साथ, 2% का सही F0 पानी के लिए उपयोग किया जाता है।)

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

 float aspect = _MainTex_TexelSize.y * _MainTex_TexelSize.z; float2 refract_uv = (i.grab_pos.xy + N.xy * float2(1, -aspect) * fluid.a * _RefractionMultiplier) / i.grab_pos.w; float4 refract_color = tex2D(_LiquidRefractTexture, refract_uv); 

(ध्यान दें कि सहसंबंध सुधार का उपयोग किया जाता है; यह वैकल्पिक है - आखिरकार, यह सिर्फ एक सन्निकटन है, लेकिन इसे जोड़ना काफी सरल है।)

यह अपवर्तित प्रकाश तरल से होकर गुजरता है, इसलिए इसका कुछ भाग अवशोषित होता है:

 float3 water_color = _AbsorptionColor.rgb * _AbsorptionIntensity; refract_color.rgb *= exp(-water_color * fluid.a); 

ध्यान दें कि _AbsorptionColor अपेक्षित तरीके के बिल्कुल विपरीत में निर्धारित किया जाता है: प्रत्येक चैनल के मान संचरित प्रकाश के बजाय अवशोषित की मात्रा को इंगित करते हैं। इसलिए, _AbsorptionColor मूल्य के साथ (1, 0, 0) लाल नहीं देता है, लेकिन फ़िरोज़ा रंग (चैती)।

परावर्तन और अपवर्तन को Fresnel गुणांक का उपयोग करके मिलाया जाता है:

 float spec_blend = lerp(0.02, 1.0, pow(1.0 - ldoth, 5)); float4 clear_color = lerp(refract_color, spec, spec_blend); 

उस क्षण तक, हम नियमों (ज्यादातर) से खेलते थे और शारीरिक छायांकन का उपयोग करते थे।

वह काफी अच्छा है, लेकिन उसे पानी की समस्या है। यह देखने में थोड़ा कठिन है:


इसे ठीक करने के लिए, चलो कुछ फोम जोड़ें।

फोम दिखाई देता है जब पानी अशांत होता है और हवा पानी के साथ बुलबुले बनाने के लिए मिलाती है। इस तरह के बुलबुले प्रतिबिंब और अपवर्तन में सभी प्रकार की विविधताएं बनाते हैं, जो सभी पानी को फैलाने वाले प्रकाश की भावना देता है। मैं इस व्यवहार को लिपटे परिवेश प्रकाश के साथ मॉडल करूंगा:

 float3 foam_color = _SunColor * saturate((dot(N, L)*0.25f + 0.25f)); 

यह एक विशेष कारक का उपयोग करके अंतिम रंग में जोड़ा जाता है, जो तरल पदार्थ के शोर और नरम फ्रिसेल गुणांक पर निर्भर करता है:

 float foam_blend = saturate(fluid.r * _NoiseStrength) * lerp(0.05f, 0.5f, pow(1.0f - ndotv, 3)); clear_color.rgb += foam_color * saturate(foam_blend); 

लिपटे हुए परिवेश प्रकाश को ऊर्जा संरक्षण के लिए सामान्यीकृत किया जाता है ताकि इसे प्रसार के सन्निकटन के रूप में इस्तेमाल किया जा सके। फोम के रंग का मिश्रण अधिक ध्यान देने योग्य है। यह ऊर्जा के संरक्षण के कानून का काफी स्पष्ट उल्लंघन है।

लेकिन सामान्य तौर पर, सब कुछ अच्छा दिखता है और धारा को अधिक ध्यान देने योग्य बनाता है:

आगे का काम और सुधार

बनाई गई प्रणाली में, बहुत सुधार किया जा सकता है।

• कई रंगों का उपयोग करना। फिलहाल, अवशोषण की गणना केवल छायांकन के अंतिम चरण में की जाती है और स्क्रीन पर सभी तरल के लिए एक निरंतर रंग और चमक का उपयोग करता है। विभिन्न रंगों के लिए समर्थन संभव है, लेकिन एक दूसरे रंग के बफर की आवश्यकता होती है और बेस द्रव बफर के प्रतिपादन की प्रक्रिया में प्रत्येक कण के लिए अवशोषण अभिन्न के समाधान की आवश्यकता होती है। यह संभावित रूप से एक महंगा ऑपरेशन हो सकता है।
• पूर्ण कवरेज। GPU की तरफ प्रकाश की खोज संरचना तक पहुंच (या तो हाथ से बनाया गया है, या नई एकता HD रेंडरिंग पाइपलाइन के लिए बाध्य करने के लिए धन्यवाद), हम किसी भी प्रकाश स्रोतों के साथ पानी को अच्छी तरह से रोशन कर सकते हैं और सही परिवेश प्रकाश व्यवस्था बना सकते हैं।
• बेहतर अपवर्तन। बैकग्राउंड टेक्सचर की धुंधली एमआईपी बनावट के साथ, हम रफ सतहों के लिए अपवर्तन को बेहतर ढंग से अनुकरण कर सकते हैं। व्यवहार में, यह तरल के छोटे स्प्रे के लिए बहुत उपयोगी नहीं है, लेकिन बड़े संस्करणों के लिए उपयोगी हो सकता है।

यदि मेरे पास अवसर होता, तो मैं इस प्रणाली को एक नाड़ी के नुकसान में सुधार करता, लेकिन फिलहाल इसे पूर्ण कहा जा सकता है।