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

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

1. उल्कापिंड EVS2 के बारे में संक्षेप में "सैपसन"

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

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

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


इस तरह के एक सिम्युलेटर सिम्युलेटर के लिए सॉफ्टवेयर का विकास एक बहुत व्यापक प्रश्न है, और मैं भविष्य में (अगर कोई हो) इन मुद्दों में पाठकों की रुचि को संतुष्ट करने के लिए (मेरी क्षमता से सर्वश्रेष्ठ) कोशिश करेगा, लेकिन अब, लेख के मुख्य विषय पर लौटते हैं - ट्रेन आंदोलन प्रक्रिया के त्रि-आयामी दृश्य।

2. अतीत की पृष्ठभूमि और प्रौद्योगिकी

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

आज इसका कोई मतलब नहीं है, क्योंकि:

1. कम ट्रेन की गति पर अपर्याप्त फ्रेम दर तस्वीर को ताज़ा करने की वांछित चिकनाई प्रदान नहीं करता है। हमारे पास 25 एफपीएस केवल उसी गति से होगा, जिस गति से ड्राइवर की कैब से वीडियो शूट किया गया था। और इस घातक दोष को किसी भी चीज से दूर नहीं किया जा सकता है - न तो एक हाई-स्पीड कैमरा के साथ शूटिंग करके (120 फ्रेम प्रति सेकंड के वज़न पर वीडियो कितना शूट किया जाएगा? यह वही है ...), या प्रोग्रामेटिक रूप से मध्यवर्ती फ़्रेम उत्पन्न करके। बाद में हमारे द्वारा OpenCV तकनीक का उपयोग किया गया, लेकिन सामान्य परिणाम नहीं हुए। इस प्रश्न का सभी पक्षों से बार-बार अध्ययन किया गया और इसके परिणामस्वरूप यह निष्कर्ष निकाला गया कि इस तरह की प्रणाली बनाने के लिए संसाधनों की लागत एक समान प्रणाली के विकास की तुलना में बहुत अधिक है, लेकिन 3 डी ग्राफिक्स पर आधारित है
2. वीडियो को आसानी से पीछे की ओर स्क्रॉल करने में कठिनाई। और यहां तक ​​कि यह ध्यान में रखते हुए कि वे दूर हो जाएंगे, फिर प्लेटफॉर्म पर चलने वाले कुत्ते कहाँ भागेंगे, क्या हमें लगता है कि हमें रिवर्स में जाना चाहिए?
3. सभी "अन्तरक्रियाशीलता" की कमी। ट्रैफिक लाइट में बदलाव, टर्नआउट की आवाजाही, आने-जाने वाली ट्रेनों की आवाजाही के साथ क्या करना है?

इसलिए, सभी आधुनिक सिमुलेटर और सिमुलेटर इंटरैक्टिव 3 डी-ग्राफिक्स का उपयोग करके बनाए गए हैं, क्योंकि आज किसी भी सॉफ्टवेयर या हार्डवेयर बिंदु से कोई बाधा नहीं है।

यदि हार्डवेयर के दृष्टिकोण से सब कुछ बहुत स्पष्ट है - विंडशील्ड के बजाय स्थापित मॉनिटर एक सामान्य वीडियो कार्ड (यहां तक ​​कि टॉप-एंड एक भी नहीं) के साथ एक पीसी से जुड़ा है, तो सॉफ्टवेयर बिंदु से, कार्य को लागू करने के लिए प्रौद्योगिकी चुनने पर सवाल उठता है।

3. ग्राफिक्स इंजन बनाम गेम इंजन या ओपनसेकेग्राफ को क्यों चुना गया

मुझसे गलती हो सकती है, लेकिन मैं पहले से टिप्पणियों का अनुमान लगाता हूं, जो पूरी तरह से तार्किक सवाल पूछेंगे, क्यों जब मौजूदा प्रौद्योगिकियों का विश्लेषण किया जाता है, तो हमारी पसंद एकता या अवास्तविक इंजन 4 जैसे मास्टोडन पर नहीं रुकी? मैं इस सवाल का जवाब दूंगा, इसके अलावा, मैं अपने जवाब को सही ठहराऊंगा।

