मुझे ग्राफिक्स प्रोग्रामिंग बहुत पसंद है

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

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

आपका स्वागत है!

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

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

हम किस बारे में बात कर रहे हैं?

मैं शुरुआत से शुरू करूंगा, बिना किसी विषयांतर के कि मैं कौन हूं और क्यों। एक नया फोन खरीदा है (यहाँ हब पर मेरे लेखों की प्रवृत्ति पहले से ही कम है ...), मैं खुद को "लाइव वॉलपेपर" सेट करना चाहता था, क्योंकि मुझे नहीं पता कि क्यों, लेकिन मुझे पसंद है जब स्क्रीन पर कुछ चलता है। शायद सभी क्योंकि तब मुझे लगता है कि मैंने एक कारण के लिए चार-कोर प्रोसेसर वाला फोन खरीदा है। मैं दुकान के चारों ओर चला गया, सोचा कि मैं स्क्रीन पर देखना चाहूंगा और फैसला किया कि मुझे मिनीक्राफ्ट की शैली में कुछ चाहिए, लेकिन दुर्भाग्य से मुझे ऐसा कुछ नहीं मिला जो मुझे ठीक से खुश कर सके। तब मुझे खुद ही सब कुछ करने का निर्णय लेने की ललक थी ...

पहले इस बारे में संदेह ...

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

विकास प्रक्रिया और अन्य विवरणों के बारे में एक कहानी के साथ आपको बोर नहीं करने के लिए (मेरी कहानी उस बारे में नहीं है), मैं सिर्फ इस अर्थ का वर्णन करता हूं: लिखा, यह ठीक उसी तरह काम किया जैसे मैंने याद किया, एक बार खेला, छोड़ दिया, क्योंकि डिबगिंग की प्रक्रिया में पहले से ही "पर्याप्त खेला" ।

जो लोग रुचि रखते हैं, उनके लिए यह परिणाम है:


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

और ग्राफिक्स प्रोग्रामिंग कहाँ है?

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


चूंकि मैंने शुरू से ही तय कर लिया था कि मैं खुद सब कुछ लागू करूंगा और मैं साहित्य में नहीं जाऊंगा या इंटरनेट पर मदद नहीं मांगूंगा, मेरी छवि के किनारे कुछ इस तरह दिखे:


जाहिर है, छवियों को सही ढंग से संसाधित नहीं किया जाता है, जिसमें से केवल एक हिस्सा खींचा जाना चाहिए, हम सही कर रहे हैं ...
इसलिए, समस्या का समाधान किया जा रहा है, जिसका अर्थ है कि आप व्यवसाय के लिए नीचे उतर सकते हैं और समाधान और इष्टतम कार्यान्वयन की तलाश शुरू कर सकते हैं।

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

"परिणाम"

तो, क्षितिज (अभी तक यादृच्छिक ब्लॉकों के साथ, मुझे यह भी पता नहीं है कि मैंने इसे यादृच्छिक क्यों बनाया, मैं एक लेख लिख रहा हूं और खुद आश्चर्यचकित हूं):

बड़ी तस्वीरें क्लिक करने योग्य होती हैं, लेकिन हैब्रस्ट्रेज ने उनका आकार थोड़ा कम कर दिया (मूल 7200 x 1280 था)

अब यादृच्छिक कचरे से, हम सार्थक सामग्री की ओर मुड़ते हैं। क्षितिज रेखा "सार्थक" है:


इसके बाद, "गुफाओं" (सतह में खरोज) को बनाना आवश्यक था ताकि राहत इतनी आदिम न दिखे। क्योंकि उस समय तक कार्यान्वयन अभी भी कच्चा था, फिर गुफाओं के निर्माण के लिए एल्गोरिथ्म का सत्यापन एक अलग तरीके से "गुफाओं" का एक चित्र था:


अगला कदम अग्रभूमि और पृष्ठभूमि में हर चीज को विभाजित करना था, जिसकी पृष्ठभूमि एक गहरी बनावट वाली थी:

यह पहले से ही कुछ जैसा दिखता है, लेकिन फिर भी परिणाम से बहुत दूर है।

मैंने बनावट को बदल दिया, मैंने नीचे एक प्रकाश स्रोत जोड़ने का फैसला किया - लावा, लेकिन मैंने बनावट के साथ एक गलती की, इसलिए नीचे "मशालों से भरा" था:


मैं सही और एक और प्रकाश स्रोत जोड़ - मशालें:


मैंने महसूस किया कि अग्रभूमि और पृष्ठभूमि ब्लॉक का अनुपात मेरे अनुरूप नहीं है और गुणांकों को बदल दिया है:

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

प्रकाश स्रोतों को जोड़ने का उद्देश्य अधिक पर्याप्त प्रकाश व्यवस्था था - प्रकाश स्रोतों से प्रकाश व्यवस्था। प्रकाश स्रोतों को तीन समूहों में विभाजित किया गया था:

