Гайд Советы по оптимизации блюпринтов

Начинающий
Статус
Оффлайн
Регистрация
14 Окт 2020
Сообщения
44
Реакции[?]
10
Поинты[?]
0
В этом посте собранно несколько советов, которые новички (а может и некоторые продвинутые) часто не знают или забывают при работе с блюпринтами.
Эти советы могут легко увеличить фпс в игре в несколько раз не прибегая к оптимизации графики, настройке лодов и всего прочего. Здесь только про блюпринты.

Первое и пожалуй самое основное - используй как можно меньше кастов!
Касты тратят очень много ресурсов из-за чего игра будет работать гораздо медленнее, так же это часто может стать причиной фризов.
Лучшее что можно сделать, это провести все касты в начале логики (на begin play или event construct) или же до неё начала если это виджет блиюпринт (event pre construct) а потом записать результат каста в переменную, которую потом использовать по необходимости. Если есть вариант обойтись без каста, то им лучше всего воспользоваться.
Пример сохранения результата каста в переменную и дальнейшего использование переменной (кэширование)
1643830247172.png

Совет №2. Не выстраивай логику на основе event tick. Event tick вызывается каждый кадр (К примеру если у игрока 40 фпс, то логика будет вызываться 40 раз в секунду) из-за этого повторение большой логики многократно, будет сильно нагружает пк, да и небольшая логика тоже пару фпс вполне может съесть. Помимо этого и сама логика привязанная к event tick'у может работать по разному у разных пользователей, ведь у кого-то 30 фпс и логика вызывается 30 раз в секунду, а у кого-то 60 фпс и логика соответственно будет вызываться вдвое чаще. Для решения этой проблемы в блюпринте можно выставить Tick interval, тогда зависимости от фпс не будет, но производительность всё равно страдать не перестанет.
Лучшее решение проблемы - это заменить использование event tick на таймеры и таймлайны.
Пример использования таймлайна
1643830455466.png

Ну и напоследок довольно очевидная вещь про которую я почему-то узнал достаточно поздно - это нода switch. Если вы всё ещё делайте многократные проверки через branch, то лучше использовать switch. Нода "Switch" проверяет полученную информацию (как правило это int, string или значение из enum таблицы) и выполняет последующую логику в зависимости от полученного значения. Помимо оптимизированности, её использование сильно упрощает работу и помогает избежать большого количества проверок. Особенно хорош switch при использовании enum таблиц.
Пример использования ноды switch on int
1643830637841.png

Лично мне эти советы помогли увеличить фпс примерно в 4- 5 раза и избавиться от фризов, но для полной оптимизации проекта этого может не хватать. Если вам так же интересны темы оптимизации моделей и интерфейса, то я буду рад рассказать о них.
Спасибо за прочтение и удачи в разработке!
 
Последнее редактирование модератором:
Начинающий
Статус
Оффлайн
Регистрация
1 Янв 2021
Сообщения
158
Реакции[?]
15
Поинты[?]
11K
В этом посте собранно несколько советов, которые новички (а может и некоторые продвинутые) часто не знают или забывают при работе с блюпринтами.
Эти советы могут легко увеличить фпс в игре в несколько раз не прибегая к оптимизации графики, настройке лодов и всего прочего. Здесь только про блюпринты.

Первое и пожалуй самое основное - используй как можно меньше кастов!
Касты тратят очень много ресурсов из-за чего игра будет работать гораздо медленнее, так же это часто может стать причиной фризов.
Лучшее что можно сделать, это провести все касты в начале логики (на begin play или event construct) или же до неё начала если это виджет блиюпринт (event pre construct) а потом записать результат каста в переменную, которую потом использовать по необходимости. Если есть вариант обойтись без каста, то им лучше всего воспользоваться.
Пример сохранения результата каста в переменную и дальнейшего использование переменной (кэширование)
Посмотреть вложение 190654

