Collision detection methods of detection
Хорошо! Это были сами объекты, которые показывают движку, где и на чем можно ускорить вычисления!
А теперь посмотрим на "методы" которые используются для этого! :D
На самом деле это лишь звучит Красиво, но в МВ все до безобразия печально.
Хотя он (вроде бы) и может использовать несколько методов (сразу), но на практике в 99% случаев применяется только один.
А именно просчет по треугольникам.
Т.е. просчет столкновений может идти:
- по треугольникам поверхностей (шейпов).
- по "виртуальным" зонам, ака коробкам окружения (ББ).
- так и по совмещенному методу, если в модели имеются, как шейпы, так и ББ.
В свою очередь, ББ, внезапно, имеет несколько пресетов позволяющих подобрать наиболее подходящую форму "виртуальной зоны".
Но, в МВ, это не очень работает... если конечно МВСЕ что-то там не подшаманит.
ОпМВ, может использовать это в большем объеме!
Методы детектирования коллизий.
В основном применяются для "неживых" объектов, но вполне себе могут использоваться и для существ, если те не имеют ББ в своих моделях.
Т.е. на основе просчета данных с шейпов, игра автоматически создаст ББ для оных.
Для снарядов магии, ББ не создается автоматически.
Если его нет в модели снаряда, значит будет использоваться обычный просчет по треугольникам.
Смена значения определяется флагом на шейпе или ноде!
|
Triangles
|
Use only triangle data even if mesh has a bounding box.
Всегда использовать просчет по треугольникам.
The least efficient propagation flag. If attached to a triangle mesh, collision testing will iterate through every triangle of that mesh, if the ABV deems a collision is possible, so it is best used for low-triangle meshes.
Система коллизий в МВ находится в зачаточном состоянии и в основном пользует только этот метод.
|
Это стандартный метод движка МВ, выбранный по умолчанию для всех шейп поверхностей и нод.
В т.ч. при экспорте моделей из МАХа.
Фактически означает, что если некоторый объект в ниф файле имеет активное значение "has bounding box" - оно будет игнорировано и просчеты пойдут по видимой сетке полигонов.
|
|
BoundingBox
|
Use only bounding box data even if mesh has triangles.
Если в моделях есть настройка "has bounding box" просчет пойдет (должен идти) только по этим значениям.
Like the previous flag, this one has different meanings for triangle meshes and parent nodes. If defined for a mesh, this causes the collision system to test using an algorithm that is efficient for a large mesh.
|
Применяется на ББ "живых" объектах, по видимости в т.ч. на автомате движком игры.
Фактически имеет место совмещение понятий.
Системный объект bounding box ака коробка окружения вокруг объектов, является и прокси геометрией.
Т.е. той самой виртуальной зоной ускоряющий просчеты коллизий объектов.
А также методом этого самого детектирования.
Use_Obb как раз и включает (должен включать) эту самую зону просчетов.
Если в моделях стоит флаг "use BB", но в настройках шейпов (нод) не включено "has bounding box", или включено, но не настроено:
- вероятно игнорируется на уровне движка.
Либо движок, вовсе не реагирует на смену флага, всегда проводя вычисления по треугольникам.
Есть (было) некоторое мнение, что этот флаг, примененный на "РК" может положительно сказываться на фпс.
Однако включение ББ в настройках шейпов, не привело к желаемому результату.
В одном из тестов, поверхность стала полностью проходима.
Вероятно, этот метод, и плохо применим к "неживым" объектам.
(всегда приходится делать поправку на древность движка и некоторую неточность имеющихся наблюдений)
Т.к. сложна геометрия не может быть эффективно просчитана по "кубикам".
Т.е. игрок банально окажется внутри большого куба, или среди множестве мелких.
В целом, метод "коробки" хорошо подошел бы только для простых объектов, на вроде ящиков, или стен.
Но не для сложных помещений.
|
|
Continue
|
Use both triangle data and bounding box data.
The CONTINUE flag is designed to support ABVs attached to objects such as animated characters, where the ABVs need to move with the portion of the character that they are enclosing.
Т.е. совмещение обоих двух методов просчета столкновений.
Вероятно, основное назначение использование в моделях (существ).
Для МВ, это, не актуально.
Здесь всегда один ББ на всю модель.
Но возможно, такой метод как-то можно применять в РК?
|
По идее это самый правильный метод, но в МВ, моделей где бы он применялся не замечено.
Хотя справка относит это к моделям "живых" объектов и, по видимости, для расчета сложных схем столкновений. Регдол?
Опять же, модель должна содержать не только шейпы, но и ноды (шейпы) в настройках которых включено то самое значение "has bounding box" = 1 + XYZ.
Но получить такую поверхность через ТЕСэкспортер, "затруднительно". |
|
NONE
NOTEST
|
NONE flag—a collision with the ABV means the underlying geometry is considered to be hit. The difference is that, whether or not a collision is found, testing is always continued on to the children of the node.
This flag indicates that no testing should be done. It effectively turns off collision detection for the object.
|
Сообщает игре не проводить тестирования объекта на предмет просчета столкновений.
Однако, это не сделает указанный объект проходимым.
Т.е. если установить флаг шейпа, или ноды, как NONE, это не сделает его в игре проходимым для игрока и прочих.
Вероятно, это лишь сокращает некоторые вычисления.
Либо движок МВ, игнорирует флаги в моделях, задавая шаблон просчета столкновений на уровне графиков сцены.
Например:
- все предметы, оружие и пр. "проходимы" всегда.
- статики, если не имеют специальных настроек, "непроходимы" всегда.
|
Вероятно, метод детектирования, (может быть) жестко зашит в движок МВ и, изменения в файлах могут вовсе не оказывать никакого значимого эффекта.
При экспорте моделей из МАХа через ТЕСэкспортер, как правило, всегда получается значение флагов на нодах и шейпах, как "работа по треугольникам" (use_tri).
Но как было показано выше, особо заморачиваться над этим, по любому, не имеет смысла.
Разве в случае особо сложной РК у особо большого объекта.
Да и то, большее пользы для фпс будет от разбиения большой поверхности на много мелких, чем от смены флага детектирования.
А для всех остальных случаях, просчеты коллизии находятся на минимальном уровне.
Итого:
В ручную менять метод детектирования коллизий в МВ фактически не актуально.
Он либо будет сброшен на use_tri, либо проигнорирован.
Т.е. объект станет полностью проходим.
Также, заметно влияния на фпс, смена метода, также не оказывает.
Читать далее по тексту, т.е. продолжение.
Выдержка из оригинальной справки. (NDL Gamebryo 1.1)(С)
Следует учитывать что это более новая версия движка, и не все упомянутые ниже "вкусняшки", работают в МВ.
Но, что имеем.
Collision Methods
Gamebryo provides a number of methods for performing fast collision detection. Some of these methods are optional while others are internally chosen automatically. From the start, Gamebryo collision detection uses the bounding spheres of nodes which have already been calculated for scene graph culling. Using the bounding spheres takes advantage of the hierarchical nature of the scene graph. Subsystems such as picking use these same bounds for determining if a ray intersects with some portion of the scene graph and ultimately with some geometry in the scene. Other methods that are used by the collision system include raw triangle to triangle collision detection,
OBB's (Oriented Bounding Boxes), which provide a more efficient way of testing for triangle collision detection, and finally, the ability to supply
ABV's (Alternate Bounding Volumes) which can provide much faster collision detection than the previous methods. All of these methods will be discussed in sections following this one..
Собственно, да, те самые ББ ака "виртуальные" математический зоны не имеющий видимых сетчатых оболочек, но вполне себе используемые для вычислений столкновений между объектами.
В МВ все это работает, но в "зачаточном" состоянии с поправкой, на "чтотамещебеседканакодила"(С)
Примечание.
Движок МВ не имеет отдельного узла NiCollisionData, т.е. просчеты столкновений в нем находятся на самом раннем уровне создания.
И только в последующих версиях движка они были достаточно развиты и оптимизированы.
Выдержка из оригинальной справки. (NDL Gamebryo 1.1)
The type of collision that occurs between two given objects depends on the collision control flags that are set on the collision data. Using the collision control flags, one can specify if triangle, OBB, or ABV is to be used for collision detection. The collision control flags are enumerated in the NiCollisionData class of the NiCollision system. The single parameter that is accepted by the function is a NiCollisionData scoped enumerated type called CollisionMode.
The different values and their meanings for the CollisionMode flag are as follows:
USE_OBB
This flag indicates that collision is to be done by creating an efficient oriented bounding box for the associated geometric data. If the NiCollisionData is to use this flag, then it should be constructed with a pointer to valid geometry data. Typically, this flag will be used on an NiAVObject that is some sort of geometry.
USE_TRI
This flag indicates to collision that the object wishes to use it's raw triangles for collision detection. This is the least efficient method of collision, especially for meshes with a high triangle count. As with the USE_OBB flag, this flag should be used in conjunction with a geometry based object, else no collisions will occur.
When testing against other objects, there are a few things to note. If the other object is also set to use triangles, then triangle-to-triangle testing will occur. If the other object uses an alternate bounding volume, triangle-to-bounding volume testing will occur. But note that testing between triangles and OBBs is not possible. In this case, an OBB will be created on the fly so that OBB vrs OBB testing can be achieved.
