Не могли бы вы уточнить, пожалуйста, что именно должно содержаться в графике игровой сцены? Смотрите следующий список, пожалуйста:
- Актеры игры? (очевидно, да, все объекты, изменяющие состояние, должны быть основной частью графа сцены)
- Простые статические игровые объекты? (Я имею в виду объекты в фоновом режиме, которые не анимируются и не сталкиваются)
- Триггеры игры ?
- Игровые огни?
- Игровые камеры?
- Оружие пули?
- Игры Взрывы и спецэффекты?
Рассмотренные выше типы объектов. Теперь к освещению графа сцены:
- Должен ли граф сцены содержать всю карту игрового уровня с начала уровня или он должен содержать только видимую часть карты? Если второе верно, это будет означать, что граф сцены будет постоянно обновляться, добавляя / удаляя игровые объекты по мере движения игрока. Тем не менее, содержащие только видимые области карты, очевидно, будет гораздо быстрее проходить и обновлять.
game-design
architecture
scene-graph
Bunkai.Satori
источник
источник
Ответы:
Я думаю, что хорошее прочтение того, что делают другие технологии графа сцены, принесло бы вам много преимуществ.
Фон
Например, посмотрите на описание 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/#features
Это решение на основе графа сцены на основе OpenGL, и на странице возможностей показаны все узлы, которые он может содержать.
Ваши предложенные узлы
Я считаю, что граф сцены должен быть максимально удален от логики игры, чтобы у вас не было проблем с зависимостями. Для каждого из ваших пунктов я бы сказал следующее:
Игровые актеры
я бы наверное сказал нет. Как и в Ogre, у меня был бы базовый класс Entity (который содержал бы логику, специфичную для объекта) и базовый SceneNode с указателем члена Entity для получения соответствующей информации для визуализации объекта (Position, Orientation и т. Д.)
РЕДАКТИРОВАТЬ: Я не говорю, чтобы не включать ваши игровые актеры в график сцены здесь (в противном случае ничего не будет отображаться: P) Я говорю, что есть узел сцены со ссылкой на класс игрового актера, так что вы по-прежнему слабое соединение рендеринга и обновления игровых объектов.
Простые статические игровые объекты
Да
Триггеры игры?
Нет, для меня это звучит как логика игры.
Игровые огни?
да
Игровые камеры?
да
Оружие пули?
Не совсем уверен насчет этого, но я бы, вероятно, сказал «да», но вы, вероятно, захотите, чтобы все маркеры в качестве дочерних элементов имели родительский узел сцены «BulletCollection», просто чтобы вы могли кэшировать эту позицию, и вам не придется проходить через Граф сцены много, чтобы удалить и добавить маркеры для визуализации.
Игры Взрывы и спецэффекты?
Не уверен, я позволю кому-то еще ответить на это.
Охват графа сцены
Если у вас относительно небольшой уровень, вы сможете сохранить весь уровень в графе сцены, а затем оптимизировать его для видимости, используя Octree (обычно для наружной среды) или дерево BSP (обычно для внутренней среды).
Если у вас гораздо больший уровень, и вы не хотите загружать его, это то место, где потоковое вещание вступает в игру, но это совсем другая проблема. Я бы начал с небольшого уровня и понемногу смотрю, насколько велик вы можете сделать это без ущерба для производительности.
Заключение
Для меня граф сцены предназначен для рендеринговой части игрового цикла. Вы не должны соединять ваш рендеринг и обновления логики слишком близко друг к другу, иначе вы столкнетесь с досадными проблемами зависимости.
источник
Я склонен предлагать помещать меньше вещей в граф сцены. Смотрите, в частности, эту статью Тома Форсайта: « Графики сцен - просто скажите нет ».
Суть статьи Форсайта в том, что вам не следует пытаться втиснуть кучу несвязанных вещей в одну большую структуру основных данных. Это очень похоже на идеи, которые я затронул в этом ответе, относительно извлечения всего в игре,
GameObjectа затем выбросить все это в один большой разнородный список (то есть, это плохо).Относительно немногие объекты в мире действительно демонстрируют прочные отношения родитель-ребенок, как и положено древовидной структуре. Канонический пример кофейной чашки на столе обычно используется здесь - конечно, вы могли бы считать ее «ребенком» стола… по крайней мере, до тех пор, пока его не выбьют. Тогда это действительно все еще дитя за столом? Это означает, что ваше «дерево» может оказаться довольно мелким и выродиться в список в любом случае.
Поэтому я бы посоветовал вам использовать несколько структур данных для нескольких вещей, что наиболее целесообразно для этих вещей. Например, статическая геометрия и источники света кажутся разумной вещью для вставки в граф сцены. Даже если представленные объекты не имеют естественных родительско-дочерних отношений, тот факт, что они являются статическими, означает, что вы можете дать им структурные родительско-дочерние отношения, зная, что они никогда не изменятся.
Актеры игры ... Я не уверен в этом. Все, что имеет тенденцию двигаться, на самом деле означает, что вам обычно нужно держать их рядом с корнем графа или постоянно переучивать их (что является рутиной и не очень эффективным).
Пули, триггеры, спецэффекты и другие временные объекты я бы хранил в другом месте. Ничто из того, что визуализирует или имеет визуальное представление (триггер, как правило, является невидимым ограничивающим томом, пуля, как правило, просто приведением лучей), не должно быть в графе визуализации. Вы должны стремиться к разделению слоев рендера и логики .
Что бы это ни стоило, я никогда не использовал древовидный граф сцены ни в одном из средств визуализации, которые я построил для неакадемического использования (очевидно, я раньше строил древовидные графы сцены, и именно поэтому я пришел к выводу, что сейчас пытаюсь заставить вас согласиться).
Я использую методы пространственного разделения, соответствующие стилю игры (quad-tree, octree, BSP и т. Д.), Чтобы группировать / отбирать логические объекты в игре, которые должны (а) обрабатывать этот кадр и (б) отображать этот кадр. Затем я в конечном итоге передаю набор объектов из списка (b) в систему, которая отображает логические объекты для рендеринга описаний и сортирует эти описания в сегменты на основе свойств (например, все, что использует прозрачность, будет помещено в корзину для «вещи» это должно быть отрисовано задом наперед). Затем я рендерил все сегменты по порядку, а для каждого сегмента рендерил каждое описание по порядку. Я думаю, вы могли бы назвать это «деревом», но оно не демонстрирует типичное состояние / преобразовать методы распространения, как это делают традиционные древовидные графы сцен. YYMV,
источник