Отложенный рендеринг. Что такое. Кто занимается рендерингом

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

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

Что такое рендеринг? (для программистов)

Итак, Википедия дает такое определение: Ре́ндеринг (англ. rendering - «визуализация») - термин в компьютерной графике, обозначающий процесс получения изображения по модели с помощью компьютерной программы.

Довольно неплохое определение, продолжим с ним. Рендеринг — это визуализация. В компьютерной графике и 3д-художники и программисты под рендерингом понимают создание плоской картинки - цифрового растрового изображения из 3д сцены.
То есть, неформальный ответ на наш вопрос «Что такое рендеринг?» — это получение 2д картинки (на экране или в файле не важно). А компьютерная программа, производящая рендеринг, называется рендером (англ. render) или рендерером (англ. renderer).

Рендер

В свою очередь словом «рендер» называют чаще всего результат рендеринга. Но иногда и процесс называют так же (просто в английском глагол — render перенесся в русский, он короче и удобнее). Вы, наверняка, встречали различные картинки в интернете, с подписью «Угадай рендер или фото?». Имеется ввиду это 3D-визуализация или реальная фотография (уж настолько компьютерная графика продвинулась, что порой и не разберешься).

Виды рендеринга

В зависимости от возможности сделать вычисления параллельными существуют:

• многопоточный рендеринг — вычисления выполняются параллельно в несколько потоков, на нескольких ядрах процессора,
• однопоточный рендеринг — в этом случае вычисления выполняются в одном потоке синхронно.

Существует много алгоритмов рендеринга, но все их можно разделить на две группы по принципу получения изображения: растеризация 3д моделей и трасировка лучей. Оба способа используются в видеоиграх. Но трасировка лучей чаще используется не для получения изображений в режиме реального времени, а для подготовки так называемых лайтмапов — световых карт, которые предрасчитываются во время разработки, а после результаты предрасчета используются во время выполнения.

В чем суть методов? Как работает растеризация и трасировка лучей? Начнем с растеризация.

Растеризация полигональной модели

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

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

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

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

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

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

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

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

Трасировка лучей (англ. ray tracing )

Помните о корпускулярно волновом дуализме? Напомню в чем суть: свет ведёт себя и как волны и как поток частиц — фотонов. Так вот трассировка (от англ «trace» прослеживать путь), это симуляция лучей света, грубо говоря. Но трассирование каждого луча света в сцене непрактично и занимает неприемлемо долгое время.

Мы ограничимся относительно малым количеством, и будем трассировать лучи по нужным нам направлениям.
А какие направления нам нужны? Нам надо определять какие цвета будут иметь пиксели в результирующей картинке. Тоесть количество лучей мы знаем, оно равно количеству пикселей в изображении.

Что с направлением? Все просто, мы будем трассировать лучи в соответствии с точкой наблюдения (то как наша виртуальная камера направлена). Луч встретится в какой-то точке с объектом сцены (если не встретится, значит там темный пиксель или пиксель неба из скайбокса, например).

При встрече с объектом луч не прекращает своё распространение, а разделяется на три луча-компонента, каждый из которых вносит свой вклад в цвет пикселя на двумерном экране: отражённый, теневой и преломлённый. Количество таких компонентов определяет глубину трассировки и влияет на качество и фотореалистичность изображения. Благодаря своим концептуальным особенностям, метод позволяет получить очень фотореалистичные изображения, однако из-за большой ресурсоёмкости процесс визуализации занимает значительное время.

Рендеринг для художников

Но рендеринг это не только программная визуализация! Хитрые художники тоже используют его. Так что такое рендеринг с точки зрения художника? Примерно то же самое, что и для программистов, только концепт-художники выполняют его сами. Руками. Точно так же как рендерер в видео-игре или V-ray в Maya художники учитывают освещение, подповерхностное рассеивание, туман и др. факторы, влияющие на конечный цвет поверхности.

