Как я переходил с 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 я получил множество полезных решений и подходов, которые облегчили процесс отладки и экспериментов:

  1. Отладка шейдеров и проверка рендер-текстур — GPT помог настроить правильную проверку рендер-текстур для воды и объяснил, как их тестировать в реальном времени, помогая понять, почему вода не отображалась должным образом.

  2. Создание инструмента для массовой конвертации материалов — Во время перехода на URP я использовал стандартный конвертер, а для перехода обратно на Built-In стандартных средств не было. С помощью Chat GPT я создал скрипт для автоматического поиска материалов с некорректными шейдерами и их массовой конвертации. Получился инструмент с возможностью выбора материалов для конвертации, что сэкономило кучу времени.

    Перед откатом назад надо сначала сконвертить материалы из URP
    Перед откатом назад надо сначала сконвертить материалы из URP
  3. Шаги по оптимизации производительности — Вместе с GPT мы прошлись по шагам оптимизации: настройка освещения, теней, уровня детализации и другие элементы. Однако, даже с учетом этих оптимизаций, URP оставался слишком тяжелым для старых устройств.

Заключение

Переход на URP обещал множество преимуществ, но в моём случае он привёл к неожиданным проблемам, таким как падение производительности, ошибки с рендерингом воды и сложности с деревьями. С помощью Chat GPT я смог глубже понять работу URP, провести серьёзную отладку, создать инструменты для автоматизации процесса, но в итоге мне всё равно пришлось вернуться на Built-In, так как это был единственный способ достичь нужного уровня производительности и качества.

Мой вывод: URP — это мощный инструмент для современных проектов, но если вы работаете с кастомными решениями и старыми устройствами, то Built-In может оказаться более стабильным и производительным выбором.

Комментарии (3)


  1. alexxxdevelop
    05.10.2024 11:34
    +1

    У меня тоже был негативный опыт перехода на URP. На мобильных устройствах не просто ужасная производительность, а вообще никакая. Кроме этого не хватало многих эффектов. Например, в URP отсутствует нормальный эффект Motion Blur, когда двигаешь камерой и все вокруг красиво сглаживается. И многое другое, включая воду и т.д. В Built-In рендере можно добиться неплохих эффектов постобработки компонентами Post-process Layer и Post-process Volume из пакета Post Processing, и при этом они не ухудшают производительность.

    Такое ощущение, что URP делать начали, но не закончили, делали в спешке и на от..бись


    1. Tirarex
      05.10.2024 11:34
      +1

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

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


  1. HexGrimm
    05.10.2024 11:34
    +1

    Всё таки, переключить галочку на URP и попробовать ассеты из ассетстора это не "перейти на URP". Сам по себе URP имеет набор модифицируемых и комбинируемых слоёв, котоыре можно фасовать и заменять, в зависимости от нужд. И по скольку URP сделан на основе SRP API, то можно собрать свой пайплайн, подсмотрев что происходит в URP, его исходный код открыт.

    Я соглашуть что URP слишком универсален, содержит множество багов и имеет плохую производительность, но в статье нет фактической аргументировации. Например, что именно даёт такой низкий fps в вашем случае? Дело ли в URP и в каком проходе именно узкое место? Дело только в одном месте в коде или в множестве? Что будет с выводами, если это одно место исправить или отключить (ведь не всем нужна вода в игре)?

    По моему опыту, самую высокую производительность можно получить, взяв минимум из URP, собрав из него облегчённого франкенштейна на базе SRP, и рендерить только то что нужно в проекте, удалив ненужные буферы, шейдер-варанты, системы теней, мета-данные лайтмап и тд. Но уж ни как не со стандартным набором шейдеров выходить на мобильные устройства, разве что с Unlit-Diffuse картинкой.