Совет №2. Не выстраивай логику на основе event tick. Event tick вызывается каждый кадр (К примеру если у игрока 40 фпс, то логика будет вызываться 40 раз в секунду) из-за этого повторение большой логики многократно, будет сильно нагружает пк, да и небольшая логика тоже пару фпс вполне может съесть. Помимо этого и сама логика привязанная к event tick'у может работать по разному у разных пользователей, ведь у кого-то 30 фпс и логика вызывается 30 раз в секунду, а у кого-то 60 фпс и логика соответственно будет вызываться вдвое чаще. Для решения этой проблемы в блюпринте можно выставить Tick interval, тогда зависимости от фпс не будет, но производительность всё равно страдать не перестанет.
Лучшее решение проблемы - это заменить использование event tick на таймеры и таймлайны.
Пример использования таймлайна
Посмотреть вложение 190655

Ну и напоследок довольно очевидная вещь про которую я почему-то узнал достаточно поздно - это нода switch. Если вы всё ещё делайте многократные проверки через branch, то лучше использовать switch. Нода "Switch" проверяет полученную информацию (как правило это int, string или значение из enum таблицы) и выполняет последующую логику в зависимости от полученного значения. Помимо оптимизированности, её использование сильно упрощает работу и помогает избежать большого количества проверок. Особенно хорош switch при использовании enum таблиц.
Пример использования ноды switch on int
Посмотреть вложение 190656

Лично мне эти советы помогли увеличить фпс примерно в 4- 5 раза и избавиться от фризов, но для полной оптимизации проекта этого может не хватать. Если вам так же интересны темы оптимизации моделей и интерфейса, то я буду рад рассказать о них. Если вам эта небольшая статья действительно помогла, то вы знаете как можете меня отблагодарить.
Спасибо за прочтение и удачи в разработке!
Спасибо за статью ,про то что касты нагружают систему я знал , но вот то что евентик можно заменить таймлайном я впервые прочитал
 
Начинающий
Статус
Оффлайн
Регистрация
13 Авг 2020
Сообщения
44
Реакции[?]
36
Поинты[?]
0
В этом посте собранно несколько советов, которые новички (а может и некоторые продвинутые) часто не знают или забывают при работе с блюпринтами.
Эти советы могут легко увеличить фпс в игре в несколько раз не прибегая к оптимизации графики, настройке лодов и всего прочего. Здесь только про блюпринты.

Первое и пожалуй самое основное - используй как можно меньше кастов!
Касты тратят очень много ресурсов из-за чего игра будет работать гораздо медленнее, так же это часто может стать причиной фризов.
Лучшее что можно сделать, это провести все касты в начале логики (на begin play или event construct) или же до неё начала если это виджет блиюпринт (event pre construct) а потом записать результат каста в переменную, которую потом использовать по необходимости. Если есть вариант обойтись без каста, то им лучше всего воспользоваться.
Пример сохранения результата каста в переменную и дальнейшего использование переменной (кэширование)
Посмотреть вложение 190654

Совет №2. Не выстраивай логику на основе event tick. Event tick вызывается каждый кадр (К примеру если у игрока 40 фпс, то логика будет вызываться 40 раз в секунду) из-за этого повторение большой логики многократно, будет сильно нагружает пк, да и небольшая логика тоже пару фпс вполне может съесть. Помимо этого и сама логика привязанная к event tick'у может работать по разному у разных пользователей, ведь у кого-то 30 фпс и логика вызывается 30 раз в секунду, а у кого-то 60 фпс и логика соответственно будет вызываться вдвое чаще. Для решения этой проблемы в блюпринте можно выставить Tick interval, тогда зависимости от фпс не будет, но производительность всё равно страдать не перестанет.
Лучшее решение проблемы - это заменить использование event tick на таймеры и таймлайны.
Пример использования таймлайна
Посмотреть вложение 190655

Ну и напоследок довольно очевидная вещь про которую я почему-то узнал достаточно поздно - это нода switch. Если вы всё ещё делайте многократные проверки через branch, то лучше использовать switch. Нода "Switch" проверяет полученную информацию (как правило это int, string или значение из enum таблицы) и выполняет последующую логику в зависимости от полученного значения. Помимо оптимизированности, её использование сильно упрощает работу и помогает избежать большого количества проверок. Особенно хорош switch при использовании enum таблиц.
Пример использования ноды switch on int
Посмотреть вложение 190656

