Что означает рендеринг. Введение в Deferred Rendering

Рендеринг

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

• Растеризация (англ. rasterization ) совместно с методом сканирования строк (англ. scanline rendering ). Визуализация производится проецированием объектов сцены на экран без рассмотрения эффекта перспективы относительно наблюдателя.
• Ray casting (рейкастинг ) (англ. ray casting ). Сцена рассматривается, как наблюдаемая из определённой точки. Из точки наблюдения на объекты сцены направляются лучи, с помощью которых определяется цвет пиксела на двумерном экране. При этом лучи прекращают своё распространение (в отличие от метода обратного трассирования), когда достигают любого объекта сцены либо её фона. Возможно использование каких-либо очень простых способов добавления оптических эффектов. Эффект перспективы получается естественным образом в случае, когда бросаемые лучи запускаются под углом, зависящим от положения пикселя на экране и максимального угла обзора камеры.
• Трассировка лучей (англ. ray tracing ) похожа на метод бросания лучей. Из точки наблюдения на объекты сцены направляются лучи, с помощью которых определяется цвет пиксела на двумерном экране. Но при этом луч не прекращает своё распространение, а разделяется на три компонента, луча, каждый из которых вносит свой вклад в цвет пиксела на двумерном экране: отражённый, теневой и преломленный. Количество таких разделений на компоненты определяет глубину трассирования и влияет на качество и фотореалистичность изображения. Благодаря своим концептуальным особенностям, метод позволяет получить очень фотореалистичные изображения, но при этом он очень ресурсоёмкий, и процесс визуализации занимает значительные периоды времени.
• Трассировка пути (англ. path tracing ) содержит похожий принцип трассировки распространения лучей, однако этот метод является самым приближенным к физическим законам распространения света. Также является самым ресурсоёмким.

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

Математическое обоснование

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

Основное уравнение

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

Неформальное толкование таково: Количество светового излучения (L o), исходящего из определённой точки в определённом направлении есть собственное излучение и отражённое излучение. Отражённое излучение есть сумма по всем направлениям приходящего излучения (L i), умноженного на коэффициент отражения из данного угла. Объединяя в одном уравнении приходящий свет с исходящим в одной точке, это уравнение составляет описание всего светового потока в заданной системе.

Программное обеспечение для рендеринга - рендеры (визуализаторы)

• 3Delight
• AQSIS
• BMRT (Blue Moon Rendering Tools) (распространение прекращено)
• BusyRay
• Entropy (продажи прекращены)
• Fryrender
• Gelato (разработка прекращена в связи с покупкой NVIDIA , mental ray)
• Holomatix Renditio (интерактивный рейтрейсер)
• Hypershot
• Keyshot
• Mantra renderer
• Meridian
• Pixie
• RenderDotC
• RenderMan (PhotoRealistic RenderMan, Pixar’s RenderMan или PRMan)
• Octane Render
• Arion Renderer

Рендереры, работающие в реальном (или почти в реальном) времени.

• VrayRT
• Shaderlight
• Showcase
• Rendition
• Brazil IR
• Artlantis Render

• Autodesk 3ds Max (Scanline)
• e-on Software Vue
• SideFX Houdini
• Terragen , Terragen 2

Таблица сравнения свойств рендеров

См. также

• Алгоритмы использующие z-буфер и Z-буферизация
• Алгоритм художника
• Алгоритмы построчного сканирования like Reyes
• Алгоритмы глобального освещения
• Излучательность
• Текст как изображение

Хронология важнейших публикаций

