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

Количество переменных на Pawn
http://uengine.ru/forum/viewtopic.php?f=2&t=13151		 Страница 5 из 5
Автор:  Snake [ 07 фев 2018, 11:01 ]
Заголовок сообщения: 
Цитата:
Но все равно в конечном счете логики на мобе будет больше чем SimleMoveToLocation на тике, то есть ресурсов потребуется больше.

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

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

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

(кстати бехавир три не рассинхронено между ботами... поэтому неоднородные просадки ФПС циклические... если просто запустить все БТ с задержкой между запусками то просадок уже не будет, проверить это профайлером можно)
Автор:  Zail94 [ 07 фев 2018, 11:21 ]
Заголовок сообщения: 
А как рассредоточить принятие решений ботов по секунде времени, если боты будут спауниться не в один момент времени. И вообще где подсмотреть пример этого рассредотачивания?
Автор:  Snake [ 07 фев 2018, 11:26 ]
Заголовок сообщения: 
Цитата:
боты будут спауниться не в один момент времени

и при этом если они не будут принимать решения слишком часто
(каждый тик, через тик , через два и тп. тоесть если бот принимает решение только когда ему действительно нужно его принять)
то вероятность совпадения принятия решений нескольких ботов одновременно - уже довольно невысокая, и если иногда будет совпадать то особо не повлияет ни на что.
Примеров нету, как сделаешь так и будет.
Автор:  Snake [ 08 фев 2018, 09:56 ]
Заголовок сообщения: 
к обсуждаемой ранее теме
http://www.gdcvault.com/play/1022411/Ma ... assin-s%20
не скажу что ассассин-юнити хороший пример производительности, но его толпы nps впечатляют...
Автор:  Zail94 [ 08 фев 2018, 10:12 ]
Заголовок сообщения: 
Я находил различного рода видео подобного характера по UE4

https://www.youtube.com/watch?v=8BB1-S4Uqo0

Если я всё правильно понял, то заполнить улицы городов массовкой не так сложно. Но переходя от теории к практике, я столкнулся с куда более примитивными проблемами про пытке воспроизвести банальный тест обсуждаемый здесь ранее https://www.youtube.com/watch?v=Fx5km4fqBoo ...

Я создал таких же чарактеров и дал им самую простую логику SimpleMove с целью на игроке, и к моему удивлению часть агентов просто стояла на месте, NavMesh покрывал всю карту, самого персонажа я водил вблизи этих павнов, но они просто стояли не реагируя... возможно есть в этой системе что-то о чём я ещё не знаю?
Автор:  Prytaleks [ 08 фев 2018, 10:53 ]
Заголовок сообщения:  Re:
Zail94 писал(а):
Я создал таких же чарактеров и дал им самую простую логику SimpleMove с целью на игроке, и к моему удивлению часть агентов просто стояла на месте, NavMesh покрывал всю карту, самого персонажа я водил вблизи этих павнов, но они просто стояли не реагируя... возможно есть в этой системе что-то о чём я ещё не знаю?


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

p.s. http://picua.org/img/2018-02/08/z0z4vqp ... 5lx6y4.png
Автор:  Prytaleks [ 08 фев 2018, 10:57 ]
Заголовок сообщения:  Re:
Snake писал(а):
а вот не должно быть так

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

p.s. но если мы говорим о сотнях, то да, согласен, функционал на тике лучше исключить вообще(также как и коллизии), и использовать таймеры + лайнтрэйсы.
Автор:  Snake [ 08 фев 2018, 11:41 ]
Заголовок сообщения: 
Цитата:
Я создал таких же чарактеров и дал им самую простую логику SimpleMove с целью на игроке

тут есть некоторые проблемы:
игрок это динамическая цель, тоесть подвижная, тоесть к ней нужно обновлять путь,
а обновление пути слишком часто не есть хорого для производительности
-> из этого следует:
1 - что либо нужно провести ревизию кода и знать как часто происходит поиск пути, и использовать подвижную цель уже с пониманием нагрузки
2 - не использовать подвижную цель для навигации и вручную обновлять позицию цели с нужной частотой и параметрами

а вот то что часть ботов игнориловало движение нужно разбираться... неочевидно по крайней мере чего они не двигались.
Автор:  Zail94 [ 23 окт 2018, 22:09 ]
Заголовок сообщения: 
Товарищи, я вновь решил поднять старую тему и она схожа по смыслу с предыдущими постами. После нашего обсуждения я на долгое время забросил идею работы с большим числом актёров в сцене, однако, моя дорога изучения движка вновь привела меня к данной тематике. В связи с чем я провёл несколько стресс тестов.
Они заключались в сравнении того какую задержку по просчёту CPU дадут 2500 акторов и 2500 чаракторов. Базовые болвачики имели только сферу коллизии и белый куб. По итогу:
-Caracter просаживает CPU до 31-35 ms
-Actor при том же количестве выдаёт 6 ms
Как и следовало ожидать пустой класс Actor обладает огромным запасом производительности и логичнее использовать его, собственно что мне и писали ранее.
Но, при добавлении стандартной скелетной сетки приводило меня к крайне удручающим результатам:
Actor увеличивал задержку CPU до 106 ms просто из-за того что была активна анимация покоя, и это ещё до добавления какой- бы то ни было логики. Оптимизация логики и блупринтов не будет иметь смысла пока не будет убрана основа сжирающая большую часть ресурсов а именно скелетная анимация. Порывшись в гугле я смог найти только примитивные способы сгладить данный момент, а именно отключать рендер анимации если актор не находится в кадре. Это неплохой способ, позволяющий вновь сократить задержку CPU до:
- 20 ms при условии что персонаж не находится в кадре и
- 11 ms если к мешу в принципе не подключать анимблупринт.
Но если вновь обратить взор камеры на все эти 2500 юнитов, то даже при условии того, что анимация к ним не подключена, приводит к падения CPU до задержки в 70 ms.

Итак подведя итоги проделанной работы у меня возник вопрос, есть ли методики позволяющие оптимизировать скелетные сетки персонажей, упрощать их в рантайме, или же на данном поприще пока ни у кого успехов не было?
Автор:  Snake [ 24 окт 2018, 07:33 ]
Заголовок сообщения: 
есть - лоды, лоды не только на ассет скелетал меша но также и в аним бп используются, у скелетал мешь компонента так же есть настройка отключения просчета анимации когда он не рендерится...
собственно это основное.
а вообще - берешь всех участников действа - скелетал мешь компонент, аним блупринт , скелетал мешь, актор содержащий все это.
и разбираешь за что отвечает каждая(!) настройка в них. а в аним бп еще и настройки нод участвующих.
Страница 5 из 5 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/