কীভাবে পদার্থবিজ্ঞান বা গ্রাফিক্স উপাদানগুলি সাধারণত কোনও উপাদান-ভিত্তিক সিস্টেমে নির্মিত হয়?


19

আমি অবজেক্ট কম্পোনেন্ট সিস্টেমগুলি পড়তে শেষ 48 ঘন্টা ব্যয় করেছি এবং আমি মনে করি এটি কার্যকর করতে শুরু করার জন্য আমি যথেষ্ট প্রস্তুত। আমি বেস অবজেক্ট এবং কম্পোনেন্টের ক্লাসগুলি তৈরি করেছি, তবে এখন আমার আসল উপাদানগুলি তৈরি করা শুরু করা উচিত আমি কিছুটা বিভ্রান্ত am আমি যখন হেলথ কম্পোনেন্ট বা এমন কিছু হিসাবে বিবেচনা করি যা মূলত কেবল একটি সম্পত্তি হতে পারে, তখন এটি সঠিক ধারণা দেয়। এটি যখন পদার্থবিজ্ঞান / গ্রাফিক্স উপাদান হিসাবে আরও সাধারণ কিছু হয় তখন আমি কিছুটা বিভ্রান্ত হয়ে পড়ি।

আমার অবজেক্ট ক্লাসটি এখনও পর্যন্ত এটির মতো দেখাচ্ছে (আপনি যদি আমার কোনও পরিবর্তন লক্ষ্য করেন তবে দয়া করে আমাকে জানান, এটি এখনও নতুন) ...

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;
};

এখন আমি যে সমস্যাটি চালাচ্ছি তা হ'ল সাধারণ জনগণ ফিজিক্স / গ্রাফিক্সের মতো উপাদানগুলিতে কী রাখবে? ওগ্রে (আমার রেন্ডারিং ইঞ্জিন) এর জন্য দৃশ্যমান অবজেক্টগুলি দৃশ্যের সাথে সংযুক্ত করতে একাধিক ওগ্রে :: সিন নোড (সম্ভবত একাধিক), দৃশ্যমান মেসগুলি দেখানোর জন্য ওগ্রে :: সত্তা (সম্ভবত একাধিক) সমন্বিত থাকবে। কেবলমাত্র একাধিক গ্রাফিকসম্পটোনকে অবজেক্টে যুক্ত করা এবং প্রতিটি গ্রাফিককম্পোনেন্টকে একটি দৃশ্য ননড / সত্তা পরিচালনা করতে দেওয়া ভাল বা প্রতিটি উপাদানগুলির মধ্যে একটির ধারণা থাকা দরকার?

পদার্থবিজ্ঞানের জন্য আমি আরও বিভ্রান্ত। আমি মনে করি সম্ভবত একটি RigidBody তৈরি করছে এবং ভর / আন্তিয়া / ইত্যাদি সম্পর্কে নজর রাখছে। বুদ্ধি করতে হবে। তবে কীভাবে আসলে কোনও কম্পোনেন্টে স্পেসিফিকেশন লাগানো যায় তা ভাবতে আমার সমস্যা হচ্ছে।

আমি যখন এই "প্রয়োজনীয়" উপাদানগুলির কয়েকটি তৈরি করলাম তবে আমি মনে করি এটি আরও অনেক বেশি অর্থবোধ করবে। এই মুহূর্তে যদিও আমি এখনও কিছুটা স্টম্পড।

উত্তর:


32

প্রথম সব, আপনি বিল্ড কম্পোনেন্ট ভিত্তিক সিস্টেম, আপনি না তখন আছে বাঁক অভিগমন সবকিছু একটি উপাদান মধ্যে। আসলে, আপনার সাধারণত করা উচিত নয় - এটি একটি নিওফাইট ভুলের কিছু। আমার অভিজ্ঞতায় কোন উপাদান ভিত্তিক আর্কিটেকচারে রেন্ডারিং এবং ফিজিক্স সিস্টেমগুলি একত্রে বেঁধে রাখার সর্বোত্তম উপায় হ'ল সেই উপাদানগুলিকে আসল রেন্ডারিং বা পদার্থবিজ্ঞানের আদিম বস্তুর জন্য বোবা কনটেইনারগুলির তুলনায় কিছুটা বেশি করা।

