RootCollisionNode - notes
Примечание.
Если объект кастующий, через действие скриптов, некое заклинание не имеет RootCollisionNode - будет выдано сообщение "bad scale magick efffect XXX", т. е. возникают какие-то проблемы с установкой размера для магического "взрыва"!
Примечание.
Двери не должны иметь RootCollisionNode!
Если РК есть в модели, то дверь становиться проходимой...
А также могут возникать иные оказии и проблемы.
Двери это особый раздел редактора, они получают коллизии по умолчанию.
Примечание.
Если в модель двери был добавлен (динамически, во время игры) новый шейп, или ББ, то ему будет сообщено детектирование коллизий!
Такое может происходить при использовании МВСЕ 2.Х.
Т.е. надо быть осторожным при работе с дверями по средствам МВСЕ.
Примечание.
Разбиение поверхностей в составе РК на большее чем один кол-во шейпов, однозначно дает + к фпс.
Т.е. при создании коллизий какой-либо поверхности, сначала слегка увеличьте кол-во полигонов, а затем разделите их на отдельные объекты.
Либо кнопка explode в Editable Mesh (МАХа)
Либо с помощью дополнительных скриптов.
Примечание.
Неправильно настроенные РК будут влиять на пролезание камеры ЗА стены!
Т.е. если шейпы в РК имеют значительные размеры (более 1024ед) и как следствие значительный радиус.
То, камера от 3его лица будет далеко проваливаться за видимые сетки стен!
Примечание.
Если было создано какое-то большое помещение (больше 2048х2048) и в него не были помещены меньшие объекты.
Будут наблюдаться проблемы с перемещением игрока!
Т.е. скорее всего он будет ходить по воздуху и вообще делать вид, что коллизии где угодно, но только не там где они есть.
Исправить это безобразие поможет добавление в локацию меньших объектов.
Столы, стулья и пр.
Разместить их по локации в разных местах.
Т.е. если в сцене есть только один большой объект (даже с правильно настроенными РК) просчет положения Игрока будет проходить с ошибками!
Либо, следует разбить модель на несколько меньших и поместить их в сцену частями.
Это также решает проблему.
Т.е. если при первом тесте Громадной Локации выполненной из одной модели начались такие проблемы, не надо искать проблему на стороне модели.
Но сперва, добавить в сцену некоторое кол-во меньших объектов. Активаторы, статики, светильники и пр.
Но если это не помогло, тогда конечно, надо смотреть основную модель, на предмет правильности РК.
Примечание.
Если в локацию был помещен объект больше чем 2048 (скорее 4096), вероятность того, что локация просто не загрузиться весьма велика.
Т.е. в редакторе конечно все нормально, но вот в игре уже нет.
Это решается "нарезкой" такого объекта на несколько меньших.
В целом, игра крайне плохо переваривает большие объекты.
И что-то более чем 2048 лучше не создавать.
Но и не стоит делать слишком длинные локации, особенно по оси Z.
Это также может приводить к разного рода багам.
Вылетам, зависаниям и пр.
Максимальный размер одной (интерьер) локации не должен превышать 8096 ед.
Это размер ячеек в мире игры.
Т.е. если замыслили сделать что-то ну вот прям совсем БЫЛИННОЕ и ЭПИЧНОЕ, придется танцевать с бубном!
В т.ч. разделяя локацию (и модели оной) на несколько меньших, или шаманствуя с бекграундами.
Также, большие модели расходуют больше памяти и требуют более тщательной настройки РК.
Примечание.
RootCollisionNode могут работать только в статиках, контейнерах, светильниках (статичных) и активаторах!
Для всех остальных типов объектов они не работают даже если будут добавлены!
Для правильной работы по просчету столкновений, RootCollisionNode обязательно требует наличия шейпа\шейпов!
Без шейпов, сама по себе, эта нода, не будет работать.
От наличия шейпов, собственно и берутся данные для просчета коллизий.
Поэтому, проще проводить конвертирование уже имеющейся ноды с шейпами, или упаковывать отдельные шейпы в RootCollisionNode.
Установить флаг 3. Иначе объект может остаться видимым.
Т.е. подразумевается, что движок будет автоматически скрывать объект названный RootCollisionNode, но делает это не всегда.
Флаг ставится вручную!
После смены имени ноды, опция редактирования флага исчезает из контекстного меню.
Примечание.
Однако, вариант когда РК не содержит шейпов также может использоваться.
Например, если требуется создать проходимую для игрока (НПС и существ) поверхность.
Создается пустая РК и собственно все!
Игра пытается просчитать столкновения согласно данным находящимся в РК, где их нет по факту.
Влияние этого метода на фпс - не изучалось. Т.е. пытается ли игра постоянно найти эти данные, или проверив один раз "успокаивается".
Некоторые модели в новых (после 2020) года плагинах, используют такой метод.
В ванильных моделях, все РК содержат шейпы (иной раз сосем небольшие, см. модель паутины).
Вероятно это происходит в силу ограничение экспортера. Где требуется использовать "физический" объект.
Если создавать пустышку (dummy) и назвать ее Collision - РК не создается.
Т.е. без нифскопе, получить пустую РК - не получается.
Triangles = Use only triangle data even if mesh has a bounding box.
Это стандартный метод, выбранный по умолчанию для всех поверхностей.
BoundingBox = Use only bounding box data even if mesh has triangles.
Похоже - это работает только для существ и нпс.
Continue = Use both triangle data and bounding box data.
Т.е. совмещение обоих двух методов просчета столкновений.
Справка, рекомендует этот метод, только для файлов "живых" объектов. В МВ он также не особо влияет на фпс и поверхности.
На практике, все изменения флагов РК в файле могут не оказывать никакого заметного эффекта.
Примечание.
Кол-во шейпов в RootCollisionNode может быть любым.
Также, она может содержать вложенные niNode со своим набором шейпов.
Что бывает в случае загрузки в РК копии корневой ноды модели.
Но, все же, лучше, если в ней будут размещены только шейпы!
Т.е. выгрузить все шейпы из такой копии (flatten branches).
Однако это займет лишнее время и может нарушить позиции шейпов, отчего этим можно пренебречь.
Отчего, конечно много лучше, создавать поверхность для РК в 3д редакторе!
Это позволит настроить ее максимально эффективно.
Примечание.
См. файлы "мясорубок" и пр. из гробничке Сота Сил. Иде оных далее по тексту.
Там многие анимированные объекты имеют в составе РК анимационные ноды.
Это позволяет коллизиям работать синхронно с видимыми оболочками объектов.
Коллизии в т.ч. используются для просчета нанесения ущерба ГГ.
Примечание.
Сообществом, на 2021ый год принято считать, что РК, для строений и пр. объектов радиусом больше чем 512 уе, лучше собирать из нескольких шейпов.
Для маленьких объектов, на вроде стульев, шкафов и пр. это не критично.
Т.е. РК состоящая из одной большой поверхности, создает проблемы для игры и (может) понижать фпс.
См. кантоны Вивека, как основной пример такого явления.
Особенно при низких фпс, существует высокая вероятность провалиться сквозь такую поверхность.
Но эта же поверхность разбитая на несколько меньших шейпов, показывает положительный результат!
Вероятно связанно с тем, как обрабатываются столкновения.
По одной большой поверхности, или по небольшим участкам в виде отдельных шейпов.
Т.е. с небольшими объектами, игре проще просчитать позиции (живых объектов) и вовремя "принять меры" (по корректировке их положения).
Примечание.
По работе радиусов шейпов внутри РК.
*Взято с одного форума(С).
- Если РК состоит из одного шейпа, то радиус просчета увеличен значительно.
- Если РК имеет несколько шейпов, то радиус уменьшается, что может быть полезно для фпс и точности просчета столкновений.
Greatness7 писал.
and splitting up collision into multiple pieces can make a big performance improvement
since the way the game decides if it needs to do collision calculations is to first check if the actor is within the meshes' radius sphere
so a shape like this has this radius. and any actor inside that radius must calculate collision against the object. which is rather expensive and involves going over all the vertices and such
in this case because its all one shape, that sphere is stretched out and there is a lot of empty space that will still be calculating collision even though its not theoretically necessary
splitting it into 3, you get a much tigter fit
Примечание.
С шейпа в РК, рекомендуется, удалить все свойства!
Текстурные и пр. а также любые иные настройки параметров, они здесь не нужны.
Т.к флаг 3 делает объект скрытым. Также, это уменьшает размер ниф файла.
Примечание.
Согласно выше сказанному, проводить слияния шейпов для РК, может оказаться не лучшей идеей.
ПКМ по ноде - Optimise->combine shapes, для объектов в РК, делать не следует!
Примечание.
В ниф файле может быть только одна RootCollisionNode!
Если в ниф файле несколько РК, то будет работать только одна, в корне файла.
Если их несколько в корне файла - то обрабатывается только одна из них.
Вторая станет видимой, но не будет создавать коллизии.
Т.е. игрок будет проходить через нее, если она не пересекается с рабочей РК.
Примечание.
Если, RootCollisionNode находится в составе любой вложенной ноды, она перестает выполнять свои основные функции.
Т.е. начинает обрабатываться в качестве обычной ноды.
При этом, если на РК не стоял флаг Hidden (обычно 3), она станет видимой!
Т.е. движок перестает расценивать РК, как системный объект и отключает автоскрытие его шейпов.
Но если РК в корне файла, движок игры не будет отображать ее содержимое, даже если на РК не стоит флаг Hidden!
Однако!
Сохранив детектирование столкновений только по РК и автоскрытие в составе вложенных нод
См. ванильную модель моста перед Акулаханом.
Где, РК находится в составе другой ноды содержащей анимацию.
По причине которой она и размещена здесь.
Т.е. если, по каким-то причинам, РК требуется поместить внутрь обычной ноды, следует обязательно добавить эти экстра свойства!
Примечание.
Основной причиной (RCN), может стать, добавление анимации в активатор, где требуется совместить изменение положение видимого объекта с его РК.
Это актуально для анимированных активаторов на вроде; дверей, мостов, или больших контейнеров.
Если этого не сделать, то игрок будет упираться в невидимую стену, хотя видимая часть активатора и будет выглядеть открытой.
Примечание.
ТЕС экспортер - (как оказалось, все же) поддерживает экспорт анимации для RootCollisionNode.
Т.е. в 2021 году (07-08) было таки "открыто" нужное заклинание. )))
Примечание.
RootCollisionNode не помещается в Лодноды!
Т.е. если в 3д МАХ объект названный Collison поместить в состав Лодов, он не будет помещен туда.
Но будет создана обычная РК нода.
Что можно конечно обойти через Нифскоп.
Но, особого смысла менять детализацию для РК не выглядит актуальным.
Т.к. игра не сумеет просчитать такие изменения.
Поскольку РК либо есть, либо ее нет. Она будет просчитана сразу, вне зависимости от того что показывает камера игрока.
Примечание.
Коллизией может работать любая "физическая" поверхность т.е. шейп.
Есть мнение, что из-за низких фпс коллизии не успевали срабатывать, отчего игрок часто застревал, или проваливался сквозь поверхности.
Также, возможно, РК, является дополнительным буфером для ускорения просчета столкновений и работы АИ.
Примечание.
Если RootCollisionNode нет в модели вовсе, то коллизия будет создаваться по видимым сетчатым оболочкам.
Т.е. шейпы модели будут работать для просчета коллизий.
Флаги детектирования коллизий, на шейпах и нодах - не важны!
None, continue, triangles, bounding box - не важно.
С любым значением флагов, объект будет полностью не проходим для игрока.
Если сделать объект с разными флагами детектирования коллизий на разных шейпах - результат аналогичен.
Все шейпы, вне зависимости от флага на их нодах, останутся не проходимыми!
Т.е. версия движка Морровинда крайне примитивно работает с просчетом столкновений, не учитывая настройки детектирования коллизий указанные в настройках шейпов. Даже при включении использования прокси геометрии.
Примечание.
Приходилось слышать мнение, что наличие Колижена в качестве отдельного объекта (т.е. РК) повышает ФПС игры!
Т.е. если РК в моделях нет, игра начинает просчитывать все коллизии "на лету", что понижает фпс.
И да, это мнение верно!
Отчего, следует рекомендовать создание коллизий для ВСЕХ статических объектов, с которыми будут как-то взаимодействовать боты.
Кроме особых случаев!
Например, см. дефолтные растения, через которые игрок и прочие, могут проходить.
Собственно если отключить коллизии через TCL, фпс действительно заметно подрастают.
Хотя, если сравнивать небольшие объекты с РК и без РК по влиянию на фпс, это не столь заметно.
Но стоит поместить в сцену Огромный объект и проверить влияние РК уже в нем, то здесь изменение фпс проявляются сразу и во всей силе!
Правильная РК, значительно повышает и стабилизирует Фпс!
Т.е. да, РК является ускорителем для просчета коллизий и при правильных настройках оказывает огромное влияние.
Примечание.
РК позволяет управлять участками непроходимости объекта.
Т.е. можно создавать зоны доступные для прохождения игрока, без добавления флага NCO!
Достаточно создать РК с "отверстиями".
Например: видимая плоскость сплошной стены может иметь сложную РК в которой предусмотрены проходы, это позволит создать... например; Лабиринт из фильма Лабиринт.
Просто и легко. И не потребуется создавать дополнительные модели стен заточенные под полную проходимость.
Примечание.
Спорный момент.
Возможно, для шейпов в РК, полезно иметь больше полигонов, чем у базового объекта.
В рендере они не участвуют, но вот точность просчета столкновений могут улучшить!
Впрочем, обычно делается наоборот. Чем меньше поликов, тем лучше.
Т.е. точность просчета может понижать фпс.
Скорее наоборот - чем меньше полигонов тем лучше.
Но самих шейпов - чем больше тем лучше.
Но один большой шейп с малым кол-вом полигонов, еще хуже.
Собственно тесты и выше писанное показывают такую динамику.
Примечание.
На самом деле, все куда проще.
- Взять базовую сетку строения.
- Сгладить.
- Разбить на полигоны (detach).
- Упаковать все множество полигонов в отдельную ноду.
- Преобразовать эту ноду в РК, либо прямо в МАХ, либо через нифскоп.
Означенный метод способствует существенному улучшению фпс.
При этом, шейпов может быть ОЧЕНЬ много! 2-4к шейпов было проверено.
Единственный минус, МАХ сильно зависает при экспорте подобного РК.
Равно и нифскоп долго думает на открытии такого файла.
Дополнительно, сам видимый объект, можно поместить в CollisionSwithcNode, чтобы точно избавиться от любых попыток движка "и его посчитать"(С)
А для удобства выделения в редакторе, добавить в файл Маркер и ББ.
Примечание.
Не смотря на значение флага РК - скрыто, частицы, использующие геометрию шейпов в качестве эмиттера, будут отображены!
Примечание.
Внутри РК могут находится Анимационные ноды!
Что можно видеть в моделях механизмов Заводного города.
Morrowind\Data Files\Meshes\i\act_sotha_clockwork.NIF
Здесь они используются для сохранения анимаций.
Т.е. соответствуют вращению видимых деталей.
Т.е. внутри РК поддержана полноценная анимация для всех вложенных объектов.
Контроллер невидимости, или анимации материалов - здесь не имеют смысла.
Примечание.
RootCollisionNode — непременно нужна лестницам и полам!
Т.е. если лестницы используют видимую геометрию, то вероятность того, что игрок в них будет застревать, крайне высока!
Обязательно создавайте пологий пандус! Только не слишком крутой, иначе игрок будет скатываться.
Полам, РК нужен для упрощения обработки коллизий. Видимая плоскость конечно справиться, но РК упростит задачу и может поднять фпс.
Стены и «ящики» могут обходиться без этой ноды. Поскольку игрок редко когда на них залезает, но вот если у лестницы нет коллизии, шансы провалиться сквозь оную при подъеме (или застрять), весьма велики!
Для лестниц, колижены НЕ должны повторять их структуру!
Иначе ГГ и прочие существа, будут спотыкаться и застревать.
Т.е. угол БоундБокса ГГ удачно впишется в угол ступенек! Чем выше ступеньки, тем сложнее будет по ним ходить.
Лестницы должны содержать гладкий РК, аля скат с горки.
Слишком высокий угол подъема, также создаст проблемы, поэтому создание крутых и высоких лестниц несколько затруднено,
но не невозможно! Достаточно сделать очень маленькую высоту ступенек.
Возможно что основное значений колиженов в объектах, это смягчать кривую работу БоундБокса.
Также, подъем по очень крутым лестницам можно облегчить за счет Velocity.
Примечание.
Существует "легенда", согласно которой, в одной из первых сборок МВ коллизий не было, но во время одного из первых показов Игры, был некоторый казус - Игрок то и дело застревал, или проваливался в объекты.
После этого, объекты получили дополнительные ноды по просчету Коллизии.
- что косвенно подтверждается фактом падения фпс при наличие существ\НПС в сцене.
Т.е. алгоритм просчета столкновений не был доработан? Вероятно да, т.к. ранняя версия движка не содержала отдельных элементов по работе с коллизиями, как это было добавлено в старших версиях.
Примечание.
Если вызвать TCL в консоли, можно наблюдать заметный рост ФПС.
Просчет столкновение НПС и существ занимает значительные мощности процессора.
Примечание.
RootCollisionNode значительно повышает фпс, особенно для больших объектов!
Влияния числа нпс и существ находящихся на поверхности объекта - влияет на фпс!
В сторону понижения.
Однако правильно нарезанный, на мелкие фрагменты РК, реагирует мягче.
Т.е. фпс проседает меньше, чем если использовать единый шейп большого размера.
Однако, другой тест, проведенный в пустом помещении, не выявил линейной зависимости от наличия\отсутствия RootCollisionNode в объектах при нахождении на оных некоторого числа существ.
Т.е. на фпс влияет сразу несколько факторов.
В т.ч. сложности геометрии локации, настройка РК, кол-во существ.
Примечание.
По представлению SSG.
Как видно, никаких особых настроек.
Т.е. движок игры (TCB) и редактора (F4) добавляет их автоматически всем РК в мире, дабы коллизии не загораживали обычные (видимые) сетки объектов.
Из переписки на одном форуме:
Tyddy Ner
Can anyone explain me, why a lot of MW meshes has multishaped collisions?
Is it necessary?
MinerMan60101
More shapes in collision actually reduces lag
MinerMan60101
Each collision box is loaded if something enters a certain sphere, going from the box's origin to its outermost point. You want that sphere to be small, so collision is only calculated for it when actually necessary, not just all the time
Svrdm
Is toggling collision something that's known to affect framerate?
No collision = more fps?
Remiros
Yes and no
Generally, a properly made collision shouldn't affect performance.
Bad collisions do have the potential to severely tank performance, though, especially if it's a large mesh with a lot of actors colliding.
Svrdm
Huh, bc turning off collision in the open vivec mod significantly increased my fps...
eddie5
The typical problem with the vivec cantons (for me at least) has always been the sudden and inexplicable LACK of collision. Leaving me in the drink.
Не уверен, но возможно это можно отнести и к РК собранной из нескольких шейпов.
Т.е. РК, по виду и есть группа колизий.
Выдержка из оригинальной справки. (NDL Gamebryo 1.1)
NiCollisionGroup Improvements
The move-able Soldier is added to the NiCollisionGroup as a collider, but the one moving in-place is added as a collidee. As it is animating, we still have to call Update on the collidee, but for larger collections of collidees, the collision testing would be more efficient because of this separation. First of all, most of the collidees would not need to be updated. Second, the collidees would not be tested against each other, reducing the total number of collision test combinations made significantly, as most apps have a large number of collidees and a fewer number of colliders in the scene at any time. For instance, if there were no separation and we had 10 objects in the collision group, we would have to run 10 Updates and 9+8+7+6+5+4+3+2+1 = 45 object-object collision tests (and propagate down the respective trees for each, possibly). If only three of those objects were colliders with the new behavior of the NiCollisionGroup, then only 3 Updates need be called and 9+8+7 = 24 object-object collision tests made. This is a 2:1 improvement for a small data set. For a more realistic NiCollisionGroup consisting of 10 colliders and 90 collidees, we have a 5:1 improvement.
|
|
|
|
Внутренности ванильной сторожевой башни - все ступеньки накрыты ровными скатами.
|
Лестница - вместо ступенек пологий скат.
Иначе, ГГ будет спотыкаться о них.
|
|
|
|
|
Это отображение радиуса коллизии кантона Вивека средствами МВСЕ.
Чем меньше радиус, тем точнее детектирования положения объекта.
Что положительно скажется на фпс, так и на работе скриптов!
|
|
|
|
|
|
|
|
|
16 фпс! Строение без РК.
|
60 фпс! Строение получило нарезанную на мелкие фрагменты РК.
|
