Как предварительно рассчитать траектории в игре в бильярд (пул)?

Начните с дерева квадрантов и уменьшите интервал выборки. Однако если ваши бильярдные шары движутся так быстро, что проходят сквозь другие шары, вы неправильно моделируете игру. Вы когда-нибудь играли в бильярд, где шары ДЕЙСТВИТЕЛЬНО двигались так быстро?

В качестве альтернативы

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

Самый простой способ — просто использовать «наивный» подход с очень мелким шагом, но пока не анимировать шары.

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

Реализация выглядит примерно так: у вас есть параметризованный по времени метод для определения положения мяча (в текущее время T плюс переменное время V); по умолчанию указывается значение V, равное 1,0. При расчете обновленной позиции вы можете выполнить обнаружение столкновений; естественный артефакт обнаружения столкновений является дробным индикатором того, когда происходит столкновение. Если это произойдет, сбросьте свои позиции для текущей итерации и повторно отправьте все ходы с дробным V, затем повторите количество 1,0 - V.

Это работает на удивление хорошо и имеет то преимущество, что является относительно простой реализацией. Одной из проблем является то, что вам нужно достаточно мощности процессора, чтобы иметь возможность вычислять движения потенциально много раз в течение «естественного» временного интервала (т. е. одного кадра отображения и т. д.). Однако, поскольку этот тип вычислений довольно прост для современных процессоров, это не должно быть проблемой.

Я сделал что-то подобное много лет назад и описал движение шаров с положением как функцию времени. Используя этот метод, я смог найти точное время пересечения любых двух шаров. Каждый мяч сохранял приоритетную очередь с наименьшим временем пересечения в начале очереди, и очереди корректировались при возникновении столкновения. Это сработало очень хорошо и было довольно легко для первого паса, который не имел ускорения по мячу. Позже (с более сложной математикой) я также смог расширить его для работы с добавлением трения.

Главный недостаток этого метода заключается в том, что вычисления, как правило, происходят сразу, а затем какое-то время ничего не происходит, вместо того, чтобы выполнять небольшую работу в каждом кадре. Это означает, что ваша частота кадров не будет стабильной. Это не вызвало каких-либо заметных сбоев на оборудовании, которое я использовал 8 или около того лет назад. Даже на изломе или в странных, более или менее невозможных случаях, таких как несколько мячей, точно соприкасающихся и движущихся в одном направлении, когда они ударяются о стену, будет провал в частоте кадров, но ничего заметного.