এতে রেন্ডারিং এবং ফিজিক্স সিস্টেমগুলি উপাদান উপাদান থেকে decoupled রাখার অতিরিক্ত সুবিধা রয়েছে।

পদার্থবিজ্ঞানের সিস্টেমগুলির জন্য, উদাহরণস্বরূপ, পদার্থবিজ্ঞান সিমুলেটর সাধারণত কঠোর বডি অবজেক্টগুলির একটি বৃহত তালিকা রাখে যা প্রতিবার এটি টিক করে দেখায়। আপনার উপাদান সিস্টেমটি এতে বিভ্রান্ত হয় না - আপনার পদার্থবিজ্ঞানের উপাদানটি অনমনীয় শরীরের জন্য কেবল একটি রেফারেন্স সঞ্চয় করে যা উপাদানটির অন্তর্ভুক্ত অবজেক্টের শারীরিক দিকগুলিকে উপস্থাপন করে এবং উপাদান উপাদান থেকে কোনও বার্তা অনমনীয় শরীরের উপযুক্ত ম্যানিপুলেশনে অনুবাদ করে।

একইভাবে রেন্ডারিংয়ের সাথে - আপনার রেন্ডারারের কাছে উপস্থাপনের জন্য উপস্থাপিত ডেটা উপস্থাপন করার জন্য কিছু থাকবে এবং আপনার ভিজ্যুয়াল উপাদানটি কেবল তার একটি রেফারেন্স ধরে রেখেছে।

এটি তুলনামূলকভাবে সোজা - যে কারণেই এটি লোককে বিভ্রান্ত করে বলে মনে হয় তবে এটি প্রায়শই কারণ তারা এ সম্পর্কে খুব কঠিন চিন্তা করে। সেখানে প্রচুর যাদু নেই। এবং যেহেতু নিখুঁত ডিজাইনের উপর যন্ত্রণা না দিয়ে জিনিসগুলি করা সবচেয়ে গুরুত্বপূর্ণ, তাই আপনার এমন একটি পদ্ধতির দৃ strongly়তার সাথে বিবেচনা করা উচিত যেখানে কমপক্ষে কয়েকটি উপাদান ইন্টারফেসকে সংজ্ঞায়িত করেছে এবং গেম অবজেক্টের প্রত্যক্ষ সদস্য, যেমন মোম্বোকো পরামর্শ দিয়েছে। এটি ঠিক যেমন একটি পদ্ধতির বৈধ এবং এটি আঁকাবাঁকা করা সহজ হতে ঝোঁক।

অন্যান্য বক্তব্য

এটি আপনার সরাসরি প্রশ্নের সাথে সম্পর্কিত নয়, তবে আপনার কোডটি দেখার সময় এগুলি আমি লক্ষ্য করেছি:

আপনি কেন আপনার গেমের অবজেক্টে ওগ্রে :: স্ট্রিং এবং স্টাড :: স্ট্রিংকে মেশাচ্ছেন, যা সম্ভবত একটি গ্রাফিক্স অবজেক্ট এবং সুতরাং ওগ্রের উপর নির্ভরতা থাকা উচিত নয়? আমি রেন্ডারিং উপাদানটি বাদ দিয়ে ওগ্রের সমস্ত প্রত্যক্ষ রেফারেন্সগুলি সরিয়ে ফেলার পরামর্শ দেব, যেখানে আপনার রূপান্তরটি করা উচিত।

