Система материалов, часть 3
Тут надо сделать небольшое лирическое отступление и поговорить про организацию, непосредственно рендерера. Практически все имплементации рендеринга, которые доступны в опенсорсе предполагают архитектуру, при которой со стороны системы описания материалов приходят какие-то настройки, которые рендерер самостоятельно копирует в юниформы, затем так же самостоятельно грузит в шейдеры и наконец начинает процесс отрисовки в строго заданном порядке, который даже для forward рендеринга обычно разбит на какие-то нелогичные абстракции, что изначально ещё можно было объяснить наличием фиксированного конвейера, а потом пожалуй просто стало устоявшимся стереотипом. Любопытно, что и для проприетарных, закрытых движков, эта ситуация тоже сохраняется, мы не видим их код, но можем посмотреть на фазы рендеринга в отладчике.
Типично эта ситуация выглядит так:
- рисуем непрозрачные полигоны сцены
- рисуем траву, растительность с альфа-тестом
- рисуем непрозрачные полигоны анимированных моделей NPC
- рисуем полупрозрачные полигоны
- рисуем погодные эффекты
- рисуем всякие флаеры, glow-эффекты
- рисуем скайбокс, облака
- рисуем пушку от первого лица
Где-то внутри мы так же можем допустить дополнительные проходы динамического освещения, но в данном примере это не так уж и важно. Я просто хочу показать сам принцип разбиения рендеринга на какие-то вымученные абстракции. То что имело смысл в первом Quake, с приходом полностью программируемого конвейера его утратило, остались лишь стереотипы, что рендеринг надо организовывать именно таким образом.
Для реализации отложенного освещения рендеринг не упростился, а наоборот - лишь усложнился, т.к. отложка не поддерживает полупрозрачные поверхности. И не все поверхности требуют освещения.
При таком подходе требовать какой-то гибкости от системы материалов попросту невозможно - какие-то крайне ограниченные настройки по месту, как правило отвечающие за подгрузку карты нормалей и карты блеска, а так же факторы этого самого блеска.
Так же стоит заметить, что при массовом внедрении PBR, программисты рендеров вздохнули с облегчением и начали предлагать минималистичный вариант системы материалов, где по сути всё сводилось только к загрузке карты нормалей и специальной pbr-карты, где в разных каналах были закодированы glossines, metalness и emission. Написал бы по-русски, но думаю так понятнее.
Таким образом художники были вообще избавлены от необходимости настраивать материалы какими-то параметрами, всё регулировалось цветом самих текстур. Стало проще настраивать типовые материалы. Но обозначенная выше проблема никуда не исчезла.
При архитектуре, когда рендерер просто копирует из материалов некоторые настройки, а потом рендерит картинку согласно внутреннему жестко определённому порядку никакой минимальной гибкости достичь невозможно.
Насколько я понимаю, единственные кто попытался (во всяком случае анонсировал) решить эту проблему, на данный момент является Юнитех, со своим программируемым рендерером. Но поскольку их реализация ещё не вышла, нам остается только гадать как она будет устроена и не внесёт ли груз былой совместимости в эту стройную концепцию какие-то неустранимые недостатки. Ну а в XashNT подобный конвейер проектировался с самого начала разработки, он уже существует и неплохо работает.