Комментарии 9
Принцип на котором построен пускай и простенький, но уже движок, содержит фундаментальный изъян. Дело в том, что две фазы слиты в одну: поиск взаимодействующих объектов и применения к ним воздействия (метод collidecell).
Проиллюстрирую проблему на мысленном эксперименте. Есть три шара A, B и C. Шар A и B до момента разрешения коллизий пересекаются друг с другом. C находится в свободном состоянии. После обнаружения коллизии A и B, и ёё разрешения может оказаться, что теперь A или B сталкивается с C. Хотя изначально этой коллизии не было. И это проблема. Причём результат ещё и зависит от того, в каком порядке мы обходим объекты: A -> B -> C или C -> B -> A.
Обычно предлагают две фазы разделять: сначала мы считаем равнодействующую сил для каждой частицы по исходным данным, а уже потом, зная силы, высчитываем ускорения и применяем нужный метод интегрирования. Когда мы расчитываем равнодействующую сил, нам уже не важен порядок обхода.
Вообще, есть ну очень хороший и доступный материал от Карнеги-Меллона, рекомендуемый к ознакомлению.
https://www.cs.cmu.edu/~baraff/sigcourse/
То что я описал выше подробно описано в лекциях Differential Equation Basics и Particle Dynamics.
Там есть и про идеальные связи, которые вы пытаетеесь сделать. Лекция Constrained Dynamics.
Но ведь автор производит вычисления итеративно, причём несколько раз за кадр. Правильно ли я понимаю, что с увеличением количества итераций и, соответственно, с уменьшением dt эта проблема также будет "уменьшаться"?
Ну да. Мы можем рассматривать каждую пару как отдельное линейное уравнение, а всю систему как СЛАУ. Тогда последовательное решение каждой коллизии в несколько проходов будет эквивалентно методу итераций для решения СЛАУ.
Но предполагаю, что tony-space предлагает что-то более оптимальное.
В физических движках для разрешения коллизий внутри композитных объектов и между ними обычно используются различные солверы с различными алгоритмами под капотом. В данном случае у автора простая стратегия - просчитывать только попарные взаимодействия простых объектов, но делать это итеративно много раз за кадр, и оно дает удовлетворительный результат, но это далеко неидеальное решение. Следующим шагом, например, можно объединять все связанные объекты в одну структуру и считать ее движение и коллизию как целого, но тут уже начнется нормальная кинематика с расчетом центра массы конструкции, суммарных линейных и вращательных моментов и т.д.
Спасибо за хороший источник, обязательно попробую.
Решил написать про метод Верле именно из-за его простоты, с оговоркой в начале первой части («некое подобие физического движка»)
Кстати, есть даже реализация на GPU. Не забудьте поиграть с масштабом (ползунок сверху) и физикой (кнопки справа)
https://www.shadertoy.com/view/tstSz7
останится проверить
останЕтся
расскажи, как считать коллизию на GPU
Это сложно, люди научные статьи на эту тему пишут. Вот, например:
Или вот, вроде как здесь более понятным языком написано
https://docs.taichi-lang.org/blog/acclerate-collision-detection-with-taichi
Верле: разрешаем коллизии (часть 2 — сетка, квадратики)