UEngine.Ru

Всем привет, закончил стадию прототипирования своего TOP-Down шутана (ну или я его так называю) Full Blueprint Only, сбилжен выделенный сервер плейтест прошел вполне удачно

Для контекста добавлю: По сути у меня очень много маленьких акторов с минимальной логикой. 80% функционала крутится на BP_Player + BP_TopDownController

И вроде сейчас все работает достаточно стабильно и в общем причин париться нет.

НО! постепенно возникают вопросы о будущем проекта:

1.Как скоро я упрусь в тормоза из за использования BluePrints only?
2.Что тогда делать?
3.Бонусом после изучения блюпринтов все же прикоснуться к CPP в контексте UE. Но переписывать "ВСЕПОДРЯД" вижу бессмысленным

Ответы достаточно просты, но я хотел бы уточнить моменты у знатоков:

1. Как правильно выявить, какую часть логики переносить в CPP? / Как выявить критичность влияния на производительность?
- Верно ли я понимаю, что для переноса в CPP лучше и профитнее начать с функций (например в моих BP_Player + BP_TopDownController) которые работают на EventTick? Т.к. именно они более всего дают нагрузку. Достаточно ли это адекватный критерий выбора переноса функционала? Если нет - то поясните пожалуйста какой критерий будет более верный

2. Нужно ли париться за небольшие Акторы с минимальной логикой? а-ля Begin Overlap -> simple IF -> ApplyDamage
Существенность прироста в функциях с многократной итерацией я видел в тестах CPP vs BP коих на ютубе немало, но если логика умещается в 5 нод без ForEachLoop`ов и прочих аналогичных переборов - стоит ли их переносить с CPP? Или можно пока-что их не трогать/ или можно оставить их покое и не париться совсем?

P.S> Во избежание советов: ПИШИ ВСЕ НА CPP - ЭТО TRUEWAY, ТОЛЬКО ХАРДКОР. Поясню - Да, я и сам понимаю что по хорошему желательно ВСЕ написать на CPP. Но переписывать ВСЕ - я точно не буду по двум причинам:

1. Я копаю своей проект в соло и у меня нет такого количества времени
2. Я не хочу тратить время на то что не несет критичной надобности в связи с п.1

P.P.S> Очень надеюсь на адекватные ответы. Буду признателен, форумчане, спасибо заранее!

самое узкое место блюпринта, это циклы с большим количеством итераций, примерно от 500+(например циклы в циклах), как только у тебя появятся подобные функции, они просто будут лагать во время выполнения.
Эту проблему можно решить путем разбиения вычислений на несколько кадров. То есть, сделать так, что бы расчет происходил не мгновенно, а например за 4-10 кадров(с помощью delay - 0 ).
Так я решаю проблемы с быстродействием БП. - https://picua.org/images/2019/10/18/0a3 ... e0ff07.png
Что бы создать свой макрос для выполнения циклов с задержкой между итерациями, кликни дважды на форлупе, скопируй код и создай свой макрос, что бы он был на все времена и для любых ситуаций, можно добавить логику где ты будешь указывать как часто будет вызываться задержка.
В моем макросе я могу указывать желаемую задержку, но это бесполезная штука(задержка 0 самое оно) - https://picua.org/images/2019/10/18/a7d ... c5ed11.png

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


Если необходимо мгновенное выполнение функции или евента с огромным количеством итераций и вычислений, то целесообразно именно эту функцию написать в С++, а в БП вызывать ее как и все остальные ноды.



если акторы содержат в себе активные коллизии, то да, лучше избавится от коллизий, чем их меньше тем лучше.
Очень часто, вместо коллизий, можно использовать BoxTrace например или другой код.
Серьезное падение быстродействия(ФПС) оказывает не код(за исключением выше), а количество активных компонентов.
Если ты используешь класс чарактер, он в себе уже содержит мовемент компонент, который судя по количеству переменных и функций не является "легким".

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

p.s. с басней про осла и соловья ознакомился.

Ответ годный и по делу, спасибо.

Хотелось уточнить пару моментов во избежание недопонимания с моей стороны:
+ Что имеется в виду под активными коллизиями? Всё объекты с активными Generate overlap events?
+ Выходит особой нужды переписывать мой код (циклов больше чем с 15 итерациями у меня нет) - без особой надобности? Даже функции которые висят на EventTick?
+ Если ответ на предыдущий вопрос положительный, выходит что при отсутствии вложенных циклов BP не особо уступает cpp по производительности и вполне реально написать мультиплеерный проект только на BP?

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

Я не пойму зачем delay. Обычный Sequence не пойдет? Если я не ошибаюсь, разница между сигналами на выходах у этой ноды вроде бы 0.5 секунд. При частоте кадров 60 это составляет 8 кадров.

Sequence не дает задержек, да и суть разделить цикл например из тысячи итераций на 5 частей, с задержкой в 1 кадр, проще отредактировать макрос форлуп.

Как это не дает задержек. Сделай у Sequence два выхода и проверь. На обоих выходах сигнал появляется не одновременно.

но и без задержки, как если бы мы просто поставили два принтсринга в один поток.

У Sequence по умолчанию два выхода, мб ты имеешь какой то другой Sequence?

верхний и нижний вариант работают идентично - https://picua.org/images/2019/10/22/b58 ... 2bd7d0.png

если мы добавим в Sequence третий поток, а во второй добавим delay, мы получим значительное отличие, а так это работает как один поток, тоесть в одном кадре.

p.s. когда то давно я спорил также как и ты насчет sequence, но потом мне перевели это слово на русский, слово "поток" в данном случае просто обозначения для белых линий, это не является "многопоточностью".

Да, действительно Prytaleks прав.