Что должно содержаться в графике сцены игры?

Не могли бы вы помочь мне прояснить, пожалуйста, что именно должно содержаться в графике сцены игры? См. следующий список:

  • Игровые актеры? (очевидно, да, все объекты, меняющие состояние, должны быть главной prart графика сцены)
  • Простые статические игровые игры? (я имею в виду объекты в фоновом режиме, которые не ожидают, и они не сталкиваются)
  • Игра Триггеры?
  • Игра Загорается?
  • Игра Камеры?
  • Оружие Пули?
  • Игровые взрывы и Специальные эффекты?

Вышеупомянутые типы объектов. Теперь в охват графика сцены:

  • Если граф сцены содержит карту уровня всей игры с начала уровня или должен содержать только видимую часть карты? Если второе значение истинно, это означало бы, что график сцены будет постоянно обновляться путем добавления /удаления игровых объектов, когда игрок перемещается. Однако, содержащие только видимые карты, очевидно, было бы намного быстрее, чтобы проходить и обновлять.
10 голосов | спросил Bunkai.Satori 8 FebruaryEurope/MoscowbTue, 08 Feb 2011 20:03:07 +0300000000pmTue, 08 Feb 2011 20:03:07 +030011 2011, 20:03:07

2 ответа


4

Я думаю, что хорошее чтение информации о том, что делают другие технологии графа сцены, принесет вам много пользы.

Фон
Например, посмотрите описание Ogre3D. Это графический движок, основанный на графике сцены, который является открытым исходным кодом. Я бы предложил посмотреть учебники и посмотреть, как используются узлы сцены (Примечание: я не говорю вам, чтобы узнать, как использовать Ogre, а не какие функции присутствуют в узлах сцены и менеджерах сцен Ogre)

Документация SceneNode:
http://www.ogre3d.org/Docs /API /1,9 /class_ogre_1_1_scene_node.html

Документация SceneManager: http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_manager.html

Что-то еще стоит посмотреть на следующую ссылку:
http://sgl.sourceforge.net/ # Особенности

Это графическое решение сцены на основе OpenGL, а на странице функций отображаются все узлы, которые он может содержать.

Ваши рекомендуемые узлы
Я придерживаюсь мнения, что график сцены должен быть как можно более абстрагирован от логики игры, поэтому у вас нет проблем с зависимостью. Для каждого из ваших пулевых точек я бы сказал следующее:

Игровые актеры
Я бы, наверное, сказал «нет». Подобно Ogre, у меня будет базовый класс Entity (который будет содержать специфичную для объекта логику) и базовый SceneNode с указателем-членом Entity, чтобы получить соответствующую информацию для визуализации объекта (Position, Orientation и т. Д.)

РЕДАКТИРОВАТЬ: Я не говорю, чтобы не включать ваших игровых актеров в график сцены здесь (иначе ничего не появлялось: P) Я говорю, что есть узел сцены со ссылкой на логического игрового актера класс, поэтому у вас все еще есть свободное соединение рендеринга и обновления игровых объектов.

Простые статические игровые игры
Да

Игровые триггеры?
Нет, это звучит как логическая логика для меня.

Игровые огни?
Да

Игровые камеры?
Да

Пули оружия?
Не совсем уверен в этом, но я, вероятно, скажу «да», но вы, вероятно, захотите, чтобы все пули в качестве дочерних элементов были размещены на родительском узле «BulletCollection», так что вы можете кэшировать эту позицию, и вам не придется проходить через график сцены много, чтобы удалить и добавить маркеры для рендеринга.

Взлеты и спецэффекты?
Не уверен, я позволю кому-то ответить на это.

Охват графика сцены
Если у вас относительно небольшой уровень, вы должны иметь возможность хранить весь уровень в графе сцены, а затем оптимизировать видимость с помощью Octree (обычно для наружной среды) или дерева BSP (обычно для внутренних сред).

