GPU बाध्य। भाग दो अंतहीन जंगल

लगभग हर खेल में, आभासी दुनिया की दृश्य समृद्धि, सुंदरता और परिवर्तनशीलता बनाने वाली वस्तुओं के साथ खेल के स्तर को भरना आवश्यक है। कोई भी खुली दुनिया का खेल लो। वहाँ पेड़, घास, पृथ्वी और पानी चित्र के मुख्य "प्लेसहोल्डर" हैं। आज बहुत कम GPGPU होंगे, लेकिन मैं आपको यह बताने की कोशिश करूंगा कि जब आप नहीं कर सकते, तो फ्रेम में बहुत सारे पेड़ और पत्थर कैसे खींच सकते हैं, लेकिन वास्तव में चाहते हैं।

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

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

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

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

प्रतिपादन

आइए एक शुरुआत के लिए देखें कि क्या सब कुछ सामान्य स्पीडट्री ऑब्जेक्ट के साथ इतना बुरा है:



यहां मंच पर लगभग 2,000 पेड़ हैं। सब कुछ रेंडर के साथ है, वहाँ पेड़ों को बैचों में संयोजित किया गया है, लेकिन सीपीयू के साथ सब कुछ खराब है। कैमरा रेंडर करते समय आधा ठंडा हो रहा है। और हमें सैकड़ों हजारों चाहिए। हम निश्चित रूप से GameObjects को मना करते हैं, लेकिन अब हमें स्पीडट्री मॉडल की संरचना को उजागर करने, एलओडी को स्विच करने के लिए तंत्र और हैंडल के साथ सब कुछ करने की आवश्यकता है।

स्पीडट्री ट्री में कई एलओडी (आमतौर पर 4) होते हैं, जिनमें से अंतिम एक बिलबोर्ड होता है, और बाकी सभी विस्तार की बदलती डिग्री की ज्यामिति होते हैं। उनमें से प्रत्येक में कई सबमेश होते हैं, इसकी अपनी सामग्री के साथ:


यह स्पीडट्री की विशिष्टता नहीं है। किसी भी संरचना में ऐसी संरचना हो सकती है। LOD स्विचिंग दो उपलब्ध मोड में कार्यान्वित की जाती है:

1. क्रॉस फीका:
   
   
2. स्पीड ट्री:
   
   

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

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

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

वन जनक

लैंडिंग स्वयं सरल और सरल है। प्रत्येक प्रकार के पेड़ के लिए, हम दुनिया को क्वैड में विभाजित करते हैं ताकि प्रत्येक पेड़ एक पेड़ फिट हो। हम सभी क्वैड्स पर जाते हैं और फॉर्म का मास्क चेक करते हैं:



स्तर पर दिए गए बिंदु पर, क्या यहां पेड़ लगाना संभव है? "जंगली" स्थानों के साथ मुखौटा, स्तर डिजाइनर द्वारा तैयार किया गया है। पहले तो पूरी बात CPU और C # पर थी। जनरेटर ने धीरे-धीरे काम किया, और स्तरों का आकार इतना बढ़ गया कि कई दसियों मिनटों तक उत्थान की प्रतीक्षा तनावपूर्ण हो गई। यह जनरेटर को GPU और कंप्यूट shader में स्थानांतरित करने का निर्णय लिया गया था। यहाँ भी, सब कुछ सरल है। हमें जमीन की ऊंचाई, पेड़ लगाने वाले मास्क और एपेंडस्ट्रक्चरर बफ़र की आवश्यकता है, जहां हम उत्पन्न पेड़ (स्थिति और आईडी, यह सब डेटा है) जोड़ते हैं।

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

खींचना और LOD स्विच करना

एक प्रभावी प्रतिपादन करने के लिए पेड़ की स्थिति और प्रकार जानना पर्याप्त नहीं है। रेंडर को भेजने के लिए प्रत्येक फ्रेम को निर्धारित करना आवश्यक है कि कौन सी वस्तुएं दिखाई दे रही हैं और कौन सा एलओडी (ट्रांजिशन लॉजिक को देखते हुए)।

एक विशेष गणना करने वाला शेडर भी ऐसा करेगा। प्रत्येक वस्तु के लिए, फ्रस्टम कलिंग सबसे पहले किया जाता है:


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

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

ड्रॉ कॉल के लिए तर्कों के साथ गणना बफर, को वर्गों में विभाजित किया गया है, जिनमें से प्रत्येक इसके सबमेश के प्रतिपादन को कॉल करने के लिए जिम्मेदार है। वर्तमान फ्रेम में जाली के लिए कंपाउंडर शेडर में, इसी InstanceCount मान को बढ़ाएँ।

यहाँ यह कैसे प्रस्तुत में दिखता है:


GPU रोड़ा culling स्पष्ट अगला कदम है, लेकिन इस तरह के एक कैमरा के साथ RTS के लिए, और बहुत बड़ी पहाड़ियों नहीं, जीत इतनी स्पष्ट नहीं हैं (और यहाँ यह उन दिलचस्पी के लिए है)। मैंने अभी तक ऐसा नहीं किया है।

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

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

CBUFFER_START(SpeedTreeWind) float4 _ST_WindVector; float4 _ST_WindGlobal; float4 _ST_WindBranch; float4 _ST_WindBranchTwitch; float4 _ST_WindBranchWhip; float4 _ST_WindBranchAnchor; float4 _ST_WindBranchAdherences; float4 _ST_WindTurbulences; float4 _ST_WindLeaf1Ripple; float4 _ST_WindLeaf1Tumble; float4 _ST_WindLeaf1Twitch; float4 _ST_WindLeaf2Ripple; float4 _ST_WindLeaf2Tumble; float4 _ST_WindLeaf2Twitch; float4 _ST_WindFrondRipple; float4 _ST_WindAnimation; CBUFFER_END 