• 1968 Ray casting (Appel, A. (1968). Some techniques for shading machine renderings of solids. Proceedings of the Spring Joint Computer Conference 32 , 37-49.)
• 1970 Scan-line algorithm (Bouknight, W. J. (1970). A procedure for generation of three-dimensional half-tone computer graphics presentations. Communications of the ACM )
• 1971 Gouraud shading (Gouraud, H. (1971). Computer display of curved surfaces. IEEE Transactions on Computers 20 (6), 623-629.)
• 1974 Texture mapping PhD thesis , University of Utah.)
• 1974 Z-buffer (Catmull, E. (1974). A subdivision algorithm for computer display of curved surfaces. PhD thesis )
• 1975 Phong shading (Phong, B-T. (1975). Illumination for computer generated pictures. Communications of the ACM 18 (6), 311-316.)
• 1976 Environment mapping (Blinn, J.F., Newell, M.E. (1976). Texture and reflection in computer generated images. Communications of the ACM 19 , 542-546.)
• 1977 Shadow volumes (Crow, F.C. (1977). Shadow algorithms for computer graphics. Computer Graphics (Proceedings of SIGGRAPH 1977) 11 (2), 242-248.)
• 1978 Shadow buffer (Williams, L. (1978). Casting curved shadows on curved surfaces. 12 (3), 270-274.)
• 1978 Bump mapping (Blinn, J.F. (1978). Simulation of wrinkled surfaces. Computer Graphics (Proceedings of SIGGRAPH 1978) 12 (3), 286-292.)
• 1980 BSP trees (Fuchs, H. Kedem, Z.M. Naylor, B.F. (1980). On visible surface generation by a priori tree structures. Computer Graphics (Proceedings of SIGGRAPH 1980) 14 (3), 124-133.)
• 1980 Ray tracing (Whitted, T. (1980). An improved illumination model for shaded display. Communications of the ACM 23 (6), 343-349.)
• 1981 Cook shader (Cook, R.L. Torrance, K.E. (1981). A reflectance model for computer graphics. Computer Graphics (Proceedings of SIGGRAPH 1981) 15 (3), 307-316.)
• 1983 Mipmaps (Williams, L. (1983). Pyramidal parametrics. Computer Graphics (Proceedings of SIGGRAPH 1983) 17 (3), 1-11.)
• 1984 Octree ray tracing (Glassner, A.S. (1984). Space subdivision for fast ray tracing. 4 (10), 15-22.)
• 1984 Alpha compositing (Porter, T. Duff, T. (1984). Compositing digital images. 18 (3), 253-259.)
• 1984 Distributed ray tracing (Cook, R.L. Porter, T. Carpenter, L. (1984). Distributed ray tracing. Computer Graphics (Proceedings of SIGGRAPH 1984) 18 (3), 137-145.)
• 1984 Radiosity (Goral, C. Torrance, K.E. Greenberg, D.P. Battaile, B. (1984). Modelling the interaction of light between diffuse surfaces. Computer Graphics (Proceedings of SIGGRAPH 1984) 18 (3), 213-222.)
• 1985 Hemi-cube radiosity (Cohen, M.F. Greenberg, D.P. (1985). The hemi-cube: a radiosity solution for complex environments. Computer Graphics (Proceedings of SIGGRAPH 1985) 19 (3), 31-40.)
• 1986 Light source tracing (Arvo, J. (1986). Backward ray tracing. SIGGRAPH 1986 Developments in Ray Tracing course notes )
• 1986 Rendering equation (Kajiya, J.T. (1986). The rendering equation. Computer Graphics (Proceedings of SIGGRAPH 1986) 20 (4), 143-150.)
• 1987 Reyes algorithm (Cook, R.L. Carpenter, L. Catmull, E. (1987). The reyes image rendering architecture. Computer Graphics (Proceedings of SIGGRAPH 1987) 21 (4), 95-102.)
• 1991 Hierarchical radiosity (Hanrahan, P. Salzman, D. Aupperle, L. (1991). A rapid hierarchical radiosity algorithm. Computer Graphics (Proceedings of SIGGRAPH 1991) 25 (4), 197-206.)
• 1993 Tone mapping (Tumblin, J. Rushmeier, H.E. (1993). Tone reproduction for realistic computer generated images. IEEE Computer Graphics & Applications 13 (6), 42-48.)
• 1993 Subsurface scattering (Hanrahan, P. Krueger, W. (1993). Reflection from layered surfaces due to subsurface scattering. Computer Graphics (Proceedings of SIGGRAPH 1993) 27 (), 165-174.)
• 1995 Photon mapping (Jensen, H.J. Christensen, N.J. (1995). Photon maps in bidirectional monte carlo ray tracing of complex objects. Computers & Graphics 19 (2), 215-224.)
• 1997 Metropolis light transport (Veach, E. Guibas, L. (1997). Metropolis light transport. Computer Graphics (Proceedings of SIGGRAPH 1997) 16 65-76.)

Что такое Рендер (Рендеринг)

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

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

слова «Рендер».

Слово Рендер (Рендеринг) — это англицизм, который зачастую переводится на русский язык словом “Визуализация ”.

Что такое Рендеринг в 3D?