আপডেট () একটি খাঁটি ভার্চুয়াল, যা বোঝায় যে একটি অবশ্যই গেমওজেক্টকে সাবক্লাস করতে হবে, যা আসলে কোনও উপাদান আর্কিটেকচারের সাথে আপনি যেতে চাইছেন ঠিক তার বিপরীতে of উপাদানগুলি ব্যবহারের মূল বিষয় হ'ল উত্তরাধিকারের চেয়ে কার্যকারিতার সংহতকরণকে পছন্দ করা।

আপনি কিছু ব্যবহার করে উপকার পেতে পারেন const(বিশেষত যেখানে আপনি রেফারেন্স দিয়ে ফিরে যাচ্ছেন)। এছাড়াও আমি নিশ্চিত নই যে আপনি সত্যিই বেগটি একটি স্কেলার হতে চান (বা যদি এটি হয় এবং অবস্থান হয় তবে যে ধরণের অতিরিক্ত জেনেরিক উপাদান পদ্ধতিটি আপনি যাচ্ছেন বলে মনে হচ্ছে তা খেলায় উপস্থিত থাকতে হবে)।

update()গেম অবজেক্টে উপাদানগুলির একটি বৃহত মানচিত্র এবং একটি কল ব্যবহার করার জন্য আপনার পদ্ধতির বিষয়টি যথেষ্ট উপ-অনুকূল (এবং যারা প্রথমে এই ধরণের সিস্টেম তৈরি করছেন তাদের জন্য একটি সাধারণ ক্ষতি)। এটি আপডেটের সময় খুব দুর্বল ক্যাশে একাত্মতা তৈরি করে এবং আপনাকে একযোগে ডেটা বা আচরণের বড় ব্যাচগুলির সিমডি-স্টাইল প্রক্রিয়াটির দিকে সম্মতি এবং প্রবণতার সুবিধা নিতে দেয় না। গেম অবজেক্ট তার উপাদানগুলি আপডেট না করে এমন নকশা ব্যবহার করা প্রায়শই ভাল but তবে উপাদানটির জন্য দায়বদ্ধ সাবসিস্টেম নিজেই সেগুলি একবারে আপডেট করে। এটি একটি পাঠ্য মূল্য হতে পারে।


এই উত্তরটি দুর্দান্ত ছিল। আমি এখনও মন্তব্যে স্পেস অনুচ্ছেদে কোনও উপায় বের করতে পারি নি (কীটি জমা দেওয়ার কী লিখুন) তবে আমি এই প্রতিক্রিয়াগুলিকে সম্বোধন করব। অবজেক্ট / কম্পোনেন্ট সিস্টেম সম্পর্কিত আপনার বিবরণটি অনেক অর্থবোধ করেছে। সুতরাং কেবল স্পষ্ট করে বলতে, একটি পদার্থবিজ্ঞানের ক্ষেত্রে, উপাদানটির কনস্ট্রাক্টরের ক্ষেত্রে, আমি কেবল আমার ফিজিক্স ম্যানেজারের ক্রিয়েটরিজিডবডি () ফাংশনটি কল করতে পারি এবং তারপরে উপাদানটির মধ্যে একটি রেফারেন্স সঞ্চয় করতে পারি?
আইডান নাইট

"অন্যান্য মন্তব্য" অংশ হিসাবে, এই জন্য ধন্যবাদ। আমি স্ট্রিংগুলি মিশ্রিত করলাম কারণ আমি সাধারণত আমার প্রকল্পের ওগ্রে ব্যবহারের ভিত্তিতে সমস্ত ওগ্রে ফাংশন ব্যবহার করতে পছন্দ করি তবে মানচিত্র / জুড়ি / ইত্যাদির অভাবের কারণে আমি এটি অবজেক্ট / উপাদান উপাদানটিতে স্যুইচিং শুরু করি। আপনি যদিও ঠিক আছেন এবং ওগ্র থেকে আলাদা করার জন্য আমি তাদের সমস্ত স্ট্যান্ডের সদস্যদের কাছে রূপান্তর করেছি।
আইডান নাইট

