🧚🏻 👉🏼 👩‍🚀 सी ++ और वुलकन में एक सप्ताह में न्यूनतम निर्माण 🚴🏻 💮 🦈

मैंने अपने आप को C ++ और वल्कन में अपने स्वयं के इंजन का उपयोग करके एक सप्ताह में Minecraft को फिर से बनाने का कार्य निर्धारित किया। मैं होपसन से प्रेरित था , जिन्होंने सी ++ और ओपनजीएल के साथ भी ऐसा ही किया था। बदले में, वह शेन बेक से प्रेरित था, जो कि Minecraft से प्रेरित था, जिसके लिए प्रेरणा का स्रोत Infiniminer था, जिसका निर्माण, संभवतः, वास्तविक खनन से प्रेरित था।

इस परियोजना के लिए GitHub भंडार यहाँ है । प्रत्येक दिन का अपना स्वयं का टैग होता है।

बेशक, मैंने सचमुच Minecraft को फिर से बनाने की योजना नहीं बनाई थी। इस परियोजना को एक शैक्षिक माना जाता था। मैं vulkan-tutorial.com या साशा विलेम के डेमो से अधिक जटिल कुछ में वल्कन का उपयोग करने के बारे में सीखना चाहता था । इसलिए, मुख्य जोर वल्कन इंजन के डिजाइन पर है, न कि खेल के डिजाइन पर।

कार्य

वल्कन पर विकास ओपेन वील की तुलना में बहुत धीमा है, इसलिए मैं इस Minecraft की कई विशेषताओं को खेल में शामिल नहीं कर सका। कोई मॉब नहीं है, कोई क्राफ्टिंग नहीं है, कोई लाल पत्थर नहीं है, कोई ब्लॉक भौतिकी नहीं है, आदि। शुरुआत से ही, परियोजना के उद्देश्य इस प्रकार थे:

एक इलाके प्रतिपादन प्रणाली बनाना
- सानी
- प्रकाश
एक इलाके जनरेटर प्रणाली बनाना
- राहत
- पेड़
- बायोम
इलाके बदलने और ब्लॉकों को स्थानांतरित करने की क्षमता जोड़ना

मुझे खेल में एक जीयूआई को जोड़ने के बिना यह सब लागू करने का एक तरीका खोजने की आवश्यकता थी, क्योंकि मुझे कोई भी जीयूआई पुस्तकालय नहीं मिला जो वल्कन के साथ काम करते हैं और एकीकृत करने में आसान थे।

पुस्तकालय

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

VulkanWrapper - Vulkan API के लिए मेरा अपना C ++ रैपर
GLFW - खिड़कियों और उपयोगकर्ता इनपुट के लिए
VulkanMemoryAllocator - वल्कन मेमोरी को आवंटित करने के लिए
जीएलएम - गणित वैक्टर और मैट्रिस के लिए
entt - संकेतों / स्लॉट और ईसीएस के लिए
stb - इमेज लोडिंग यूटिलिटीज के लिए
FastNoise - 3 डी शोर पैदा करने के लिए

पहला दिन

पहले दिन, मैंने एक वल्कन बॉयलरप्लेट और एक इंजन कंकाल तैयार किया। अधिकांश कोड एक बॉयलरप्लेट था और मैं इसे vulkan-tutorial.com से कॉपी कर सकता था । यह भी एक शीर्ष shader के हिस्से के रूप में भंडारण डेटा के साथ एक चाल शामिल है। इसका मतलब यह था कि मुझे मेमोरी एलोकेशन को ट्यून करना भी नहीं आता था। बस एक साधारण कन्वेयर जो केवल एक ही काम कर सकता है: एक त्रिकोण खींचना।

त्रिकोण के रेंडरर का समर्थन करने के लिए इंजन काफी सरल है। इसमें एक विंडो और एक गेम लूप है जिससे सिस्टम कनेक्ट किया जा सकता है। GUI विंडो शीर्षक में प्रदर्शित फ्रेम दर द्वारा सीमित है।

