Различные примечания по этому объекту.
Bounding Box (здесь и далее (BB)или(ББ)
ББ по сути обычная нода, без шейпа имеющая значение «Has Bounding Box» YES и правильное название (Bounding Box)!
Кроме Нод, возможно использовать также и шейпы, хотя в этом нет особого смысла, разве что, небольшое удобство в ряде случаев.
Если нода, или шейп, были названы как; Bounding Box, это внушит движку особое к ним отношение.
Т.е. они автоматически получат включение этого параметра в своих настройках силами движка игры.
И будут просчитываться в качества, так называемой PROXY геометрии, даже без установки флага "ХББ=1" в настройках ниф файла.
Основное назначение которой - ускорение и упрощение вычислений детектирования столкновений.
Здесь же рассматриваются особенности поведения названного именной ноды (ББ) в игре и редакторе.
Важно!
Настроить объем ББ.
И только затем переименовать этот объект в Bounding Box.
Это является обязательным условием для правильной работы ББ!
Если выбранная нода не будет переименована - игра проигнорирует настройки и не будет учитывать такой объект в качестве системного.
Т.е. зона выделения, вокруг объекта в редакторе, не измениться, а существа будут иметь весь набор "глюков" о них см. далее.
Если объект был переименован, но объем не был настроен, игра не сможет правильно работать с этим, что опять же приведет к разного рода глюкам.
Чаще всего - вылетам на рабочий стол.
Обращайте внимание!
ББ не используется для выбора объектов в редакторе!
Но лишь управляет размером этой области!
Т.е. ББ это "не материальный" объект, за него не возможно зацепиться мышью в редакторе!
Это особенно для актуально для ЛОДированных объектов, которые на удалении полностью скрывают свои "физические" детали.
Например, как та звезда Азуры (см. скриншоты здесь) которая заменяется спрайтам по мере удалении от камеры.
Поэтому, все активаторы и статики (в особенности состоящие из системы частиц)(см. модели огня из каминов) и пр, где в составе может находится ВВ, обязательно требуют наличия, постоянно видимого "физического" объекта (ака обычного шейпа) для выделения оных в редакторе.
Если "физического" объекта нет, объект будет невозможно перемещать по сцене. Это можно видеть на примере ванильных ВФХ эффектов.
Которые можно поместить в сцену, но затем никак нельзя ни выделить, ни передвинуть курсором.
Для решения этой "задачи" удобно использовать дополнительный МАРКЕР объект.
Который будет видно только в редакторе.
ББ объектов (статиков, предметов и пр.) не отображается в сеансе игры!
Но только в редакторе.
Т.е. по команде TCB, можно увидеть размеры Боунд Бокса только у существ и НПС, но на предметов!
Даже для содержащих эту именную ноду.
ББ в них не будет выделен.
Однако, можно сделать так, чтобы зона ББ все-таки отображалась и в игре.
При этом, можно даже сделать несколько зон выделения!
В модели может быть только 1 ББ, второй просто не будет отображаться.
ББ, может находится в любом месте модели. Т.е. как в корне, так и в любой из вложенных нод.
Однако, правильно помещать его в корень файла.
Для существ всегда, для предметов, не обязательно.
Размер ББ влияют на дистанцию атаки существ!
Т.е. У существ с большой пастью, BB должен сильно выступать перед мордой, иначе камера окажется в «брюхе» существа, что выглядит весьма неважно.
Для этого приходится управлять его Размером, а не позицией!
Т.е. изменение позиции ББ в его настройках - не оказывает эффекта в игре!
ББ всегда приклеен к нулевым координатам существа!
ББ используется для "ориентации существа в пространстве".
Если ББ в файле нет, то существо способно атаковать из-за барьера, если ББ есть - оно пытается обойти барьер для атаки.
*да, это странный момент который может давать некоторые плюсы при создании стационарных существ, на вроде Турелей (см. Симфонию).
*При этом барьер может быть совсем не высоким и стрелок вполне может, чисто технически, стрелять из-за него.
В ряде подобных случаев существо может в упор не замечать игрока, пока тот сам не атакует оное.
Либо, на существо, за барьером, срабатывают только стрелковые и атаки по области.
Атака мечом и точечная магия его не задевают, особенно если оно сидит за высоким барьером.
(данные стоит перепроверить перед использованием)
Помимо перемещения в мире и просчета попаданий в существо!
ББ отвечает за отображения размера частиц магии появляющихся вокруг объекта (НПС или существа) во время каста, или при поражении оной.
Просчет столкновений с объектами мира, попаданий магии и оружия, дистанций до активации - на каком расстоянии появится Имя существа и пр.
А также может использоваться для управлением размера выделения вокруг статичных объектов в редакторе.
Все это завязано на ББ!
А еще ББ отвечает за положение объекта в воде.
Т.е. при погружении в воду, верхняя кромка ББ определит погружение (нпс существа) по умолчанию.
Здесь ББ (изменен в xbase_animkna.nif) достигает до уровня пояса.
Отчего половина корпуса находится выше уровня воды.
Конечно это не помешает погрузиться под воду целиком, но при заплыве вдоль поверхности будет сказываться.
Этим можно пользоваться, создавая "водоплавающих" существ.
ГусиЛебедиЖукиВодомерки?
Выглядит вероятным!
Соответственно, более высокий ББ, позволит погрузить (существо, или НПС) под воду глубже.
|
|
|
|
|
ББ еще более короткий.
(на воде отключены шейдеры)
|
А здесь наоборот, удлинен.
Видно, что уровень погружения реагирует на верхний край ББ и уровень воды.
|
Под водой хорошо видно, как смещается объект (здесь игрок) относительно габаритов ББ.
|
Обращайте внимание!
При скалировании игрока в игре через консоль, могут быть проблемы для ББ!
Верно для зверорас.
Их ББ может остаться большего размера!
Для "человеческих" рас, скалирование проходит нормально.
Наличие ББ у существ обязательно! (кроме особых случаев, см. выше).
В случае если ББ нет, существо получит совершенно необъятный радиус активации, а магический щит будет в несколько раз больше самого существа.
Т.е. ББ будет создан автоматически согласно радиусам объекта.
Откуда он считывается, нет точных данных.
Можно полагать, что высчитывается на основе радиусов всех имеющихся шейпов.
Т.е. самый большой радиус послужит для авто генерации ББ.
ББ создается, это можно видеть по наличию в корне модели атрибутов указывающих на это, а также по контуру вокруг при использовании консоли (TCB).
Однако, как ни странно, отсутствующий в модели ББ, все же создает ряд проблем, о которых уже упоминалось.
Магические щиты, накладываются НА этот объект.
Т.е. размер щита прямо зависит от размера ББ.
Чем больше ББ, тем большего размера станет "капсула" магического щита.
Если же ББ в файле нет - размер щита будет рассчитан по крайним точкам видимых сеток существа, что обычно создает неестественно громадные "капсулы".
Либо расчет по габаритам существа сначала создает свое представление о ББ, а затем создав оный, накладывает щит.
ББ также может использовать в статиках, предмета и активаторах, при этом, вместе с РутКолиженом.
РутКолизия будет отвечать за просчет столкновений, а ББ за размер выделения объекта в редакторе.
Это позволяет удобно управлять размером коробки выделения объекта.
Т.е. будет выделяться не весь объект по крайним точкам оного, но лишь зона заданная в параметрах ВВ.
Это может быть удобно при работе с большими объектами в редакторе.
Т.к. они перестают загораживать маленькие, которые можно удобно разместить на поверхности больших объектов.
Bounding Box can also be used to fix the CS selection box if you have a mesh with screwed up mesh centers, lol.
Примеры можно увидеть в плагинах Abota.
Корабль возле Сейда Нин имеет подобные настройки.
А также ББ, в статиках и активаторах, влияет на радиус ExplodeSpell от объекта!
Т.е. можно полностью скрыть эффект от магического эффекта вокруг кастующего оный объекта.
Как ни странно но именно ББ а не РК.
Т.е. эффект каста магии вокруг кастующего объекта, учитывает габариты именно РК, полностью игнорируя сетку находящуюся в РК.
Вероятно связано с особенностями просчет коллизий объектов.
ББ влияет на дистанцию и положение, в котором появится плашка с названием объекта.
Работает, как для предметов, так и для существ.
Т.е. ББ можно использовать для контроля за позицией сообщения с именем объекта которого "касается" прицел Игрока!
Особенно полезно, если некий объект не хочет выводить сообщение в удобном месте, постоянно показывая оное выше видимых сеток.
Или в случаях слишком больших радиусов у скиненных объектов (броня, существа).
Т.е. добавление ББ позволит решить эту проблему.
Например добавив ББ в некую "большую" модель, можно добиться, что плашка будет находится постоянно рядом с курсором.
И хотя сообщение появляется только при наведении курсора на видимую сетку модели, положение оной (плашки) управляется размерами ББ!
Если упаковать часть сеток модели в collisionSwitchNode, плашка с названием, не будет появляться при прохождении прицела через их сетки!
Такая упаковка весьма полезна для моделей использующих спрайты, как показано на этих скриншотах.
К сожалению, задать ЗОНУ активации объекта, через ББ - невозможно.
Т.е. только положением плашки можно управлять в некоторое степени.
Но нельзя сделать так, чтобы "название" появлялось только при наведении на область ББ.
|
|
|
|
|
Здесь есть ББ, только игра его не показывает. ^-^
Значение 25 25 z45.
Плашка выползает по верхней кромке ББ, когда курсор "касается" видимых сеток объекта.
|
Здесь же ББ = 1.1.1
И плашка двигается, как приклеенная, всегда рядом с курсором.
Т.е. если провести по объекту курсором, название будет двигаться словно приклеенное и не пытаться убежать в угол экрана.
Как это видно на соседних скриншотах.
|
А здесь нет ББ в виде именного объекта!
Не смотря на то, что игра (TCB) нарисовала контур выделения.
Отчего, сообщение, появляется сразу же при "касании" ореола прицелом и болтается на максимально неудобном удалении от центра объекта.
Высчитывая свое положение исходя из данных о его (ореола) радиусе (вероятно).
|
Также, ББ может использоваться в метательном оружии.
Стрелы, дротики, болты, магические заряды... впрочем они тоже стрелы.
Где позволяет обойти проблему преждевременного взрыва снаряда.
Что интересно, ББ существ и НПС не помещаются в сцену игру, как таковые!
Т.е. в графике сцены не появляется такой ноды.
Однако, по команде TCB можно точно видеть, что он все же имеется!
И все изменение объема, внесенные в ниф файле, соответствуют видимым вокруг существа линиям.
Возникает вопрос, что же собственно происходит...
Но, если вызвать консоль и набрать TCB, а затем SSG, то можно увидеть вот такой занятный объект:
В редакторе, по Ф10, ничего подобного не отмечалось.
Т.е. в редакторе, существа не получают выделение таким методом, но выделяются на общих, так сказать, правах.
Тонкие цветные линии накладываются на ББ оных, равно, как и для всех прочих объектов в сцене.
Это (по видимости) костыль, который делает видимым не видимое.
А вот сама зона, оказывается, перекочевывает из настроек ББ, в атрибуты корня файла!
И при этом, опять же, видно это только в игре.
Во всех случаях, что для biped creatures, что для NPC, что для других типов существ (walk, swims) значения одинаковы.
Union + два вложенных бокса.
Это отвечает на вопрос, отчего ББ вокруг существ (нпс) имеет дополнительную линию в нижней части.
Там находится второй ББ!
Т.е. игра создает составную зоны прокси геометрии вокруг "живых" объектов.
Зачем, не ясно.
Предположение.
Возможно сей костыль связан с кривой работой niLines объектов в движке?
т.к. изучение движка, показали наличие серьезного бага в этом элементе.
Отчего можно думать, что беседка не стала морочиться на исправление и сделала "костыль".
Поэтому в редакторе все объекты выделяются через использование niLines.
А в игре, к объектам добавляется примитив (куб) с настройками WireFrame, что создает сходный с niLines эффект.
Отчасти, даже более заметный и удобный в наблюдении.
Но это простое предположение, что там на самом деле было, Векх ведает то(С)
Т.к. Path Grid вполне себе свободно использует линии для связи между "чекпойнтами", как в игре, так и в редакторе.
Примечание.
По видимости не стоит применять значение Union для объекта называемого Bounding Box в файлах существ.
Т.е. если такое сделать, редактор улетит на рабочий стол.
Видимо дело в оптимизациях которая игра автоматически добавляет объекту с этим системным названием.
В "неживых" моделях, можно совмещать и системное имя и значения, впрочем толку от этого будет мало.
Union можно "применить" в любой ноде, или шейпу, не имеющим системного названия и в файлах существ, но опять же, смысла особого не наблюдается.
Либо, ниф.хмл не имеет правильных данных для этого объекта!
Примечание.
Нифскоп 2.0 имеет более точные данные по прокси геометрии объектов.
Т.е. переключить режим с бокса на сферу, в настройках нод и шейпов, стало возможным.
НО!
Данные не совсем точны. Имеются ошибки в значении некоторых параметров.
А режим ромба и вовсе не подходит для МВ.
Здесь не определено, толи ошибка в ниф.хмл, толи в МВ этот режим не работает нормально.
Так или иначе, для МВ, оптимально всегда использовать режим коробки (box) и с этим замечательно справляется Нифскоп 1.1.3.
Все остальные режимы фактически не актуальны.
Для "неживых" объектов, ББ из файла модели работает в полной мере и отображаются в графике сцены.
ББ (здесь) 5 5 5И как было писано выше, управляет зоной выделения объекта.
Тип ББ оказывает влияние на видимые сетки существа!
Т.е. не смотря на какие-то странные действия движка игры, всегда создающего ББ для "живых" объектов, из хниф файла, учитывается не только объем зоны.
Сфера покажет заметное расширение радиуса, Бокс позволит настроить объем более точно, а ромб... исказит существо в странной проекции!
Если конечно вообще согласится загрузится в игру, увы, его настройки, не декодированы правильно. Хотя, несколько раз срабатывали.
При этом, неправильные настройки сферы, также исказят имеющие скининг детали существа (брони, или одежды).
Т.е. зоны прокси геометрии могут оказывать влияние на видимые сетки существ (и одежду НПС) в некоторых случаях!
Скриншоты этого безобразия, см. здесь.
Настройки для ниф.хмл файла - см. здесь. Нифскоп 1.1.3 не умеет корректно создавать что-то отличное от БОКСа.
Однако, для "использования" режима ромба, придется еще воспользоваться HEX редактором, дабы сменить флаг с 3 на 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 применяется в магических снарядах.
Если его нет, «большие» сгустки магии будут взрываться при малейшем касании любой поверхности своим краем.
Т.е. даже если самая малая частица коснется чего-то - произойдет реакция!
Если ББ есть — снаряд сможет пролетать в небольшого размера окна и двери, свободно задевая их частицами хвоста, или ореолом.
Т.е. ББ - позволяет создать, своего рода, "ударное ядро" и полностью игнорировать просчет столкновений по видимым сеткам объекта.
ББ - в снарядах работает как необходимый элемент отвечающий за просчет столкновений!
ББ, в левом верхнем углу экрана, это "плевок ядом" от того даэдрота в удалении.
И именно этот ББ отвечает за момент смены модели стрелы, на модель взрыва.
Т.е. при касании оным ББ поверхности (земли, или другого объекта) происходит взрыв.
Т.е. в игру помещается ниф файл эффекта взрыва, а стрела убирается из рендеринга.
На переднем плане, прах алчущего (или кланфира) у которого вытянутый ББ.
Т.е. ББ всегда вертикален и не может быть "положен" на бок.
ББ в магических снарядах и в моделях оружия, может иметь Radius 5,5,5 или еще меньше.
1.0.1, или вовсе 0.0.1 и пр. т.е. нет лимита, однако габариты должны быть, иначе просто теряется смысл.
Вероятно это связано с позиционированием объекта в мире относительно прочих объектов.
Магия и стрелы работают в отдельном дереве сцены. А существа в другом.
Либо дело в упрощенном просчете положения метательных снарядов в мире во время их "жизни".
Примечание.
Кто-то вроде бы отмечал, что (VFX_Pattern(e\vfx_pattern0ХХ.nif) могут использовать ББ в своем составе.
Однако, наблюдения этого не показали.
Т.е. влияет положение DUMMY01 нод, но не наличие в оных ББ (в качестве именной ноды).
Примечание!
В игре можно видеть только изменение размера ББ.
Поворот и смещение могут не показать никакого результата.
Поворот, по видимости, не работает вовсе.
Только масштаб и смещение, последнее только косвенно.
Т.е. если в модели существа повернуть, или подвинуть ББ, в игре он так и останется в нулевых координатах без какого-либо поворота по осям.
И только изменение размера будет явно заметно.
Т.е. если вызвать TCB, или Ф4 в редакторе, можно увидеть, что все визуальные изменения положения ББ (кроме масштаба) были игнорированы.
Однако, это не значит, что оные не будут иметь эффекта. См. далее.
Однако, изменение размеров и позиции «Bounding Box» может привести к интересным результатам!
Если ББ меньше 25 по оси Z:
— в существо будет сложно попасть.
Стрелы пролетают насквозь, т.к. попасть в маленький ББ весьма сложно.
Но именно он отвечает за детектирование попаданий!
Так и попадание мечом в верхнюю часть тела, может не причинить урона.
— также, существо может "просочиться" сквозь стену, или закрытую дверь.
Примечание.
А если видимые сетки существа убрать в 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х ББ (автоматически создаваемых игрой) может делать это не всегда корректно.
Очень большой и обширный ББ может скрывать эффект каста от триолитов.
Или прочих объектов использующих ExplodeSpell команду в скриптах.
Т.е. если ББ в разы больше самого объекта, то магический эффект каста окажется вне поля зрения ГГ.
А если сама поверхность объекта использует текстуру с черным бампом, то эффект станет практически не заметен.
На активацию Триолита это не как не скажется, равно и на наложение эффекта на игрока.
Для существ, атакующим выпадом вперед, или с сильным наклоном, рекомендуется выдвигать ВВ вперед.
Иначе камера ГГ окажется внутри их оболочки.
Однако, Боунд Бокс не должен быть сильно квадратным.
Иначе, существо будет застревать в узких корридорах.
Все это управляется редактированием Radius-а в нифскопе.
|
|
|
|
Несколько выступающий вперед, относительно видимой сетки ББ, позволит избавиться от проваливания камеры в брюхо существа во время их атаки.
Высота ББ, может быть также меньше, чем видимая сетка.
|
С боков, ББ, наоборот полезно слегка сжать.
Это избавляет от проблем с застреваниям в дверях и прочих узких местах.
|
Еще раз, обращайте внимание!
Что выдвинуть ББ вперед, можно только изменением радиуса по оси Y.
Не получится просто переместит ББ вперед, меняя значения в строках translation.
Боунд Бокс работает НА другой Боунд Бокс.
Т.е. дистанция атаки, повреждения оружием, визуальный контакт оболочек определяется его размерами.
Т.е. если у игрока слишком маленький, а у существа не достаточно большой - камера будет в брюхе.
Взаимодействие ВВ между собой у предметов - не активно.
Т.е. наличие РК и ББ в айтимах (предметах) не оказывают никакого эффекта.
Вычисления размещения объектов один на другой, берется из их видимых оболочек (ака шейпов).
Тоже самое для оружия.
Наличие ББ в их моделях при размещении оных в мир из инвентаря - не играет роли.
Bounding Box
Неподвижная часть существа!
Он не может и не должен быть анимирован, это своего рода якорь, который управляется только движком игры!
Примечание.
В коде игры есть объект "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.
