Концепція
По суті, сценічний графік - це не що інше, як двонаправлений ациклічний графік, який служить для відображення ієрархічно структурованого набору просторових відносин.
Як зазначалося, двигуни в дикій природі включають інші смаколики. Чи ви бачите це як м'ясо чи корову, мабуть, залежить від вашого досвіду роботи з двигунами та бібліотеками.
Зберігаючи його легким
Я віддаю перевагу стилю Unity3D, щоб ваш графічний вузол сцени (який в його основі є топологічним, а не просторовою / топографічною структурою) по суті включав просторові параметри та функціональні можливості. У моєму двигуні мої вузли мають навіть легшу вагу, ніж Unity3D, де вони успадковують безліч зайвих непотрібних членів від суперклассів / реалізованих інтерфейсів. Ось, що я маю - про таке легке, як ви можете отримати:
- члени вказівника батька / дитини.
- заздалегідь перетворені просторові параметри членів: положення xyz, крок, позіхання та кочення
- матриця перетворення; матриці в ієрархічному ланцюжку можуть дуже швидко і легко розмножуватися, проходячи рекурсивно вгору / вниз по дереву, надаючи вам ієрархічні просторові перетворення, які є головною особливістю графіка сцени;
updateLocal()метод , який оновлює тільки цей вузол матриці перетворення цеupdateAll()метод , який оновлює це і всі дочірні вузли перетворення матриць
... Я також включаю логіку рівнянь руху та, таким чином, члени швидкості / прискорення (лінійні та кутові) у свій клас вузлів. Ви можете відмовитися від цього та обробити це у своєму головному контролері, якщо хочете. Але це все - справді дуже легкий. Пам'ятайте, ви могли мати це на тисячах організацій. Отже, як ви запропонували, будьте світлом.
Побудова ієрархій
Що ви кажете про графік сцени, що посилається на інші графіки сцен ... Я чекаю на пунктир? Звичайно, вони. Це їх головне використання. Ви можете додати будь-який вузол до будь-якого іншого вузла, і перетворення повинні відбуватися автоматично в локальному просторі нового перетворення. Все, що ви робите, - це зміна вказівника, це не так, як ви копіюєте дані навколо! Змінивши вказівник, ви отримаєте більш глибокий графік сцени. Якщо використання Proxies робить ефективнішими речі, то я ніколи не бачив потреби.
Уникайте логіки, пов'язаної з візуалізацією
Забудьте про візуалізацію, коли ви пишете клас вузла графіка сцени, або ви будете плутати речі для себе. Важливо лише те, що у вас є модель даних - будь то графік сцени чи ні, не має значення - і якийсь рендерінг буде перевіряти цю модель даних і відповідно рендерувати об'єкти у світі, незалежно від того, чи є вона у 1,2 , 3 або 7 розмірів. Я зазначаю: Не забруднюйте графік сцени логікою візуалізації. Графік сцени стосується топології та топографії, тобто зв'язку та просторових характеристик. Це справжній стан моделювання і існує навіть за відсутності візуалізації (яке може приймати будь-яку форму під сонцем від перегляду від першої особи до статистичного графіка до текстового опису). Вузли не вказують на об'єкти, пов’язані з візуалізацією - однак, зворотній зв'язок цілком може бути правдою. Також врахуйте це: Не кожен вузол графіка сцени у вашому дереві буде доступним. Багато хто буде просто контейнерами. То чому б навіть виділяти пам'ять для вказівника на об'єкт відтворення? Навіть член вказівника, який ніколи не використовується, все ще займає пам'ять. Тому поверніть напрямок вказівника: Екземпляр, пов’язаний з візуалізацією, посилається на модель даних (яка може бути або включати ваш вузол графіка сцени), а не навпаки. І якщо ви хочете простий спосіб пройти через ваш список контролерів, але все-таки отримати доступ до відповідного перегляду, то використовуйте словник / хеш-таблицю, який наближається до (1) часу доступу для читання. Таким чином, немає забруднення, і ваша логіка моделювання не має значення, які рендері є на місці, що робить ваші дні та ночі кодування То чому б навіть виділяти пам'ять для вказівника на об'єкт відтворення? Навіть член вказівника, який ніколи не використовується, все ще займає пам'ять. Тому поверніть напрямок вказівника: Екземпляр, пов’язаний з візуалізацією, посилається на модель даних (яка може бути або включати ваш вузол графіка сцени), а не навпаки. І якщо ви хочете простий спосіб пройти через ваш список контролерів, але все-таки отримати доступ до відповідного перегляду, то використовуйте словник / хеш-таблицю, який наближається до (1) часу доступу для читання. Таким чином, немає забруднення, і ваша логіка моделювання не має значення, які рендері є на місці, що робить ваші дні та ночі кодування То чому б навіть виділяти пам'ять для вказівника на об'єкт відтворення? Навіть член вказівника, який ніколи не використовується, все ще займає пам'ять. Тому поверніть напрямок вказівника: Екземпляр, пов’язаний з візуалізацією, посилається на модель даних (яка може бути або включати ваш вузол графіка сцени), а не навпаки. І якщо ви хочете простий спосіб пройти через ваш список контролерів, але все-таки отримати доступ до відповідного перегляду, то використовуйте словник / хеш-таблицю, який наближається до (1) часу для читання. Таким чином, немає забруднення, і ваша логіка моделювання не має значення, які рендері є на місці, що робить ваші дні та ночі кодування І якщо ви хочете простий спосіб пройти через ваш список контролерів, але все-таки отримати доступ до відповідного перегляду, то використовуйте словник / хеш-таблицю, який наближається до (1) часу для читання. Таким чином, немає забруднення, і ваша логіка моделювання не має значення, які рендері є на місці, що робить ваші дні та ночі кодування І якщо ви хочете простий спосіб пройти через ваш список контролерів, але все-таки отримати доступ до відповідного перегляду, то використовуйте словник / хеш-таблицю, який наближається до (1) часу для читання. Таким чином, немає забруднення, і ваша логіка моделювання не має значення, які рендері є на місці, що робить ваші дні та ночі кодуваннясвіти легше.
Що стосується вибивання, зверніться до вищезазначеного. Відсікання області за інтересами - це концепція логіки моделювання. Тобто ви не обробляєте світ поза цією (зазвичай коробкою, круговою чи сферичною) областю. Це відбувається в головному циклі контролера / гри, перш ніж відбудеться візуалізація. З іншого боку, знищення фрустрації пов'язане лише з рендерінгом. Тож забудьте про відсікання прямо зараз. Це не має нічого спільного з графіками сцен, і зосередившись на ньому, ви будете затемнювати справжню мету того, чого ви намагаєтеся досягти.
Заключна примітка ...
Я відчуваю сильне відчуття, що ви приїжджаєте з Flash (зокрема, AS3), враховуючи всі деталі щодо відображення, включені тут. Так, парадигма Flash Stage / DisplayObject включає всю логіку візуалізації як частину сцени. Але Flash робить багато припущень, які не обов’язково хочеться робити. Для повноцінного ігрового двигуна їх краще не змішувати з міркувань продуктивності, зручності та контролю складності коду через належний SoC .