Использование объектов в комнатах и порталах

Обычно, когда вы используете Godot, все объекты, которые вы видите (VisualInstances), обрабатываются движком одинаково. Визуализатор портала немного отличается тем, что он делает различие между различными ролями, которые объекты будут иметь в вашей игре. Это делается для определения комнаты Rooms, а также для рендеринга и обработки всего наиболее эффективным способом.

Portal mode

Если вы посмотрите в инспекторе, каждый VisualInstance (отображаемый экземпляр) в Godot является производным от CullInstance (отброшенный экземпляр), где вы можете установить PortalMode (Режим портала). Это определяет, как объекты будут вести себя в системе портала.

../../../_images/cull_instance.png

СТАТИЧЕСКИЙ режим

Режим по умолчанию для объектов STATIC. Статические объекты — это объекты внутри комнат, которые не будут перемещаться на протяжении всего жизненного цикла уровня. Такие вещи, как полы, стены, потолки, являются хорошими кандидатами на «СТАТИЧЕСКИЕ» объекты.

ДИНАМИЧЕСКИЙ режим

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

режим ПЕРЕМЕЩЕНИЯ (роуминг)

Режим перемещения предназначен для объектов, которые могут перемещаться между комнатами. Такие вещи, как игроки и враги, должны быть помечены как перемещающиеся. Их расчет сложнее, чем режимы «СТАТИЧЕСКИЙ» или «ДИНАМИЧЕСКИЙ», потому что система должна отслеживать, в какой комнате находится перемещающийся объект.

ГЛОБАЛЬНЫЙ режим

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

режим ИГНОРИРОВАНИЯ

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

Следует ли размещать объекты в комнатах (в дереве сцены) или нет?

СТАТИЧЕСКИЕ (STATIC)и ДИНАМИЧЕСКИЕ (DYNAMIC) объекты идеально размещаются в комнатах в дереве сцены. Системе необходимо знать, в какой комнате они находятся во время преобразования, поскольку она предполагает, что они никогда не поменяют комнату. Размещение их в комнатах в дереве сцен позволяет вам явно указать системе, где вы хотите их разместить.

Автозаполнение

Однако, для простоты использования, также возможно разместить СТАТИЧЕСКИЕ и ДИНАМИЧЕСКИЕ объекты вне комнат в дереве сцены, но внутри ветки RoomList. Система попытается автоматически разместить объекты в соответствующей комнате. Это работает в большинстве случаев, но если вы сомневаетесь, используйте явный подход. Явный подход особенно необходим при работе с внутренними помещениями, которые имеют некоторые ограничения для растянутых объектов.

../../../_images/freeform.png

Заметьте, что если вы вставите STATIC и DYNAMIC объекты за пределы комнаты, они не будут учитываться границами комнаты. Если вы используете геометрию комнаты для вывода границы, столы и стулья могут быть перемещены за границы комнаты. Однако, стены и пол должны быть за ветвью комнаты в дереве сцены, чтобы убедиться в корректности границы.

Объекты ROAMING и GLOBAL рекомендуется сохранить в дереве сцены вне других комнат из списка комнат. Они могут быть перемещены внутрь комнат, но, чтобы избежать путаницы, лучше сохранять их за пределами ветвей. Ограничений на размещение объектов IGNORE нет.

Object Lifetimes

Важно отметить, что время жизни STATIC и DYNAMIC объектов привязано к жизни уровня, между тем, когда вы вызываете rooms_convert() для активации системы портала, и вызовом ` rooms_clear()` для разгрузки системы. Это связано с тем, что на этапе преобразования выполняется довольно много предварительной обработки для их эффективного рендеринга.

Поэтому вам не следует пытаться создавать или удалять STATIC или DYNAMIC объекты, пока система портала активна. Это приведет к автоматической выгрузке системы, поскольку она находится в недопустимом состоянии. Однако вы можете свободно показывать show() и скрывать hide() эти объекты.

The sequence should be therefore:

  • Загрузите свой уровень.

  • Добавьте несколько STATIC или DYNAMIC объектов.

  • Затем запустите rooms_convert() после все объекты STATIC и DYNAMIC были добавлены в дерево сцены.

Объекты ROAMING, GLOBAL или IGNORE могут быть легко созданы или удалены по необходимости.

Sprawling

Хотя пользователи обычно могут не обращать внимания на внутреннее устройство портальной системы, они должны знать, что она способна работать с объектами, которые настолько велики, что оказываются более чем в одной комнате. Каждый объект имеет центральную комнату, но с помощью AABB или геометрии система может определить, когда объект распространяется через портал в соседнюю комнату (или несколько комнат). Это называется разрастанием.

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

Portal Margins

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

Вы можете установить маржу глобально в RoomManager. Вы также можете переопределить это значение поля в любом портале, если вам нужно что-то подправить. По мере редактирования значений полей в инспекторе вы должны видеть, как они обновляются в окне просмотра 3D-редактора.

Include in Bound

Поддержка объектов, которые больше одной комнаты, имеет и обратный эффект. Вы можете не захотеть включать некоторые объекты в автоматический расчёт границы комнаты. Вы можете включить или выключить это в инспекторе для каждого объекта. Смотреть Cull Instance > Include In Bound.

While sprawling works great for large moving objects, it also gives you a lot more leeway in level design. You can for instance create a large terrain section and have it present in multiple rooms, without having to split up the mesh.

Lighting

В целом, источники света обрабатываются так же, как и любой другой визуальный экземпляр. Они могут быть размещены в комнатах, и они будут распространяться, воздействуя на соседние комнаты, следуя размерам и направлению света. Исключением является DirectionalLights. У DirectionalLights нет места для источника, поскольку они воздействуют везде. Поэтому их не следует размещать в комнате. Так как DirectionalLights может быть затратным по производительности, рекомендуется выключать их, когда вы находитесь внутри. Подробнее о том, как это сделать, см. в следующем разделе RoomGroups.

Поздравляем! Теперь вы освоили промежуточные техники, необходимые для использования комнат и порталов. Вы уже можете использовать их для создания игр, но есть еще много других функций.