संक्षेप में - न तो एकता और न ही अवास्तविक इंजन काम की आवश्यकताओं को पूरा करता है। एक अधिक विस्तृत जवाब प्रदान करता है, सबसे पहले, प्रश्न में आवश्यकताओं की एक सूची। टीके, त्रि-आयामी दृश्य के सबसिस्टम पर हमारे द्वारा संकलित, निम्नलिखित प्रावधानों में (महत्व के घटते क्रम में) शामिल हैं:

1. विज़ुअलाइज़ेशन सबसिस्टम के सॉफ्टवेयर विकास की प्रक्रिया की स्वतंत्रता और इसके लिए संसाधन बनाने की प्रक्रिया। इस मामले में, संसाधन में तीन आयामी मॉडल, बनावट और साथ ही तथाकथित मार्ग शामिल हैं । एक मार्ग को कॉन्फ़िगरेशन ऑब्जेक्ट्स और संसाधनों के संयोजन के रूप में समझा जाता है जो वीडियो सबसिस्टम को रेलवे के वांछित सेक्शन को प्रदर्शित करने और इसके साथ ट्रेन की गति के सिमुलेशन प्रदान करने की अनुमति देता है। इसमें वीडियो सबसिस्टम के सॉफ़्टवेयर भाग के पुनर्निर्माण के बिना मार्ग बदलने की संभावना भी शामिल है
2. असीमित लंबाई के मार्ग बनाएं। मैं एक आरक्षण करूँगा कि सीमित हार्डवेयर संसाधनों के कारण असीमित लंबाई सिद्धांत रूप में अप्राप्य है। इस आवश्यकता को समझना चाहिए कि मार्ग की लंबाई कम से कम एक "कंधे" के भीतर होनी चाहिए, अर्थात, टर्नअराउंड बिंदुओं के बीच सड़क का एक खंड, और यह, विभिन्न कारकों के आधार पर, एक पर्याप्त बड़ी दूरी है, जो एक सौ किलोमीटर से अधिक अनुमानित है। यह आवश्यकता उचित स्मृति खपत के साथ पर्याप्त चिकनाई के साथ कार्यक्रम के संसाधनों के गतिशील लोडिंग / अनलोडिंग प्रदान करने की आवश्यकता को लागू करती है। और यह वांछनीय है कि इंजन में ऐसी कार्यक्षमता हो "बॉक्स से बाहर"
3. प्रयुक्त प्रौद्योगिकी स्टैक के साथ सुविधाजनक एकीकरण। परंपरागत रूप से, फिर से वस्तुनिष्ठ कारणों के कारण, हमारी टीम ULK PS के लिए सॉफ्टवेयर विकसित करने के लिए Q ++ फ्रेमवर्क, QtCreator IDE और Git को एक संस्करण नियंत्रण प्रणाली के रूप में उपयोग करती है। सिस्टम प्लेटफॉर्म ULK PS के रूप में, लिनक्स कर्नेल पर आधारित एक ओएस का उपयोग किया जाता है

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

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

उपरोक्त के संबंध में, सवाल उठता है - अगर इस समस्या को हल करने के लिए गेम इंजन पर एक शक्तिशाली सॉफ़्टवेयर परत लिखना आवश्यक है, जिसमें से अधिकांश कार्यक्षमता को केवल विचाराधीन समस्या की आवश्यकता नहीं है, तो हमें गेम इंजन की आवश्यकता क्यों है?

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

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

OpenSceneGraph अब तक C ++ विकास पर केंद्रित सबसे विकसित (खुला और मुक्त) ग्राफिक्स इंजन है। यह व्यापक रूप से विदेशों में तकनीकी त्रि-आयामी दृश्य के लिए सटीक रूप से उपयोग किया जाता है। यह इंजन किसी भी प्रकार के सिम्युलेटर द्वारा बख्शा नहीं गया था, जिनमें से सबसे प्रसिद्ध फ्लाइटगियर है । कभी इस इंजन पर आधारित एक रेलवे सिम्युलेटर था - इंद्र , जो, हालांकि, ऊपर दिए गए लिंक के केवल सुस्त स्क्रीनशॉट को छोड़ दिया और इसके आगे का भाग्य मेरे लिए अज्ञात है।

हाथ में कार्य के संदर्भ में, OSG ग्राफिक्स इंजन में निम्नलिखित सकारात्मक गुण हैं:

