भौतिकी या ग्राफिक्स घटक आमतौर पर एक घटक-उन्मुख प्रणाली में कैसे बनाए जाते हैं?

Question

मैंने पिछले 48 घंटे ऑब्जेक्ट कंपोनेंट सिस्टम पर पढ़ने में बिताए हैं, और मुझे लगता है कि मैं इसे लागू करने के लिए पर्याप्त तैयार हूं। मुझे बेस ऑब्जेक्ट और कंपोनेंट क्लासेज मिलीं, लेकिन अब जब मुझे उन वास्तविक कंपोनेंट्स को बनाने की शुरुआत करने की जरूरत है जो मैं थोड़ा उलझन में हूं। जब मैं उनके बारे में HealthComponent या किसी ऐसी चीज के बारे में सोचता हूं जो मूल रूप से सिर्फ एक संपत्ति होगी, तो यह सही समझ में आता है। जब यह भौतिकी / ग्राफिक्स घटक के रूप में कुछ और सामान्य है, तो मैं थोड़ा भ्रमित हो जाता हूं।

मेरी ऑब्जेक्ट क्लास अब तक इस तरह दिखती है (यदि आपको कोई भी बदलाव नज़र आता है तो कृपया मुझे बताएं, मुझे अभी भी इस बारे में नया बताना चाहिए ...)

typedef unsigned int ID;

class GameObject
{
public:

    GameObject(ID id, Ogre::String name = "");
    ~GameObject();

    ID &getID();
    Ogre::String &getName();

    virtual void update() = 0;

    // Component Functions
    void addComponent(Component *component);
    void removeComponent(Ogre::String familyName);

    template<typename T>
    T* getComponent(Ogre::String familyName)
    {
        return dynamic_cast<T*>(m_components[familyName]);
    }

protected:

    // Properties
    ID m_ID;
    Ogre::String m_Name;
    float m_flVelocity;
    Ogre::Vector3 m_vecPosition;

    // Components
    std::map<std::string,Component*> m_components;
    std::map<std::string,Component*>::iterator m_componentItr;
};

अब मैं जिस समस्या को लेकर चल रहा हूं, वह यह है कि सामान्य आबादी भौतिक विज्ञान / ग्राफिक्स जैसे घटकों में क्या डालेगी? ओग्रे (मेरे रेंडरिंग इंजन) के लिए दृश्यमान ऑब्जेक्ट्स में दृश्य से जुड़ने के लिए कई Ogre :: SceneNode (संभवतः कई) होंगे, जो दृश्य मेषों को दिखाने के लिए Ogre :: Entity (संभवतः कई) हैं, और इसी तरह। क्या सिर्फ ऑब्जेक्ट में कई ग्राफिक.कॉम को जोड़ना और प्रत्येक ग्राफिककंपनी को एक सीनोडेन / एंटिटी को संभालने देना अच्छा होगा या क्या विचार है कि प्रत्येक घटक में से एक की आवश्यकता है?

भौतिकी के लिए मैं और भी अधिक भ्रमित हूँ। मुझे लगता है शायद एक RigidBody बनाने और द्रव्यमान / अंतर / / का ट्रैक रखने के लिए। समझ में आता है। लेकिन मुझे यह सोचने में परेशानी हो रही है कि वास्तव में कॉम्पोनेंट्स में कंपोनेंट्स को कैसे रखा जाए।

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

Answer 1

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

यह घटक प्रणाली से डिकोडिंग और भौतिकी प्रणालियों को बनाए रखने का अतिरिक्त लाभ है।

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

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

यह अपेक्षाकृत सरल है - जो भी कारण लोगों को भ्रमित करने के लिए लगता है, लेकिन ऐसा अक्सर होता है क्योंकि वे इसके बारे में बहुत कठिन सोच रहे हैं। वहाँ बहुत जादू नहीं है। और चूँकि यह सबसे महत्वपूर्ण है कि चीजों को सही डिज़ाइन के ऊपर तड़पाने के बजाय, आपको एक ऐसे दृष्टिकोण पर विचार करना चाहिए जहाँ कम से कम कुछ घटकों ने इंटरफेस को परिभाषित किया है और गेम ऑब्जेक्ट के प्रत्यक्ष सदस्य हैं, जैसा कि मोम्बोको ने सुझाया है। यह सिर्फ एक दृष्टिकोण के रूप में मान्य है और यह अधिक आसान हो जाता है।