1. आकाश से प्रकाश। प्रकाश का सबसे उज्ज्वल स्रोत, लेकिन दिन के समय का परिवर्तन मूल रूप से कल्पना की गई थी, जिसका अर्थ है कि आकाश से प्रकाश समय पर निर्भर करता है।
2. लावा प्रकाश। दिन के दौरान आकाश की तुलना में प्रकाश का कम उज्ज्वल स्रोत, लेकिन चमक समय के साथ नहीं बदलती है।
3. मशालों से रोशनी। सबसे कम उज्ज्वल प्रकाश स्रोत। चमक भी स्थिर है।

परिणामस्वरूप, दो मापदंडों ने ब्लॉक की रोशनी को प्रभावित करना शुरू कर दिया - आकाश की दूरी और स्थैतिक प्रकाश स्रोत से दूरी:

बाईं ओर स्रोतों से प्रकाश का प्रसार है, और दाईं ओर "पृष्ठभूमि अग्रभूमि की तुलना में गहरा है"।

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

सही कर रहा है ...

पृष्ठभूमि को ठीक करते हुए, उसने गलती से पृथ्वी के साथ गुफाओं को "चित्रित" किया:

मुझे पता है कि ऐसा लग सकता है कि इसमें से कुछ जानबूझकर किया गया था, लेकिन मैं आपको विश्वास दिलाता हूं कि सभी परिणाम संयोग से प्राप्त हुए थे। सच में, मुझे यह कहना भी मुश्किल है कि मैंने इसे कैसे किया, लेकिन नतीजा यह है कि यह क्या है। हम इसे भी ठीक करते हैं ...

एक मशाल के बाद एक ब्लॉक की रोशनी गलत तरीके से गणना की जाती है (एक मशाल के बाद ब्लॉक पड़ोसी ब्लॉकों की तुलना में गहरा होता है):

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

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

और


यह कम से कम कहने के लिए बहुत "गलती से," निकला।

अगला कदम, अतिरिक्त ब्लॉक जोड़े गए (मुझे यह कदम याद है, मुझे माफ करना, और बहुत सारी तस्वीरें हैं) राहत की उपस्थिति में विविधता लाने के लिए, और फिर पेड़ों की बारी आई।

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

तो, पेड़ों के साथ पीड़ा की पहली पुनरावृत्ति:

इसके साथ शुरू करने के लिए, एक पेड़ को ट्रंक बनाने का फैसला किया गया था और ट्रंक के ऊपर पत्तियां (अब तक पक्षों पर कोई पत्तियां नहीं हैं), लेकिन यहां तक ​​कि मैंने ब्लॉकों को मिलाया और एक उलटा परिणाम मिला।

मैंने त्रुटि को ठीक किया और पक्षों पर पत्तियों को जोड़ा, और फिर से गलत ब्लॉक:


परिणामस्वरूप, पेड़ों की संख्या बदलने के बाद, यह परिणाम है:


तब मैंने फैसला किया कि क्षितिज रेखा उत्पन्न करने के लिए एल्गोरिथ्म मुझे परेशान करता है और इसे ठीक करना अच्छा होगा, जो मैंने किया। परिणाम काफी अनुमानित था - कुछ भी अच्छा नहीं:


फिर कई डेवलपर्स के लिए सामान्य क्विक-फिक्स आया, समस्या के सार के बहुत समझ के बिना (आखिरकार, मैंने अभी यह कोड लिखा है, यह स्पष्ट है कि मैं इसे बिना किसी हिचकिचाहट के ठीक कर सकता हूं!), जो एक के रूप में मान सकता है, एक सकारात्मक परिणाम है। परिणाम नहीं हुआ:

उत्सुकता से पर्याप्त, क्षितिज पूरी तरह से सपाट नहीं है, लेकिन शुरुआत में थोड़ी विकृति है।

परिणामस्वरूप, मैंने विभिन्न मापदंडों के साथ प्रयोग किया और कई परिणामों के बाद शांत हो गया और क्षितिज रेखा के सुधार के बारे में सोचना बंद कर दिया। यहाँ क्षितिज के लिए कुछ परिणाम हैं:


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

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


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


फिर यह मुझ पर लगभग तुरंत हावी हो गया, मैंने क्या गलत किया और नए सुधार को इंतजार करने में देर नहीं लगी:


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

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


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


समय-समय पर, मैंने कोड को व्यवस्थित करने के लिए कुछ विधियों का शासन किया और समय-समय पर विभिन्न प्रकार के परिणाम प्राप्त किए। एक और उदाहरण:


समय-समय पर, डिबगिंग की दुनिया से काफी मनोरंजक स्थितियां सामने आईं। उदाहरण के लिए, एक ढाल बनाने में त्रुटि (बहु-रंगीन पट्टियों का एक और जनरेटर):


इस त्रुटि के डीबगिंग के दौरान, जब मेरे लिए पहले से ही विचार चल रहे थे, डीबगर ने इस रंग मान का उत्पादन किया:

