Обработка столкновений

[Kostia]

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

[Granus]

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

[Kostia]

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

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

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

Опять же см. ссылки в посте #3
и еще пара полезных:
http://www.l1f.ru/dev/download/Advan...terPhysics.rar
http://demiart.ru/forum/index.php?showtopic=136990

[Granus]

Kostia, спасибо огромное.

[s-andriano]

Сообщение от Granus

s-andriano, видимо, не до конца Вас понимаю. Вы сильно критикуете многое из того, что здесь пишут. Опишите целиком, как, по-вашему, должно все это происходить, по полочкам.

Granus, видимо, Вы не до конца читаете сообщения. Прочитайте, пожалуйста, последнее предложение моего сообщения, непосредственно предшествующего тому, на которое я сейчас отвечаю.

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

По всей видимости, Вас интересует подход с непрерывным временем.
С моей точки зрения, если игра (либо вообще любой виртуальный мир) подразумевает физику (существуют логические игры, для которых физика не нужна в принципе, впрочем, как и такая категория как время), то время должно идти только непрерывно. В то же время любое численное моделирование возможно только при дискретном времени. Соответственно, необходимо нахождение компромисса.
Некоторым идеализированным компромиссом мог бы служить такой, в котором приращение времени в точности равно интервалу между событиями, которые необходимо учитывать. Например, времени между столкновением объектов.
Пусть у нас N объектов. Мы рассчитываем, когда должны произойти все возможные столкновения, выбираем из них ближайшее по времени и именно до этого момента и будет продолжаться наш шаг по времени. Шагнули. Определяем, когда произойдет следующее столкновение, делаем еще один шаг и т.д.
Если нас интересует только физическое моделирование, такой подход представляется оптимальным, но в случае, когда у нас требуется еще и отображение в реальном времени, он может вызвать серьезные трудности, минимум, по одной из двух причин (в том числе и по обеим сразу):
1. Шаг слишком велик - перемещения тел по экрану не выглядят плавными.
2. Шаг слишком мал, - на один кадр приходится слишком много шагов, в результате чего объем приходящихся на кадр вычислений оказывается неприемлемо большим - компьютер не успевает все обсчитать.
С первой "трудностью" бороться довольно легко - достаточно ограничить величину шага по времени.
Со второй - хуже. Приходится применять какие-либо хитрости для снижения объема вычислений. Например, вместо общего шага интегрирования вводить разные шаги для отдельных объектов или их групп. Как - это уже конкретные особенности задачи, которые нужно анализировать в каждом конкретном случае.

[Kostia]

1. Шаг слишком велик - перемещения тел по экрану не выглядят плавными.

1. Объекты столкнутся далеко в будущем. Комп сгорит считать.
2. При постоянном добавлении в систему новых объектов придется ВСЁ пересчитывать.

2. Шаг слишком мал, - на один кадр приходится слишком много шагов, в результате чего объем приходящихся на кадр вычислений оказывается неприемлемо большим - компьютер не успевает все обсчитать.

Объект лежит на другом объекте. Соприкосновения происходят постоянно, нужно обрабатывать трение...
Объекты являются связанными...
При моделирование воды...

Ограничения метода, Position-Based:

Разумеется, чудес не бывает и не бывает одновременно простого, быстрого и общего метода моделирования физики. За простоту реализации и широкий спектр моделируемых явлений position-based подход заплатил своё:

Любые попытки изменять шаг по времени до добра не доведут. Если оригинальная схема имеет второй порядок точности по времени, то использование нефиксированного шага сбрасывает порядок точности до первого. Если в игре не фиксированный fps, лучше вызывать физику не каждый кадр а, например, тогда, когда с момента предыдущего обновления физики прошло какое-то время, например, 1/50 секунды.
Метод вовсе не дружит с continuous collision detection. Если неаккуратно выбрать размеры или скорости тел, они могут безнаказанно пролетать друг через друга. Если избавиться от быстро летящих частиц нельзя, то можно попытаться обрабатывать их другим, не position-based подходом.

Эти ограничения естественны исключительно для чистого Position-Based подхода. Поэтому правильней использовать смешанные подходы.

[Beermonza]

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

[s-andriano]

Сообщение от Kostia

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

Ну да, так и есть.

[s-andriano]

Сообщение от Kostia

1. Объекты столкнутся далеко в будущем. Комп сгорит считать.

Это шутка такая?

2. При постоянном добавлении в систему новых объектов придется ВСЁ пересчитывать.

Разумеется.
А что, в каком-то другом случае придется пересчитывать не ВСЕ?

Поэтому правильней использовать смешанные подходы.

А вот с этим трудно не согласиться.

[Kostia]

Это шутка такая?

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

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

Разумеется.
А что, в каком-то другом случае придется пересчитывать не ВСЕ?

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

Второе, даже если время фиксированное, как вы собираетесь определять столкновения если объекты движутся по сложным траекториям и обладают сложной формой и вдобавок деформирующейся в полете. Единственный выход это фиксация шага времени(dt) и просчитывать состояние всей системы с данным шагом, проверять не нашлось ли столкновения, если нет, делаем t += dt, до тех пор пока не обнаружим столкновения или не кончится наш фиксированный интервал времени.
Естественно чем меньше этот фиксированный интервал времени, тем меньше ресурсов будет тратить компьютер, устремляем его в нуль...