परियोजना को दो भागों में विभाजित किया गया है: VoxelEngineऔर VoxelGame।

दूसरा दिन

मैंने वल्कन मेमोरी एलोकेटर लाइब्रेरी को एकीकृत किया। यह लाइब्रेरी अधिकांश वल्कन मेमोरी आवंटन बॉयलरप्लेट की देखभाल करती है: मेमोरी प्रकार, डिवाइस मेमोरी ढेर और द्वितीयक आवंटन।

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

थोड़ा बदल गया है

तीसरा दिन

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

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

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

इंजन में तीन प्रकार के नोड होते हैं। AcquireNodeएक बफर चेन (स्वेपचैन) से एक छवि प्राप्त होती है, TransferNodeसीपीयू से जीपीयू में डेटा स्थानांतरित PresentNodeकरता है , और प्रदर्शित होने के लिए एक बफर श्रृंखला की छवि प्रदान करता है।

प्रत्येक नोड को लागू कर सकते हैं preRender, renderऔर postRender, जो प्रत्येक फ्रेम में निष्पादित होते हैं। AcquireNodeके दौरान बफ़र्स की एक श्रृंखला की छवि मिलती है preRender। PresentNodeइस छवि को समय पर प्रदान करता है postRender।

मैंने त्रिकोण रेंडरर को रिफलेक्ट किया ताकि यह सब कुछ प्रोसेस करने के बजाय एक रेंडर ग्राफ सिस्टम का उपयोग करे। के बीच एक किनारा है AcquireNodeऔरTriangleRendererसाथ ही साथ TriangleRendererऔर PresentNode। यह सुनिश्चित करता है कि फ्रेम के दौरान इसके उपयोग के दौरान बफर चेन की छवि सही ढंग से सिंक्रनाइज़ की गई है।

मुझे लगता है कि इंजन के अंदर कसम बदल गई है

दिन 4

मैंने एक कैमरा और एक 3 डी रेंडरिंग सिस्टम बनाया। अब तक, कैमरा अपने स्वयं के लगातार बफर और डिस्क्रिप्टर पूल को प्राप्त करता है।

मैं उस दिन धीमा हो गया क्योंकि मैं वल्कन के साथ 3 डी रेंडरिंग के लिए सही कॉन्फ़िगरेशन खोजने की कोशिश कर रहा था। अधिकांश ऑनलाइन सामग्री ओपनजीएल का उपयोग करके रेंडरिंग पर ध्यान केंद्रित करती है, जो वल्कन से थोड़ा अलग समन्वय प्रणालियों का उपयोग करती है। OpenGL में, क्लिप स्पेस का Z अक्ष इस प्रकार निर्दिष्ट किया गया है [-1, 1], और स्क्रीन के ऊपरी किनारे पर है Y = 1। वल्कन में, Z अक्ष के रूप में निर्दिष्ट किया गया है [0, 1], और स्क्रीन के शीर्ष किनारे पर है Y = -1। इन छोटे अंतरों के कारण, मानक GLM प्रोजेक्शन मैट्रिसेस सही ढंग से काम नहीं करते हैं, क्योंकि वे ओपनजीएल के लिए डिज़ाइन किए गए हैं।

GLM का एक विकल्प हैGLM_FORCE_DEPTH_ZERO_TO_ONE, Z अक्ष के साथ समस्या को समाप्त करना। उसके बाद, Y अक्ष के साथ समस्या को केवल (1, 1)प्रक्षेपण मैट्रिक्स तत्व के संकेत को बदलकर समाप्त किया जा सकता है (GLM 0 से अनुक्रमण का उपयोग करता है)।

यदि हम वाई अक्ष को फ्लिप करते हैं, तो हमें शीर्ष डेटा को फ्लिप करने की आवश्यकता है, क्योंकि इससे पहले, वाई अक्ष की नकारात्मक दिशा को इंगित किया गया था।

अब 3 डी में!

दिन 5

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