Чаще всего, когда мы говорим о рендере, то имеем в виду рендеринг в 3D графике. Сразу стоит отметить, что на самом деле в 3D рендере нету трех измерений как таковых, которые мы зачастую можем увидеть в кинотеатре надев специальные очки. Приставка “3D” в название скорее говорит нам о способе создание рендера, который и использует 3-х мерные объекты, созданные в компьютерных программах для 3D моделирования. Проще говоря, в итоге мы все равно получаем 2D изображение или их последовательность (видео) которые создавались (рендерелись) на основе 3-х мерной модели или сцены.

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

Построение изображения.

Как уже говорилось ранее, рендеринг — это один из самых сложных технических этапов, ведь во время рендеринга идут сложные математические вычисления, выполняемые движком рендера. На этом этапе, движок переводит математические данные о сцене в финальное 2D-изображение. Во время процесса идет преобразование 3d-геометрии, текстур и световых данных сцены в объединенную информацию о цветовом значение каждого пикселя в 2D изображение. Другими словами, движок на основе имеющихся у него данных, просчитывает то, каким цветом должен быть окрашено каждый пиксель изображения для получения комплексной, красивой и законченной картинки.

Основные типы рендеринга:

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

Что такое Рендеринг в реальном времени?

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

Поскольку ключевым фактором в таком типе рендеринга есть интерактивность со стороны пользователя, то изображение приходится просчитывать без задержек и практически в реальном времени, так как невозможно точно предсказать поведение игрока и то, как он будет взаимодействовать с игровой или с интерактивной сценой. Для того, чтоб интерактивная сцена или игра работала плавно без рывков и медлительности, 3D движку приходится рендерить изображение со скоростью не менее 20-25 кадров в секунду. Если скорость рендера будет ниже 20 кадров, то пользователь будет чувствовать дискомфорт от сцены наблюдая рывки и замедленные движения.

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

Что такое Предварительный рендер?

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

В отличие от Рендера в реальном времени, где основная нагрузка приходилась на графические карты(GPU) В предварительном рендере нагрузка ложится на центральный процессор(ЦП) а скорость рендера зависит от количества ядер, многопоточности и производительности процессора.

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

Программы для рендеринга.

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

Как правило, рендер движки являются встроенными в крупные 3D программы для работы с графикой и имеют огромный потенциал. Среди наиболее популярных 3D программ (пакетов) есть такой софт как:

• 3ds Max;
• Maya;
• Blender;
• Cinema 4d и др.

Многие из этих 3D пакетов имеют уже идущие в комплекте рендер движки. К примеру, рендер-движок Mental Ray присутствует в пакете 3Ds Max. Также, практически любой популярный рендер-движок, можно подключить к большинству известных 3d пакетов. Среди популярных рендер движков есть такие как:

• V-ray;
• Mental ray;
• Corona renderer и др.

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

Многие рендер-движки сыскали славу в определенных сферах работы с 3д графикой. Так, например, “V-ray” имеет большую популярность у архитектурных визуализаторов, из-за наличия большого количества материалов для архитектурной визуализации и в целом, хорошего качества рендера.

Методы визуализации.

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

1. Scanline (сканлайн).

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

Алгоритм работы:

Вместо рендеринга «пикселя по пикселю», алгоритм функционирования «scanline» рендера заключается в том, что он определяет видимую поверхность в 3D графике, и работая по принципу «ряд за рядом», сперва сортирует нужные для рендера полигоны по высшей Y координате, что принадлежит данному полигону, после чего, каждый ряд изображения просчитывается за счет пересечения ряда с полигоном, который является ближайшим к камере. Полигоны, которые больше не являются видимыми, удаляются при переходе одного ряда к другому.

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

2. Raytrace (рейтрейс).

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

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

Алгоритм работы:

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

Метод Raycasting.

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

Нередко бывает, что «метод трассировки лучей» (raytrace) путают с методом «бросания лучей» (raycasting). Но на самом деле, «raycasting» (метод бросания луча) фактически является упрощенным «raytrace» методом, в котором отсутствует дальнейшая обработка отбившихся или заломленных лучей, а просчитывается только первая поверхность на пути луча.

3. Radiosity.

Вместо «метода трассировки лучей», в данном методе просчет работает независимо от камеры и является объектно-ориентированным в отличие от метода «пиксель по пикселю». Основная функция “radiosity” заключается в том, чтобы более точно имитировать цвет поверхности путем учета непрямого освещения (отскок рассеянного света).