К примеру картинка выше, поэтапно прорабатывается таким образом: Грубый скетч — Лайн — Цвет — Объем — Рендер материалов.

Рендер материалов включает в себя текстурирование, проработку бликов — металлы, например, чаще всего очень гладкие поверхности, которые имеют четкие блики на гранях. Помимо всего этого художники сталкиваются с растеризацией векторной графики, это примерно то же самое, что и растеризация 3д-модели.

Растеризация векторной графики

Суть примерно такая же, есть данные 2д кривых, это те контуры, которыми заданы объекты. У нас есть конечное растровое изображение и растеризатор переводит данные кривых в пиксели. После этого у нас нет возможности масштабировать картинку без потери качества.

Читайте дальше

• — простое объяснение сложных и страшных шейдеров
• — Полезный обзор частиц и подборка видео-уроков, по созданию спецэффектов в Unity3d

Послесловие

В этой статье, я надеюсь, вы осили столько букв, вы получили представление о том, что такое рендеринг, какие виды рендеринга существуют. Если какие-то вопросы остались — смело задавайте их в комментариях, я обязательно отвечу. Буду благодарен за уточнения и указания на какие-то неточности и ошибки.

Note : Deferred Lighting is considered a legacy feature starting with Unity 5.0, as it does not support some of the rendering features (e.g. Standard shader, reflection probes). New projects should consider using Deferred Shading rendering path instead.

NOTE: Deferred rendering is not supported when using Orthographic projection. If the camera’s projection mode is set to Orthographic, the camera will always use Forward rendering.

Обзор

Тип рендеринга Deferred Lighting имеет высочайшее качество освещения и теней. При таком типе не существует ограничений на количество источников света, влияющих на один объект и всё источники света просчитывается попиксельно, что позволяет им корректно работать с картами нормалей и т.д. Кроме того, все источники света могут иметь тени и cookie текстуры.

Преимущество отложенного освещение в том, что потребление ресурсов при просчёте освещения пропорционально количеству освещаемых пикселей. Оно определяется размером светового объёма в сцене и не зависит от количества освещаемых объектов. Поэтому, можно использовать небольшие источники освещения для улучшения производительности. Также отложенное освещение имеет очень логичное и предсказуемое поведение. Результат работы каждого источника освещения просчитывается попиксельно, поэтому тут не производится расчётов освещения, которые “запинаются” на больших треугольниках и т.д.

С другой стороны, отложенное освещение не имеет настоящей поддержки anti-aliasing’а (сглаживание изображения) и не может обрабатывать полупрозрачные объекты (такие объекты должны отрисовываться с помощью упреждающего рендеринга). Также не поддерживается опция Receive Shadows (получать тени) компонента Mesh Renderer и culling masks (маски выборочного рендеринга по слоям) поддерживаются только в ограниченной форме. Если быть точнее, то вы можете использовать не более четырёх culling масок. Следовательно, culling маска слоёв должна содержать как минимум все слои минус 4 произвольных слоя, то есть, к примеру, должно быть установлено 28 слоёв из 32. Иначе могут появиться графические артефакты.

Требования

It requires a graphics card with Shader Model 3.0 (or later), support for Depth render textures and two-sided stencil buffers. Most PC graphics cards made after 2004 support deferred lighting, including GeForce FX and later, Radeon X1300 and later, Intel 965 / GMA X3100 and later. On mobile, all OpenGL ES 3.0 capable GPUs support deferred lighting, and some of OpenGL ES 2.0 capable ones support it too (the ones that do support depth textures).

Вопросы производительности

Потребление ресурсов источниками динамического освещения при отложенном освещении пропорционально количеству освещаемых пикселе и не зависит от сложности сцены. Так что для рендеринга небольших точечных или прожекторных источников света требуется не много ресурсов, а если они полностью или частично закрыты другими объектами в сцене - то требуется ещё меньше.

