Comments 8
(зря написал)
+1
Во-первых, вы забыли очень важный множитель в формуле Эйлера — dt (он же h – шаг). Без него в играх будет получаться треш из-за нефиксированной скорости обработки кадров.
Во-вторых, ваш метод не гарантирует, что персонаж вообще попадет в цель (если максимальная скорость его будет больше, чем расстояние до цели, а текущая — перпендикулярно — он будет вечно вращаться вокруг нее)
В-третьих, вы никак не оговариваете максимальную скорость вращения (точнее, угловая скорость), а это достаточно заметная величина, имеющая под собой вполне разумные физические основания, в отличии от вектора steering.
Итого — я бы не рекомендовал использовать этот метод. Можно же поступить гораздо проще, описывая вектор скорости движения как скаляр и угол курса (к примеру), и уже менять угол курса, исходя из максимальной угловой скорости.
Например, можно просто поворачивать на цель с максимальной угловой скоростью, пока ваш курс не будет совпадать с направлением на цель. Тогда ваша траектория будет представлять из себя окружность + прямая, где радиус окружности известен. Кроме того, этот способ управления оптимальный в плане наименьшего пути (если у вас есть текущая скорость и вы можете попасть в цель по прямой), это доказано, хотя и так очевидно. Ровно так же и уходить от препятствия.
Во-вторых, ваш метод не гарантирует, что персонаж вообще попадет в цель (если максимальная скорость его будет больше, чем расстояние до цели, а текущая — перпендикулярно — он будет вечно вращаться вокруг нее)
В-третьих, вы никак не оговариваете максимальную скорость вращения (точнее, угловая скорость), а это достаточно заметная величина, имеющая под собой вполне разумные физические основания, в отличии от вектора steering.
Итого — я бы не рекомендовал использовать этот метод. Можно же поступить гораздо проще, описывая вектор скорости движения как скаляр и угол курса (к примеру), и уже менять угол курса, исходя из максимальной угловой скорости.
Например, можно просто поворачивать на цель с максимальной угловой скоростью, пока ваш курс не будет совпадать с направлением на цель. Тогда ваша траектория будет представлять из себя окружность + прямая, где радиус окружности известен. Кроме того, этот способ управления оптимальный в плане наименьшего пути (если у вас есть текущая скорость и вы можете попасть в цель по прямой), это доказано, хотя и так очевидно. Ровно так же и уходить от препятствия.
0
В статье видимо не хватает силы трения
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);
0
Спасибо за отзыв.
По поводу то, что персонаж не попадет в цель, можно делать очень простую вещь, выбрать определённый радиус, и если расстояние от юнита до цели меньше этого радиуса — пропорционально уменьшать скорость. Примерно так:
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
}
По поводу угловой скорости, её также можно учитывать, когда будете рассчитывать угол между текущим положением и тем, которое рассчитали. Да и особенности реализации физики игрового мира лежит на разработчике, и от него зависит будет он учитывать угловую скорость, силу трения и пр.
0
Вы не поверите, но таким образом вы так же никогда не попадете в цель (задача про Ахиллеса и черепаху. Суть в том, что вы будете асимптотически приближаться, но никогда не приблизитесь (упретесь в машинный ноль в вычислениях, в предел в математике). Решается вводом эпсилона, однако если радиус замедления достаточно большой — это плохая идея).
Тем не менее, способов решить указанные проблемы действительно несколько. У предложенного мной так же есть проблемы с устойчивостью (почти наверное в моем случае объект будет вечно колебаться в пределах некого эпселона направления на цель. А с ПИДаим в играх никто заморачиваться не будет). Ждем следующих статей!
Тем не менее, способов решить указанные проблемы действительно несколько. У предложенного мной так же есть проблемы с устойчивостью (почти наверное в моем случае объект будет вечно колебаться в пределах некого эпселона направления на цель. А с ПИДаим в играх никто заморачиваться не будет). Ждем следующих статей!
0
Это ж перевод. По-моему, там в следующей главе как раз про замедление при прибытии в нужную точку будет.
0
Полистал я оригинал. Понял одно — мои мозги безвозвратно повернуты на авиации, где, в общем то, замедлиться до нуля не так просто, тем более менять, стоя на месте свой курс (да, да, я знаю про вертолеты, но они не входят в сферу моих интересов).
В общем то, это выглядит неплохо (на интерактивных демках), если представить, что ты управляешь живыми существами. Хотя и тут есть неестественные проблемы, как почти отсутствующее ползание на месте и только моментальный поворот рядом с целью, так себя никто не ведет. И совсем ужасно выглядит следование по точкам, даже со сглаживанием, если нужна большая точность. Но если говорить о средствах передвижения, тем более самолетах (что мне первое почему-то приходит в голову), этот способ не канает.
В общем то, это выглядит неплохо (на интерактивных демках), если представить, что ты управляешь живыми существами. Хотя и тут есть неестественные проблемы, как почти отсутствующее ползание на месте и только моментальный поворот рядом с целью, так себя никто не ведет. И совсем ужасно выглядит следование по точкам, даже со сглаживанием, если нужна большая точность. Но если говорить о средствах передвижения, тем более самолетах (что мне первое почему-то приходит в голову), этот способ не канает.
0
Sign up to leave a comment.
Steering behavior. Виды изменения направления движения персонажа на ходу