Преимуществами «radiosity» являются мягкие градуированные тени и цветовые отражения на объекте, идущие от соседних объектов с ярким окрасом.

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

Что такое Рендеринг видео?

Иногда, выражение «рендерить» используют не только в работе с компьютерной 3D графикой, но и при работе с видеофайлами. Процесс рендеринга видео начинается тогда, когда пользователь видеоредактора закончил работу над видеофайлом, выставил все нужные ему параметры, звуковые дорожки и визуальные эффекты. По сути, все что осталось, это соединить все проделанное в один видеофайл. Этот процесс можно сравнить с работой программиста, когда он написал код, после чего все что осталось, это скомпилировать весь код в работающую программу.

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

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

• Tutorial

Привет, друг! В этот раз я опять подниму вопрос о графике в ААА -играх. Я уже разобрал методику HDRR (не путать с HDRI) и чуть-чуть поговорил о коррекции цвета. Сегодня я расскажу, что такое SSLR (так же известная как SSPR, SSR): . Кому интересно - под кат.

Введение в Deferred Rendering

В случае с Color map , Normal map вроде все понятно, это обычные Surface.Color текстуры: пожалуй, за исключением того, что вектор нормали может лежать в пределах [-1, 1] (используется простая упаковка вектора в формат ).

А вот ситуация с Depth map становится непонятной. Как же Depth map хранит в себе информацию о позиции пикселя, да еще и одним числом? Если говорить сильно упрощенно, трансформация примитива:

Float4 vertexWVP = mul(vertex, World*View*Projection);

Дает нам экранные координаты:

Float2 UV = vertexWVP.xy;

И некоторую информацию о том, насколько “далеко” от камеры пиксель:

Float depth = vertexWVP.z / vertexWVP.w;

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

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