1
+1 আমি এখানে কিছুক্ষণের জন্য কম্পোনেন্ট ভিত্তিক মডেল পড়ার বিষয়ে প্রথম বুদ্ধিমান উত্তর, অতিরিক্ত-জেনারেলাইজিংয়ের বিরুদ্ধে দুর্দান্ত বৈপরীত্য
মাইক সেমদার

5
এটি আরও ভাল সংহতি (ডেটা এবং নির্দেশের ক্যাশে উভয়ই) জন্য অনুমতি দেয় এবং আপনাকে স্বতন্ত্র থ্রেড বা কর্মী প্রসেসের (উদাহরণস্বরূপ) প্রায় তুচ্ছভাবে আপডেটগুলি আপলোড করার সম্ভাবনা দেয়। কিছু ক্ষেত্রে উপাদানগুলি এমনকি কোনওভাবে আপডেট করার প্রয়োজন হবে না, যার অর্থ আপনি কোনও আপডেট () পদ্ধতিতে কোনও অপ-কলের ওভারহেড এড়াতে পারবেন। আপনাকে ডেটা-ওরিয়েন্টেড সিস্টেমগুলি তৈরি করতে সহায়তা করে - এটি হ'ল বাল্ক প্রসেসিং সম্পর্কে, যা সিপিইউ আর্কিটেকচারে আধুনিক ট্রেন্ডগুলির সুবিধা গ্রহণ করে।

2
"নিখুঁত ডিজাইনের কারণে যন্ত্রণা না করে কাজগুলি করা সবচেয়ে গুরুত্বপূর্ণ"
+1

5

উপাদান হ'ল আর্কিটেকচার হ'ল একটি বৃহত্তর শ্রেণিবিন্যাস যা একই নোড থেকে সমস্ত উপাদানকে উত্তরাধিকার সূত্রে প্রাপ্ত হয় এবং দম্পতির সমস্যা যা নেতৃত্ব দেয় তা এড়ানোর বিকল্প alternative

আপনি "জেনেরিক" উপাদানগুলির সাথে একটি উপাদান আর্কিটেকচার দেখিয়ে চলেছেন। "জেনেরিক" উপাদানগুলিকে সংযুক্ত এবং বিচ্ছিন্ন করার আপনার কাছে প্রাথমিক যুক্তি রয়েছে। জেনেরিক উপাদান সহ একটি আর্কিটেকচার অর্জন করা আরও কঠিন কারণ আপনি জানেন না কোন উপাদানটি। সুবিধাগুলি হ'ল এই পদ্ধতিটি এক্সটেনসিবল।

একটি বৈধ উপাদান আর্কিটেকচার নির্ধারিত উপাদানগুলির সাথে অর্জন করা হয়। সংজ্ঞায়িত বলতে আমি বলতে চাইছি, ইন্টারফেসটি সংজ্ঞায়িত হয়, বাস্তবায়ন নয়। উদাহরণস্বরূপ, গেমওজেক্টে আইফিসিকআইনস্ট্যান্স, ট্রান্সফর্মেশন, আইএমেশ, আইএনিমেশনকন্ট্রোলার থাকতে পারে। এর ইন্টারফেসটি হ'ল আপনি ইন্টারফেসটি জানেন এবং গেমওজেক্ট প্রতিটি উপাদানগুলির সাথে কীভাবে আচরণ করতে জানে।

অতিরিক্ত-সাধারণকরণ শব্দটির প্রতিক্রিয়া

আমি মনে করি যে ধারণাগুলি পরিষ্কার নয়। আমি যখন উপাদানটি বলি, তার মানে এই নয় যে কোনও গেম-অবজেক্টের সমস্ত উপাদানকে অবশ্যই কোনও উপাদান ইন্টারফেস বা অনুরূপ কিছু থেকে উত্তরাধিকারী হতে হবে। তবে এটি জেনেরিক উপাদানগুলির জন্য দৃষ্টিভঙ্গি, আমি মনে করি যে এটি একটি ধারণা হিসাবে আপনি নামটি ধারণ করেছেন।

