Что такое рендеринг? И что такое рендер? Словарь разработчиков компьютерных игр.

• 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-алгоритма).

If you"re a developer of 3D games, then you"ve probably come across the terms forward rendering and deferred rendering in your research of modern graphics engines. And, often, you"ll have to choose one to use in your game. But what are they, how do they differ, and which one should you pick?

Deferred Rendering for many lights (Image courtesy of Hannes Nevalainen)

Modern Graphics Pipelines

To begin, we need to understand a little bit about modern, or programmable, graphics pipelines.

Back in the day, we were limited in what the video card graphics pipeline had. We couldn"t change how it drew each pixel, aside from sending in a different texture, and we couldn"t warp vertices once they were on the card. But times have changed, and we now have programmable graphics pipelines . We can now send code to the video card to change how the pixels look, giving them a bumpy appearance with normal maps , and adding reflection (and a great deal of realism).

This code is in the form of geometry , vertex , and fragment shaders , and they essentially change how the video card renders your objects.

Forward Rendering

Forward rendering is the standard, out-of-the-box rendering technique that most engines use. You supply the graphics card the geometry, it projects it and breaks it down into vertices, and then those are transformed and split into fragments, or pixels, that get the final rendering treatment before they are passed onto the screen.

It is fairly linear, and each geometry is passed down the pipe one at a time to produce the final image.

Deferred Rendering

In deferred rendering, as the name implies, the rendering is deferred a little bit until all of the geometries have passed down the pipe; the final image is then produced by applying shading at the end.

Now, why would we do that?

Deferred lighting is a modification of deferred rendering that reduces the size of the G-buffer by using more passes on the scene.

Lighting Performance

Lighting is the main reason for going one route versus the other. In a standard forward rendering pipeline, the lighting calculations have to be performed on every vertex and on every fragment in the visible scene, for every light in the scene.

If you have a scene with 100 geometries, and each geometry has 1,000 vertices, then you might have around 100,000 polygons (a very rough estimate). Video cards can handle this pretty easily. But when those polygons get sent to the fragment shader, that"s where the expensive lighting calculations happen and the real slowdown can occur.

Developers try to push as many lighting calculations into the Vertex shader as possible to reduce the amount of work that the fragment shader has to do.

The expensive lighting calculations have to execute for each visible fragment of every polygon on the screen, regardless if it overlaps or is hidden by another polygon"s fragments. If your screen has a resolution of 1024x768 (which is, by all means, not very high-res) you have nearly 800,000 pixels that need to be rendered. You could easily reach a million fragment operations every frame. Also, many of the fragments will never make it to the screen because they were removed with depth testing, and thus the lighting calculation was wasted on them.

If you have a million of those fragments and suddenly you have to render that scene again for each light, you have jumped to x 1,000,000 fragment operations per frame! Imagine if you had a town full of street lights where each one is a point-light source...

The formula for estimating this forward rendering complexity can be written, in big O notation , as O(num_geometry_fragments * num_lights) . You can see here that the complexity is directly related to the number of geometries and number of lights.

Fragments are potential pixels that will end up on the screen if they do not get culled by the depth test.

Now, some engines optimize this, by cutting out lights that are far away, combining lights, or using light maps (very popular, but static). But if you want dynamic lights and a lot of them, we need a better solution.

Deferred Rendering to the Rescue

Deferred Rendering is a very interesting approach that reduces the object count, and in particular the total fragment count, and performs the lighting calculations on the pixels on the screen, thereby using the resolution size instead of the total fragment count.

The complexity of deferred rendering, in big O notation, is: O(screen_resolution * num_lights) .

You can see that it now doesn"t matter how many objects you have on the screen that determines how many lights you use, so you can happily increase your lighting count. (This doesn"t mean you can have unlimited objects-they still have to be drawn to the buffers to produce the final rendering result.)

Let"s see how it works.

The Guts of Deferred Rendering