Конечно, источники света с тенями требуют намного больше ресурсов, чем источники света без теней. При отложенном освещении, объекты, отбрасывающие тени, всё ещё должны отрисовываться один или более раз для каждого источника освещения с отбрасываемыми тенями. Более того, шейдер освещения, применяющий тени, имеет большее потребление ресурсов при отрисовке, чем в случае с отключенными тенями.

Детали реализации

При включенном отложенном освещении, процесс отрисовки в Unity происходит в 3 прохода:-

1. Базовый проход: объекты рендерятся для создания буферов экранного пространства с глубиной, нормалями и степенью зеркальности.
2. Проход освещения: буферы, созданные на предыдущем шаге, используются для расчёта освещения в другой буфер экранного пространства.
3. Финальный проход: объекты снова рендерятся. Они получают рассчитанное освещение, объединяют его с цветными текстурами и добавляют любое излучаемое освещение или освещение окружения.

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

Базовый проход

Базовый проход рендерит каждый объект один раз. Нормали экранного пространства и степень зеркальности рендерятся в одну ARDB32 Render Texture (с нормалями в RGB каналах и степенью зеркальности в A). Если платформа и оборудование позволяют считывать содержимое Z-буфера в виде текстуры, тогда глубина рендерится неявно. Если к Z-буферу нет доступа в качестве текстуры, тогда глубина рендерится в дополнительном проходе рендеринга с помощью замены шейдера .

Результатом базового прохода является Z-буфер, заполненный содержимым сцены и Render Texture с нормалями и степенью зеркальности.

Проход освещения

Проход освещения рассчитывает освещение, основанное на глубине, нормалях и степени зеркальности. Освещение рассчитывается в экранном пространстве, так что время, требуемое на расчёты не зависит от сложности сцены. Буфер освещения - это одна ARGB32 Render Texture, с диффузным освещением в RGB каналах и монохромным зеркальным освещением в канале A. Значения освещения кодируются логарифмически, для обеспечения большего динамического диапазона, чем обычно доступно при использовании ARGB32 текстуры. Единственная модель освещения, доступная при отложенном освещении - это Blinn-Phong.

Точечные и прожекторные источники света, не пересекающие ближайшую плоскость камеры, рендерятся как 3D формы, с включенным тестом Z-буфера против сцены. Это позволяет тратить немного ресурсов на рендеринг частично или полностью скрытых точечных и прожекторных источников света. Если направленные источники света и точечные/прожекторные источники света пересекают ближайшую плоскость камеры, то они рендерятся в виде полноэкранных квадов.

The above doesn’t apply to directional lights, which are always rendered as fullscreen quads.

Если у источника света включены тени, то они тоже рендерятся и применяются в этом проходе. Учтите, что тени не даются “даром”; требуется рендеринг отбрасывающих тень объектов и к ним должен применяться шейдер с более сложным расчётом освещения.

Единственная доступная модель освещения - Blinn-Phong. Если вы желаете использовать другую модель, вы можете изменить шейдер прохода освещения, разместив изменённую версию файла Internal-PrePassLighting.shader из набора в папке с именем “Resources” в вашей папке “Assets”.

Финальный проход

Финальный проход производит итоговое отрисованное отображение. Здесь все объекты отрисовываются ещё раз шейдерами, которые получают освещение, совмещают его с текстурами и добавляют излучаемое освещение. Карты освещения также применяются в финальном проходе. Вблизи камеры используется динамическое освещение и добавляется только запечённое непрямое освещение. Это переходит в полностью запечённое освещение вдали от камеры.

Детали упреждающего типа рендеринга

Подробности способа рендеринга вершинного освещения

Полностью исходный код содержится в примерах, доступных по ссылке в конце статьи.

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

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

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

Однако даже этот подход можно еще больше оптимизировать - дело в том, что далеко не все фрагменты, соответствующие границе области влияния источника света, на самом деле попадают в эту область (см. рис 6).

