Bullet дебажный рендер btConvexHullShape

Может кто знает уже какуюнить реализацию алгоритма, который на основании облака точек выщитывает треугольники выпухлого меша который покрывает это облако.

А то в булете есть btConvexHullShape но он для дебага рендерется какимто странным образом:

btCollisionWorld.cpp
  1. void btCollisionWorld::debugDrawObject&;const btTransform& worldTransform, const btCollisionShape* shape, const btVector3& color&; &;
  2. // ...
  3.      for &;i=0;polyshape->getNumEdges&;&;;i++&; &; // polyshape - Это преобразованный указатель на btConvexHullShape
  4.          btVector3 a,b;
  5.          polyshape->getEdge&;i,a,b&;;
  6.          btVector3 wa = worldTransform * a;
  7.          btVector3 wb = worldTransform * b;
  8.          getDebugDrawer&;&;->drawLine&;wa,wb,color&;;
  9.      &;
  10. //...
btConvexHullShape.cpp
  1. int btConvexHullShape::getNumEdges&;&; const
  2.         return m_unscaledPoints.size&;&;;
  3.  
  4. void btConvexHullShape::getEdge&;int i,btVector3& pa,btVector3& pb&; const
  5.  
  6.         int index0 = i%m_unscaledPoints.size&;&;;
  7.         int index1 = &;i+1&;%m_unscaledPoints.size&;&;;
  8.         pa = getScaledPoint&;index0&;;
  9.         pb = getScaledPoint&;index1&;;

Такой способ явно не отрисует все возможные грани у объекта. Поэтому хотелось бы более адекватный способ, желательно уже реализованный гделибо Smile

Плюс, может еще подскажет кто еще по поводу того

  • В btConvexTriangleMeshShape есть комент типа "The btConvexTriangleMeshShape is a convex hull of a triangle mesh, but the performance is not as good as btConvexHullShape", но btConvexTriangleMeshShape больше преспособлен для конвертации из стандартного меша и обратно. Соотвественно может кто знает насколько ошутимая будет просадка по перфомансу если вместо btConvexHullShape везде юзать btConvexTriangleMeshShape?
  • В реализации впухлых фигур (btBvhTriangleMeshShape, btStaticPlaneShape и т.д.) говориться о том что они "for non-moving (static) concave shapes" - это значит что тела с такими шейпами после добавления в мир вообще нельзя передвигать из вне, или просто они являются статическими и не двигаются при столкновении с другими нестатическими телами?
Последняя правка: вт, 07/05/2013 - 23:20
Submitted by Victor on

Комментарии

btConvexTriangleMeshShape очевидно более "дорогой" shape, в любом физ.движке. Насколько "везде юзать" не знаю, но десяток-другой таких обхектов на сотню-другую треугольников иметь не проблема. Другой вопрос зачем — т.е. обычно обычных shape'ов (бокс,капсула) достаточно.

btBvhTriangleMeshShape можно двигать, но операция перемещения доргая (нужно дерево пересчитывать), т.е. в каждом кадре перемещать десятки таких объектов — идея не очень хорошая; такие штуки типично для статической части мира используются.

Как двигаются/не-двигаются объекты это не к щейпам, это тип btCollisionObject -- динамик, кинематик, статик.

Расчёт convex-hull в буллете есть, я просто не юзал; недавно кстати добавляли всякие новые прикольные алгоритмы.

В дебажном рисовании я как то не вижу особых странностей — по умаолчанию всё просто линиями рисуется.

Submitted by BLK Dragon on
BLK Dragon wrote:

btConvexTriangleMeshShape очевидно более "дорогой" shape, в любом физ.движке. Насколько "везде юзать" не знаю, но десяток-другой таких обхектов на сотню-другую треугольников иметь не проблема. Другой вопрос зачем — т.е. обычно обычных shape'ов (бокс,капсула) достаточно.

Про примитивы это понятно. Вопрос в том что если btConvexTriangleMeshShape юзать везде где может юзаться btConvexHullShape вместо него, то сильно ли будет заметна разница в производительности?

BLK Dragon wrote:

btBvhTriangleMeshShape можно двигать, но операция перемещения доргая (нужно дерево пересчитывать), т.е. в каждом кадре перемещать десятки таких объектов — идея не очень хорошая; такие штуки типично для статической части мира используются.

Как двигаются/не-двигаются объекты это не к щейпам, это тип btCollisionObject -- динамик, кинематик, статик.

Собственно вопрос и был в том что значит "for non-moving (static) concave shapes" и можно ли двигать btCollisionObject у которых шейпы заданы скажем статик-плейном или btBvhTriangleMeshShap? Про пересчет не понял - просмотрел код булета, там генерация дерева вызывается вроде только при создании объекта.

BLK Dragon wrote:
Расчёт convex-hull в буллете есть, я просто не юзал; недавно кстати добавляли всякие новые прикольные алгоритмы.

В дебажном рисовании я как то не вижу особых странностей — по умаолчанию всё просто линиями рисуется.