Every geometry is rendered, but without light shading, to several screen space buffers using multiple render targets . In particular, the depth, the normals, and the color are all written to separate buffers (images). These buffers are then combined to provide enough information for each light to light the pixels.

By knowing how far away a pixel is, and its normal vector, we can combine the color of that pixel with the light to produce our final render.

Which to Pick?

The short answer is, if you are using many dynamic lights then you should use deferred rendering. However, there are some significant drawbacks:

• This process requires a video card with multiple render targets. Old video cards don"t have this, so it won"t work on them. There is no workaround for this.
• It requires high bandwidth. You"re sending big buffers around and old video cards, again, might not be able to handle this. There is no workaround for this, either.
• You can"t use transparent objects. (Unless you combine deferred rendering with Forward Rendering for just those transparent objects; then you can work around this issue.)
• There"s no anti-aliasing. Well, some engines would have you believe that, but there are solutions to this problem: edge detection , FXAA .
• Only one type of material is allowed, unless you use a modification of deferred rendering called Deferred Lighting .
• Shadows are still dependent on the number of lights, and deferred rendering does not solve anything here.

If you don"t have many lights or want to be able to run on older hardware, then you should stick with forward rendering and replace your many lights with static light maps. The results can still look amazing.

Conclusion

I hope that has shed some light on the subject. Your options are there to solve your rendering problems, but it is very important to choose the right one at the start of your game development to avoid difficult changes later on.

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

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

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

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

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

Что такое Рендеринг в 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 дизайнера, так и у пользователя видеоредактора, процесс рендеринга идет автоматически и без участия пользователя. Все что требуется, это задать некоторые параметры перед стартом.

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

Отложенное освещение и затенение , отложенный рендеринг (англ. deferred shading ) - программная техника (методика) в трёхмерной компьютерной графике, которая обрабатывает освещение и затенение визуальной сцены. В результате работы алгоритма отложенного освещения и затенения процесс вычисления разбивается на меньшие части, которые записываются в промежуточную буферную память и объединяются потом. Главным отличием отложенного освещения и затенения от стандартных методов освещения является то, что эти методы немедленно записывают результат работы шейдера во фреймбуфер цвета. Реализации в современных аппаратных средствах по обработке графики имеют тенденцию использовать множественные цели рендеринга (англ. multiple render targets - MRT ) для избежания избыточных трансформаций вершин. Обычно, как только построены все необходимые буферы, они затем считываются (обычно как вводная текстура) из шейдерного алгоритма (например, уравнение освещения) и объединяются для создания результата. В этом случае вычислительная сложность и полоса пропускания памяти, необходимые для рендеринга сцены, уменьшаются до видимых частей, таким образом уменьшая сложность освещаемой сцены.

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

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

Другим довольно важным недостатком отложенного рендеринга является несовместимость со сглаживанием. Так как стадия освещения отделена от стадии геометрии, то аппаратный анти-алиасинг не приводит к правильным результатам. Хотя первый проход, используемый при рендеринге базовых свойств (диффузная обработка, карта высот), может использовать сглаживание, к полному освещению сглаживание неприменимо. Одной из стандартных методик для преодоления этого ограничения является метод выделения границ (en:edge detection) финального изображения и затем применения размытия к граням (границам).

Методика отложенного рендеринга всё более часто используется в компьютерных играх, так как допускает использование неограниченного количества источников света и уменьшает сложность необходимых шейдерных инструкций. В частности, «Advanced Technology Group», команда специалистов компании Sony Computer Entertainment, исследовала эту область и помогает разработчикам встраивать эту технологию в графические движки. PhyreEngine, бесплатный графический движок разработки Sony Computer Entertainment, имеет поддержку отложенного освещения и затенения. Примерами игр, использующих отложенный рендеринг и разработку которых поддержала Sony Computer Entertainment, являются Killzone 2 разработки Guerrilla Games, LittleBigPlanet разработки Media Molecule и inFamous разработки Sucker Punch Productions. К играм, использующим отложенный рендеринг, но в разработке которых Sony не принимала участие, являются серия игр S.T.A.L.K.E.R. разработки GSC Game World, Dead Space разработки Electronic Arts и Tabula Rasa разработки NCSoft. Технология отложенного освещения и затенения используется в игровом движке CryEngine 3 разработки Crytek.

