Unreal Engine 4
https://uengine.ru/forum/

Можно ли сделать A* pathfinding на БП?
https://uengine.ru/forum/viewtopic.php?f=3&t=75243
Страница 3 из 3

Автор:  antokog [ 03 авг 2020, 17:59 ]
Заголовок сообщения:  Re:

icms писал(а):
Полностью согласен с предыдущим комментарием. Осталось выяснить какой формы и какого размера преграды. antokog а дайте нам схематическое изображение вашего уровня(естественно его части) но масштабы что бы были реальными.

Уровень состоит из таких тайл сетов (около 10 на 1 уровень) на 1 плитке помещается 2 нпс в ширину и 2 в высоту. Конечно им не нужно ходить по всей карте, но на половину или треть одного тайл сета надо. Совсем лабиринта не будет, но приблизительно такие штуки проходить надо:

ИзображениеИзображение
ИзображениеИзображение

Автор:  icms [ 03 авг 2020, 21:23 ]
Заголовок сообщения: 

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

Автор:  Agny [ 04 авг 2020, 02:56 ]
Заголовок сообщения:  Re:

icms писал(а):
тем более с математикой нужно ещё учитывать размер мухи, чего помоему в расчёте небыло.


Как это не было?

Цитата:
Вторые стороны - это радиус капсулы персонажа, которого нужно нам обойти. Обычно берется больше.


Берется больше с учетом размеры мухи, которая обходит. Т.е прибавляешь радиус мухи которая обходит.

antokog писал(а):
Уровень состоит из таких тайл сетов (около 10 на 1 уровень) на 1 плитке помещается 2 нпс в ширину и 2 в высоту.


Если из таких состоит в таком положении. Не под углом. Посчитать четыре waypoints, которые находятся по углам прямоугольника не сложно.
Напиши алгоритм поиска наименьшего и наибольшего значения координат всех точек прямоугольника.
От меньшего значения вычитай размеры мухи, а к большему прибавляй размеры мухи. Плюс с запасом ещё бери процентов на 30.

Автор:  Prytaleks [ 04 авг 2020, 06:21 ]
Заголовок сообщения: 

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

https://picua.org/images/2020/08/04/180 ... 303130.png

p.s. в 99% случаев у меня каст делается один раз на бегин плээ, затем есть - ссылка, и да бокстрэйсы сфер трэйсы использовать здесь удобнее, но в принципе все также как и с лайнтрэйсами, здесь будет в основном математика 3 класса, главное понимать что такое форвард вектор и ап вектор, и как их складывать и как прибавлять к ним.
А если нацелится на облет препятствий просто через вверх или низ, без построения пути на 5 и более точек , это все будет намного проще.

Автор:  antokog [ 04 авг 2020, 14:04 ]
Заголовок сообщения:  Re:

Prytaleks писал(а):
я бы трэйсы во все стороны пулял, как в циклах так и нет, мой алгоритм выглядел бы примерно так, но раза в 3-4 сложнее(что бы учесть все детали и оптимизировать), желтые и оранжевые трэйсы это те что в циклах, зеленый точки это вэйпоинтсы.
Такое количество итераций выполнится за тик вообще без какого либо ущерба(проводить функцию повторно по мере достижения мухи последнего вэйпоинтса в массиве или в другой ситуации), так же бы раз в секунду я бы кидал линию по направлению к персонажу, что бы знать когда выходить на финишную прямую.

https://picua.org/images/2020/08/04/180 ... 303130.png

p.s. в 99% случаев у меня каст делается один раз на бегин плээ, затем есть - ссылка, и да бокстрэйсы сфер трэйсы использовать здесь удобнее, но в принципе все также как и с лайнтрэйсами, здесь будет в основном математика 3 класса, главное понимать что такое форвард вектор и ап вектор, и как их складывать и как прибавлять к ним.
А если нацелится на облет препятствий просто через вверх или низ, без построения пути на 5 и более точек , это все будет намного проще.


Я примерно то же уже и сделал. Сначала я проверяю прямой путь, и, если его нет ищу обходной. Когда я его нахожу из массива векторов создаю сплайн, по которому потом лечу. Вот только мне не очень нравится как оно работает. Когда мои мухи летят друг к другу перпендикулярно, они врезаются и начинают танцевать вверх вниз, что с этим делать я еще не придумал... Помимо этого, когда они близко к препятствиям иногда они дергаются.
Итак вопрос: можно ли эту конструкцию исправить, или лучше сделать вообще по другому?
Прямой путь:
ИзображениеИзображение

ИзображениеИзображение

Обход:

ИзображениеИзображение

ИзображениеИзображение

ИзображениеИзображение

AngleArray:

ИзображениеИзображение

Автор:  Prytaleks [ 05 авг 2020, 11:10 ]
Заголовок сообщения: 

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

Автор:  Agny [ 05 авг 2020, 14:16 ]
Заголовок сообщения: 

Я не пытался разобраться в твоем коде.
Но я подумал. А почему они сталкиваются ?
У тебя нет проверки перед тем как начать движение, не занят ли путь другой мухой?

Например, в той же игре Dune. Стоит поставить препятствие на пути юнита, как он тут же разворачивается и ищет другой путь.

Автор:  antokog [ 05 авг 2020, 17:37 ]
Заголовок сообщения:  Re:

Agny писал(а):
Я не пытался разобраться в твоем коде.
Но я подумал. А почему они сталкиваются ?
У тебя нет проверки перед тем как начать движение, не занят ли путь другой мухой?

Например, в той же игре Dune. Стоит поставить препятствие на пути юнита, как он тут же разворачивается и ищет другой путь.

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

Автор:  antokog [ 05 авг 2020, 17:38 ]
Заголовок сообщения:  Re:

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

А если без массива, то как?

Автор:  Prytaleks [ 05 авг 2020, 23:32 ]
Заголовок сообщения: 

если коротко, у меня бы был массив с точками, для движения, которые создавался бы и изменялся динамически, и еслибы мне не нужно было движения по кривой, делал бы без сплайна.
как? - ну здесь вероятно на всю ночь работы, вот так.

Страница 3 из 3 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/