अन्य टिप्पणी

यह आपके प्रत्यक्ष प्रश्नों से संबंधित नहीं है, लेकिन ये ऐसी चीजें हैं जिन्हें मैंने आपके कोड को देखते समय देखा था:

आप अपने गेम ऑब्जेक्ट में Ogre :: String और std :: string को क्यों मिला रहे हैं, जो कि वास्तव में एक नॉन-ग्राफिक्स ऑब्जेक्ट है और इस तरह Ogre पर निर्भरता नहीं होनी चाहिए? मैं सुझाव देना चाहूंगा कि ओगरे के सभी प्रत्यक्ष संदर्भों को केवल रेंडरिंग कंपोनेंट को छोड़कर, जहां आपको अपना रूपांतरण करना चाहिए।

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

आप कुछ उपयोग से लाभान्वित हो सकते हैं const(विशेष रूप से जहां आप संदर्भ द्वारा लौट रहे हैं)। इसके अलावा, मुझे यकीन नहीं है कि आप वास्तव में एक स्केलर होना चाहते हैं (या अगर यह और स्थिति, तो आप जिस वस्तु के लिए जा रहे हैं, उसी तरह से सामान्य जेनेरिक घटक पद्धति में गेम ऑब्जेक्ट में मौजूद होना चाहिए)।

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

Comments

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

— ऐदन नाइट

जहाँ तक "अन्य टिप्पणियाँ" भाग है, इसके लिए धन्यवाद। मैंने स्ट्रिंग्स को मिलाया क्योंकि मैं आमतौर पर अपनी परियोजना के लिए एक आधार के रूप में सभी Ogre फ़ंक्शन का उपयोग करना पसंद करता हूं जो Ogre का उपयोग करते हैं, लेकिन मैंने इसे मैप / जोड़ी / आदि की कमी होने के बाद से ऑब्जेक्ट / घटक प्रणाली में स्विच करना शुरू कर दिया। हालांकि आप सही हैं और मैंने उन्हें ओगरे से अलग करने के लिए उन सभी को एसटीडी सदस्यों में बदल दिया है।

— ऐदन नाइट

+1 यह एक घटक आधारित मॉडल है, जिसे मैंने थोड़ी देर में यहां पढ़ा था, सामान्यीकरण के खिलाफ अच्छा विपरीत

— माईक सेमर

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

+1 के लिए "यह सबसे महत्वपूर्ण है कि चीजों को सही डिजाइन पर

— तड़पाने के

Answer 2

घटक वास्तुकला बड़े पदानुक्रम से बचने के लिए एक विकल्प है जो एक ही नोड से सभी तत्वों को विरासत में प्राप्त किया जाता है, और युग्मन की समस्याएं जो आगे बढ़ती हैं।

आप "जेनेरिक" घटकों के साथ एक घटक वास्तुकला दिखा रहे हैं। आपके पास "जेनेरिक" घटकों को संलग्न करने और अलग करने का मूल तर्क है। जेनेरिक घटकों के साथ एक आर्किटेक्चर को प्राप्त करना अधिक कठिन है क्योंकि आप नहीं जानते कि कौन सा घटक है। लाभ यह है कि यह दृष्टिकोण व्यापक है।

एक मान्य घटक आर्किटेक्चर परिभाषित घटकों के साथ हासिल किया जाता है। परिभाषित अर्थ के साथ, इंटरफ़ेस परिभाषित है, कार्यान्वयन नहीं। उदाहरण के लिए, GameObject में एक IPhysicInstance, परिवर्तन, IMesh, IAnimationController हो सकता है। इसका यह लाभ है कि आप इंटरफ़ेस जानते हैं और गेमऑब्जेक्ट जानता है कि प्रत्येक घटक से कैसे निपटना है।

