64k परिचय के लिए बनावट: यह आज कैसे किया जाता है

यह लेख हमारे एच - विसर्जन श्रृंखला के दो भाग है । पहला भाग यहाँ पढ़ा जा सकता है: विसर्जन में विसर्जन ।

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


पनडुब्बी के जलप्रपात सीबड के विवरण को रोशन करते हैं।

प्रारंभिक संस्करण

बनावट पीढ़ी हमारे कोड आधार के पहले तत्वों में से एक थी: प्रक्रियात्मक बनावट हमारे पहले बी - इनक्यूबेशन इंट्रो में पहले से ही उपयोग की गई थी। कोड में फ़ंक्शंस का एक सेट शामिल होता है जो टेक्सचर को भरने, फ़िल्टर करने, बदलने और संयोजित करने के साथ-साथ एक बड़ा लूप भी होता है जो सभी टेक्सट को बायपास करता है। ये फ़ंक्शन शुद्ध C ++ में लिखे गए थे, लेकिन C API इंटरैक्शन को बाद में जोड़ा गया ताकि उनका मूल्यांकन C PicoC दुभाषिया द्वारा किया जा सके। उस समय, हमने प्रत्येक पुनरावृत्ति द्वारा लिए गए समय को कम करने के लिए पिकोसी का उपयोग किया: इस तरह हम कार्यक्रम के निष्पादन के दौरान बनावट को बदलने और पुनः लोड करने में सक्षम थे। सी के एक सबसेट पर स्विच करना इस तथ्य की तुलना में एक छोटा बलिदान था कि अब हम कोड को बदल सकते हैं और तुरंत परिणाम देख सकते हैं, पूरे डेमो को बंद किए, फिर से लोड करने और पुनः लोड किए बिना।


एक सरल पैटर्न, थोड़ा शोर और विरूपण का उपयोग करके, हम एक लकड़ी की बनावट प्राप्त कर सकते हैं।


एफ - फेलिक्स की कार्यशाला के इस दृश्य में विभिन्न लकड़ी की बनावट का उपयोग किया गया था।

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


हमारे पुराने बनावट जनरेटर की वेब गैलरी। सभी बनावट को ब्राउज़र में संपादित किया जा सकता है।

पूरा नया स्वरूप

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


कपड़े की थैली । पदार्थ डिजाइनर में एक पूरी तरह से प्रक्रियात्मक कपड़े की बनावट। द्वारा पोस्ट किया गया: Imanol Delgado। www.artstation.com/imanoldelgado


वन तल । पदार्थ डिजाइनर द्वारा बनाई गई पूरी तरह से प्रक्रियात्मक वन मिट्टी की बनावट। डैनियल थिगेर द्वारा पोस्ट किया गया। www.artstation.com/dete

हमें अपने उपकरणों पर पुनर्विचार करने की लंबे समय से जरूरत है। सौभाग्य से, एक ही बनावट जनरेटर के साथ कई वर्षों के काम ने हमें इसकी कमियों को पहचानने की अनुमति दी। इसके अलावा, हमारे नवजात जाल जनरेटर ने हमें यह भी बताया कि प्रक्रियात्मक सामग्री पाइपलाइन को कैसा दिखना चाहिए।

सबसे महत्वपूर्ण स्थापत्य गलती बनावट वस्तुओं के साथ संचालन के एक सेट के रूप में पीढ़ी का कार्यान्वयन था। उच्च-स्तरीय परिप्रेक्ष्य के दृष्टिकोण से, यह सही दृष्टिकोण हो सकता है, लेकिन कार्यान्वयन के दृष्टिकोण से , बनावट जैसे कार्य। DoSomething () या Combine (बनावट, बनावट) में गंभीर कमियां हैं।

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

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

नई संरचना तर्क के पुनर्गठन के माध्यम से इन समस्याओं को हल करती है। व्यवहार में अधिकांश कार्य स्वतंत्र रूप से प्रत्येक बनावट तत्व के लिए एक ही ऑपरेशन करते हैं। इसलिए, एक बनावट लिखने के बजाय। डीओमोसिएटिंग () फ़ंक्शन जो सभी तत्वों को बायपास करता है, हम बनावट लिख सकते हैं ।ApplyFunction (एफ) , जहां एफ (तत्व) केवल एक बनावट तत्व के लिए काम करता है। फिर एक विशिष्ट बनावट के अनुसार एफ (तत्व) लिखा जा सकता है।

