Collision detection RCNode flags&test
Общие наблюдения.
Изменение типа детектирование коллизий согласно методу устанавливаемому флагом.
А также влияние параметра has bounding box на это.
В целом, это работает для всех типов Нод и Шейпов, не только для
РК.
Т.е. флаг можно сменить на любом объекте ниф файлов и это отразиться по
ССГ.
Однако, для РК это может иметь некоторый больший резон.
Т.к. именно РК должна отвечать за оптимизацию просчета столкновений.
И, теоретически, установка правильного флага, могла бы оказывать влияние на скорость этих вычислений, а как следствие повлиять на фпс.
Для всех остальных типов объектов (предметы, оружие и пр.) которые не учитывают наличие РК, по видимости, смена метода, не имеет смысла.
Т.к. коллизии для них просчитываются крайне упрощенно.
Отчего и были проведены некоторые тесты.
Примечание.
Согласно справке, наиболее шустрый метод это OBBS, а вот просчет по треугольникам (TRI), значиться как более медленный.
Насколько это верно для МВ, вопрос от части открытый.
Т.к. движок более ранней версии и, по умолчанию из МАХа, экспортируется именно этот (TRI) режим детектирования коллизий.
И получить OBBS из "коробки" проблематично.
Т.е. тесэкспортер всегда и для всего задает режим детектирования по треугольникам.
Т.е. объект называемый
Bounding Box получает флаг 2, несмотря на активацию раздела has bounding box.
Для которого, по идее, было бы уместно включать и режим просчета, как OBBS.
Т.е. возможно МВ в принципе не умеет правильно работать с proxy геометрией.
Или умеет, но только для "живых" объектов.
В итоге, были проведены следующие тесты.
Был создан простейший объект из пары кубиков.
Затем, в нифскопе менялись флаги нод (и шейпа), а также значение "has bounding box" +-, для всех трех объектов.
А затем полученное проверялось в Игре. Без МСП!
Сам объект был помещен в раздел Статики.
(мало вероятно, что для активаторов что-то существенно изменилось бы, но все может быть) (активаторы не тестировались).
- Нода с видимой в игре сеткой, белый куб.
- РК с вложенной дополнительной нодой в которую помещен шейп красного куба.
Тесты смены флагов проводились только в приделах РК!
Флаги и прочее, на видимом объекте, не менялись.
Хбб = has bounding box
Значение = (+) да. Был установлен режим куба + объем оного.
Значение = (-) нет. Объем куба оставался равен 0.0.0
РК = рут коллизион нода.
Нода = здесь безымянная нода в которую помещен куб.
Шейп = куб.
Примечание.
Помимо игры модель проверялся по SSG, где корректно отображались все вносимые изменения.
ББ+- (объем, смена типа и пр.), а равно менялся режим Propagate, который как-раз и показывает текущий режим детектирования столкновений.
Итого:
- РК флаг 5 ХББ+, внутри вложенная нода флаг 5 ХББ+, далее шейп в виде кубика ХББ+ флаг 5.
Игрок свободно проходит через все зоны, где по идее должна быть коллизия.
- РК флаг, нода ХББ+, шейп Хбб+. Флаги 5 везде.
Объект полностью проходим.
- РК 5, нода 5, ХББ+, шейп флаг 5, но без значений в ХББ.
Объект полностью проходим.
- РК 5, Нода 5, Шейп 5. Везде убрано ХББ.
Объект стал не проходим в местах где находится шейп куба помещенный в состав РК.
- РК 7 ХББ активен, но без значения, Нода 7 ХББ+, Шейп без ХББ и флаг 2.
Объект проходим.
- РК 7 ХББ-, Нода 7 ХББ-, Шейп 2.
Объект НЕ проходим согласно данным шейпа.
Либо игра находя "обычный" шейп, с отключенным ХББ, включает типовой просчет столкновений по треугольникам.
Либо игра начинает автоматически создавать прокси геометрию согласно данным с шейпа, в случае ХББ флага на нодах.
Впрочем, первый вариант, более вероятен.
- РК 7, Нода 8 ХББ+, Шейп 2.
Объект проходим!
- РК 7, Нода 7, Шейп 2 ХББ+.
Объект проходим.
Т.е. похоже большее значение оказывают влияние флаги вложенных нод, а не самой РК.
Равно и значение ХББ для вложенных шейпов.
- РК 0, Нода 0(5,7) ХББ+, без шейпа.
Объект проходим.
- Пустая нода безымянная нода, флаг 0 (5, 7) ХББ+.
Объект проходим по всей области это ноды.
Но не проходим, где размещены видимые сетки.
Т.е. выглядит так, что включение прокси геометрии на уровнях нод и шейпов в составе РК, приводит к полной потере "осязаемости" объекта.
Игрок может свободно проходить через такую зону.
С поправкой на возможность "ошибок в тесте" или неучтенного фактора, можно предполагать, что прокси геометрия вообще не считывается для статичных объектов.
Включение ХББ и настройка внутреннего объема оного, результативно только с "живыми" объектами.
Или для управления областью выделения, см. раздел Б
оунд Бокса.
Но может совершенно не использоваться, движком игры, в просчетах коллизий для статичных, ака "неживых", объектов.
Другой тест проводился для плоской поверхности, дабы проверить влияние смены флага на фпс.
Были созданы "беговые" дорожки по которым боты весело бежали пообниматься с игроком.
Возможно отмечалось незначительное улучшение фпс при использовании флагов 5-7 и обычном шейпе в составе РК.
Против типовых флагов 2, 8, 10.
Но, скорее в приделах погрешности.
Нет полной уверенности, что это как-то влияло.
Желательно провести дополнительные тесты.
Единственное, что действительно влияет на фпс, так это разделение одной большой поверхности в составе РК, на несколько меньших.
Итого, что это дает в целом?
Теоретически разбиение одной большой поверхности на много меньших участков и установка флага 5, может сколько-то повысить фпс.
Против случая одной большой поверхности и флага 3.
Т.е практические тесты, однозначно показали пользу разбиения большой поверхности на меньшие участки.
Равно пользу от сокращения в них полигонов. Чем проще геометрия, тем лучше для просчета коллизий.
Однако, влияние флага не показывает значительных изменений фпс.
А игры вокруг значения has bounding box и настроек оного, показали вовсе прямо обратный результат.
Поверхность полностью теряет осязаемость.
Отчего, можно не особо заморачиваться на смену флагов у РК и прочих объектов, кроме отдельных случаев.
Т.е. игра отключит все просчеты для ряда объектов (предметы, оружие и пр.) не взирая на флаг в настройках нод и шейпов модели.
А для других объектов (статики, активаторы) игры с флагом не приносят желаемого повышения ФПС.
Впрочем, все таки, может быть...
Есть какой-то там момент, что флаг 5 будет лучше показывать себя на объектах с простой плоской поверхностью (ака поверхность лавы, к примеру).
А флаг 3 на более сложных (помещения на вроде даэдрических и т.п.)
Примечание.
Флаг детектирования работает в связке с другими параметрами.
Например:
- если модель содержит
стринг NCO то уже нет никакого смысла что-то шаманить с флагами нод. Т.к. просчет столкновений будет отключен по умолчанию.
- но если это
niCollisionSwitch Нода, то флаг становится важным моментом! Включая, или отключая просчет столкновений.
- также, все нечетные флаги сделают ноду скрытой! А четные наоборот. Просто к слову.
Однако, РК нода правильно помещенная в корень файла, будет скрытой всегда.
Таблица влияние флагов на метод детектирования коллизий.
|
|
|
|
Флаг = 0
|
|
|
Флаг = 1
|
|
|
Флаг = 2
|
|
|
Флаг = 3
|
|
|
Флаг = 4
|
|
|
Флаг = 5
|
|
|
Флаг = 6
|
|
|
Флаг = 7
|
|
|
Флаг = 8
|
|
|
Флаг = 9
|
|
|
Флаг = 10
|
|
|
Флаг = 11
|
|
|
Флаг = 12
|
|
|
Флаг = 13
|
|
|
Флаг = 14
|
|
|
Флаг = 15
|
|
|
Флаг = 32
|
|
|
Флаг = 42
|
|
