Как я переходил с Built-In на URP в Unity и обратно с помощью Chat GPT
Недавно я решил попробовать перейти с классического Built-In рендеринга на URP (Universal Render Pipeline) в Unity в своей игре "Подводная охота". Многие разработчики советуют URP за его продвинутую графику и возможности оптимизации для мобильных устройств. Я ожидал, что переход принесёт только улучшения, но в итоге столкнулся с массой проблем, которые побудили меня вернуться обратно на Built-In Pipeline. В этом процессе я активно использовал Chat GPT. Вот мой опыт и основные причины, которые привели меня к возврату на старую систему.
1. Падение производительности на старых устройствах
Одна из главных целей моего проекта — работа на широком спектре устройств, включая старые модели. Когда игра работала на Built-In, я видел стабильные 26 fps. После перехода на URP, производительность значительно снизилась до 18 fps. Несмотря на множество возможностей для оптимизации, таких как настройка уровней теней, освещения и использования лайтмапов, улучшить производительность на уровне Built-In мне так и не удалось.
С помощью Chat GPT я выбрал несколько стратегий по оптимизации, таких как использование URP Asset с минимальными настройками качества, отключение тяжелых эффектов и динамических теней. Несмотря на это, прироста fps я так и не увидел. На своем стареньком Honor 9 Lite, Built-In оказался более стабильным.
2. Проблемы с водой и ошибки шейдеров
Одной из самых больших проблем при переходе на URP стала вода. В проекте я использовал шейдер для воды FX/Water, и в Built-In всё работало как надо. Однако при переходе на URP начали появляться ошибки, например:
IsCameraProjectionMatrixFlipped is being called outside camera rendering scope.
UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&)
Я решил попробовать несколько популярных ассетов для воды, совместимых с URP, таких как:
Crest Water System URP Ocean Rivers Lakes
KWS Water System
Dragon Water URP
Stylized Water 2
Однако эти решения либо требовали слишком много ресурсов и ухудшали производительность, либо не достигали качества, которого я добивался в Built-In. Я пробовал переделать шейдер через GPT, переписывал скрипт воды, пытаясь адаптировать его к моей старой системе. Однако, несмотря на все попытки и советы GPT, я так и не смог исправить ошибку.
3. Проблемы с деревьями и билбордами
Третьей серьёзной проблемой стали деревья. В Built-In я использовал Nature/Tree Soft Occlusion Leaves (Bark) для деревьев, чтобы террайн автоматически делал биллборды. В URP я попробовал использовать SpeedTree шейдеры, но деревья выглядели криво — они были чересчур темными при ближнем рассмотрении. Также возникли проблемы с отображением билбордов (простых 2D-изображений деревьев на дальнем расстоянии), часть дерева полностью исчезала и биллборды были значительно выше detailed tree.
Решения через Chat GPT
В процессе работы с Chat GPT я получил множество полезных решений и подходов, которые облегчили процесс отладки и экспериментов:
Отладка шейдеров и проверка рендер-текстур — GPT помог настроить правильную проверку рендер-текстур для воды и объяснил, как их тестировать в реальном времени, помогая понять, почему вода не отображалась должным образом.
-
Создание инструмента для массовой конвертации материалов — Во время перехода на URP я использовал стандартный конвертер, а для перехода обратно на Built-In стандартных средств не было. С помощью Chat GPT я создал скрипт для автоматического поиска материалов с некорректными шейдерами и их массовой конвертации. Получился инструмент с возможностью выбора материалов для конвертации, что сэкономило кучу времени.
Шаги по оптимизации производительности — Вместе с GPT мы прошлись по шагам оптимизации: настройка освещения, теней, уровня детализации и другие элементы. Однако, даже с учетом этих оптимизаций, URP оставался слишком тяжелым для старых устройств.
Заключение
Переход на URP обещал множество преимуществ, но в моём случае он привёл к неожиданным проблемам, таким как падение производительности, ошибки с рендерингом воды и сложности с деревьями. С помощью Chat GPT я смог глубже понять работу URP, провести серьёзную отладку, создать инструменты для автоматизации процесса, но в итоге мне всё равно пришлось вернуться на Built-In, так как это был единственный способ достичь нужного уровня производительности и качества.
Мой вывод: URP — это мощный инструмент для современных проектов, но если вы работаете с кастомными решениями и старыми устройствами, то Built-In может оказаться более стабильным и производительным выбором.
Комментарии (3)
HexGrimm
05.10.2024 11:34+1Всё таки, переключить галочку на URP и попробовать ассеты из ассетстора это не "перейти на URP". Сам по себе URP имеет набор модифицируемых и комбинируемых слоёв, котоыре можно фасовать и заменять, в зависимости от нужд. И по скольку URP сделан на основе SRP API, то можно собрать свой пайплайн, подсмотрев что происходит в URP, его исходный код открыт.
Я соглашуть что URP слишком универсален, содержит множество багов и имеет плохую производительность, но в статье нет фактической аргументировации. Например, что именно даёт такой низкий fps в вашем случае? Дело ли в URP и в каком проходе именно узкое место? Дело только в одном месте в коде или в множестве? Что будет с выводами, если это одно место исправить или отключить (ведь не всем нужна вода в игре)?
По моему опыту, самую высокую производительность можно получить, взяв минимум из URP, собрав из него облегчённого франкенштейна на базе SRP, и рендерить только то что нужно в проекте, удалив ненужные буферы, шейдер-варанты, системы теней, мета-данные лайтмап и тд. Но уж ни как не со стандартным набором шейдеров выходить на мобильные устройства, разве что с Unlit-Diffuse картинкой.
alexxxdevelop
У меня тоже был негативный опыт перехода на URP. На мобильных устройствах не просто ужасная производительность, а вообще никакая. Кроме этого не хватало многих эффектов. Например, в URP отсутствует нормальный эффект Motion Blur, когда двигаешь камерой и все вокруг красиво сглаживается. И многое другое, включая воду и т.д. В Built-In рендере можно добиться неплохих эффектов постобработки компонентами Post-process Layer и Post-process Volume из пакета Post Processing, и при этом они не ухудшают производительность.
Такое ощущение, что URP делать начали, но не закончили, делали в спешке и на от..бись
Tirarex
URP надо уметь готовить как и стандартный рендер. Новый srp батчер неплохо работает, есть нативное уменьшение разрешения (а не костыли как в стандарте) и еще куча фишек. Но все это надо правильно конфигурировать. Моушен блюр тоже появился.
Но с чистой совестью скажу что я продолжаю пользоваться стандартным рендером, так как его работа чуть более контролируема, и на мобильных платформах он показывает себя лучше.