यह मामूली बदलाव की तरह लगता है। हालांकि, यह संरचना एपीआई को सरल बनाती है, पीढ़ी कोड को अधिक लचीला और अभिव्यंजक बनाती है, अधिक कैश-फ्रेंडली है, और आसानी से समानांतर प्रसंस्करण की अनुमति देती है। कई पाठकों ने पहले ही महसूस किया कि यह अनिवार्य रूप से एक शेडर है। हालाँकि, वास्तविक कार्यान्वयन प्रोसेसर पर निष्पादित C ++ कोड रहता है। हम अभी भी लूप के बाहर संचालन करने की क्षमता रखते हैं, लेकिन इस विकल्प का उपयोग केवल तभी आवश्यक है, उदाहरण के लिए, दृढ़ संकल्प द्वारा।

यह था:

//     . // API . //    -  API. //      . class ProceduralTexture { void DoSomething(parameters) { for (int i = 0; i < size; ++i) { //   . (*this)[i] = … } } void PerlinNoise(parameters) { … } void Voronoi(parameters) { … } void Filter(parameters) { … } void GenerateNormalMap() { … } }; void GenerateSomeTexture(texture t) { t.PerlinNoise(someParameter); t.Filter(someOtherParameter); … //  .. t.GenerateNormalMap(); } 

यह बन गया:

 //       . // API . //     . //      . class ProceduralTexture { void ApplyFunction(functionPointer f) { for (int i = 0; i < size; ++i) { //    . (*this)[i] = f((*this)[i]); } } }; void GenerateNormalMap(ProceduralTexture t) { … } void SomeTextureGenerationPass(void* out, PixelInfo in) { result = PerlinNoise(in); result = Filter(result); … //  .. *out = result; } void GenerateSomeTexture(texture t) { t.ApplyFunction(SomeTextureGenerationPass); GenerateNormalMap(t); } 

साथ में चलाना

बनावट पीढ़ी में समय लगता है, और इस समय को कम करने के लिए एक स्पष्ट उम्मीदवार समानांतर कोड निष्पादन है। बहुत कम से कम, आप सीख सकते हैं कि एक साथ कई बनावट कैसे उत्पन्न करें। यह वही है जो हमने एफ - फेलिक्स की कार्यशाला के लिए किया था, और इससे लोड समय बहुत कम हो गया।

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




एक विचार का चित्रण जो हमने एच - विसर्जन के लिए खोजा और त्याग दिया: ऑरिक्लेन अस्तर के साथ एक मोज़ेक सजावट। यहाँ यह हमारे इंटरैक्टिव एडिटिंग टूल में दिखाया गया है।

GPU पक्ष पीढ़ी

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

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

हालांकि, अच्छी खबर यह है कि, नए ढांचे के लिए धन्यवाद, GPU के साथ प्रयोग करना अब बहुत तुच्छ लगता है। दोनों प्रकार के प्रोसेसर के परीक्षण संयोजन भविष्य के लिए एक दिलचस्प प्रयोग होगा।

बनावट पीढ़ी और शारीरिक रूप से सटीक छायांकन

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

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

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










नई संरचना हमें बनावट के लिए मनमाने ढंग से पिक्सेल प्रारूप घोषित करने की अनुमति देती है। इसे एपीआई का हिस्सा बनाने के बाद, हम इसे सभी बॉयलरप्लेट कोड से निपटने की अनुमति देते हैं। पिक्सेल प्रारूप घोषित करने के बाद, हम इस डेटा को संसाधित करने में बहुत अधिक प्रयास किए बिना रचनात्मक कोड पर ध्यान केंद्रित कर सकते हैं। रन टाइम में, यह कई बनावट उत्पन्न करेगा और पारदर्शी रूप से उन्हें GPU में स्थानांतरित करेगा।

कुछ पीबीआर पाइपलाइनों में, फैलाना और स्पेक्युलर रंग सीधे प्रसारित नहीं होते हैं। इसके बजाय, "बेस कलर" और "मेटलनेस" मापदंडों का उपयोग किया जाता है, जिसमें इसके फायदे और नुकसान हैं। एच - विसर्जन में, हम डिफ्यूज़ + स्पेकुलर मॉडल का उपयोग करते हैं, और सामग्री में आमतौर पर पांच परतें होती हैं:

1. डिफ्यूज़ रंग (RGB; 0: Vantablack ; 1: ताज़ा बर्फ़ )।
2. विशिष्ट रंग (RGB: 90 डिग्री पर प्रतिबिंबित प्रकाश का अंश, जिसे F0 या R0 भी कहा जाता है)।
3. खुरदरापन (ए; 0: पूरी तरह से चिकनी; 1: रबर की तरह)।
4. सामान्य (XYZ; इकाई वेक्टर)।
5. इलाके की ऊंचाई (ए; लंबन रोड़ा मानचित्रण के लिए इस्तेमाल किया)।

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



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

अड़चनें और भविष्य के काम

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

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

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


ऊपर दिखाए गए इमादोल डेलगाडो के काम के समान कपड़े की बनावट बनाने के लिए एक प्रयोग।