Float3 GetPosition(float2 UV, float depth) { float4 position = 1.0f; position.x = UV.x * 2.0f - 1.0f; position.y = -(UV.y * 2.0f - 1.0f); position.z = depth; //Transform Position from Homogenous Space to World Space position = mul(position, InverseViewProjection); position /= position.w; return position.xyz; }

Напомню, что для построения GBuffer необходима такая методика как MRT (Multiple Render Targets ), которая рисует модель сразу в несколько Render Target (причем в каждом RT содержится разная информация). Одно из правил MRT - размерность всех Render Target должна быть одинаковой . В случае Color Map , Normal Map - Surface.Color : 32-ух битная RT , где на каждый канал ARGB приходится по 8 бит, т.е. 256 градаций от 0 до 1.

Благодаря такому подходу мы можем применять сложные эффекты к любой геометрии, например самый популярный Screen Space эффект: SSAO (Screen Space Ambient Occlusion). Этот алгоритм анализирует буферы глубины и нормали, считая уровень затенения. Весь алгоритм я описывать не буду, он уже на хабре, скажу лишь то, что задача алгоритма сводится к трассировки карты глубины: у нас есть набор случайных векторов, направленных из считаемого “пикселя” и нам нужно найти кол-во пересечений с геометрией.

Пример эффекта (слева без SSAO, справа с SSAO):

Так же Deferred Shading является Screen Space эффектом. Т.е. для каждого источника света на экране (без всяких оптимизаций) мы рисуем квад в режиме Additive в так называемый RenderTarget : Light Map . И зная мировую позицию “пикселя”, его нормаль, позицию источника света - мы можем посчитать освещенность этого пикселя.

Пример Deferred Shading (освещение выполнено отложено, после отрисовки геометрии):

Достоинства и проблемы Screen Space эффектов

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

Ну и стоит отменить, что Screen Space эффекты выполняются полностью на GPU и являются пост-процессингом.

Наконец SSLR

Для начала разберемся с перспективной проекцией:

Горизонтальный и вертикальный угол зрения задается FOV (обычно 45 градусов, я предпочитаю 60 градусов), в виртуальной камере они разные т.к. учитывается еще и Aspect Ratio (соотношение сторон).

Окно проекции (там, где мы оперируем UV-space данными) - это, что мы видим, на то мы проецируем нашу сцену.
Передняя и задняя плоскости отсечения это соответственно Near Plane, Far Plane , задаются так же в проекцию как параметры. Делать в случае Deferred Rendering слишком большим значением Far Plane стоит, т.к. точность Depth Buffer сильно упадет: все зависит от сцены.

Теперь, зная матрицу проекции и позицию на окне проекции (а так же глубину) для каждого пикселя мы вычисляем его позицию следующим образом:

Float3 GetPosition(float2 UV, float depth) { float4 position = 1.0f; position.x = UV.x * 2.0f - 1.0f; position.y = -(UV.y * 2.0f - 1.0f); position.z = depth; position = mul(position, InverseViewProjection); position /= position.w; return position.xyz; }

После нам нужно найти вектор взгляда на этот пиксель:

Float3 viewDir = normalize(texelPosition - CameraPosition);
В качестве CameraPosition выступает позиция камеры.
И найти отражение этого вектора от нормали в текущем пикселе:

Float3 reflectDir = normalize(reflect(viewDir, texelNormal));
Далее задача сводится к трассировке карты глубины. Т.е. нам нужно найти пересечение отраженного вектора с какой-либо геометрией. Понятное дело, что любая трассировка производится через итерации. И мы в них сильно ограниченны. Т.к. каждая выборка из Depth Map стоит времени. В моем варианте мы берем некоторое начальное приближение L и динамически меняем его исходя из расстояния между нашим текселем и позицией, которую мы “восстановили”:

Float3 currentRay = 0; float3 nuv = 0; float L = LFactor; for(int i = 0; i < 10; i++) { currentRay = texelPosition + reflectDir * L; nuv = GetUV(currentRay); // проецирование позиции на экран float n = GetDepth(nuv.xy); // чтение глубины из DepthMap по UV float3 newPosition = GetPosition2(nuv.xy, n); L = length(texelPosition - newPosition); }

Вспомогательные функции, перевод мировой точки на экранное пространство:

Float3 GetUV(float3 position) { float4 pVP = mul(float4(position, 1.0f), ViewProjection); pVP.xy = float2(0.5f, 0.5f) + float2(0.5f, -0.5f) * pVP.xy / pVP.w; return float3(pVP.xy, pVP.z / pVP.w); }

После завершения итераций мы имеет позицию “пересечения с отраженной геометрией”. А наше значение nuv будет проекцией этого пересечения на экран, т.е. nuv.xy – это UV координаты в экранном нашем пространстве, а nuv.z это восстановленная глубина (т.е. abs(GetDepth(nuv.xy)-nuv.z) должен быть очень маленьким) .

В конце итераций L будет показывать расстояние отраженного пикселя. Последний этап - собственно добавление отражения к Color Map :

Float3 cnuv = GetColor(nuv.xy).rgb; return float4(cnuv, 1);

Разбавим теорию иллюстрациями, исходное изображение (содержание Color Map из GBuffer):

После компиляции шейдера (отражения) мы получим следующую картину (Color Map из GBuffer + результат шейдера SSLR):

Не густо . И тут стоит еще раз напомнить, что Space-Screen эффекты это сплошной Information Lost (примеры выделены в красные рамки).

Дело в том, что если вектор отражения выходит за пределы Space-Screen – информация о Color -карте становится недоступной и мы видим Clamping нашего UV .

Чтобы частично исправить эту проблему, можно ввести дополнительный коэффициент, который будет отражать “дальность” отражения. И далее по этому коэффициенту мы будем затенять отражение, проблема частично решается:

L = saturate(L * LDelmiter); float error *= (1 - L);

Результат, отражение умноженное на error (попытка убрать артефакт SSLR - information lost):

Уже лучше, но мы замечаем еще одну проблему, что будет, если вектор отразится в направлении камеры? Clamping ’а UV происходить не будет, однако, несмотря на актуальность UV (x > 0, y > 0, x < 1, y < 1) он будет неверным:

Эту проблему так же можно частично решить, если как-нибудь ограничить углы допустимых отражений. Для этого идеально подходит фишка с углами от эффекта Френеля :

Float fresnel = dot(viewDir, texelNormal);
Чуть-чуть модифицируем формулу:

Float fresnel = 0.0 + 2.8 * pow(1+dot(viewDir, texelNormal), 2);
Значения Френеля, с учетом Normal-маппинга (значения fresnel-переменной для SSLR-алгоритма).

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

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

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

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

Однако даже этот подход можно еще больше оптимизировать - дело в том, что далеко не все фрагменты, соответствующие границе области влияния источника света, на самом деле попадают в эту область (см. рис 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 - «визуализация») - термин в компьютерной графике, обозначающий процесс получения изображения по модели с помощью компьютерной программы.

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

Рендер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Послесловие

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