কম্পোনেন্ট আর্কিটেকচার রানটাইম অবজেক্ট মডেলের জন্য বিদ্যমান অন্য স্থাপত্যগুলি। এটি একমাত্র নয় এবং এটি সব ক্ষেত্রেই সেরা নয়, তবে অভিজ্ঞতাটি প্রমাণ করেছে যে কম সংযোগের মতো প্রচুর সুবিধা রয়েছে।

উপাদান বৈশিষ্ট্যটি পৃথক করে এমন প্রধান বৈশিষ্ট্যটি হ'ল-এ-এ সম্পর্কটিকে রূপান্তর করে a উদাহরণস্বরূপ কোনও বস্তুর আর্কিটেকচার হ'ল:

একটি আর্কিটেকচার

কোনও অবজেক্টের পরিবর্তে আর্কিটেকচারের রয়েছে একটি (উপাদান):

একটি আর্কিটেকচার আছে

সম্পত্তি-কেন্দ্রিক স্থাপত্যগুলিও রয়েছে:

উদাহরণস্বরূপ, একটি সাধারণ অবজেক্ট আর্কিটেকচার এরকম:

  • Object1

    • অবস্থান = (0, 0, 0)
    • ওরিয়েন্টেশন = (0, 43, 0)
  • Object2

    • অবস্থান = (10, 0, 0)
    • ওরিয়েন্টেশন = (0, 0, 30)

একটি সম্পত্তি কেন্দ্রিক আর্কিটেকচার:

  • অবস্থান

    • অবজেক্ট 1 = (0, 0, 0)
    • অবজেক্ট 2 = (10, 0, 0)
  • ঝোঁক

    • অবজেক্ট 1 = (0, 43, 0)
    • অবজেক্ট 2 = (0, 0, 30)

এটা কি বস্তু মডেল আর্কিটেকচার ভাল? কর্মক্ষেত্রের দৃষ্টিতে এটি সম্পত্তি-কেন্দ্রিকের চেয়ে ভাল কারণ এটি আরও ক্যাশে-বান্ধব।

অংশটি হ'ল-এ-এর পরিবর্তে সম্পর্কের বিষয়ে উল্লেখ করা হয়। কোনও উপাদান ট্রান্সফর্মেশন ম্যাট্রিক্স, একটি চৌম্বক ইত্যাদি হতে পারে তবে গেম-অবজেক্টের সাথে সম্পর্কটি হ'ল একটি, গেম-অবজেক্টের রূপান্তর নেই কারণ এটি উত্তরাধিকার সূত্রে প্রাপ্ত। গেম-অবজেক্টটির (সম্পর্কের রয়েছে একটি) রূপান্তর। রূপান্তরটি তখন একটি উপাদান।

গেম-অবজেক্ট হাবের মতো। আপনি যদি এমন কোনও উপাদান চান যা সর্বদা থাকে, তবে সম্ভবত উপাদানটি (ম্যাট্রিক্সের মতো) অবজেক্টের ভিতরে থাকা উচিত এবং কোনও পয়েন্টার নয়।

সমস্ত ক্ষেত্রে একটি নিখুঁত গেম-অবজেক্ট নেই, এটি ইঞ্জিন নির্ভর করে, ইঞ্জিনগুলি যে লাইব্রেরিগুলি ব্যবহার করে। হতে পারে আমি এমন ক্যামেরা চাই যাতে জাল না থাকে। একটি আর্কিটেকচারের সমস্যা হ'ল গেম-অবজেক্টটিতে যদি জাল থাকে তবে গেম-অবজেক্ট থেকে উত্তরাধিকার সূত্রে প্রাপ্ত ক্যামেরাটিতে একটি জাল থাকা উচিত। কমপিউনেট সহ, ক্যামেরায় একটি রূপান্তর আছে, চলাচলের জন্য একটি নিয়ামক এবং আপনার প্রয়োজনীয় কিছু রয়েছে।