• क्रॉस-प्लेटफ़ॉर्म, जो इसे जीएनयू / लिनक्स पारिस्थितिकी तंत्र में लागू करना संभव बनाता है
• विकास की भाषा C ++ / STL है, जो इसे आसानी से और स्वाभाविक रूप से विकास की स्थापित तकनीकी प्रक्रिया में एकीकृत करना संभव बनाती है;
• संसाधन प्लग की सबसे विस्तृत श्रृंखला "बॉक्स से बाहर" का समर्थन करती है - विकसित प्लग-इन सिस्टम के कारण 3 डी ज्यामिति और बनावट। गैर-मानक प्रारूपों के लिए संसाधन प्रबंधक की स्थापना के लिए अपना स्वयं का प्लग-इन लिखने के लिए एक सरल और सहज ज्ञान युक्त इंटरफ़ेस, जिसका हमने उपयोग किया (मैं इस बारे में नीचे लिखूंगा);
• स्मार्ट पॉइंटर्स के अपने स्वयं के मॉडल पर आधारित एक मेमोरी मैनेजमेंट सिस्टम (स्मार्ट पॉइंटर्स का एक मालिकाना प्रारूप ऐतिहासिक रूप से उपयोग किया गया है, इस तथ्य के कारण कि स्मार्ट पॉइंटर इंजन के विकास की शुरुआत में सी ++ में कोई मानक नहीं था);
• लचीले मॉड्यूलर वास्तुकला;
• दृश्य वस्तु प्रबंधक जो गतिशील रूप से वस्तुओं को लोड करता है, केवल उन वस्तुओं का लोडिंग और रेंडरिंग प्रदान करता है जो कतरन पिरामिड के भीतर आते हैं (ओएसजी के कारण :: PagedLOD वर्ग)
• Qt ढांचे के साथ एकीकृत करने की क्षमता। Qt द्वारा प्रदान किए गए सुविधाजनक "सिग्नल - स्लॉट्स" मॉडल के लिए धन्यवाद, जो C ++ विकास को काफी सरल और गति प्रदान करता है, हम व्यापक रूप से प्रशिक्षण जटिल सॉफ्टवेयर के विकास के लिए इस ढांचे का उपयोग करते हैं। तदनुसार, हमने विभिन्न परियोजनाओं में पुन: उपयोग किए गए एक महत्वपूर्ण कोड आधार को संचित किया है, खासकर टीसीपी सॉकेट्स के आधार पर इंटरप्रोसेस संचार की लाइब्रेरी के संबंध में। वीडियो सबसिस्टम परियोजना में क्यूटी की क्षमताओं का उपयोग करना एक तार्किक निर्णय लगता है;
• कार्य को हल करने के लिए पर्याप्त छवि गुणवत्ता।

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

4. आर्किटेक्चर से लेकर वर्किंग प्रोटोटाइप तक

रोलिंग स्टॉक ट्रेनिंग सिमुलेटर (एचसीएस) का वीडियो सबसिस्टम एक ग्राहक अनुप्रयोग है, जिसे नियमित रूप से वीडियो 3 डी-क्लाइंट के रूप में संदर्भित किया जाता है, और निम्नलिखित कार्य करता है:

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

ऐसा नहीं है कि यह परियोजना ओपनसोर्स थी, लेकिन एक पूर्ण-विशेषताओं वाली प्रौद्योगिकी डेमो का कोड यहां पाया जा सकता है । परियोजना में निम्नलिखित मॉड्यूल शामिल हैं:

• filesystem - फाइल सिस्टम के साथ काम करने के लिए एक पुस्तकालय, कॉन्फ़िगरेशन फ़ाइलों और अनुप्रयोग संसाधनों के लिए पथ की पीढ़ी प्रदान करता है
• पुस्तकालय - गतिशील पुस्तकालय लोडर का एक क्रॉस-प्लेटफॉर्म कार्यान्वयन। सामान्य तौर पर, ऐसे समय में लिखी गई बैसाखी जब Qt के साथ एकीकरण की संभावनाएं (जहां युद्ध के लिए QLibrary मॉड्यूल तैयार है) अभी भी अस्पष्ट था
• osgdb_dmd - DGLEngine इंजन संस्करण 1.1 के लिए एक प्रारूप के लोडिंग मॉडल के लिए एक प्लगइन। इसके लिए क्या आवश्यक था, मैं थोड़ा नीचे बताऊंगा
• मार्ग-लोडर एक पुस्तकालय है जो मार्ग लोडर को एक सार इंटरफ़ेस प्रदान करता है। मनमाना प्रारूप मार्गों को लोड करना संभव है
• टीसीपी-कनेक्शन - टीसीपी सॉकेट्स पर इंटरप्रोसेस संचार पुस्तकालय
• दर्शक - कार्यक्रम का मुख्य निष्पादन योग्य मॉड्यूल
• Zds- रूट-लोडर - ZDSimulator प्रारूप के लोडिंग मार्गों के लिए प्लग-इन