Странность заключается в том что всегда рисуется n рёбер, где n - количество точек задающих выпухлую область. Очевидно же что в общем случае ребер у фигуры будет больше чем n, т.е. не все ребра отрисуются в дебажном рендере.

 
Последняя правка: ср, 17/04/2013 - 01:33
Submitted by Victor on
Quote:

Про примитивы это понятно. Вопрос в том что если btConvexTriangleMeshShape юзать везде где может юзаться btConvexHullShape вместо него, то сильно ли будет заметна разница в производительности?

Зависит от количества и сложности объектов, как всегда; лучше так не делать.

Quote:

можно ли двигать btCollisionObject 

Всё можно, последствия разные. Двигать (перемещать вызовами setTransform итп) каждый кадр весьма нежелательно (и непонятно зачем нужно вообще) ибо ломается кеш бродфазы и всякое такое. Поставить один раз или изредка плдвигать — не проблема.

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

Submitted by BLK Dragon on

Вообщем разобрался - LinearMath/btConvexHullComputer.h с помощью него можно сгенерить меш по облаку точек. Интересно почему они не используют его нигде в исходниках (т.е. используют но только в коде который помечен как эксперементальный и отключен по дефолту...)

Столкнулся счас со следующей засадой - есть статическая поверхность заданая через btBvhTriangleMeshShape на нее падает btConvexHullShape... и пролетает на сквозь слегка подрыгавшись в момент контакта. Если btConvexHullShape заменить на btSphereShape, то сфера замечательно преземляется и катиться. А вот как заставить btConvexHullShape нормально колизить. Пробовал изменять Margin и включать CCD, но так ничего толкового и не получилось... Wallkiller

Последняя правка: пт, 19/04/2013 - 03:08
Submitted by Victor on
Quote:

Вообщем разобрался - LinearMath/btConvexHullComputer.h с помощью него можно сгенерить меш по облаку точек. Интересно почему они не используют его нигде в исходниках

Эм, а зачем его использовать в исходниках?.. Ну т.е. генерация оболочки — операция оффлайновая, в рантайме каждый раз это проделывать не нужно. В демках/тестах наверное где-то и используется, а так при создании btConvexHullShape готовый набор точек указать и всё.

Про пролетание насквозь лучше почитать форумы буллета — ну там типовые нубские ошибки.

Я ешё помню отключал SSE ибо при сборке с ним были какие то странные проблемы в рантайме (в btScalar.h закомментил кусок с BT_USE_SSE).

Submitted by BLK Dragon on
BLK Dragon wrote:
Про пролетание насквозь лучше почитать форумы буллета — ну там типовые нубские ошибки.

Собственно на всех форумах которые нашел и говорится что мол подкрутите Margin, включите CCD или измените разрешение таймстэмпа, на не которых еще говориться что в булете вообще Bvh-тримеш кроме как с примитивами больше ни с чем нормально не колизится. И еще остается попробовать заюзать GImpact может с ним прокатит...

Последняя правка: пт, 19/04/2013 - 14:33
Submitted by Victor on
Quote:

булете вообще Bvh-тримеш кроме как с примитивами больше ни с чем нормально не колизится 

Да ну бред какой, у меня второй тест физики как раз с бросанием на тримеш боксов и конвекс-хуллов -- нормально работает на всех платформах, в многопоточном режиме тоже.

Пролетание насквозь это явно что-то совсем не так сделал.

Submitted by BLK Dragon on

Да, и попробуй таки скомпилить буллет с отключенным BT_USE_SSE.

Я посмотрел по истории в перфорсе, там комент к сабмиту "disabled SSE in Bullet2 on win32 (due to strange glitches in some cases)". Вполне может быть оно.

Submitted by BLK Dragon on
BLK Dragon wrote:

Да, и попробуй таки скомпилить буллет с отключенным BT_USE_SSE.

У меня билд с BT_USE_DOUBLE_PRECISION, а с ним sse вродебы отключено.

Submitted by Victor on
BLK Dragon wrote:
 у меня второй тест физики как раз с бросанием на тримеш боксов и конвекс-хуллов -- нормально работает на всех платформах, в многопоточном режиме тоже.

А какую версию булета кстати используешь?

Submitted by Victor on
Quote:

А какую версию булета кстати используешь?

2.81 rev2613, чуть-чуть модифицированную

Submitted by BLK Dragon on

Да странный глюк с физикой, при установке массы в 10 едениц работает нормально в 100 и более чудеса, пролетает на сквозь, причём в момент касания дёргается как паралитичный. *whitevoid_2*

Submitted by Relyer on
Quote:

Да странный глюк с физикой, при установке массы в 10 едениц работает нормально в 100 и более чудеса, пролетает на сквозь, причём в момент касания дёргается как паралитичный. Whitevoid  2

Такие аномалии обычно получаются при попытках использовать объекты с большой (порядка 100 раз) разницей в массе/размере, типа столкнуть дом и теннисный мяч. Даже вот бутылку (капсулу с радиусом 0.1м) уронить тримеш из трегольников 5-10м размера — ролучится не очень здорово (нестабильность, по крайней мере на шаге 1/60сек). Нужно просто так не делать — как и советуют в доках.