शब्द का सामान्यीकरण पर प्रतिक्रिया

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

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

घटक आर्किटेक्चर को अलग करने वाली मुख्य विशेषता यह है कि संबंध ए-ए है। उदाहरण के लिए एक वस्तु वास्तुकला एक है:

ऑब्जेक्ट आर्किटेक्चर के बजाय एक (घटक) हैं:

प्रॉपर्टी-केंद्रित आर्किटेक्चर भी है:

उदाहरण के लिए, एक सामान्य वस्तु वास्तुकला इस प्रकार है:

• Object1

  • पद = (0, 0, 0)
  • अभिविन्यास = (0, 43, 0)

• Object2

  • पद = (10, 0, 0)
  • अभिविन्यास = (0, 0, 30)

एक संपत्ति केंद्रित वास्तुकला:

• स्थान

  • Object1 = (0, 0, 0)
  • Object2 = (10, 0, 0)

• अभिविन्यास

  • Object1 = (0, 43, 0)
  • Object2 = (0, 0, 30)

यह बेहतर है वस्तु मॉडल वास्तुकला? प्रदर्शन के परिप्रेक्ष्य में, यह संपत्ति-केंद्रित बेहतर है क्योंकि यह अधिक कैश-फ्रेंडली है।

घटक का संबंध है-ए की बजाय संबंध से है। एक घटक एक परिवर्तन मैट्रिक्स, एक quaternion, आदि हो सकता है। लेकिन गेम-ऑब्जेक्ट के साथ संबंध एक संबंध है-ए, गेम-ऑब्जेक्ट में परिवर्तन नहीं है क्योंकि यह विरासत में मिला है। गेम-ऑब्जेक्ट में (संबंध है-ए) परिवर्तन है। परिवर्तन तब एक घटक है।

खेल-वस्तु एक हब की तरह है। यदि आप एक ऐसा घटक चाहते हैं जो हमेशा बना रहे, तो हो सकता है कि घटक (मैट्रिक्स की तरह) ऑब्जेक्ट के अंदर होना चाहिए न कि कोई पॉइंटर।

सभी मामलों के लिए एक आदर्श गेम-ऑब्जेक्ट नहीं है, यह इंजन, पुस्तकालयों का उपयोग करता है जो इंजन का उपयोग करता है। शायद मुझे ऐसा कैमरा चाहिए, जिसमें जाली न हो। एक आर्किटेक्चर के साथ समस्या यह है कि यदि गेम-ऑब्जेक्ट में एक मेष है, तो गेम-ऑब्जेक्ट से विरासत में आने वाले कैमरे में एक मेष होना चाहिए। इटोमेनसेट्स के साथ, कैमरा में एक परिवर्तन, आंदोलन के लिए एक नियंत्रक और कुछ भी आपकी आवश्यकता है।

अधिक जानकारी के लिए, "जेसन ग्रेगरी" के "गेम इंजन आर्किटेक्चर" पुस्तक से अध्याय "14.2। रनटाइम ऑब्जेक्ट मॉडल आर्किटेक्चर" विशेष रूप से इस विषय पर काम करता है।

यूएमएल आरेख वहाँ से निकाले जाते हैं

Comments

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

— माईक सेमर

@ माईक सेमर: मैं सामान्य शब्दों में ओवर-जनरलिंग में आपसे सहमत हूं, लेकिन मुझे लगता है कि टर्म कंपोनेंट स्पष्ट नहीं है। मैंने अपना उत्तर संपादित कर दिया है। इसे पढ़ें और मुझे अपने इंप्रेशन दें।

— मोम्बोको

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

— Maik Semder

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

— माईक सेमर

अगर एनिमेशनकंट्रोलर (AC) और मेश के बीच, 2 फ़ंक्शनलिटीज़ के बीच एक मजबूत संबंध है, तो किसी भी तरह से AC को एक घटक में दबाकर इस रिश्ते को न तोड़ें, इसके विपरीत मेश एक पूर्ण घटक है, लेकिन एक AC मेष में।

— माईक सेमर