उस दिन मैंने डिबगिंग को छोड़ दिया और आराम करने का फैसला किया ताकि डिबगर ने भोजन की खराब गुणवत्ता के बारे में बात करना बंद कर दिया।

इस बिंदु पर, मैंने फोन पर परिणाम का परीक्षण एक साथ शुरू करने का फैसला किया। फोन पर, रंग क्रम थोड़ा अलग था, इसलिए लाल और नीले रंग के घटक रंग बदल गए:


वैसे, मैं एक बार फिर याद दिलाना भूल गया कि मुझे पेड़ों से नफरत है ... पेड़ों ने रात में अजीब व्यवहार किया:


इस समय, फ़ोन में आम तौर पर अपना दृष्टिकोण था कि शिफ्टिंग (उंगली से स्क्रॉल करना) के बाद चित्र कैसे बनाया जाए।
और

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

वैसे! बहुत समय तक मैंने तुम्हें अपने पेड़ नहीं दिखाए! यहां:

यहां काफी कुछ समस्याएं हैं - पत्तियों के कुछ ब्लॉकों की गलत रोशनी और "पारदर्शी पिक्सल" का गलत प्रतिपादन।

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


विज़ुअलाइज़ेशन का एक और अधिक उन्नत संस्करण इस तरह देखा गया:


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

कुछ बिंदु पर, जब मैंने पेड़ों की उपस्थिति को ठीक करने की कोशिश की, तो मुझे एक और "सकारात्मक" मिला:


यहाँ फोन से कुछ और दिलचस्प कीड़े हैं जो सीधे पारदर्शिता (अल्फा चैनल) से संबंधित हैं:
और

तब अतिरिक्त बनावट (और इसलिए बनावट सूचकांकों के परिवर्तन) के अतिरिक्त होने के कारण त्रुटियां थीं:


तब मैंने ड्रॉइंग अल्गोरिथम में कुछ "सही" किया और एक अजीब प्रभाव डाला (मैं शायद बनावट के आकार और स्थिति के साथ गड़बड़ कर दिया):


रेंडरिंग एल्गोरिथ्म के नवीनतम अनुकूलन के परिणामस्वरूप, मुझे एक बार में दो त्रुटियां प्राप्त हुईं (फिर से, मिंक व्हेल):
और

इस चमत्कार को चित्रित करने की प्रक्रिया इस तरह दिखती है (जाहिर है, यह सबसे इष्टतम विकल्प है):


अंतिम चीज जिसे लागू करने की आवश्यकता थी, वह वॉल्यूम (ब्लॉकों के किनारों) का प्रभाव था ताकि तस्वीर इतनी सपाट और सरल न हो। चेहरों के लिए, दो एल्गोरिदम लिखना आवश्यक था - छवि को आकार देने के लिए एल्गोरिथ्म और छवि को झुकाव के लिए एल्गोरिथ्म।

मैं चित्र के आकार को कम करने के लिए एल्गोरिथ्म के साथ शुरू करूँगा:


ऊपर से नीचे तक - एल्गोरिदम के परिणाम। बहुत नीचे - वांछित परिणाम (एक बड़ी तस्वीर में परीक्षण किया गया था, स्पष्टता के लिए)।

रोटेशन एल्गोरिथ्म अधिक प्रतिष्ठित था:


ऊपर बाईं ओर प्रारंभिक छवि है, और नीचे दाईं ओर वांछित परिणाम है, और बीच में वह सब कुछ है जो परिणाम के रास्ते पर प्राप्त किया गया था।

जब एल्गोरिदम तैयार थे, तो वॉल्यूम बनाना पहले से ही काफी सरल था। ब्लॉक 3 चेहरों से बना था (एक तरफ से देखें, छद्म 3 डी या तथाकथित 2.5 डी)। सुंदरता के लिए, एक रैखिक ढाल को कगार पर लागू किया गया था, जिसे वांछित परिणाम प्राप्त करने के लिए डीबग करना पड़ा:


चूँकि मैं ब्लॉक चेहरों के आकार का निर्धारण नहीं कर सका, इसलिए मैंने इस पैरामीटर को बदलना संभव बना दिया है:


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

इस त्रुटि के सुधार का परिणाम इतना दिलचस्प नहीं रहा:

परिणाम

अंत में, सभी महत्वपूर्ण त्रुटियों को डीबग किया गया, प्रभाव के रूप में बनावट और बन्स जोड़ा गया। स्टोर के लिए दो संस्करण बनाए गए थे - मुफ्त (बहुत सरलीकृत) और भुगतान (सभी माल के साथ)।

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

मुझे उम्मीद है कि यह किसी और को अपने हाथों से कुछ बनाने के लिए धक्का देगा, न कि केवल तैयार रूपरेखा और पुस्तकालयों का उपयोग करने के लिए।

उन लोगों के लिए भी धन्यवाद, जिन्होंने लेख के अंत तक छोड़ दिया!