कीबोर्ड और माउस इनपुट अनिवार्य रूप से GLFW के शीर्ष पर एक पतली आवरण है, जो सिग्नल हैंडलर के माध्यम से खोला जाता है entt।

बस तुलना के लिए - एक ही चीज़ के बारे में होपसन ने अपनी परियोजना के दिन 1 किया।

दिन 6

मैंने voxel ब्लॉक्स बनाने और रेंडर करने के लिए कोड जोड़ना शुरू किया। मेशिंग कोड लिखना आसान था क्योंकि मैंने इसे पहले किया था और अमूर्तता को जानता था जिसने मुझे कम गलतियाँ करने की अनुमति दी।

सार में से एक एक टेम्पलेट वर्ग था ChunkData<T, chunkSize>जो प्रत्येक पक्ष के Tआकार chunkSizeके एक क्यूब को परिभाषित करता है । यह वर्ग 1 डी सरणी में डेटा संग्रहीत करता है और 3 डी समन्वय के साथ डेटा को अनुक्रमित करता है। प्रत्येक ब्लॉक का आकार 16 x 16 x 16 है, इसलिए आंतरिक डेटा 4096 की लंबाई के साथ एक साधारण सरणी है। एक

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

for (glm::ivec3 pos : Chunk::Positions()) {
    auto& data = chunkData[pos];
    glm::ivec3 offset = ...;
    auto& neighborData = chunkData[pos + offset];
}

मेरे पास कई स्थिर सरणियाँ हैं जो आमतौर पर खेल में उपयोग किए जाने वाले ऑफ़सेट्स को निर्दिष्ट करती हैं। उदाहरण के लिए, यह Neighbors66 पड़ोसियों को परिभाषित करता है जिनके साथ घन के आम चेहरे हैं।

static constexpr std::array<glm::ivec3, 6> Neighbors6 = {
        glm::ivec3(1, 0, 0),    //right
        glm::ivec3(-1, 0, 0),   //left
        glm::ivec3(0, 1, 0),    //top
        glm::ivec3(0, -1, 0),   //bottom
        glm::ivec3(0, 0, 1),    //front
        glm::ivec3(0, 0, -1)    //back
    };

Neighbors26- ये सभी पड़ोसी हैं जिनके साथ घन का एक आम चेहरा, किनारा या शीर्ष है। यही है, यह एक केंद्रीय घन के बिना एक 3x3x3 ग्रिड है। पड़ोसियों के अन्य सेटों के लिए और पड़ोसियों के 2D सेटों के लिए समान सरणियाँ भी हैं।

क्यूब का एक चेहरा बनाने के लिए आवश्यक डेटा को परिभाषित करने वाला एक सरणी है। इस सरणी में प्रत्येक चेहरे की दिशाएं सरणी में दिशाओं के अनुरूप हैं Neighbors6।

static constexpr std::array<FaceArray, 6> NeighborFaces = {
    //right face
    FaceArray {
        glm::ivec3(1, 1, 1),
        glm::ivec3(1, 1, 0),
        glm::ivec3(1, 0, 1),
        glm::ivec3(1, 0, 0),
    },
    ...
};

इसके लिए धन्यवाद, मेष निर्माण कोड बहुत सरल है। यह बस ब्लॉकों के डेटा को बायपास करता है और ब्लॉक ठोस होने पर एक चेहरा जोड़ता है, लेकिन इसका पड़ोसी नहीं है। कोड बस एक घन में प्रत्येक घन के हर चेहरे की जाँच करता है। यह यहाँ वर्णित "भोली" विधि के समान है ।

for (glm::ivec3 pos : Chunk::Positions()) {
    Block block = chunk.blocks()[pos];
    if (block.type == 0) continue;

    for (size_t i = 0; i < Chunk::Neighbors6.size(); i++) {
        glm::ivec3 offset = Chunk::Neighbors6[i];
        glm::ivec3 neighborPos = pos + offset;

        //NOTE: bounds checking omitted

        if (chunk.blocks()[neighborPos].type == 0) {
            Chunk::FaceArray& faceArray = Chunk::NeighborFaces[i];
            for (size_t j = 0; j < faceArray.size(); j++) {
                m_vertexData.push_back(pos + faceArray[j]);
                m_colorData.push_back(glm::i8vec4(pos.x * 16, pos.y * 16, pos.z * 16, 0));
            }
        }
    }
}

