Цитата:
Сообщение от [CCCP] Monster
При загрузке модели объекта расчитывать обрамляющий параллелепипед. Bounding Box то бишь. И сравнивать сначала его, а потом уже физическую модель. Что это даст? При обработке тех объектов, которые не столкнулись, нужно обработать всего лишь 8 точек для каждого.
|
Это ясно, спасибо. Меня интересует само решение вопроса об обработке столкновений. Уравненице там ой-ой-ой получается. И, кстати, кто сказал, что у меня нет собственного решения?
Мне интересно послушать, что скажут остальные. Всё-таки тут у нас практика.
Цитата:
Сообщение от [CCCP] Monster
Есть еще один финт. Основан на запоминании длины поливинки диагонали бокса. Эта половинка - тоже, что радиус сферы, описанной вокруг модельки. Теперь отсеем те объекты. что не соприкасаются сферами. Оставшиеся посчитаем. А уж посчитать 3-4 одновременно сталкивающихся объекта из оставшихся можно запросто.
|
Это всё ясно! Оптимизировать рассчёты можно кучей способов, меня интересует, как их проводить-то будем, неважно насколько оптимизированные! Пусть у нас хоть останутся те линии, с которыми точно есть столкновение - проблема от этого не исчезнет. Время в компьютере, ясное дело, дискретное - стало быть нужно либо фиксированными порциями и двигать машину, проверяя пересечения; либо же решать сложные нелинейные уравнения, чтобы определить момент пересечения.
Кстати, один из вариантов, пришедший мне на ум - организовать в месте предполагаемого столкновения де-факто воксельный движок, т.е. заменить часть граний-стен препятствий на стоящие друг за другом сферы, с которыми и рассчитывать столкновение (можно и на кубики, но сферы проще). Такая "область вокселизации" будет двигаться по мере того, как машина будет ехать от препятствия к препятствию.
P.S. Кстати, не забывай, что гонки у нас 2D в принципе, а потому давай лучше говорить не о параллелепипедах и сферах, а о прямоугольниках и окружностях, так правильнее будет.