वीटीपीएस को डिजाइन करते समय, इस सवाल का उदय हुआ कि स्वतंत्र रूप से एक मार्ग प्रारूप विकसित करना है, या मौजूदा मार्ग प्रारूप का उपयोग करना है, साथ ही मौजूदा रेलवे सिम्युलेटर के लिए घरेलू रेलवे के तैयार मार्गों का उपयोग करना है। सौभाग्य से, निर्णय आया - एक बंद मालिकाना उत्पाद ZDSimulator , , . , , , . , DGLEngine. , ( ), 1.1, ZDSimulator. 1.1 , .

, DGLEngine v1.1 Gtihub. , 3D-. OSG.

OSG. , , .







, , RouteLoader. , , .

OSG Qt. osgQt . :

1. , Qt. OSG GUI GUI GUI, osgQt OSG GUI Qt
2. osgQt — OpenGL, OSG QGLWidget, - , Qt. , .

, Qt «-», tcp-connection, Qt - . OSG TCP- ( ) . , , , , :

1. QObject से इनहेरिटिंग क्लासेस
2. सिग्नल प्रोसेसिंग लूप व्यवस्थित करें
3. अनुप्रयोग संचालन के दौरान स्मृति में मौजूद QApplication (या QCoreApplication) वर्ग का एक उदाहरण बनाएँ

QApplication::exec(), , QApplication::processEvents(). OSG ( , ) , osgGA::GUIEventAdapter::FRAME, .

क्यूटी-events.h

#ifndef QT_EVENTS_H #define QT_EVENTS_H #include <osgGA/GUIEventHandler> #include <QtCore/QtCore> class QtEventsHandler : public osgGA::GUIEventHandler { public: QtEventsHandler(){} virtual bool handle(const osgGA::GUIEventAdapter &ea, osgGA::GUIActionAdapter &aa); protected: }; #endif // QT_EVENTS_H 

क्यूटी-events.cpp

 #include "qt-events.h" bool QtEventsHandler::handle(const osgGA::GUIEventAdapter &ea, osgGA::GUIActionAdapter &aa) { switch (ea.getEventType()) { case osgGA::GUIEventAdapter::FRAME: { QCoreApplication::processEvents(QEventLoop::AllEvents, 100); break; } default: break; } return false; } 

main.cpp

 #include "main.h" /*! * \fn * \brief Entry point */ //------------------------------------------------------------------------------ // //------------------------------------------------------------------------------ int main(int argc, char *argv[]) { QCoreApplication app(argc, argv); RouteViewer viewer(argc, argv); if (viewer.isReady()) return viewer.run(); return 0; } 

जिसके बाद, QObject और उसके डेरिवेटिव से विरासत में मिली कक्षाएं तब तक संकेतों का आदान-प्रदान कर सकती हैं जब तक कि पल्स खो नहीं जाती।

उपरोक्त सभी ने HTPS का पहला कार्यशील प्रोटोटाइप बनाने के लिए दो महीने की अनुमति दी। अंत में क्या हुआ, यह प्रदर्शित करने के लिए, मैं वास्तविक मार्गों पर प्रायोगिक यात्राओं से निम्नलिखित अनुभाग का प्रस्ताव करता हूं। मैं शूटिंग की गुणवत्ता के लिए अग्रिम रूप से माफी मांगता हूं - उन्हें स्मार्ट तकनीक नहीं मिली

निष्कर्ष और निष्कर्ष

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

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

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

आपका ध्यान के लिए धन्यवाद!

(c) नवप्रवर्तन दक्षताओं के विकास का केंद्र