Лично мне эти советы помогли увеличить фпс примерно в 4- 5 раза и избавиться от фризов, но для полной оптимизации проекта этого может не хватать. Если вам так же интересны темы оптимизации моделей и интерфейса, то я буду рад рассказать о них. Если вам эта небольшая статья действительно помогла, то вы знаете как можете меня отблагодарить.
Спасибо за прочтение и удачи в разработке!
Жесть, что у тебя там было такого, что фпс подрос аж в 4-5 раз... Спавн на эвент тике что ли?)
 
Начинающий
Статус
Оффлайн
Регистрация
14 Окт 2020
Сообщения
44
Реакции[?]
10
Поинты[?]
0
Жесть, что у тебя там было такого, что фпс подрос аж в 4-5 раз... Спавн на эвент тике что ли?)
Скорее много кастов на эвент тиках, хотя возможно и спавны, сейчас не вспомню, давно дело было)
 
Пользователь
Статус
Оффлайн
Регистрация
11 Июн 2020
Сообщения
224
Реакции[?]
80
Поинты[?]
0
В этом посте собранно несколько советов, которые новички (а может и некоторые продвинутые) часто не знают или забывают при работе с блюпринтами.
Эти советы могут легко увеличить фпс в игре в несколько раз не прибегая к оптимизации графики, настройке лодов и всего прочего. Здесь только про блюпринты.

Первое и пожалуй самое основное - используй как можно меньше кастов!
Касты тратят очень много ресурсов из-за чего игра будет работать гораздо медленнее, так же это часто может стать причиной фризов.
Лучшее что можно сделать, это провести все касты в начале логики (на begin play или event construct) или же до неё начала если это виджет блиюпринт (event pre construct) а потом записать результат каста в переменную, которую потом использовать по необходимости. Если есть вариант обойтись без каста, то им лучше всего воспользоваться.
Пример сохранения результата каста в переменную и дальнейшего использование переменной (кэширование)
Посмотреть вложение 190654

Совет №2. Не выстраивай логику на основе event tick. Event tick вызывается каждый кадр (К примеру если у игрока 40 фпс, то логика будет вызываться 40 раз в секунду) из-за этого повторение большой логики многократно, будет сильно нагружает пк, да и небольшая логика тоже пару фпс вполне может съесть. Помимо этого и сама логика привязанная к event tick'у может работать по разному у разных пользователей, ведь у кого-то 30 фпс и логика вызывается 30 раз в секунду, а у кого-то 60 фпс и логика соответственно будет вызываться вдвое чаще. Для решения этой проблемы в блюпринте можно выставить Tick interval, тогда зависимости от фпс не будет, но производительность всё равно страдать не перестанет.
Лучшее решение проблемы - это заменить использование event tick на таймеры и таймлайны.
Пример использования таймлайна
Посмотреть вложение 190655

Ну и напоследок довольно очевидная вещь про которую я почему-то узнал достаточно поздно - это нода switch. Если вы всё ещё делайте многократные проверки через branch, то лучше использовать switch. Нода "Switch" проверяет полученную информацию (как правило это int, string или значение из enum таблицы) и выполняет последующую логику в зависимости от полученного значения. Помимо оптимизированности, её использование сильно упрощает работу и помогает избежать большого количества проверок. Особенно хорош switch при использовании enum таблиц.
Пример использования ноды switch on int
Посмотреть вложение 190656

Лично мне эти советы помогли увеличить фпс примерно в 4- 5 раза и избавиться от фризов, но для полной оптимизации проекта этого может не хватать. Если вам так же интересны темы оптимизации моделей и интерфейса, то я буду рад рассказать о них.
Спасибо за прочтение и удачи в разработке!
а в чем смысл заменять бранч свитчем, если нужна именная булевая логика? по сути если нам надо определить true / false то проще использовать булевую переменную, а ее мы проверим как раз на бранче
 
Сверху Снизу