Игровые движки: что такое графики сцен?

что такое график сцены в игре контекст разработки двигателя?

Ну, это какой-то код, который активно сортирует ваши игровые объекты в игровом пространстве таким образом, что позволяет легко быстро найти, какие объекты находятся вокруг точки в игровом пространстве.

таким образом, это легко :

1. быстро найти, какие объекты находятся в виде камеры (и отправлять только их на видеокарты, что делает рендеринг очень быстро)
2. быстро найти объекты рядом с игроком (и применять проверки столкновений только те)

и другие вещи. Речь идет о быстром поиске в космосе. Это называется "разделение пространства". Речь идет о разделении и завоевании.

почему я хочу реализовать один для мой 2D игровой движок?

Это зависит от типа игры, точнее от структуры вашего игрового пространства.

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

Итак, это зависит. Большую часть времени это требуется по соображениям производительности. Но реализация вашего разделения пространства полностью относительно того, как структурировано ваше игровое пространство.

стоит ли использование графика сцены в качестве альтернативы классической сущности система с линейным менеджером сущностей?

нет.

независимо от того, как вы управляете жизнью объектов ваших игровых сущностей, пробел-раздел / сцена-граф существует только для того, чтобы позволить вам быстро искать объекты в пространстве, не больше не меньше. Большую часть времени это будет объект, который будет иметь некоторые слоты объектов, соответствующие различные части игрового пространства и в тех слотах это будут объекты, которые находятся в этих частях. Он может быть плоским (например, 2D-делитель экрана в 2 или 4), или это может быть дерево (например, двоичное дерево или четырехугольник или любой другой вид дерева) или любая другая структура сортировки, которая ограничивает количество операций, которые вы должны выполнить, чтобы получить некоторую информацию, связанную с пространством.

Примечание одно :

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

чтобы привести пример, я хочу сделать игру" пуля ад", где есть много шаров, которые космический корабль игрока должен увернуться очень точно. Чтобы достичь достаточной производительности рендеринга и обнаружения столкновений, мне нужно знать:

1. когда пули появляются в пространстве экрана
2. когда пули покидают пространство экрана
3. когда игрок входит в столкновение с пулями
4. когда игрок входит в столкновение с монстрами

поэтому я рекурсивно вырезал экран, который является 2D в 4 частях, что дает мне четырехугольник. Quadtree обновляется каждый игровой ТИК, потому что все постоянно движется, поэтому я должен отслеживать положение каждого объекта (космический корабль, пуля, монстр) в quadtree, чтобы знать, какой из них находится в какой части экрана.

достижения 1. легко, просто введите пулю в системе.

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

для достижения 3 и 4. Мне нужно получить объекты, которые находятся рядом с кораблем игрока. Итак, сначала я получаю лист, где находится космический корабль игрока, и я получаю все предметы в нем. Таким образом, я буду тестировать столкновение с космическим кораблем игрока только на объектах, которые вокруг него, а не на всех объектах. (Это немного сложнее, но вы понимаете идею.)

таким образом, я могу убедиться, что моя игра будет работать гладко даже с тысячами пуль постоянно движется.

в других типах структуры пространства требуются другие типы разделения пространства. Как правило, игры kart / auto будут иметь" туннельную " сцену-график, потому что визуально игрок будет видеть только вещи вдоль дороги, поэтому вам просто нужно проверить, где он находится на дороге, чтобы получить все видимые объекты вокруг в "туннеле".

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

по большей части, однако, они используются только для 3D-сцен. Я бы предложил не идти с чем-то сложно 2D сцена.

существует довольно много различных философий в интернете, что responsebilties из сцен. Люди склонны вкладывать много разных вещей, таких как геометрия, камеры, источники света, игровые триггеры и т. д.

В общем случае я бы описал scenegraph как описание сцены и состоит из одной или нескольких структур данных, содержащих объекты, присутствующие в сцене. Эти структуры данных могут быть любого вида (массив, дерево,композитный шаблон и т. д.) и может описывать любое свойство сущностей или любые отношения между сущностями в сцене. Этих сущностей может быть что угодно, начиная от твердых предметов мешочки для столкновения-сетки, источники света и камеры. Единственное реальное ограничение, которое я видел до сих пор, заключается в том, что люди рекомендуют держать игровые компоненты (например, игровые триггеры), чтобы предотвратить проблемы с depedency позже. Такие вещи должны быть абстрагированы, скажем, "LogicEntity", "InvisibleEntity" или просто "Сущность."

вот некоторые общие использования и datastructures в scenegraph.

родитель/потомок

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

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

пространство-перегородки

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

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

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

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