Комментарии
8
(зря написал)
Во-первых, вы забыли очень важный множитель в формуле Эйлера — dt (он же h – шаг). Без него в играх будет получаться треш из-за нефиксированной скорости обработки кадров.
Во-вторых, ваш метод не гарантирует, что персонаж вообще попадет в цель (если максимальная скорость его будет больше, чем расстояние до цели, а текущая — перпендикулярно — он будет вечно вращаться вокруг нее)
В-третьих, вы никак не оговариваете максимальную скорость вращения (точнее, угловая скорость), а это достаточно заметная величина, имеющая под собой вполне разумные физические основания, в отличии от вектора steering.
Итого — я бы не рекомендовал использовать этот метод. Можно же поступить гораздо проще, описывая вектор скорости движения как скаляр и угол курса (к примеру), и уже менять угол курса, исходя из максимальной угловой скорости.
Например, можно просто поворачивать на цель с максимальной угловой скоростью, пока ваш курс не будет совпадать с направлением на цель. Тогда ваша траектория будет представлять из себя окружность + прямая, где радиус окружности известен. Кроме того, этот способ управления оптимальный в плане наименьшего пути (если у вас есть текущая скорость и вы можете попасть в цель по прямой), это доказано, хотя и так очевидно. Ровно так же и уходить от препятствия.
Во-вторых, ваш метод не гарантирует, что персонаж вообще попадет в цель (если максимальная скорость его будет больше, чем расстояние до цели, а текущая — перпендикулярно — он будет вечно вращаться вокруг нее)
В-третьих, вы никак не оговариваете максимальную скорость вращения (точнее, угловая скорость), а это достаточно заметная величина, имеющая под собой вполне разумные физические основания, в отличии от вектора steering.
Итого — я бы не рекомендовал использовать этот метод. Можно же поступить гораздо проще, описывая вектор скорости движения как скаляр и угол курса (к примеру), и уже менять угол курса, исходя из максимальной угловой скорости.
Например, можно просто поворачивать на цель с максимальной угловой скоростью, пока ваш курс не будет совпадать с направлением на цель. Тогда ваша траектория будет представлять из себя окружность + прямая, где радиус окружности известен. Кроме того, этот способ управления оптимальный в плане наименьшего пути (если у вас есть текущая скорость и вы можете попасть в цель по прямой), это доказано, хотя и так очевидно. Ровно так же и уходить от препятствия.
В статье видимо не хватает силы трения
Vector3d vector_friction = (vector_velocity / velocity_len) * -FrictionKoef * weight; //трение пусть зависит от массы
//vector_velocity / velocity_len — это нормализация направления
acceleration = (vector_trust + vector_friction) / weight; //вектор ускорения
//потом вычисляется вектор скорости
vector_velocity = vector_velocity + (acceleration * time_step);
//потом вычисляется следующее положение
vector_position = vector_position + (vector_velocity * time_step);
Vector3d vector_friction = (vector_velocity / velocity_len) * -FrictionKoef * weight; //трение пусть зависит от массы
//vector_velocity / velocity_len — это нормализация направления
acceleration = (vector_trust + vector_friction) / weight; //вектор ускорения
//потом вычисляется вектор скорости
vector_velocity = vector_velocity + (acceleration * time_step);
//потом вычисляется следующее положение
vector_position = vector_position + (vector_velocity * time_step);
Спасибо за отзыв.
По поводу то, что персонаж не попадет в цель, можно делать очень простую вещь, выбрать определённый радиус, и если расстояние от юнита до цели меньше этого радиуса — пропорционально уменьшать скорость. Примерно так:
if (distance < slowingRadius) { // юнит внутри зоны замедления
desired_velocity = normalize(desired_velocity) * max_velocity * (distance / slowingRadius)
} else {
desired_velocity = normalize(desired_velocity) * max_velocity
}
По поводу угловой скорости, её также можно учитывать, когда будете рассчитывать угол между текущим положением и тем, которое рассчитали. Да и особенности реализации физики игрового мира лежит на разработчике, и от него зависит будет он учитывать угловую скорость, силу трения и пр.
По поводу то, что персонаж не попадет в цель, можно делать очень простую вещь, выбрать определённый радиус, и если расстояние от юнита до цели меньше этого радиуса — пропорционально уменьшать скорость. Примерно так:
if (distance < slowingRadius) { // юнит внутри зоны замедления
desired_velocity = normalize(desired_velocity) * max_velocity * (distance / slowingRadius)
} else {
desired_velocity = normalize(desired_velocity) * max_velocity
}
По поводу угловой скорости, её также можно учитывать, когда будете рассчитывать угол между текущим положением и тем, которое рассчитали. Да и особенности реализации физики игрового мира лежит на разработчике, и от него зависит будет он учитывать угловую скорость, силу трения и пр.
Вы не поверите, но таким образом вы так же никогда не попадете в цель (задача про Ахиллеса и черепаху. Суть в том, что вы будете асимптотически приближаться, но никогда не приблизитесь (упретесь в машинный ноль в вычислениях, в предел в математике). Решается вводом эпсилона, однако если радиус замедления достаточно большой — это плохая идея).
Тем не менее, способов решить указанные проблемы действительно несколько. У предложенного мной так же есть проблемы с устойчивостью (почти наверное в моем случае объект будет вечно колебаться в пределах некого эпселона направления на цель. А с ПИДаим в играх никто заморачиваться не будет). Ждем следующих статей!
Тем не менее, способов решить указанные проблемы действительно несколько. У предложенного мной так же есть проблемы с устойчивостью (почти наверное в моем случае объект будет вечно колебаться в пределах некого эпселона направления на цель. А с ПИДаим в играх никто заморачиваться не будет). Ждем следующих статей!
Это ж перевод. По-моему, там в следующей главе как раз про замедление при прибытии в нужную точку будет.
Полистал я оригинал. Понял одно — мои мозги безвозвратно повернуты на авиации, где, в общем то, замедлиться до нуля не так просто, тем более менять, стоя на месте свой курс (да, да, я знаю про вертолеты, но они не входят в сферу моих интересов).
В общем то, это выглядит неплохо (на интерактивных демках), если представить, что ты управляешь живыми существами. Хотя и тут есть неестественные проблемы, как почти отсутствующее ползание на месте и только моментальный поворот рядом с целью, так себя никто не ведет. И совсем ужасно выглядит следование по точкам, даже со сглаживанием, если нужна большая точность. Но если говорить о средствах передвижения, тем более самолетах (что мне первое почему-то приходит в голову), этот способ не канает.
В общем то, это выглядит неплохо (на интерактивных демках), если представить, что ты управляешь живыми существами. Хотя и тут есть неестественные проблемы, как почти отсутствующее ползание на месте и только моментальный поворот рядом с целью, так себя никто не ведет. И совсем ужасно выглядит следование по точкам, даже со сглаживанием, если нужна большая точность. Но если говорить о средствах передвижения, тем более самолетах (что мне первое почему-то приходит в голову), этот способ не канает.
Ну для авиации безусловно нужна намного более сложная физическая модель мира.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Steering behavior. Виды изменения направления движения персонажа на ходу