Если у вас намного больший уровень, и вы не хотите загружать уровень, это то, где потоковая передача вступает в игру, но это еще одна проблема. Я бы начал с небольшого уровня и постепенно посмотрел, насколько большой вы можете сделать это, не отрицательно влияя на производительность.

Заключение
Для меня график сцены предназначен для части Render игрового цикла. Вы не должны сочетать ваш рендеринг и ваши логические обновления слишком близко друг к другу, иначе вы столкнетесь с раздражающими проблемами зависимостей.

ответил Ray Dey 8 FebruaryEurope/MoscowbTue, 08 Feb 2011 20:32:57 +0300000000pmTue, 08 Feb 2011 20:32:57 +030011 2011, 20:32:57
9

Моя склонность заключается в том, чтобы предложить разместить меньше на графике сцены. См., в частности, эту статью Тома Форсайт: « Графы сцены - просто скажите Нет ".

Суть статьи Форсайт заключается в том, что вы не должны пытаться втиснуть кучу несвязанных вещей в одну большую структуру основных данных. Это очень похоже на идеи, которые я коснулся в этот ответ в отношении получения всего в игре от GameObject, а затем перетаскивания всех в один большой гетерогенный список (который скажем, это плохо).

Относительно немногие объекты в мире действительно демонстрируют сильные отношения между родителями и дочерними элементами, как подобает древовидной структуре. Канонический пример чашки кофе на столе обычно используется здесь - конечно, вы могли бы считать его «ребенком» стола ... по крайней мере, пока он не сбит с ног. Тогда действительно ли это ребенок из таблицы? Это означает, что ваше «дерево» в любом случае может оказаться довольно мелким и своего рода дегенератами.

Поэтому я предлагаю вам использовать несколько структур данных для нескольких вещей, что имеет наибольший смысл для этих целей. Статическая геометрия и освещение, например, кажутся разумными, чтобы засунуть в сцену граф. Даже если представленные объекты не имеют естественных отношений между родителями и дочерними элементами, то факт, что они являются статическими, означает, что вы можете дать им структурные отношения родитель-потомок, зная, что они никогда не меняются.

Игровые актеры ... Я не уверен. На самом деле все, что имеет тенденцию двигаться, означает, что вам обычно нужно держать их рядом с корнем графика или переустанавливать их постоянно (что является хором, а не суперэффективным).

Пули, триггеры, спецэффекты и другие переходные объекты, которые я хотел бы хранить в другом месте. Ничто, что визуализирует или не имеет визуального представления (триггер, как правило, является невидимым ограничивающим томом, пуля, как правило, просто луч-литой) должна быть в графе рендеринга. Вы должны стремиться к разделению визуальных и логических слоев .

Для чего это стоит, я никогда не использовал древовидный график сцены в любом из рендеринга, который я создал для неакадемического использования (очевидно, я раньше строил древовидные графики сцен, так как я пришел к выводы, с которыми я сейчас пытаюсь договориться).

Я использую методы пространственного разбиения, соответствующие стилю игры (quad-tree, octree, BSP и т. д.), чтобы группировать /отбирать логические объекты в игре, которые должны быть (а) обработаны этим фреймом и ( б) предоставил этот кадр. Затем я заканчиваю подачу набора объектов из списка (б) в систему, которая отображает логические объекты для отображения описаний и сортирует эти описания в ведрах на основе свойств (например, все, что использует прозрачность, будет вбито в ведро для «материала» это должно быть возвращено назад). Затем я обрабатываю каждое ведро по порядку, и для каждого ведра визуализируют каждое описание в порядке. Думаю, вы могли бы назвать это «деревом», но оно не отображает типичное состояние /преобразовать методы распространения, которые используют традиционные графические графики, ориентированные на дерево. YYMV, потому что система, безусловно, имеет недостатки, но для меня это работает очень хорошо.

ответил Josh 8 FebruaryEurope/MoscowbTue, 08 Feb 2011 20:33:36 +0300000000pmTue, 08 Feb 2011 20:33:36 +030011 2011, 20:33:36

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132