Collision detection about RootCollsionNode
Является контейнером для других объектов, в основном шейпов с упрощенной геометрией, но может содержать и вложенные ноды.
РК в 99% - содержит только шейпы и использует метод просчета столкновений по треугольникам.
РК позволяет использовать поверхности любой формы, что позволяет удобно создавать коллизии под форму видимой геометрии.
РК используется движком игры только у "неживых" объектов.
РК можно добавить и в "живые" объекты, но использоваться она в них не будет. Т.е. будет работать на правах обычной ноды.
РК является прототипом CollisionData и niCollsionObject появившихся в следующих версиях движка.
РК - может содержать, как пустые участки (т.е. дыры между полигонами), так и геометрию любой сложности (т.е. очень много полигонов).
Однако, рекомендуется упрощать геометрию в составе РК, до минимально допустимого кол-во объектов и полигонов.
РК может быть и вовсе пустой!
Полезно, для моделей которым нужно отключить все лишние вычисления.
Подобное используют некоторые (современные 2020->) плагины.
См. OABB и прочее от Melchior Dark.
Помимо просчета столкновений по своим треугольникам, каждый вложенный, в РК, шейп, создает вокруг себя значение радиуса.
Который дополнительно используется движком игры.
В т.ч. для вычисления центра объекта, т.е. на какой дистанции вообще надо включать хоть какие-то просчеты.
Также, радиус, влияет на дистанции срабатывания, чего либо еще, относительно центра объекта.
Например скриптов.
Так один большой шейп в составе РК запустит срабатывания триггера события позже, чем несколько меньших шейпов в составе той же самой РК.
Пример.
Участок лавы в 2048, локальный скрипт указывающий игроку "взлететь" если дистанция до поверхность 512.
При использовании единого шейпа на все 2048 ед, скрипт подбросит игрока в воздух, примерно на середине поверхности лавы.
Но если порезать такой шейп на несколько участков по 512 ед, скрипт поднимет игрока практически сразу, как тот подойдет к лаве.
*впрочем, возможно это не совсем точно. Т.е. расчет действия скриптов берется от центра объекта и размеры участков коллизий не влияют на это. Кроме случая если скрипт должен отрабатываться по if CollingPc(actor) команде. Здесь, точность детектирования уже важна.
Итого:
Для оптимального использования РК следует учитывать:
- кол-во полигонов на один шейп. Чем меньше тем лучше.
- кол-во самих шейпов. Чем больше модель, тем больше шейпов в РК!
- габариты шейпов. Чем они меньше, тем лучше, вычисления будут точнее относительно их радиуса.
- радиус самого объекта! Объект не должен быть более 4096, а лучше 2048 единиц!
А также не стоит помещать РК в живые и "все прочие" объекты. Оно там, все равно, не работает.
Подобные оптимизации, могут существенно повысить точность просчета положения "живых" объектов относительно, тех же, Кантонов Вивека.
А еще следует учитывать положения объекта относительно стыка ячеек!
Т.е. большой объект стоящий на границе 2х ячеек, может быть загружен не правильно, т.е. позже, чем "живые объекты" стоявшие на нем.
Отчего, можно видеть, как беседка старалась размещать Кантоны в границах одной ячейки.
Помниться, в одном старом плагине, а именно Имени Скального Наездника, можно было свалиться с такого объекта, просто подойдя к его краю.
Т.е. объект, там это была летающая цитадель размером с Пропильен, находился на стыке двух ячеек, часть там, а другая "тут".
Отчего "большая его половина" успевала уйти из зоны просчета. И игра начинала думать, что объект можно удалять из сцены, а игрок (внезапно) оказывался в воздухе хотя видел, что до края довольно далеко!
Т.е. если требуется создать действительно ЦИКЛОПИЧЕСКИЙ объект, разделите его на несколько элементов!
И по возможности, не размещайте на нем "живых существ"! Дабы кто случайно не уехал в астрал, или в воды "забвения".
Собственно та самая цитадель, из ИСНа, размерами либо больше одной ячейки, либо не совсем удачно расположенная на границе ячеек.
Читать далее по тексту, т.е. продолжение.
О методах собственно детектирования, см. эту статью.
