Полезное

Мы Вконтакте

Discord канал

#
Модератор: Di-Crash
Аватара пользователя
Пользователь
Сообщения: 17
Цитата:
скачай может у тебя получиться

Я не любитель блупринтов. Они для меня как паутина непонятных блоков. Сводят с ума просто.
Для меня текст куда понятнее, поэтому я даже не стал углубляться в тот пример, что предложил.
Аватара пользователя
Пользователь
Сообщения: 2319

_________________
we need to go deeper
Аватара пользователя
Пользователь
Сообщения: 17
Провел тестирование быстродействия алгоритмов поиска пути AStar и NavMesh.
Результаты продолжительности поиска пути на 1000 метровом расстоянии.

1. AStar - 6.39 ms
2 NavMesh - 0.06 ms(!)

То есть NavMesh эффективнее AStar по меньшей мере в 100 раз(!)
Следовательно потери на перестройку навмеша можно счесть пренебрежительно малыми в сравнении с медлительностью AStar алгоритма.
И единственное, где AStar покажет себя достойным конкурентом NavMesh-а - это при построении 3D пути в играх, где движение осуществляется по объему а не в плоскости сетки NavMesh.
Аватара пользователя
Пользователь
Сообщения: 2319
Цитата:
Следовательно потери на перестройку навмеша можно счесть пренебрежительно малыми в сравнении с медлительностью AStar алгоритма.

эм... построение навмеша еще тяжелей чем A*, при чем значительно , на порядки. (а если еще воксель мелкий выбрать)
_________________
we need to go deeper
Аватара пользователя
Пользователь
Сообщения: 17
Цитата:
эм... построение навмеша еще тяжелей чем A*, при чем значительно , на порядки.

Поиск пути производится почти каждый кадр, время поиска пути по А* на пару порядков дольше чем NavMesh (не знаю как строится NavMesh, потому как это для меня "черный ящик").
Перестроение навмеша происходит (в сравнении с поиском пути) на много порядков реже.
Впрочем, я не ставил себе задачу кого-то в чем-то убеждать и что-то доказывать.
Я показал результаты испытаний и поделился выводами, которые сделал.
А уж что со всем этим скрабом делать вам - вам и решать. Мне фиолетово, если честно...
Аватара пользователя
Пользователь
Сообщения: 589
Алгоритм A* я ещё давно на стареньких бейсик языках проверял. А они были очень чувствительны. Там нужно было исхитрятся что бы FPS не потерять. Производительность этого алгоритма была очень низкой. В этом алгоритме вроде как всё поле делится на клетки, если я не ошибаюсь, и используются многомерные массивы. А многомерные массивы дают большие потери FPS.

Тут вообще правильно прозвучало мнение что AI должен писаться под задачу.

А я бы хотел добавить, что бы всё быстро работало нужно выбрасывать лишние расчеты. Т.е нужно максимально минимизировать всё. Упрощать по возможности.
Аватара пользователя
Пользователь
Сообщения: 17
Цитата:
А я бы хотел добавить, что бы всё быстро работало нужно выбрасывать лишние расчеты. Т.е нужно максимально минимизировать всё. Упрощать по возможности.

Согласен, потому я и выбросил на помойку идею использовать A* алгоритм, взял старый добрый NavMesh и не парюсь больше )
Аватара пользователя
Пользователь
Сообщения: 589
И я не парюсь больше. Поначалу я тоже стал использовать AI с NavMesh. Но потом я обнаружил что по умолчанию движущиеся объекты не воспринимаются как препятствия. Пришлось изрядно помучить поисковик что бы найти информацию о том как сделать что бы движущиеся объекты, а именно другой Pawn, воспринимался как препятствие. Оказалось для этого в настройках Project Setting -> Navigation Mesh -> Runtime -> Runtime Generation нужно было переключить на Dynamic. И в настройках Pawn -> bCanAffectNavigationGeneration переключить на True. Но результатом был разочарован. Персонаж управляемый AI стал как то двигаться рывками. Как будто видит препятствие (другого персонажа) и не знает с какой стороны его обойти. Дергается в разные стороны. Написал об этом на форуме. Меня в гугл отправили изучать что такое rvo avoidance, или Detour crowds. Я это изучил. Ни к чему новому не привело. У меня на сцене два персонажа управляемых игроками. Потому что игрушка на двоих человек. А это Detour crowds предназначен, я так понял, для того что бы персонажи управляемые AI рассчитывали траекторию движения так что бы не сталкиваться с друг другом. Но у меня на сцене два персонажа которые не управляются AI. И он на них парится.
Столько времени потерял. А потом плюнул на всё и написал свой AI на LineTrace о котором написал в первом сообщении этой темы. И всё работает как мне надо. И не хочу больше ни в какие дебри лезть.
Аватара пользователя
Пользователь
Сообщения: 589
ХеруВам писал(а):
Изобрети тогда компьютер и операционную систему к нему, и игровой движок под них, зачем использовать чужое?


Зачем так сложно? Сразу же на железе игру и делать. Как здесь:
http://dshinin.ru/Upload_Books/AUploade ... 228391.pdf
Я в 90-х годах, когда у меня компьютера не было сам пытался создавать что то подобное паяльником из хлама.
Только сегодня это всё не актуально , не интересно и ни кому не надо. Этим никто сейчас не занимается. Всё это день вчерашний.
Аватара пользователя
Пользователь
Сообщения: 2319
Цитата:
Перестроение навмеша происходит (в сравнении с поиском пути) на много порядков реже.

когда как...
я видел на офффоруме анриала пытаются к павну прикрепить динамическое препятствие...
соответственно динамический навмешь не то что в каждом кадре пересчитывается (за кадр не успевает) задачи по пересчету в стак складываются, при чем в тоже время когда по недосчитанному навмешу нужно еще и путь почситать...
_________________
we need to go deeper


Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 28

UEngine.ru © 2017
Все права защищены. При копировании материалов с сайта, ссылка на первоисточник обязательна.
Яндекс.Метрика
Главная страница