क्या मुझे खेल में ग्राफिक्स और भौतिकी इंजन के बीच डेटा साझा करना चाहिए?


9

मैं खेल इंजन लिख रहा हूं जिसमें कुछ मॉड्यूल शामिल हैं। उनमें से दो ग्राफिक्स इंजन और भौतिकी इंजन हैं

मुझे आश्चर्य है कि अगर उनके बीच डेटा साझा करना एक अच्छा समाधान है?

दो तरीके (साझा करना या न करना) ऐसा दिखता है:

डेटा साझा किए बिना

GraphicsModel{
    //some common for graphics and physics data like position

    //some only graphic data 
    //like textures and detailed model's verticles that physics doesn't need
};

PhysicsModel{
    //some common for graphics and physics data like position

    //some only physics data 
    //usually my physics data contains A LOT more informations than graphics data
}

engine3D->createModel3D(...);
physicsEngine->createModel3D(...);

//connect graphics and physics data 
//e.g. update graphics model's position when physics model's position will change

मुझे दो मुख्य समस्याएं दिखाई देती हैं:

  1. बहुत अधिक अनावश्यक डेटा (जैसे भौतिकी और ग्राफिक्स डेटा दोनों के लिए दो स्थिति)
  2. अद्यतन डेटा के साथ समस्या (भौतिकी डेटा में परिवर्तन होने पर मुझे ग्राफिक्स डेटा को मैन्युअल रूप से अपडेट करना होगा)

डेटा साझा करने के साथ

Model{
     //some common for graphics and physics data like position
};

GraphicModel : public Model{
    //some only graphics data 
    //like textures and detailed model's verticles that physics doesn't need
};

PhysicsModel : public Model{
     //some only physics data 
    //usually my physics data contains A LOT more informations than graphics data
}

model = engine3D->createModel3D(...);
physicsEngine->assingModel3D(&model); //will cast to 
//PhysicsModel for it's purposes??

//when physics changes anything (like position) in model 
//(which it treats like PhysicsModel), the position for graphics data 
//will change as well (because it's the same model)

यहाँ समस्याएं:

  1. PhysEngine नई वस्तुओं का निर्माण नहीं कर सकता, बस इंजन 3 डी से मौजूदा "assing" (किसी तरह यह मेरे लिए और अधिक स्वतंत्र दिखता है)
  2. AssingModel3D फ़ंक्शन में डेटा कास्टिंग
  3. PhysEngEngine और graphicsEngine सावधान रहना चाहिए - वे डेटा को नष्ट नहीं कर सकते जब उन्हें उनकी आवश्यकता नहीं है (क्योंकि दूसरे को इसकी आवश्यकता हो सकती है)। लेकिन यह दुर्लभ स्थिति है। इसके अलावा, वे सिर्फ पॉइंटर को हटा सकते हैं, ऑब्जेक्ट को नहीं। या हम मान सकते हैं कि graphicsEngine वस्तुओं को हटा देगा, PhysEngine सिर्फ उनके लिए संकेत देता है।

कौन सा तरीका बेहतर है?

जो भविष्य में और अधिक समस्याएं पैदा करेगा?

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

क्या उनके पास और अधिक छिपे हुए नियम और विरोधाभास हैं?


बिल्कुल मेरा सवाल, भी।
दानीझर

जवाबों:


9

आजकल, अधिक खेल इंजन एक घटक डिजाइन (जैसे एकता, अवास्तविक) को अपनाते हैं। इस तरह के डिजाइन में, ए GameObjectघटकों की एक सूची से बना है। आपकी स्थिति में, एकल गेम ऑब्जेक्ट के साथ संलग्न होने से ए MeshComponentऔर ए PhysicalComponentदोनों हो सकते हैं ।

सादगी के लिए, आप एक विश्व परिवर्तनशील चर डाल सकते हैं GameObject। अपडेट वाक्यांश के दौरान, PhysicalComponentआउटपुट उस चर में दुनिया को बदल देता है। प्रतिपादन के दौरान, MeshComponentउस चर को पढ़ता है।

इस डिजाइन के पीछे का तर्क घटकों के बीच का विघटन है। न तो MeshComponentहै और न ही PhysicalComponentएक दूसरे को जानता है। वे सिर्फ एक सामान्य इंटरफ़ेस पर निर्भर करते हैं। और विरासत द्वारा एकल पदानुक्रम का उपयोग करने की तुलना में रचना द्वारा प्रणाली का विस्तार करना आसान हो सकता है।

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

एकता ने उनके कंपोनेंट्स का अच्छा संदर्भ दिया , जो देखने लायक था।


यह सवाल का बिल्कुल भी जवाब नहीं देता है, 2 घटक होने के बारे में कुछ भी नहीं कहता है कि वे मेष-डेटा साझा करते हैं या नहीं।
माईक सेमर

2
दरअसल, यह बेहतर डिजाइन प्रदान करता है, जो पूरी तरह से वैध है।
12

7

इंजन आमतौर पर पहला विकल्प चुनते हैं (स्वयं भौतिकी-मेष और स्वयं रेंडर-मेष) क्योंकि उन्हें गुणवत्ता और मात्रा दोनों में बहुत अलग डेटा की आवश्यकता होती है।

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

मात्रा क्योंकि भौतिकी जाल में आमतौर पर कम त्रिकोण होते हैं, इसका उच्च रिज़ॉल्यूशन मेष का सरलीकृत संस्करण होता है।

दोनों को डिकूप करने से हम यह सुनिश्चित करते हैं कि हम दूसरे को दूषित किए बिना, बेहतर प्रदर्शन के लिए इसके डेटा-लेआउट को बदलने सहित एक को ट्विक कर सकते हैं। यह अधिक स्केलेबल है।


0

इसके अलावा @ मिलो यिप महान जवाब मैं आपको यह याद दिलाना चाहूंगा कि आपको नियंत्रण मॉड्यूल और एआई मॉड्यूल के साथ एक ही डेटा साझा करने की आवश्यकता होगी और अगर मैं गलत नहीं हूं तो अधिकांश ऑडियो लाइब्रेरी में ध्वनि एमिटर की स्थिति की धारणा है इसलिए आपको उस मॉड्यूल के साथ भी डेटा साझा करना होगा।


0

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

कैसे भौतिकी से डेटा रेंडर करने योग्य हो जाता है पूरी तरह से आप पर निर्भर है।

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.