Войти
ПрограммированиеФорумФизика

Bullet physics

#0
23:56, 29 апр. 2019

Всем привет! Накопилось несколько вопросов по bullet:

1. Правильно ли я понимаю, что btBvhTriangleMeshShape лучше использовать для статической геометрии, а для динамики лучше использовать btGImpactMeshShape?
(Случай, когда нельзя аппроксимировать другими формами).

2. Как лучше использовать btBvhTriangleMeshShape - для каждого статик меша создавать свой экземпляр, а инстансы, используя btBvhScaledTriangleMeshShape или для всех статических мешей на уровне генерировать единый btBvhTriangleMeshShape?

3. Можно ли btGImpactMeshShape использовать в btCompoundShape?

4. Для уровней, состоящих из набора выпуклых многогранников (аля Quake1-3) что лучше использовать - кучу btConvexHullShape или один btBvhTriangleMeshShape?


#1
(Правка: 22:42) 22:41, 1 мая 2019
1. Правильно ли я понимаю, что btBvhTriangleMeshShape лучше использовать для статической геометрии, а для динамики лучше использовать btGImpactMeshShape?
(Случай, когда нельзя аппроксимировать другими формами).

Когда я первый раз читал про btBvhTriangleMeshShape, то тоже подумал, что его лучше (эффективнее) использовать для статической геометрии. Но оказалось, что его просто нельзя использовать для динамической геометрии (просто не заведётся физика).
2. Как лучше использовать btBvhTriangleMeshShape - для каждого статик меша создавать свой экземпляр, а инстансы, используя btBvhScaledTriangleMeshShape или для всех статических мешей на уровне генерировать единый btBvhTriangleMeshShape?

Возможно, я делал что-то не так, но создание одного гигантского btBvhTriangleMeshShape на всю сцену снижает производительность, использование слишком большого числа маленьких btBvhTriangleMeshShape - тоже. То есть вроде как оптимален некоторый промежуточный вариант...
#2
16:18, 3 мая 2019

gkv311

> создание одного гигантского btBvhTriangleMeshShape на всю сцену снижает производительность, использование слишком большого числа маленьких btBvhTriangleMeshShape - тоже

Ясно, жаль, что нет закономерности, придется тестить.

#3
(Правка: 2:16) 2:02, 4 мая 2019

Добавлю свои пять копеек в копилку.
Иммено: btBvhTriangleMeshShape или btMultimaterialTriangleMeshShape, но это не всё, читать дальше:
Выставляем флаг: btCollisionObject::CF_STATIC_OBJECT
Также геометрию стоит резать на кубики в 500м на 500м (если юнит 1 = 1м)
И еще ну не надо применять трансформацию к геометрии, экспортируйте точки уже в их финальных положениях и будет вам счастье.
И конечно не забываем, что статику можно также строить с помощью примитивов и объединять в компаунд (btBoxShape, т.д.).
Ну а если совсем уж не катит, то КАБ в помощь, можно попробовать мультипоточную версию, собирайте и бомбите, придётся не много повозится с потоками правда, но там практически всё на блюдечке.
Да и вообще физика сама по себе должна быть на отдельном потоке.
С топик стартера Jack Daniels.

#4
(Правка: 7:50) 7:50, 4 мая 2019

Кстати, люди bullet используют в играх исключительно с single floating point precision, или с double precision? Как в играх решаются проблемы с точностью на огромной карте (трюки RTC (relative to center) and RTE (relative to eye) для графики мне известны, но они никак не стыкуются с физикой)?

#5
12:04, 4 мая 2019

gkv311
> Как в играх решаются проблемы с точностью на огромной карте

Можно разделить на небольшие локации, у каждой локации своя локальная система координат. При переходе объекта с одной локации на другую - удалять физическое представление из одной локации и добавлять на другую, при этом сохраняя все свойства (скорость, масса и т.п.). Статику в локациях можно делать слегка внахлест, чтобы не было проблем на стыках.
Это чисто в теории, на практике - надо проверять.

#6
16:04, 5 мая 2019

решаются просто: стараются не использовать большие пространства (в основном из-за необходимости контента), очень стараются не использовать полноценную физику на больших расстояниях

ПрограммированиеФорумФизика