Идея отложенного освещения и затенения изначально была представлена Майклом Дирингом (en:Michael Deering) и его коллегами в работе под названием «The triangle processor and normal vector shader: a VLSI system for high performance graphics», опубликованной в 1988 году. Хотя в работе нигде не используется слово «отложенный», концепция, представленная там, только недавно нашла практическое применение в таких приложениях, как компьютерные игры.

Примечания

1. NVIDIA SDK 9.51 - Featured Code Samples - download.nvidia.com/developer/SDK/Individual_Samples/featured_samples.html. NVIDIA (2007-01-17).
2. Deferred shading tutorial - www710.univ-lyon1.fr/~jciehl/Public/educ/GAMA/2007/Deferred_Shading_Tutorial_SBGAMES2005.pdf. Pontifical Catholic University of Rio de Janeiro.
3. Dead Space by Electronic Arts - nzone.com/object/nzone_deadspace_feature.html. NVIDIA.
4. Deferred shading in Tabula Rasa - developer.nvidia.com/GPUGems3/gpugems3_ch19.html. NVIDIA.
5. Deering, Michael; Stephanie Winner, Bic Schediwy, Chris Duffy, Neil Hunt. «The triangle processor and normal vector shader: a VLSI system for high performance graphics». ACM SIGGRAPH Computer Graphics 22 (4): 21–30.
6. Deferred Shading - download.nvidia.com/developer/presentations/2004/6800_Leagues/6800_Leagues_Deferred_Shading.pdf (PDF). NVIDIA.
7. Klint, Josh. «Deferred Rendering in Leadwerks Engine - www.leadwerks.com/files/Deferred_Rendering_in_Leadwerks_Engine.pdf».

«Рендеринг» – все чаще мы встречаемся с этим новым и совсем не понятным словом. Игры, программы и, с не таких давних пор, профессии – всюду мы встречаемся с ним. Так что же такое рендеринг?

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

Рендеринг 3D модели

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

Однако в контексте под рендерингом могут иметь ввиду совсем другие вещи. Например, принимая вас на роботу, под данным требованием могут подразумевать навыки создания 3D графики, тогда как это только последний этап её создания.

Кто занимается рендерингом?

Все этапы создания 3D модели

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

И, конечно же, 3D дизайнер занимается не только рендерингом, но и всеми предшествующими этапами создания 3D графики, а именно: моделирование, текстурирование, освещение, анимация и только после – визуализация.

Однако, 3D дизайнер не работает с математическими и физическими формулами, описывая их языками программирования. Все это за него делают программы компиляторы (3D Max, Maya, Cinema 4D, Zbrush, Blender и т.д.) и уже написанных библиотек физических свойств (ODE, Newton, PhysX, Bullet и т.п.).

Отдельно среди перечисленных выше программ, позволяющих создавать 3D графику нужно выделить бесплатную программу – графические движки специально для рендеринга, с помощью которого можно не только создавать «картинки», но и реализовать целую, а главное полноценную компьютерную игру. К примеру «Torchlight» в качестве игрового движка использует именно OGRE.

Ну, а для обработки такого количества и качества графических сцен настольного компьютера будет не достаточно, поэтому в последнее время для рендеринга делают не только программы но и сервисы для обработки их процессов, такие как «рендер ферма». И стоит заметить, что удовольствие это не из дешевых, не смотря на низкие цены рендер фермы цена рендеринга получается довольно внушительной – 3,9 центов / ГГц-час.

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