Submitted by BLK Dragon on

Да и не только в Bullet. Ловил такие ситуации еще в box2d когда-то. Как и было сказано выше - приходилось выравнивать соотношение размеров, масс, кабы не кидать слона на мышь - результат и без физ.движка в голове расчитать можно Smile

Submitted by MaxImuS on
Quote:

Да и не только в Bullet. Ловил такие ситуации еще в box2d когда-то. Как и было сказано выше - приходилось выравнивать соотношение размеров, масс, кабы не кидать слона на мышь - результат и без физ.движка в голове расчитать можно

Box2d это того же автора что и Bullet, нюансы поэтому похожи. С ODE, кстати было ещё хуже — помню на PSP проекте солвер не мог удержать даже абсолютно жёсткие joint'ы в определённых ситуациах.

С размерами, на самом деле, не очень очевидный нюанс. Я наступил, когда понадобилось делать всякий мелкий физический мусор, который можно пинать ногами — пришлось сделать в физ.мире поддержку scale, т.е. объекты в физ.мире в 2-3 раза больше чем в визуальном.

Submitted by BLK Dragon on
BLK Dragon wrote:
Такие аномалии обычно получаются при попытках использовать объекты с большой (порядка 100 раз) разницей в массе/размере, типа столкнуть дом и теннисный мяч. Даже вот бутылку (капсулу с радиусом 0.1м) уронить тримеш из трегольников 5-10м размера — ролучится не очень здорово (нестабильность, по крайней мере на шаге 1/60сек). Нужно просто так не делать — как и советуют в доках.

Тримеш статический, т.е. масса = 0. Как тогда замаделить что по земле едет танк? или танк будет весить 10 грам...

Submitted by Victor on
Quote:

Тримеш статический, т.е. масса = 0. Как тогда замаделить что по земле едет танк? или танк будет весить 10 грам...

Вообще-то танк, как персонаж, скорее всего будет кинематическим объектом и ему масса, соответственно, не нужна. Это хлам который танк будет давить нужно моделить.

Я надеюсь, ты всеръёз не думаешь, что в каком-нить мире танков эти самые танки честно физично симулируются?..

Submitted by BLK Dragon on

Разобрались. Как выяснилось булет очень чувствителен к матрице инерции - и если задавать числа от балды (у нас было [1,1,1]) - то объекты пролетают друг сквозь друга.

А я то всю жизнь считал что матрица инерции влиять должна только на то - на сколько сложно объект раскрутить или затормозить вращение вокруг той или иной оси и на линейное передвижение а тем более на колизиии вообще никак сказываться не должна... А тут вот как оказалось.

Последняя правка: пн, 06/05/2013 - 18:38
Submitted by Victor on

О. Кто бы мог подумать. Я то всю дорогу вычислял тензор инерции по shape'у (calculateLocalInertia) — это как бы логично.

На коллизии тензор инерции вполне себе влияет — collision response то не магическим образом происходит, а очень даже через force/torque. Т.е. если ты не бросаешь идеальный бокс на идеальную плоскость идеально перепендикулярно, то collision response, в-основном, будет вращательным.

На самом деле на форумах буллета есть тред про типичные идиотские ошибки, тензор инерции от балды там вроде был.

Submitted by BLK Dragon on
BLK Dragon wrote:

вычислял тензор инерции по shape'у (calculateLocalInertia)

Т.е. получается в булете нельзя задать чтоб объект по одной оси вращался труднее чем по другой, при этом не изменяя его геометрической формы?

Последняя правка: вс, 12/05/2013 - 17:17
Submitted by Victor on
Victor wrote:
BLK Dragon wrote:

вычислял тензор инерции по shape'у (calculateLocalInertia)

Т.е. получается в булете нельзя задать чтоб объект по одной оси вращался труднее чем по другой, при этом не изменяя его геометрической формы?

Почему же — setAngularFactor; с тензором инерции не связано вроде никак.

Submitted by BLK Dragon on
BLK Dragon wrote:

Почему же — setAngularFactor; с тензором инерции не связано вроде никак.

Ясно.

Еще одни вопрос - для управления персонажем использовал btKinematicCharacterController или писал чтото свое?

Submitted by Victor on
Victor wrote:
BLK Dragon wrote:

Почему же — setAngularFactor; с тензором инерции не связано вроде никак.

Ясно.

Еще одни вопрос - для управления персонажем использовал btKinematicCharacterController или писал чтото свое?

Всегда своё. Проекты все разные, требования/желания тоже разные.

В драконе, например, персонаж это ригид-боди которое силами двигают (столкновения/взрывы имульсами/торками), angular-factor кстати занулён по горизонтальным осяи чтобы набок не заваливались. В одном текущем проекте что-то похожее на кинематик-контроллер, там физичность не нужна.

В btKinematicCharacterController народ вечно жалуется на всякие приколы. Его можно глядеть как референс — как фантомами (ghost object) пользоваться и т.п.

Submitted by BLK Dragon on

GameDev.by