АРХИТЕКТУРА И РЕНДЕР

Имеют ли они хоть какую-нибудь связь?

Архитектура - это способ организации кода, который отвечает на вопросы:
🔸 Какие элементы будут и какова их ответственность
🔸 Как они будут создаваться и уничтожаться
🔸 Как они будут общаться между собой

Хорошая архитектура позволит:
🔹Не переписывать код при изменении или добавлении требований (разве что лишь маленький кусочек)
🔹Улучшить производительность всего приложения. Причем этот пункт куда важнее, чем при написании обычных скриптов
🔹Позволит легче искать/исправлять баги

Вот конкретные кейсы, когда рендер о части рендера нужно думать заранее:
🔸Когда пишешь свой SRP (Scriptable Render Pipeline)
🔸Есть, пишется свой кастомный шейдер (аля убер-шейдер)
🔸И даже если у тебя уже готовый рендер: Built-in, URP, HDRP, но нужно написать какие-то кастомные фичи

Вот список вопросов, на которые нужно ответить на каждом проекте:
🔹Тени будут или будем fake'ать
🔹Какое способ орисовки, порядок opaque/transparent
🔹Postprocessing нужен ли
🔹Промежуточные pass'ы будут ли и где
🔹Различные пресеты настроек, крутилки художественные (причем некоторые из них должны переопределяться в сцене, а какие-то даже на участке сцены).

ШЕЙДЕРЫ

Странно, но шейдеры это тоже программа, которая просто пишется на другом языке.

Вот почему код в шейдерах и в *.cs файлах одинаков с точки зрения архитектуры:
🔸Находится так же внутри проекта, компилируется, исполняется своим runtime'ом на конечном устройстве
🔸Зашивается и исполняется на клиенте
🔸Можно выносить общую функциональность в отдельные методы.
В отдельные .hlsl файлы и подключать их как include'ы в шейдеры и в другие include'ы.

Соответственно проблемы, которые нужно решать очень похожи, термины местами просто другие:
🔹Какую функциональность куда подключить и нужно ли это вообще
🔹Как должны общаться функции для лучшей производительность и удобства
🔹Как следует подключать include'ы, в каком порядке, как разместить методы в них, по какому признаку
🔹Кого как и почему вынести под keyword'ы и как их организовать

CUSTOM RENDER FEATURE

Допустим, что-то элементарное:
🔸Игрок кликает на юнита и юнит должен получить обводку.
🔸Как сообщить материалу о том, что вот сейчас обводку надо включить а потом выключить?
🔸А цвет обводки?
🔸А если потом понадобится, чтобы обводка меняла паттерн или начинала мигать?

Под конец маленькие список потенциальных проблем, если пустить рендер часть на авось:
🔹Большое количество keyword'ов может привести к взрывному росту комбинаторной сложности.
Это значит — сотни тысяч, миллионы вариантов шейдеров, что отразится в часах компиляции проекта и на размере финального билда
🔹 NaN'ы, +-Infinity роняют проект на проде ни чуть не реже, чем баги в обычных скриптах

И при реализации фичи, эти вопросы всё равно должен кто-то решить. И вполне возможно, что этим "кто-то" окажешься именно ты)

Пост подготовлен при поддержке и редактуре @shiko_q, спасибо😘
Специально для любимого чатика Unity CG Tech

@UniArchitect #проект_с_нуля