Почему BiRP в Unity благодатен, а URP богомерзок

В 2018 году мир постигла трагедия: Unity Technologies создали так называемый LWRP — легковесный трубопровод рендеринга (да, Pipeline буквально переводится именно так и мне плевать на здравый смысл!). Он должен был прийти на замену встроенному трубопроводу рендеринга (BiRP — Build-In render pipeline). Позднее он был переименован в URP – Universal Render Pipeline. Очень оптимистичное название, которое (увы!) себя не оправдало. Начало было многообещающим: менеджеры обещали прямой доступ над процессом отрисовки кадра, значительное увеличение производительности, особенно на слабых устройствах, визуальный редактор шейдеров, могущественную система частиц (тоже на нодах). Кстати, все эти обещания сбылись. Но лучше от этого не стало.

Новая система рендеринга принесла в движок ограничения, словно позаимствованные из тюрьмы строгого режима. Шейдеры стали принципиально однопроходными, все многопроходные эффекты следовало делать через так называемые RenderFeature. Это такие скрипты, которые описывали как Unity должен обрабатывать графоний. Разумеется, движок НИ-ФИ-ГА не понимал, что он него хотят. Разработчики тоже.

Вопросов и жалоб нет.

На словах это была очень крутая технология, с помощью которой художник мог писать шейдеры без знания кода, а окно предпросмотра позволяло без компиляции видеть примерный результат. Ещё один плюс — невозможность написать некомпилируемый шейдер (хотя и тут есть оговорки). А теперь к минусам. И этот раздел будет длинным.

Сама концепция визуального редактора шейдеров имеет фатальный недостаток. Она не избавляет от необходимости писать код, а требует писать его на другом языке. Да, соединение узлов линиями – это тоже код, просто в другом виде. Мало того, этот язык принципиально ограничен: там нет циклов, а значит шейдер размытия нодами сделать не выйдет. Для расширения возможности есть функция CustomNode, где можно писать любой код на языке HLSL. Но эта функция так же убога, потому что туда нельзя передать текстуру для чтения в цикле.

Другой вопрос – это буфер трафарета (stencil). Управлять им при помощи визуального редактора невозможно. Конечно, на URP шейдер с поддержкой трафаретного буфера можно написать кодом, но тогда какой в нём смысл? Кодом можно и на BiRP писать, даже лучше будет. Нет встроенной текстуры GrabPass, в которую записывается весь отрисованный кадр, а значит — прощайте, простые эффекты вроде дрожащего воздуха.

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

Это та самая технология, ради которой затевалось обновление конвейера рендера. RenderFeature – это код, который позволяет добавить пользовательские проходы отрисовки во время рендера кадра. С помощью их можно реализовать постэффекты – размытие, контуры в экранном пространстве, цветокоррекция, рентгеновское зрение и т.д. В довесок шло увеличение производительности и простота создания новых эффектов (это уже явная и гнусная ложь, но сделаем вид, что поверили). Относительно неплохой была идея управлять всей графикой из одного места при помощи RenderFeature. Но результат был чудовищным. У этой технологии практически не было руководств. Самые простые эффекты требовали нагромождения непонятных функций, эффект которых зависел от контекста и погоды на марсе. Обычный RenderTexture уже не работал и надо было использовать класс RenderTargetHandle. А когда пользователь немного освоиться с этим, его ждал сюрприз — этот класс устарел и надо пользоваться современной заменой под названием RTHandle, причём просто заменить его не выйдет, придется переписывать весь код, в котором он упоминается. Если у вас уже “кипит разум возмущённый”, то это ещё не конец. С выходом последних версий Unity разработчики полностью переписали API для RenderFeature. Пол-ность-ю! Теперь разработчиками надо с нуля учить как реализовать какой-то чёртов RecordRengerGraph. Конечно же, руководство и примеры весьма лаконичны и удобно обходят сложные места. И совсем не факт, что это изменение последнее.

В качестве примера мерзости URP я могу привести код для обычного эффекта постобработки: на URP он занимает 200 строк, где один Кришна Джанардана знает, что и как работает. На BuildInRenderPipeLine это займёт 7 строк, из который 2 — это подключение библиотек. Всё.

Поразительно, как же разработчики упустили сделать возможность сделать URP почти нормальной технологией. Для этого достаточно было добавить возможность создать RenderFeature при помощи визуального графа, как шейдеры. Это бы одним махом решило все проблемы со сложностью освоения. Сделать проходы рендеринга в виде узлов, соединительными линиями указать как и куда передаются текстуры, настроить поток исполнения и т.д. Это уже давно проверенная технология, плагин для визуального программирования в Unity есть с 2023 года. Конечно, учесть все нюансы сложно, но раз так — то почему юнитеки вообще взялись за масштабное обновление графики, если не способны сделать это нормально?

А теперь вернёмся к BiRP. Несмотря на почтенный возраст эта технология по-прежнему работает. Просто, молча, без громких заявлений и дутых обещаний BuildInRenderPipeLine отрисовывает кадр. Его миновали революционные технологии, но зато он сохранил работоспособность. Unity Technologies давно обещают вырезать его из новых версий движка, но после того, как раздражённые разработчики намекнули, что знают, в какую школу ходят дети менеджеров Unity, это угроза пропала с повестки дня.

Объяснить такое поведение сложно. Конечному пользователю не нужна чехарда с версиями URP, ему нужна стабильное и логичное API для графики. Даже производительность не так важна, как надёжность и предсказуемость. С некоторой натяжкой это было в BiRP, но URP превратилось в стремительную гонку за технологиями, где пользователи безнадёжно отстали от несущегося незнамо куда движка. Хочется сказать “стой!”, но некому. Возможно, причина этого в желании создателей Unity захватить рынок AAA-игр, в которых действительно нужна передовая графика, использующая последние графические технологии. Но сами разработчики вполне довольствовались BiRP для своих проектов, которым вовсе не нужен был фотореализм. Сейчас на BiRP приходится от 24 до 30 процентов новых проектов на Unity. Возможно, этого хватит, чтобы заявить о полной и безоговорочной победе URP (кстати, а где High Definition Render Pipeline? А, он так же закрывается вслед за BiRP! Но на этот раз по-настоящему). Однако, эта победа была достигнута нечестным путём, ведь Юнитеки просто вкладывали все ресурсы в URP и его продвижение.

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

#unity3d #gamedev #технологии