Рис 6. Часть сферы, действительно требующая обработки.

Как видно из данного рисунка необходимо вычислять освещенность только для тех фрагментов нелицевой части границы области влияния источника (сферы), для которых не пройден тест глубины.

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

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

При этом выигрыш получается за счет того, что шейдер освещения, являющийся гораздо более "тяжелым" выполнится для гораздо меньшего числа точек - только тех, для которых он играет значение. Т.е. цена прохода вычисляющего освещение становится заметно ниже, а цена первого прохода, осуществляющего только запись в буфер трафарета, очень низка, что и дает выигрыш.

Таким образом, первый проход запрещает запись во все буфера, кроме буфера трафарета, устанавливает отсечение лицевых граней, в качестве теста глубины задает режим GL_LESS, в качестве теста трафарета задает режим GL_ALWAYS и задает операцию GL_REPLACE для тех фрагментов, для которых не пройден тест глубины.

В результате этого прохода у нас в буфере трафарета будут помечены заданным значением только те пикселы, которые требуют освещения.

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

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

После этого идет освещение нужных участков сцены. Фрагментный шейдер для этого очень прост, использует всего 3-4 текстуры, общие для всех источников света.

Поэтому стоимость освещения определяется фактически только количеством реально освещаемых пикселов для каждого источника света.

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

Однако далеко не для всех источников света нужны тени и даже для отбрасывающих тени источников света обновление их теневых карт можно осуществлять довольно редко (и используя сильно упрощенные модели при построении теневых карт).

Еще одним вариантом оптимизации работы с большим количеством источников света заключается в разбиении окна на набор одинаковых прямоугольников (см рис 7). После это на CPU для каждого такого прямоугольника составляется список всех источников света, освещающих его точки.

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

Рис 7.Разбиения окна на прямоугольники для локализации небольших источников света.

Довольно часто возможность поддерживать одновременно сотни источников света используется для моделирования глобальной освещенности - создается ряд "фиктивных" источников света, моделирующих отбрасывание света освещаемыми поверхностями (так называемое вторичное освещение).

Для этого от "настоящих" источников света трассируется некоторое количество лучей и в точках попадания этих лучей на поверхности сцены создаются фиктивные источники света (цвет и интенсивность этих источников определяются цветом поверхности в месте попадания луча и расстоянием до исходного источника света).

При этом положения этих источников (равно как и их яркость и цвет) изменяются довольно редко и обычно нет никакой необходимости в отбрасывания этими источниками теней. Это позволяет достаточно эффективно использовать deferred shading для подобного имитирования глобальной освещенности.

В игре STALKER была также реализована еще одна интересная идея - кроме двух цветов в одном из свободных каналов G-буфера хранится номер (индекс) материала - materialId .

На этапе освещения materialId используется для выбора слоя из 3D-текстуры, определяющей свойства материала. Фактически основным свойством материала является то, как по двум скалярным произведениям - (n,l) и (n,h) - получить коэффициенты смешивания двух базовых цветов с учетом собственной светимости материала (в игре ряд объектов обладают собственной светимостью, например, глаза монстров).

Таким образом все свойства материала были сведены в одну трехмерную текстуру, для индексирования которой использовались два скалярных произведения ((n,l) и (n,h) ) и индекс материала. В результате получались коэффициенты для смешивания цветов и собственной светимости. При этом по утверждениям разработчиков выяснилось, что принципиально разных материалов крайне мало.

За счет этого удалось прийти к очень небольшому числу материалов (не более 10), размер текстуры для индексирования по (n,l) был взят равным 16, для индексирования по (n,h) - равным 256.

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

