Around Bounding Box part 2
Различные примечания по этому объекту.
часть вторая.
(продолжаем набивать кол-во знаков)
Актуально только для существ!
Для всех прочих типов объектов размеры ВВ могут быть любыми!
– Если Radius Bound Box по оси Z меньше чем 15, игра улетит в краш!
– Если размер самого существа меньше 20 по оси Z, игра улетит в краш!
– Никогда не создавайте Bound Box меньше 15-20 и не создавайте существ (в МАХ, Blender) меньше 20 ед по оси Z!
– Если вы случайно сделали такое и получили краш игры, то в Warning.txt появится запись:
Step box height of 0 on XXXXXcreature (где ХХХ ИДе существа).
Впрочем, размер существа может быть скомпенсирован Bound Box-ом большего, чем 20 ед по оси Z размера.
Т.е. существо (может быть) 10 ед, но его ББ (должен стать) ->20.
Размеры XY могут быть меньше 10 но всегда больше 1.
Иначе — краш!
Bounding Box
Неподвижная часть существа!
Он не может и не должен быть анимирован, это своего рода якорь, который управляется только движком игры!
Bounding Box применяется в магических снарядах.
Если его нет, «большие» сгустки магии будут взрываться при малейшем касании любой поверхности своим краем.
Если ББ есть — снаряд сможет пролетать в небольшого размера окна и двери, свободно задевая их частицами хвоста, или ореолом.
Т.е. ББ - позволяет создать, своего рода, "ударное ядро" и полностью игнорировать просчет столкновений по видимым сеткам объекта.
ББ - в снарядах работает как необходимый элемент отвечающий за просчет столкновений!
ББ, в левом верхнем углу экрана, это "плевок ядом" от того даэдрота в удалении.
И именно этот ББ отвечает за момент смены модели "стрелы", на модель взрыва!
Т.е. при касании оным ББ поверхности (земли, или другого объекта) происходит взрыв, ака смена модели.
Которые модели, настраиваются в редакторе в разделе магических эффектов.
На переднем плане, прах алчущего (или кланфира) у которого вытянутый ББ.
Т.е. ББ всегда вертикален и не может быть ни "положен" на бок, ни тем более "перевернут".
Позиция и поворот ББ, для нпс и существ, всегда статичны!
ББ в магических снарядах и в моделях оружия, может иметь Radius 5,5,5 или еще меньше.
1.0.1, или вовсе 0.0.1 и пр. т.е. нет лимита, однако габариты должны быть, иначе просто теряется смысл.
Вероятно это связано с позиционированием объекта в мире относительно прочих объектов.
Магия и стрелы работают в отдельном дереве сцены. А существа в другом.
Либо дело в упрощенном просчете положения метательных снарядов в мире во время их "жизни".
Примечание.
Кто-то вроде бы отмечал, что (VFX_Pattern(e\vfx_pattern0ХХ.nif) могут использовать ББ в своем составе.
Однако, наблюдения этого не показали.
Т.е. влияет положение DUMMY01 нод, но не наличие в оных ББ (в качестве именной ноды).
Примечание (для существ).
В игре можно увидеть только изменение размера ББ.
Поворот и смещение не будут показывать видимого результата!
Только масштаб и смещение (по оси Z).
Т.е. если в модели существа повернуть, или подвинуть ББ, в игре он так и останется в нулевых координатах без какого-либо поворота по осям.
И только изменение размера будет явно заметно.
Т.е. если вызвать TCB в игре, или Ф4 в редакторе, можно увидеть, что все визуальные изменения положения ББ (кроме масштаба) были игнорированы.
Однако, это не значит, что оные не будут иметь эффекта. См. далее.
Изменение размеров и позиции «Bounding Box» в файле, такэ будут приводить к определенным "осязаемым" результатам!
Например, если ББ меньше 25 по оси Z:
— в существо будет очень сложно попасть.
Стрелы пролетают насквозь (видимой оболочки), а найти (стрелами), где там находится ББ довольно сложно.
Т.к. поскольку именно ББ отвечает за детектирование попаданий, а вовсе не те видимые на экране оболочки объекта!
Так и выпад мечом в верхнюю часть тела, не будет причинять урона.
А еще, в некоторых случаях, существо может "просочиться" сквозь стену, или закрытую дверь.
Впрочем, это скорее уже баг движка, не умеющего достаточно точно просчитать все коллизии.
Примечание.
Здесь не совсем ясно, как учитываются некоторые ГМСТ указывающие влияние процентов корпуса объекта на расчет попадания по объекту.
Возможно уменьшение размера ББ приводит к сокращению влияния этих ГМСТ отчего удар в верхнюю часть (тела читай ББокса) не засчитывается.
Т.е. существа (и Нпс) используют ББ в режиме Union, о чем было писано ранее, отчего возникает мысль:
- а не используются ли вложенные ББоксы как раз для определения верха и низа существа?
Примечание.
А если видимые сетки существа убрать в CollisionSwitch ноду, то существо будет невозможно активировать!
Для перемещения таких существ в редакторе, в их модели, следует добавить маркер.
А в игре, отправлять в дизайбл, либо создавать анимацию исчезновения, дабы не "фонили" своими тушками с которых все одно ничего взять не получиться.
Если же ББ существа будет иметь некоторое смещение в своих настройках:
к примеру; Х -80, Y -50.
— то, магический снаряд, будет лететь не от существа, но к нему!
Т.е. со спины его цели.
При этом, и в редакторе, и в игре, ББ будет отображаться в центре существа, т.е. визуального смещения не будет заметно!
Любые значения поворота, или смещения ББ в файлах существ, визуально игнорируются.
Т.е. в редакторе и в игре, ББ будет визуально всегда по центру существа.
Только изменение габаритов будет заметно.
Поворот ББ, для существ, по видимости, игнорируется игрой полностью.
А изменение смещения оказывает такой вот забавный эффект.
Слишком большой Боунд Бокс, у Игрока (xbase_anim1st.nif), может привести к не возможности активировать предметы, двери и прочее.
Т.е. если он слишком сильно выдается вперед.
Слишком маленький же ББ - игрок будет проваливаться камерой сквозь текстуры, либо попадать в брюхо существам.
Это, в основном, актуально для ББ в файле базовой анимации (xbase_anim1st.nif) который использует игрок с видом от 1-го лица.
Но для обычной анимации (xbase_anim.nif) это тоже следует учитывать!
Иначе уже NPC начнут проваливаться в середину тушки кагути, или брюшка огрима, либо ходить сквозь стены, или же застревать в дверях.
|
|
|
|
|
Y 22
Нормальный размер ББ.
Игрок будет свободно "жать все кнопки".
|
Y 50
А такой уже создаст проблему с активацией предметов. Игрок "не сможет дотянуться" до них.
|
Y 10
Слишком мало! Камера будет часто проваливаться.
|
Также, слишком короткий ББ создаст проблемы при ходьбе по лестницам, а также другие, не значительные, но малоприятные артефакты.
Такие как, "застрявшие" в стенах НПС и прочее.
Рекомендуется подбирать значения ББ в т.ч. активным игровым тестом модели существа!
Для НПС и Игрока подобное лечиться имеющимися плагинами и МСП.
К примеру, см. на Nexus.com - Jamming Off плагин.
Примечание.
МСП 2.4, 2.5 версии имеет опцию исправления размера ББ для НПС.
Однако, настройка ББ в xbase_anim файле вручную, позволяет получить более оптимальные значения.
Есть мнение, что в связи с наличием целых 2х ББ (автоматически создаваемых игрой)(МСП) может делать это не всегда корректно.
Для существ, атакующим выпадом вперед, или с сильным наклоном, рекомендуется выдвигать ВВ вперед.
Иначе камера ГГ окажется внутри их оболочки.
Боунд Бокс не должен быть квадратным, но только вытянутым!
Иначе, существо будет застревать в узких корридорах.
Все это управляется редактированием Radius-а в нифскопе.
|
|
|
|
Несколько выступающий вперед, относительно видимой сетки ББ, позволит избавиться от проваливания камеры в брюхо существа во время их атаки.
Высота ББ, также может быть заметно меньше, чем видимая сетка.
|
С боков, ББ, наоборот полезно слегка сжать.
Это избавляет от проблем с застреваниям в дверях и прочих узких местах.
|
Еще раз, обращайте внимание!
Что выдвинуть ББ вперед, можно только изменением радиуса по оси Y.
Не получится просто переместит ББ вперед, меняя значения в строках translation.
Игра это проигнорирует!
Боунд Бокс работает НА другой Боунд Бокс.
Т.е. дистанция атаки, повреждения оружием, визуальный контакт оболочек определяется его размерами.
Т.е. если ББ у игрока слишком маленький, а у существа не достаточно большой - камера будет в брюхе.
Равно и для самих существ.
Все сражения работают по методу "стенка на стенку". ББ упираются друг в друга, а дальше в дело идут анимации и просчет ГМСТ.
Впрочем для существ (нпс) использующий оружие, столкновение ББ не обязательно.
Если дистанция атаки выше 3х, то удар будет прилетать много раньше, чем объекты столкнутся своими ББ друг с другом.
Взаимодействие ВВ между собой у предметов - не активно.
Т.е. наличие РК и ББ в айтимах (предметах) не оказывают никакого эффекта.
Вычисления размещения объектов один на другой, берется из их видимых оболочек (ака шейпов).
Тоже самое для оружия.
Наличие ББ в их моделях при размещении оных в мир из инвентаря - не играет роли.
Примечание.
В коде игры есть объект "Tri Bounding Box", который, как-то используется в бодипартах.
that Tri Bounding Box code is just for body parts it seems.
Если поместить "Tri Bounding Box" в активатор, статик и пр. Он будет обрабатываться, как обычный элемент.
Аналогичные попытки поместить "Tri Bounding Box" в бодипарты брони, дали схожий результат. Объект отображается.
Возможно, "Tri Bounding Box" относится к системной части движка и не предназначен для использования в ниф файлах.
Т.е. не стоит называть ББ как tri ББ.
Примечание.
Если в МАХ сделать несколько объектов названных Bounding Box и затем упаковать их в группу с тем же названием, на выходе получается единый ББ.
Равно если объекты названные Collision упаковать в ноду Bounding Box - получится единый ББ.
Если несколько объектов названных Bounding Box упаковать в Collision группу, получится
РК... но в настройках потерявших имена шейпов, только у одного из них будет активен раздел has Bounding Box!
Т.е. при создании ББ в МАХ, оптимально создать куб желаемого (по целям) размера и выровняв его в нулевых координатах, наименовать Bounding Box.