मैंने TriangleRendererसाथ दिया ChunkRenderer। मैंने एक गहराई बफर भी जोड़ा ताकि ब्लॉक मेष सही तरीके से प्रस्तुत कर सके। यह के बीच प्रतिपादन ग्राफ के लिए एक और किनारे को जोड़ने के लिए जरूरी हो गया था TransferNodeऔर ChunkRenderer। यह किनारा हस्तांतरण कतार और ग्राफिक्स कतार के बीच कतार परिवार के संसाधनों के स्वामित्व को स्थानांतरित करता है।

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

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

आपको गतिशील व्यूपोर्ट और आकार बदलने के लिए ग्राफिक्स पाइपलाइन को बदलने की आवश्यकता है।

यदि X या Y अक्ष पर विंडो का आकार 0 है, तो एक बफ़र श्रृंखला नहीं बनाई जा सकती है। जब विंडो को छोटा किया जाता है तब भी शामिल होता है। यही है, जब ऐसा होता है, तो पूरे खेल को रोक दिया जाता है और केवल तभी जारी रहता है जब खिड़की सामने आती है।

अब मेष एक साधारण तीन आयामी शतरंज की बिसात है। मेष के आरजीबी रंग इसकी XYZ स्थिति के अनुसार 16 से गुणा किए जाते हैं।

दिन 7

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

मैंने जाल को फिर से बनाया ताकि इसके निर्माण के बाद इसका डेटा अपडेट किया जा सके। यह मुझे भविष्य में ब्लॉक जाल को अपडेट करने की अनुमति देगा जब मैं क्यूब्स को जोड़ने और हटाने की क्षमता जोड़ दूंगा।

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

पिछले शीर्ष बफ़र को तुरंत हटाया नहीं जा सकता। पिछले फ़्रेम से निष्पादित अनुदेश बफ़र्स हो सकते हैं जो किसी विशेष ऑब्जेक्ट के लिए विशिष्ट हैं VkBuffer। जब तक ये कमांड बफ़र्स पूरे नहीं होते तब तक इंजन को एक बफर रखना चाहिए। यही है, अगर हम एक फ्रेम में एक जाल खींचते हैं i, तो जीपीयू फ्रेम शुरू होने से पहले इस बफर का उपयोग कर सकता है i + 2। जब तक जीपीयू ने इसका उपयोग नहीं किया है तब तक बफर को सीपीयू से नहीं हटाया जा सकता है। इसलिए मैंने रेंडरिंग ग्राफ को बदल दिया ताकि यह संसाधनों के जीवनकाल को ट्रैक करे।

यदि रेंडरिंग ग्राफ़ नोड संसाधन (बफर या छवि) का उपयोग करना चाहता है, तो उसे विधि के syncअंदर विधि को कॉल करना होगा preRender। इस विधि shared_ptrको एक संसाधन के लिए एक संकेतक मिलता है । इसshared_ptrयह सुनिश्चित करता है कि कमांड बफ़र्स निष्पादित होते समय संसाधन हटा नहीं दिया जाएगा। (प्रदर्शन के संदर्भ में, यह समाधान बहुत अच्छा नहीं है। इस पर अधिक बाद में।)

अब प्रत्येक फ्रेम में ब्लॉक मेष को फिर से बनाया गया है।

निष्कर्ष

वह सब जो मैंने एक हफ्ते में किया था - दुनिया को कई वॉक्सल ब्लॉकों के साथ प्रदान करने की मूल बातें तैयार की और दूसरे सप्ताह में काम करना जारी रखेगा।

सी ++ और वुलकन में एक सप्ताह में न्यूनतम निर्माण