আরও তথ্যের জন্য, "জেসন গ্রেগরি" এর "গেম ইঞ্জিন আর্কিটেকচার" বইয়ের "14.2। রানটাইম অবজেক্ট মডেল আর্কিটেকচার" অধ্যায়টি বিশেষভাবে এই বিষয়টিকে নিয়েছে।

ইউএমএল চিত্রগুলি সেখান থেকে উত্তোলন করা হয়


আমি শেষ অনুচ্ছেদের সাথে একমত নই, অত্যধিক-সাধারণকরণের প্রবণতা রয়েছে। উপাদান ভিত্তিক মডেলটির অর্থ এই নয় যে প্রতিটি এবং প্রতিটি কার্যকারিতা অবশ্যই একটি উপাদান হতে হবে, তবুও একটিকে কার্যকারিতা এবং ডেটার সম্পর্ক বিবেচনা করতে হবে। জাল ছাড়াই একটি অ্যানিমেশনকন্ট্রোলার অকেজো, সুতরাং এটি যেখানে এটি জড়িত সেখানে রাখুন। কোনও রূপান্তর ছাড়াই গেম-অবজেক্ট কোনও গেম-অবজেক্ট নয়, এটি 3 ডি ওয়ার্ল্ডের সংজ্ঞা অনুসারে অন্তর্ভুক্ত তাই এটি সাধারণ সদস্য হিসাবে গেম-অবজেক্টে রাখুন। এনক্যাপসুলেশন কার্যকারিতা এবং ডেটার স্বাভাবিক নিয়ম এখনও প্রয়োগ হয়।
মাইক সেমদার

@ মাইক সেমদার: আমি সাধারণ পদে অতিরিক্ত-জেনারেল করার ক্ষেত্রে আপনার সাথে একমত, তবে আমি মনে করি যে শব্দটি উপাদানটি পরিষ্কার নয়। আমি আমার উত্তর সম্পাদনা করেছি। এটি পড়ুন এবং আমাকে আপনার ইমপ্রেশন দিন।
মোম্বোকো

@ মোম্বোকো ভাল, আপনি একই পয়েন্টগুলির চেয়ে কম পুনরাবৃত্তি করেছেন;) ট্রান্সফর্ম এবং অ্যানিমেশনকন্ট্রোলারটিকে এখনও উপাদান হিসাবে বর্ণনা করা হয়েছে, যা আমার দৃষ্টিতে উপাদান উপাদানটির একটি অতিরিক্ত ব্যবহার। কীটি একটি
উপাদানতে

গেম-অবজেক্ট (জিও) কে প্রথমে কাজ করার জন্য যদি অন্য কিছু প্রয়োজন হয়, অন্য কথায় এটি alচ্ছিক না হলেও বাধ্যতামূলক হয় তবে তা কোনও উপাদান নয়। উপাদানগুলি alচ্ছিক বলে মনে করা হচ্ছে। ট্রান্সফর্ম একটি ভাল উদাহরণ, এটি কোনও জিওর পক্ষে মোটেই optionচ্ছিক নয়, ট্রান্সফর্ম ছাড়া কোনও জিও কোনও লাভ করে না। অন্যদিকে, প্রতিটি জিও-তে পদার্থবিজ্ঞানের প্রয়োজন হয় না, যাতে এটি একটি উপাদান হতে পারে।
মাইক সেমদার

যদি অ্যানিমেশনকন্ট্রোলার (এসি) এবং মেশের মধ্যে 2 ফানশনালটির মধ্যে দৃ strong় সম্পর্ক থাকে তবে কোনও উপায়ে এসিটিকে কোনও উপাদান হিসাবে চাপিয়ে এই সম্পর্কটি ভাঙবেন না, বিপরীতে মেশ একটি নিখুঁত উপাদান, তবে একটি এসি অন্তর্ভুক্ত জাল মধ্যে।
মাইক সেমদার
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.