Добрый день

Уже неск лет используем движок Bullet (физика твердого тела). Пользователь задает 3D объекты, жмет бубочку "симуляция", и объекты начинают падать, летать, сталкиваться, отскакивать - все очень здорово. Но аппетиты растут - и вот потребовалась поддержка сцен с реально большим кол-вом объектов: 100K и более.

Ну что, написал я генератор и задал ему испускать чайники. Первые 50 фреймов - полет нормальный. Не real-time конечно, но сносно (еще мало объектов). Следующие 20 - уже минут 20. потом уже 40, потом ...ну мне машина нужна была работать, не дождался. В общем затык уже на 300 чайниках  Понятно что это объект сложный, на простых (сфера, кубик) будет пошустрее, но все равно хотя бы до 100K далеко как до небес. А юзвери губы раскатали уже и на мульен 

На форум тамошний я конечно зашел и спросил - ну обычный рез-т, т.е. нулевой. Точно такой же был для всех моих попыток в прошлом. Формально ответы были, типа "у меня тоже эта проблема" или "капитаны очевидность", но по существу там ничего не почерпнуть. Документация разумеется про/пере читана.

"Ну вот откуда я могу знать что делать? Это же Bullet, физика. Вот если бы я этим занимался...". Думается что вопрос все-таки ближе к программированию. Берутся open-source, интегрируются в приложение, и (иногда) даже успешно работают. А через какое-то время раз - и проблема, и хз что делать.

Как бы Вы поступили в таком случае?

Спасибо

Я с буллетом совсем немного работал, он меня не особо впечатлил честно говоря. Но тут я не спец, так что может сам накосячил. В любом случае, есть же уже аппаратная поддержка физики, например, у NVidia. Как насчет их решений?
Опять же, я в этой области совсем не спец, так что советовать ничего не могу, только предлагать.

А я что, спец? Я же не стал физиком от того что "прикрутил" готовый движок. Ну, допустим, наняли физика - и что он должен делать? В том-то и дело что эти проблемы ложатся на программиста.

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

В общем виде это предложение "Давайте возьмем др движок". Не исключено что в конце-концов так и придется поступить. Но это весьма затратно в любом случае (как замены так и "2 движка")

А давайте чуть "сменим декорации" - предположим тормозит QGraphicsScene c 500K QGraphicsItem, не думаю что такое предположение слишком уж смело/фантастично. Тогда Ваш совет выглядел бы так
Получилась, на мой взгляд, полная фигня Легковесность и, Вы уж простите, хвастливость такого подхода бросаются в глаза. А что же с тоннами написанного Qt кода? А если его оставить то как срастить 2 фреймворка? Да, и сколько времени Вам понадобится на изучение "нескольких фреймворков"? Тут люди годами грызут букварь, а Вы вот так "взял и выяснил"

Отображение мое, результаты симуляции автоматически записываются и могут "проигрываться" отдельно, уже без запуска движка. Время показа кадра не превышает 0.5 сек. Тоже не блеск, но сейчас это не актуально.

[OFF]
"Дифуры"..... еще в политехе были НИРС и УИРС (какая-то там "Работа Студентов") - но все неизменно сводилось к одному: выходил докладчик и рисовал эти самые "дифуры" Мои попытки "вникнуть" имели примерно тот же успех как с темплейтами - да, что-то понял, но быстро устаю и "теряю нить". Видимо за истекшие много лет ничего не изменилось, и по-прежнему долбятся "дифуры" 
[/OFF]

Так вот, никаких (аналитических) дифуров в движке нет, а есть тупой, но бессмертный метод Эйлера. т.е. делаем шажок, проверяем граничные условия и.т.д. Сначала собираются все "contact pair(s)", т.е. 2 объекта находятся на критическом расстоянии и, вероятно, должны оттолкнуться. Профайлер показывает что время жрется на сборку контактов и их resolving. Ну и это еще начало "большого пути", там еще много чего (разрешение связок - constraint) - но до этого дело просто не дошло.

Неоптимальные места есть в любой программе, НО. Я вам так скажу, десктопный процессор сбособен обработать тысяч 200 сообщений в секунду (если эта обработка хоть что-то делает, например, пробежаться по всем полям и сложить сообщения в мапу). И то после определенных оптимизаций. Чтобы ещё увеличить производительность, надо отказаться от генерик кода и писать частные случаи - напирмер, мы читаем только 10е и 11е поля.
3д объект вещь несколько болеее сложная, чем сообщение с 20ю полями. Так что делайте вывыводы.
ЗЫ: я не говорю, что не надо оптимизировать, но есть некий предел, выше которого не перепрыгнешь.

Ну я это и имел в виду..Конечно немного странно, что в булете используют Эйлеровский метод, поскольку он самый неустойчивый.. Рунге-Кутта 4, как уже заметили, гораздо лучше, хоть и медленее.. (кстатии, это всё есть в бусте)

 
Но коли дело в отображалке, в этом механизме, то и думать нужно в этом направлении.. Что то упрощать, где то схитрить и т.д. во многом зависит от предметной части..
А чего Вы ещё хотели услышать?  

Посмотрел видео http://www.youtube.com/watch?v=PfezSJB21vk: на сцене 10000 планочек симулируются 50 секунд/кадр.
Вряд-ли вы с булетом сможете получить даже для 10К объектов кадр в секунду.