हम उन्हें कैसे बाहर निकालेंगे? ऐसा करने के लिए, प्रत्येक प्रकार के पेड़ के लिए, हम मूल स्पीडट्री ऑब्जेक्ट को एक अदृश्य स्थान पर कहीं न कहीं प्रस्तुत करेंगे (या बल्कि, एकता में दिखाई दे रहे हैं, लेकिन कैमरे में दिखाई नहीं देते हैं, अन्यथा पैरामीटर अपडेट नहीं किए जाएंगे)। यह बाउंडिंग बॉक्स को बहुत बढ़ाकर और कैमरे के पीछे वस्तु को रखकर) प्राप्त किया जा सकता है। प्रत्येक फ़्रेम को सामग्री का उपयोग करके मूल्यों के वांछित सेट को हटा दिया जाता है। गेटवेक्टर (...)।

तो, पेड़ हवा में बहते हैं, लेकिन बिलबोर्ड का शीर्ष दृश्य निराशाजनक है:


Shader विकल्प के साथ BILLBOARD_FACE_CAMERA_POS और भी बदतर:


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


हमें पुराना SpeedTreeRT SDK मिलता है, और हम प्रलेखन में संरचना पाते हैं:

 struct SBillboard { bool m_bIsActive; const float* m_pTexCoords; const float* m_pCoords; float m_fAlphaTestValue; }; 

"M_pTexCurds 4 के सेट के लिए इंगित करता है (s, t) बनावट निर्देशांक जो बिलबोर्ड पर उपयोग की जाने वाली छवियों को परिभाषित करते हैं। m_pTexCoords में 8 प्रविष्टियाँ हैं। ”, यह एक विदेशी भाषा में कहता है। खैर, हम एक बाइनरी स्पम फ़ाइल में 4 फ्लोटिंग पॉइंट वैल्यू के अनुक्रम की तलाश करेंगे, जिनमें से प्रत्येक रेंज [0..1] में निहित है। वैज्ञानिक प्रहार की विधि से, हमें पता चलता है कि वांछित अनुक्रम पैटर्न के अनुरूप संकेतों के साथ 12 फ्लोट के ब्लॉक के सामने है:

 float signs[] = { -1, 1, -1, 1, 1, -1, 1, 1, 1, -1, 1, 1 }; 

हम पेशेवरों पर एक छोटी कंसोल उपयोगिता लिखते हैं, जो सभी एसपीएम फाइलों पर प्रसारित होती है, और उन में क्षैतिज होर्डिंग के लिए यूवी निर्देशांक की तलाश करता है। आउटपुट ऐसा CSV लेबल है:

 Azalea_Desktop.spm: 0, 1, 0.333333, 1, 0.333333, 0.666667, 0, 0.666667, Azalea_Desktop_Flowers_1.spm: 0, 1, 0.333333, 1, 0.333333, 0.666667, 0, 0.666667, Azalea_Desktop_Flowers_2.spm: 0, 1, 0.333333, 1, 0.333333, 0.666667, 0, 0.666667, Leaf_Map_Maker_Desktop_1_Modeler_Use_Only.spm: Pattern not found! Leaf_Map_Maker_Desktop_2_Modeler_Use_Only.spm: Pattern not found! BarrelCactus_Cluster_Desktop_1.spm: 0, 0.592376, 0.407624, 0.592376, 0.407624, 0.184752, 0, 0.184752, BarrelCactus_Cluster_Desktop_2.spm: 0, 1, 0.499988, 1, 0.499988, 0.500012, 0, 0.500012, BarrelCactus_Desktop_1.spm: 0, 0.2208, 0.220748, 0.2208, 0.220748, 5.29885e-05, 0, 5.29885e-05, BarrelCactus_Desktop_2.spm: 0, 1, 0.301392, 1, 0.301392, 0.698608, 0, 0.698608, 

क्षैतिज बिलबोर्ड की ज्यामिति को बनावट निर्देशांक निर्दिष्ट करने के लिए, हम वांछित रिकॉर्ड पाते हैं और इसे पार्स करते हैं।

अब यह इस तरह है:


अभी भी बहुत नहीं है। अल्फा टेस्ट थ्रेशोल्ड का उपयोग करते हुए, हम ऊर्ध्वाधर बिलबोर्ड को कोण से कैमरे तक रिकॉर्डिंग में फीका करेंगे:



परिणाम

Profiler गतिशील दिखा रहा है (कितनी चीजें प्रदान की जा रही हैं) और स्थैतिक (कितनी वस्तुएं और उनके पैरामीटर दृश्य पर हैं) आँकड़े:


खैर, अंतिम सुंदर वीडियो (दूसरी छमाही गुणवत्ता स्तरों के स्विचिंग से पता चलता है):


अंत में हमारे पास क्या है:

• सिस्टम पूरी तरह से सीपीयू स्वतंत्र है।
• यह तेजी से काम करता है।
• यह रेडी-मेड स्पीडट्री एसेट्स का उपयोग करता है, जिसे आप इंटरनेट पर खरीद सकते हैं।
• बेशक, मैंने उसके दोस्तों को किसी भी LODGroup के साथ बनाया, न केवल स्पीडट्री। इतने सारे कंकड़ अब संभव भी हैं।

कमियों के बीच रोना culling की कमी और अभी भी बहुत अर्थपूर्ण होर्डिंग नहीं देखा जा सकता है।