В DX10.1-версии deferred shading "а в игре STALKER:Чисто небо была использована интересная оптимизация - использовался G -буфер, состоящий всего из двух текстур. В одной текстуре формата RGBA8 хранился диффузный цвет (в RGB компонентах) и собственная светимость em (в альфа-компоненте). Вторая текстура (формата RGBA_16F) в первой компоненте хранила z eye , во второй и третьей - n x и n н , в четвертую были упакованы сразу две величины - materialId и ambient occlusion .

Рис 8. Строение G-буфера в игре STALKER:Чистое Небо.

За счет использования подобного подхода удалось заметно сократить количество бит на один пиксел. Обратите внимание на то, что используемые текстуры имеют разное количество бит на пиксел - подобная возможность (использования при MRT текстур с разным числом бит на пиксел) появилась на GPU с 4-й шейдерной моделью (GeForce 8xxx).

Построенный G -буфер можно также использовать и для реализации ряда других эффектов, таких как слоистый туман, мягкие частицы , screen-space ambient ocllusion(SSAO) и др.

Алгоритм deferred shading кроме ряда плюсов обладает и некоторыми недостатками - он не поддерживает полупрозрачные объекты и стандартные средства антиалиасинга довольно плохо ложатся на его архитектуру.

Однако есть пути обхода этих недостатков. Так для работы с полупрозрачными объектами традиционным приемом является (как и при традиционном способе рендеринга) - отсортировать и вывести все полупрозрачные объекты уже после вывода и освещения всей сцены (используя при этом буфер глубины с первого прохода).

Это может дать и некоторые плюсы - так при рендеринге воды, можно использовать значения z для дна, для точного расчета преломления.

На сайте Humus" а можно скачать альтернативный вариант работы с полупрозрачными объектами в deferred shading , только этот пример требует DX10 (а значит и убожество под названием m$ vi$ta).

В книге ShaderX7 был предложен довольно красивый способ работы с полупрозрачными объектами, не требующий увеличения размера G -буфера. Идея подхода крайне проста - мы сохраняем альфа-значения для фрагментов в G -буфере (например в альфа-канале диффузного цвета) и полупрозрачный объект выводится через строку. При этом у нас в G -буфере оказывается как информация о полупрозрачной поверхности, так и информация о том, что лежит за ней.

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

Рендеринг (rendering) – завершающий этап обработки сцен, полученных в результате 3d-визуализации. Различают две основных стадии этого процесса – в реальном времени, используют преимущественно в компьютерных играх, и пре-рендеринг. Именно он нашел применение в бизнесе. В первом случае большее значение имеет скорость выполнения расчетов, только при соблюдении этого условия качество изображений останется высоким. При предварительном рендеринге в приоритете реалистичность рисунка.

Пре-рендеринг

Для выполнения рендеринга этого типа используют особое программное обеспечение. Продолжительность обработки зависит от ее сложности. Процесс состоит из наложения света и образуемых им теней, добавления цвета, иных эффектов. Главная задача моделлеров – добиться, чтобы результат был предельно правдивым, для чего необходимо ориентироваться в одном из самых сложных разделов физики – оптике. Грамотно выполненный рендеринг особенно важен в 3d-моделировании интерьеров – надо точно просчитать, как будет выглядеть помещение при естественном и искусственном освещении, подобрать оттенки предметов обстановки, иные нюансы. Основные методы финальной обработки при объемном проектировании:

Принято использовать комбинацию нескольких методов, что позволяет снизить затраты ресурсов и обеспечить требуемое качество.

Особенности рендеринга

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

• раскраска;
• детализация мелких элементов;
• проработка световых эффектов – отражения потоков, теней и прочих;
• отображение климатических условий;
• реализация иных деталей, позволяющих повысить реалистичность.

Сложность обработки влияет на формирование цены 3d-визуализации , чем больше потребуется времени, тем дороже обойдется работа над проектом. По возможности моделлеры упрощают процесс рендеринга, к примеру, просчитывают отдельные моменты или используют другие инструменты, позволяющие сократить время визуализации без ухудшения ее качества.