Работа с Open Sources

[Igors]

Добрый день

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

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

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

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

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

Спасибо

[Bepec]

100к падающих, летающих, отскакивающих 3D объектов. Судя по всему, софт, который справлялся бы с такой задачей без лагов, заработал бы миллиарды, если не более.

PS Вам не кажется, что тут затык в ресурсах, а не в программе?

[Racheengel]

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

[Bepec]

Таки и я не спец, но интересовался этой темой давненько, года два-три назад. Более 5к объектов с физикой без тормозов создать я не смог.

PS 100к объектов сожрут любой ПК, за исключением суперкомпьютеров вроде ватсона. 

[Igors]

Опять же, я в этой области совсем не спец,

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

PS 100к объектов сожрут любой ПК,

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

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

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

[Racheengel]

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

[Igors]

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

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

В общем да - я бы тоже взял несколько фреймворков и выяснил, какой из них наиболее подходит для конкретной задачи. А баги везде будут, мы же не в Нарнии)

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

[m_ax]

Для начала хорошо бы выяснить причину лагов: либо это та часть движка, которая отвечает за математику (дифуры, фактически) не справляется с таким колическтвом объектов, либо это то, что ответственно за отображения всего это..

   

[Igors]

Для начала хорошо бы выяснить причину лагов: либо это та часть движка, которая отвечает за математику (дифуры, фактически) не справляется с таким колическтвом объектов, либо это то, что ответственно за отображения всего это..

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

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

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

[kuzulis]

но бессмертный метод Эйлера

Лучше же Рунге-Кута 4-го порядка.

[Авварон]

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

[Bepec]

Моё мнение, что 100к объектов в реалтайме без тормозов  на текущих мощностях вы не сделаете.

PS хотя на мой взгляд, если провести рассчёты заранее, вполне возможно.

[m_ax]

Так вот, никаких (аналитических) дифуров в движке нет, а есть тупой, но бессмертный метод Эйлера. т.е. делаем шажок, проверяем граничные условия и.т.д.

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

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

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

[Igors]

Моё мнение, что 100к объектов в реалтайме без тормозов  на текущих мощностях вы не сделаете.

Ну "реалтайм" задача и не стоит, нужно получить скорость с которой время симуляции "приемлемо". Напр порядка секунды (на расчет 1 кадра) при 100K объектов. Это все равно не быстро, т.к. кадров может быть много. Но худо-бедно работать можно.

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

С эрудицией и умением поддержать разговор все нормально Но "перевод Bullet на дуст" как-то не привлекает..

Но коли дело в отображалке,

Наоборот, я только заметил что она могла быть и лучше - но дело совсем не в ней (см мой предыдущий пост)

А чего Вы ещё хотели услышать?  

Я удивлен что пока не услышал вопроса который, на мой взгляд, должен быть задан немедленно    Тем более что вопрос этот 100% программистский, к физике отношения не имеет

[Old]

Ну "реалтайм" задача и не стоит, нужно получить скорость с которой время симуляции "приемлемо". Напр порядка секунды (на расчет 1 кадра) при 100K объектов. Это все равно не быстро, т.к. кадров может быть много. Но худо-бедно работать можно.

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