Рендеринг opengl включен что это
Рендеринг opengl включен что это
Регулировка аппаратного ускорения 3D
В области переходов Панели управления NVIDIA, в разделе Параметры 3D выберите Управление параметрами 3D, чтобы открыть соответствующую страницу.
На этой «расширенной» странице можно изменить все параметры изображения и рендеринга для 3D-приложений, в которых применяется технология Direct3D или OpenGL.
В группе «Настройки» щелкните настройку, соответствующую функции Ускорение нескольких дисплеев/смешанных ГП и выберите один из следующих параметров:
Режим однодисплейной производительности. Установите эту настройку, если в многодисплейных режимах возникают проблемы.
Р ежим производительности совместимости полезен при наличии двух или более активных дисплеев в режиме nView Dualview, или при использовании разных классов видеоплат на базе ГП NVIDIA.
При этом OpenGL работает в режиме «совместимости» со всеми дисплеями, и если активные ГП относятся к разным классам, во всех приложениях OpenGL используется наименьший набор функций, общих для всех этих процессоров.
Режим многодисплейной производительности полезен при наличии двух или более активных дисплеев в режиме nView Dualview, или при использовании разных классов видеоплат на базе ГП NVIDIA.
При этом OpenGL работает в режиме «наибольшей производительности» для всех дисплеев, и если активные ГП относятся к разным классам, во всех приложениях OpenGL используется наименьший набор функций, общих для всех этих процессоров.
Как настроить видеокарту NVIDIA для игр
Технические гайды для геймеров на ПК
Купить и установить видеокарту — это только половина дела. Ее ведь еще необходимо и правильно настроить. В этой статье мы расскажем, что нужно делать и дадим рекомендации по настройкам панели управления NVIDIA.
Установка драйвера
Самое первое что нужно сделать после установки новой видеокарты — скачать и установить драйвера. Если до этого у вас стояла другая видеокарта, то старый драйвер желательно удалить. Проще всего воспользоваться утилитой Display Driver Uninstaller.
Скачать драйвер NVIDIA можно на официальном сайте. Заполните поля в соответствии с вашей видеокартой и операционной системой. Также выбирайте Game Ready, так как студийные драйвера предназначены для рабочего софта.
Динамический диапазон и формат цвета
После установки драйвера нужно зайти в «Панель управления NVIDIA». Попасть туда можно кликнув по значку NVIDIA в трее или кликнуть правой кнопкой мыши на рабочем столе и выбрать из появившегося меню нужный пункт.
Слева в разделе «Дисплей» выберите пункт «Изменение разрешения». Разрешение и частота обновления должны по умолчанию стоять оптимальные, но если это не так, то нужно поправить руками. Ставьте родное разрешение монитора и максимально доступную частоту обновления. В нашем случае это [email protected]Гц.
А вот пункт «Применить следующие настройки» уже интереснее. Для наилучшей картинки нужно установить формат цвета RGB и полный динамический диапазон. В случае подключения по DisplayPort это должно стоять по умолчанию, а если используется HDMI, то диапазон может быть ограниченным. В этом случае картинка может казаться бледной, выцветшей.
Форматы цвета YCbCr 422 и 444 использовать на мониторе не стоит. Но их можно ставить, если RGB недоступен, например, в силу старой версии HDMI, которой не хватает пропускной способности. Так, сигнал 4К@60Гц с HDR по HDMI версии 2.0 передать в RGB с полным диапазоном не получится. Страшного здесь ничего нет, главное — поставить ограниченный диапазон и в настройках телевизора/монитора.
Зайдите также в раздел «Видео» и «Регулировка параметров цвета для видео». Включите переключатель «С настройками NVIDIA» и перейдите на вкладку «Дополнительно». Активируйте полный динамический диапазон.
Управление параметрами 3D
По умолчанию все графические настройки задаются 3D-приложением (в нашем случае игрой). То есть, вы меняете графические настройки, например, качество сглаживания и анизотропной фильтрации, непосредственно в игре. Но драйвер NVIDIA также позволяет тонко настраивать графические параметры. Так, например, можно установить сглаживание для старых игр, где такой опции вообще нет.
После выбора настроек не забудьте применить их, нажав на соответствующую кнопку внизу экрана.
Настройки GeForce Experience
Также стоит кое-что сделать и в программе GeForce Experience, которая идет вместе с драйвером. Сначала вам будет нужно создать учетную запись, тогда можно будет пользоваться всеми функциями.
Здесь мы рекомендуем включить внутриигровой оверлей. С его помощью можно делать скриншоты и записывать геймплей. Учтите, что функция «Мгновенный повтор» записывает видео в фоне, поэтому влияет на производительность.
Разгон в MSI Afterburner
В разгоне нет ничего страшного, если не лезть в дебри. Нужно установить утилиту MSI Afterburner и сдвинуть пару ползунков. При этом ничего у вас не сгорит и не испортится, а прирост кадров получите гарантированно.
Русские Блоги
Процесс рендеринга OpenGL
1. Что такое OpenGL?
OpenGL определяется как «интерфейс программного обеспечения для графического оборудования». По сути, это 3D-графическая и модельная библиотека с высокой степенью переносимости и имеет очень быструю скорость.
Второй. Трубопровод
Я считаю, что нет оснований OpenGL, я не понимаю, следующее представит этот процесс, а затем посмотреть на него первым.Серия коллекции Encyclopedia GPUЭто абсолютно полезно для понимания принципов работы OpenGL.
В-третьих. Подробная линия
Ниже этой картины «Руководство по программированию OpenGL ES 3.0«Этот процесс является программируемой строкой.
1.VBO/VAO(Объект буфера вершины или объект массива вершины):
2.VertexShader(Вершинский шейдер):
3.PrimitiveAssembly(Им Сборка):
Верхняя стадия вершинного шейдера является основной сборкой, примитив является геометрическим объектом, таким как треугольник, прямая или точка эльфа. Этот этап сочетает в себе вершины вывода из вершины шейдера в камеру.
4.rasterization（Растирация）：
5.FragmentShader（Фрагмент шейда）：
6.Per-Fragment Operations（Работа фрагмента）
На этом этапе выполняются следующие функции на каждом сегменте:
(1) Pixelownersetest (принадлежность пикселей):
Этот пиксель используется для определения положения (x, y) в буфере кадра, не принадлежит токосовому контексту. Например, если окно буфера кадра дисплея маскируется другим окном, оконная система может определить, что затененный пиксель не принадлежит к контексту этой OpenGL, чтобы эти пиксели не отображались.
(2) Scissortest (поездка):
Если фрагмент расположен за пределами области обрезки, он заброшен.
(3) Stensilthest и Intebtest (шаблон и тест глубины):
Тест глубины лучше понят, что если глубина фрагментатора возвращается меньше глубины в буфере, она отбрасывается. Шаблонные тесты не использовались, неясно, в частности, функция угадания должна быть как имя, форма шаблона может быть передана.
(4) смешивание:
Значение цвета вновь сгенерированного фрагмента в сочетании со значением цвета, хранящимися в буфере кадра, чтобы генерировать новый RGBA.
(5) Дигерирование:
Я не знаю, является ли это Бог лошадь?
Наконец, поместите сгенерированный клип в буфер кадра (передний буфер или после буфера или FBO), если не FBO, экран рисует защелки в буфере, генерирует пиксели на экране.
7. Фиксированный трубопровод
Фиксированный трубопровод представляет собой линию рисования OpenGL без шейдера, и OpenGL3.0 отменил эту функцию. Поток фиксированного трубопровода выглядит следующим образом:
Рендеринг 3D графики с помощью OpenGL
Введение
Что такое OpenGL?
OpenGL — cпецификация, определяющая платформонезависимый программный интерфейс для написания приложений, использующих двумерную и трёхмерную компьютерную графику. OpenGL не является реализацией, а только описывает те наборы инструкций, которые должны быть реализованы, т.е. является API.
Каждая версия OpenGL имеет свою спецификацию, мы будем работать начиная с версии 3.3 и до версии 4.6, т.к. все нововведения с версии 3.3 затрагивают мало значимые для нас аспекты. Перед тем как начать писать своё первое OpenGL приложение, рекомендую узнать какие версии поддерживает ваш драйвер(сделать это можно на сайте вендора вашей видеокарты) и обновить драйвер до последней версии.
Устройство OpenGL
OpenGL можно сравнить с большим конечным автоматом, который имеет множество состояний и функций для их изменения. Под состоянием OpenGL в основном имеют ввиду контекст OpenGL. Во время работы с OpenGL мы будем проходить через несколько меняющих состояния функций, которые будут менять контекст, и выполняющие действия в зависимости от текущего состояния OpenGL.
Например, если мы перед отрисовкой передадим OpenGL команду использовать линии вместо треугольников, то OpenGL все последующие отрисовки будет использовать линии, пока мы не изменим эту опцию, или не поменяем контекст.
Объекты в OpenGL
Библиотеки OpenGL написаны на C и имеют многочисленные API к ним для разных языков, но тем не менее это C библиотеки. Множество конструкций из языка С не транслируются в высокоуровневые языки, поэтому OpenGL был разработан с использованием большого количества абстракций, одной из этих абстракций являются объекты.
Объект в OpenGL — это набор опций, который определяет его состояние. Любой объект в OpenGL можно описать его (id) и набором опций, за который он отвечает. Само собой, у каждого типа объектов свои опции и попытка настроить несуществующие опции у объекта приведёт к ошибке. В этом кроется неудобство использования OpenGL: набор опций описывается C подобной структурой идентификатором которого, зачастую, является число, что не позволяет программисту найти ошибку на этапе компиляции, т.к. ошибочный и правильный код семантически неотличимы.
С таким кодом вы будете сталкиваться очень часто, поэтому когда вы привыкнете, что это похоже на настройку конечного автомата, вам станет намного проще. Данный код лишь показывает пример того, как работает OpenGL. В последствии будут представлены реальные примеры.
Но есть и плюсы. Основная фишка этих объектов состоит в том, что мы можем объявлять множество объектов в нашем приложении, задавать их опции и когда бы мы не запускали операции с использованием состояния OpenGL мы можем просто привязать объект с нашими предпочитаемыми настройками. К примеру этом могут быть объекты с данными 3D модели или нечто, что мы хотим на этой модели отрисовать. Владение несколькими объектами позволяет просто переключаться между ними в процессе отрисовки. С таким подходом мы можем сконфигурировать множество объектов нужных для отрисовки и использовать их состояния без потери драгоценного времени между кадрами.
Чтобы начать работать с OpenGL нужно познакомиться с несколькими базовыми объектами без которых мы ничего не сможем вывести на экран. На примере этих объектов мы поймём как связывать данные и исполняемые инструкции в OpenGL.
Базовые объекты: Шейдеры и шейдерные программы.=
Shader — это небольшая программа которая выполняется на графическом ускорителе(GPU) на определённом этапе графического конвейера. Если рассматривать шейдеры абстрактно, то можно сказать, что это этапы графического конвейера, которые:
Но как же выглядит графический конвейер? Очень просто, вот так:
Пока в этой схеме нас интересует только главная вертикаль, которая начинается с Vertex Specification и заканчивается на Frame Buffer. Как уже говорилось ранее, каждый шейдер имеет свои входные и выходные параметры, которые отличаются по типу и количеству параметров.
Кратко опишем каждый этап конвейера, чтобы понимать, что он делает:
| |
Шейдеры OpenGL пишутся на специальном С-подобном языке GLSL из которого они компилируются и линкуются в шейдерную программу. Уже на данном этапе кажется, что написание шейдерной программы это крайне трудоёмкое занятие, т.к. нужно определить 5 ступеней графического конвейера и связать их воедино. К большому счастью это не так: в графическом конвейере по умолчанию определены шейдеры тесселяции и геометрии, что позволяет нам определить всего два шейдера — вершинный и фрагментный (иногда его назвают пиксельным шейдером). Лучше всего рассмотреть эти два шейдера на классическом примере:
Эти два простых шейдера ничего не вычисляют лишь передают данные дальше по конвейеру. Обратим внимение как связаны вершинный и фрагментный шейдеры: в вершинном шейдере объявлена out переменная Color в которую будет записан цвет после выполнения главной функции, в то время как в фрагментном шейдере объявлена точно такая же переменная с квалификатором in, т.е. как и описывалось раньше фрагментный шейдер получает данные из вершинного посредством нехитрого прокидывания данных дальше через конвейер (но на самом деле не всё так просто).
Замечание: Если в фрагментном шейдере не объявить и не проинициализировать out переменную типа vec4, то на экран ничего выводиться не будет.
Внимательные читатели уже заметили объявление входных переменных типа vec3 со странными квалификаторами layout в начале вершинного шейдера, логично предполагать что это входные данные, но откуда нам их взять?
Базовые объекты: Буферы и Вершинные массивы
Я думаю не стоит объяснять что такое буферные объекты, лучше рассмотрим как создать и заполнить буффер в OpenGL.
Ничего сложно в этом нет, привязываем сгенереный буффер к нужному таргету (позже узнаем к какому) и загружаем данные указывая их размер и тип использования.
GL_STATIC_DRAW — данные в буфере изменяться не будут.
GL_DYNAMIC_DRAW — данныe в буфере будут изменяться, но не часто.
GL_STREAM_DRAW — данные в буфере будут изменяться при каждом вызове отрисовки.
Отлчно, теперь в памяти GPU расположенные наши данные, скомпилирована и слинкована шейдерная программа, но остаётся один нюанс: как программа узнает откуда брать входные данные для вершинного шейдера? Данные мы загрузили, но никак не указали откуда шейдерной программе их брать. Эту задачу решает отдельный тип объектов OpenGL — вершинные массивы.
Как и с буферами вершинные массивы лучше рассмотреть на примере их конфигурации
Создание вершинных массивов ничем не отличается от создания других OpenGL объектов, самое интересное начинается после строчки: Вершинный массив (VAO) запоминает все привязки и конфигурации проводимые с ним, в том числе и привязывание буферных объектов для выгрузки данных. В данном примере такой объект всего один, но на практике их может быть несколько. После чего производится конфигурация вершинного атрибута с определённым номером:
Всё теперь мы готовы отрендерить наше первое изображение
Не забудьте привязать VAO и шейдерную программу перед вызовом отрисовки.
Если вы всё сделали правильно, то вы должны получить вот такой результат:
Результат впечатляет, но откуда в треугольнике градиентная заливка, ведь мы указали всего 3 цвета: красный, синий и зелёный для каждой отдельной вершины? Это магия шейдера растеризации: дело в том, что во фрагментный шейдер попадает не совсем то значение Color которое мы установили в вершинном. Вершин мы передаём всего 3, но фрагментов генерируется намного больше (фрагментов ровно столько же сколько закрашенных пикселей). Поэтому для каждого фрагмента берётся среднее из трёх значений Color в зависимости от того насколько близко он находится к каждой из вершин. Это очень хорошо прослеживается у углов треугольника, где фрагменты принимают то значение цвета, которое мы указали в вершинных данных.
Забегая чуть вперёд скажу, что текстурные координаты передаются точно так же, что позволяет с лёгкостью накладывать текстуры на наши примитивы.
Думаю на этом стоит закончить данную статью, самое сложное уже позади, но самое интересное только начинается. Если у вас есть вопросы или вы увидели ошибку в статье, напишите об этом в комментариях, я буду очень признателен.
В следующей статье мы рассмотрим трансформации, узнаем о unifrom переменных и научимся накладывать текстуры на примитивы.
Learn OpenGL. Урок 5.9 — Отложенный рендеринг
В предыдущих статьях мы использовали прямое освещение (forward rendering или forward shading). Это простой подход, при котором мы рисуем объект с учётом всех источников света, потом рисуем следующий объект вместе с всем освещением на нём, и так для каждого объекта. Это достаточно просто понять и реализовать, но вместе с тем получается довольно медленно с точки зрения производительности: для каждого объекта придётся перебрать все источники света. Кроме того, прямое освещение работает неэффективно на сценах с большим количество перекрывающих друг друга объектов, так как большая часть вычислений пиксельного шейдера не пригодится и будет перезаписана значениями для более близких объектов.
Отложенное освещение или отложенный рендеринг (deferred shading или deferred rendering) обходит эту проблему и кардинально меняет то, как мы рисуем объекты. Это даёт новые возможности значительно оптимизировать сцены с большим количеством источников света, позволяя рисовать сотни и даже тысячи источников света с приемлемой скоростью. Ниже изображена сцена с 1847 точечными источниками света, нарисовання с помощью отложенного освещения (изображение предоставил Hannes Nevalainen). Что-то подобное было бы невозможно при прямом расчёте освещения:
Часть 2. Базовое освещение
Часть 3. Загрузка 3D-моделей
Часть 4. Продвинутые возможности OpenGL
Часть 5. Продвинутое освещение
Идея отложенного освещения состоит в том, что мы откладываем самые вычислетельно сложные части (типа освещения) на потом. Отложенное освещение состоит из двух проходов: в первом проходе, геометрическом (geometry pass), рисуется вся сцена и различная информация сохраняется в набор текстур, называемых G-буффером. Например: позиции, цвета, нормали и/или зеркальность поверхности для каждого пикселя. Сохранённая в G-буфере графическая информация позже используется для расчёта освещения. Ниже приведено содержания G-буфера для одного кадра:
Во втором проходе, называемом проходом освещения (lighting pass), мы используем текстуры из G-буффера, когда рисуем полноэкранный прямоугольник. Вместо использования вершинного и фрагементного шейдеров отдельно для кадого объекта, мы пиксель за пикселем рисуем сразу всю сцену. Расчёт освещения остаётся точно таким же, как и при прямом проходе, но мы берём необходимые данные только из G-буфера и переменных шейдера (uniforms), а не из вершинного шейдера.
Изображение ниже хорошо показывает общий процесс рисования.
Главным преимуществом является то, что сохранённая в G-буфере информация принадлежит самым близким фрагментам, которые ничем не заслонены: тест глубины оставляет только их. Благодаря этому мы расчитываем освещение для каждого пикселя только по одному разу, не совершая лишенй работы. Более того, отложенное освещение даёт нам возможности для дальнейших оптимизаций, позволяющих использовать намного больше источников освещения, чем при прямом освещении.
Впрочем, есть и пара недостатков: G-буфер хранит большое количество информации о сцене. Вдобавок, данные типа позиции требуется хранить с высокой точностью, в итоге G-буфер занимает довольно много места в памяти. Ещё одним недостатком является то, что мы не сможем использовать полупрозрачные объекты (так как в буфере хранится информация только для самой близкой поверхности) и сглаживание типа MSAA тоже не будет работать. Существуют несколько обходных путей для решения этих проблем, они рассмотрены в конце статьи.
(Прим. пер. — G-буффер занимает реально много места в памяти. Например, для экрана 1920*1080 и использовании 128 бит на пиксель буфер займёт 33мб. Вырастают требования к пропускной способности памяти — данных пишется и читается значительно больше)
G-буфер
G-буфером называют текстуры, используемые для сохранения связанной с освещением информации, используемой в последнем проходе рендеринга. Давайте посмотрим, какая информация нам нужна для расчёта освещения при прямом рендеринге:
С помощью этих переменных мы можем посчитать освещение по уже знакомой нам модели Блинна-Фонга. Цвет и положение источника света, а так же позиция камеры могут быть общими переменными, но остальные значения будут своими для каждого фрагмента изображения. Если мы передадим ровно же данные в финальный проход отложенного освещения, что мы бы использовалили при прямом проходе, мы получим тот же самый результат, не смотря на то, что мы будет рисовать фрагменты на обычном 2д прямоугольнике.
В OpenGL нет ограничений на то, что мы можем хранить в текстуре, так что имеет смысл хранить всю информацию в одной или нескольких текстурах размером с экран (называемых G-буфером) и использовать их все в проходе освещения. Так как размер текстур и экрана совпадает, мы получим те же самые входные данные, что и при прямом освещении.
В псевдокоде общая картина выглядит примерно так:
Информация, которая необходима для каждого пикселя: вектор позиции, вектор нормали, вектор цвета и значение для зеркальной составляющей. В геометрическом проходе мы нарисуем все объекты сцены и сохраним все эти данные в G-буфер. Мы можем использовать множественные цели рендерига (multiple render targets), чтобы заполнить все буферы за один проход рисования, такой подход обсуждался в предыдущей статье про реализацию свечения: Bloom, перевод на хабре.
Для геометрического прохода создадим фреймбуфер с очевидными именем gBuffer, к которому присоединим несколько цветовых буферов и один буфер глубины. Для хранения позиций и нормали предпочтительно использовать текстуру с высокой точностью (16 или 32-битные float значения для каждой компоненты), диффузный цвет и значения зеркального отражения мы будем хранить в текстуре по-умолчанию (точность 8 бит на компоненту).
В дальнейшем мы должны отрендерить данные в G-буфер. Если каждый объект имееет цвет, нормаль и коэффициент зеркального отражения, мы можем написать что-то вроде следующего шейдера:
Так как мы используем несколько целей рендеринга, при помощи layout указываем, что и в какой буфер текущего фреймбуфера мы рендерим. Обратите внимание, что мы не сохраняем коэффициент зеркального отражения в отдельный буфер, так как мы можем хранить float значение в альфа-канале одного из буферов.
Имейте ввиду, что при расчётах освещения крайне важно хранить все переменные в одном и том же координатном пространстве, в данном случае мы храним (и производим вычисления) в пространстве мира.
Если мы сейчас отрендерим несколько нанокостюмов в G-буфер и нарисуем его содержимое с помощью проецирования каждого буфера на четверть экрана, мы увидим что-то типа такого:
Попробуйте визуализировать вектора позиций и нормалей и убедитесь, что они верны. Например, вектора нормалей, указывающих вправо, будут красным. Аналогично с объектами, расположенными правее центра сцены. После того, как Вы будете удовлетворены содержимым G-буфера, перейдём к следующей части: проходу освещения.
Проход освещения
Теперь, когда у нас есть большок количество информации в G-буфере, мы имеем возможность полностью вычислить освещение и финальные цвета для каждого пикселя G-буфера, используя его содержание в качестве входных данных для алгоритмов расчёта освещения. Так как значения G-буфера представляют только видимые фрагменты, мы выполним сложные рассчёты освещения ровно по одному разу для каждого пикселя. Благодаря этому отложенное освещение довольно эффективно, особенно в сложных сценах, в которых при прямом рендеринге для каждого пикселя довольно часто приходится производить вычисление освещения по нескольку раз.
Для прохода освещения мы собираемся рендерить полноэкранный прямоугльник (немного похоже на эффект пост-обработки) и произвести медленное вычисление освещения для каждого пикселя.
Мы присоединяем (bind) все необходимые текстуры G-буфера перед рендерингом и вдобавок устанавливаем относящиеся к освещению значения переменных в шейдере.
Фрагментный шейдер прохода освещения сильно похож на тот, что мы использовали в уроках совещения. Принципиально новым является способ, которым мы получаем входные данные для освещение прямо из G-буфера.
Так как для каждого фрагмента есть значения (а так же uniform переменные шейдера), необходимые для рассчёта освещеняи по модели Блинна-Фонга, нам нет необходимости изменять код расчёта освещения. Единственное, что было изменено — способ получения входных значений.
Запуск простой демонстрации с 32 маленькими источникам света выглядит примерно так:
Одним из недостатков отложенного освещения являетя невозможность смешивания, так как все g-буфера для каждого пикселя содержат информацию только об одной поверхности, в то время как смешивание использует комбинации нескольких фрагментов. (Blending), перевод. Ещё одним недостатком отложенного освещения является то, что оно вынуждает вас использовать один общий для всех объектов способ расчёта освещения; хотя это ограничение можно как-нибудь обойти с помощью добавления информации о материале в g-буфер.
Чтобы справиться с этими недостатками (особенно с отсутствием смешивания), часто разделяют рендеринг на две части: рендеринг с отложенным освещением, и вторая часть с прямым рендерингом предназначина для наложения чего-то на сцену или использования шейдеров, не сочетающихся с отложенным освещением. (Прим пер. Из примеров: добавление полупрозрачных дыма, огня, стёкол) Для иллюстрации работы мы нарисуем источники света как маленькие кубики с помощью прямого рендеринга, так как кубики освещения требуют специальный шейдер (равномерно светятся одним цветом).
Комбинируем отложенный рендериг с прямым.
Предположим, что мы хотим нарисовать каждый источник света в виде 3д кубика с центром, совпадающим с позицией источника света и излучающим свет с цветом источника. Первой идеей, которая приходит в голову, является прямой рендеринг кубиков для каждого источника света поверх результатов отложенного рендеринга. Т.е,, мы рисуем кубики как обычно, но только после отложенного рендеринга. Код будет выглядить примерно так:
Эти отрендеренные кубы не учитывают значения глубины из отложенного рендеринга и в результате рисуются всегда поверх уже отрендеренных объектов: это не то, чего мы добиваемся.
Сначала нам нужно скопировать информацию о глубине из геометрического прохода в буфер глубины, и только после этого нарисовать светящиеся кубики. Таким образом, фрагменты светящихся кубиков будут нарисованы только в том случае, если они находятся ближе, чем уже нарисованные объекты.
Для объектов, нарисованных в проходе отложенного освещения, мы сохранили глубину в g-буфере объекта фреймбуфера. Если мы просто скопируем содержимое буфера глубины g-буфера в буфер глубины по-умолчанию, светящиеся кубики будут нарисованы так, как будто вся геометрия сцены была нарисована с помощью прямого прохода рендеринга. Как было кратко объяснено в примере со сглаживанием, мы должны установить фреймбуферы для чтения и записи:
Здесь мы копируем целиком содержимое буфера глубины фреймбуфера в буфер глубины по-умолчанию (При необходимости можно аналогично скопировать буферы цвета или stensil буфер). Если мы теперь отрендерим светящиеся кубики, они нарисуются так, как будто геометрия сцены реальна (хотя она рисуется как простой).
Исходный код демо можно найти здесь.
С таким подходом мы можем легко комбинировать отложенный рендеринг с прямым. Это превосходно, так как мы сможем применять смешивание и рисовать объекты, которы требуют специальных шейдеров, не применимых при отложенном рендеренге.
Больше источников света
Отложенное освещение часто хвалят за возможность рисовать огромное количество источников света без сильного снижения производительности. Отложенное освещение само по себе не позволяет рисовать очень большого количества источников света, так как мы всё ещё должны для каждого пикселя посчитать вклад всех источников света. Для рисования огромного количества источников света используется очень красивая оптимизация, применимая к отложенному рендерингу — области действия источников света. (light volumes)
Обычно, когда мы рисуем фрагменты в сильно освещённой сцене, мы учитываем вклад каждого источника света на сцене независимо от его расстояния до фрагмента. Если большая часть источников света никогда не повлияют на фрагмент, зачем мы тратим время на вычисления для них?
Идея области действия источника света состоит в том, чтобы найти радиус (или объём) источника света — т.е., область, в которой свет способен достигнуть поверхности. Так как большинство источников света используют какое-нибудь затухание, мы можем найти максимальное расстояние (радиус), которое свет может достигнуть. После этого мы выполняем сложные рассчёты освещения только для тех источников света, которые влияют на данный фрагмент. Это спасает нас от огромного количесва вычислений, так как мы вычисляем освещение только там, где это необходимо.
При таком подходе основной хитростью является определение размера области действия источнка света.
Вычисление области действия источника света (радиуса)
Для получения радиуса источника света мы должны решить уравнение затухания для яркости, которую мы посчитаем тёмной — это может быть 0.0 или что-то чуть более освещённое, но всё ещё тёмное: например, 0.03. Для демонстрации, как можно посчитать радиус, мы будем использовать одну из сложных, наиболее общих функций затухания из примера с light caster
Мы хотим решить это уравнение для случая, когда 
, т.е., когда источник света будет полностью тёмным. Впрочем, данное уравнение никогда не достигнет точного значения 0.0, так что решения не существует. Однако мы вместо этого можем решить уравнение для яркости для значения, близкого к 0.0, которое можно считать практически тёмным. В этом примере мы считаем приемлемым значение яркости в 
— делёное на 256, так как 8-битный фреймбуфер может содержать 256 различных значений яркости.
Выбранная функция затухания становится практически тёмной на расстоянии радиуса действия, если мы ограничим её на меньшей яркости чем 5/256, то область действия источника света станет слишком большой — это не так эффективно. В идеале человек не должен видеть внезапной резкой границы света от источника света. Конечно, это зависит от типа сцены, большее значение минимальной яркости даёт меньшие области действия источников света и повышает эффективность рассчётов, но может приводить к заметным артефакты на изображении: освещение будет резко обрываться на границах области действия источника света.
Уравнение затухания, которое мы должны решить, становится таким:
Здесь 
— наиболее яркая составляющая света (из r, g, b каналов). Мы спользуем самую яркую компоненту, так как остальные компоненты дудут более слабое ограничение на область действия источника света.
Продолжим решать уравнение:
Последнее уравнение является квадратным уравнением в форме 
со следующим решением:
Мы получили общее уравнение, которое позволяет подставить параметры (коэффициенты константного затухания, линейного и квадратичного), чтобы найти x — радиус области действия источника света.
Формула возвращает радиус примерно между 1.0 и 5.0 в зависимости от максимальной яркости источника света.
Мы находим этот радиус для каждого источника света на сцене и используем его для того, чтобы для каждого фрагмента учитывать только те источники света, внутри областей действия которых он находится. Ниже приведён переделанный проход освещения, который учитывает области дейстия источников света. Обратите внимание, что этот подход реализован только в целях обучения и плохо подходит для практического применения (скоро обсудим, почему).
Результат точно такой же, как и раньше, но сейчас для каждого источника света учитывается его влияние только внутри области его действия.
Реальное применение области действия источника света.
Фрагментный шейдер, показанный выше, не будет работать на практике и служит только для иллюстрации, как мы можем избавиться от ненужных вычислений освещения. В реальности видеокарта и язык шейдеров GLSL очень плохо оптимизируют циклы и ветвления. Причной этого является то, что выполенние шейдера на видеокарте производится параллельно для различных пикселей, и многие архитектуры накладывают ограничение, что при паралельном выполнении различные потоки должны вычислять один и тот же шейдер. Часто это приводит к тому, что запущенный шейдер всегда вычисляет все ветвления, чтобы все шейдеры работали одинаковое время. (Прим пер. Это не влияет на результат вычислений, но может снижать производительность шейдера.) Из-за этого может получиться, что наша проверка на радиус бесполезна: мы всё ещё будем вычислять освещение для всех источников!
Подходящим подходом для использования области действия света будет рендеринг сфер с радиусом как у источника света. Центр сферы совпадает с позицией источника света, так что сфера содержит внутри себя область действия источника света. Здесь есть небольшая хитрость — мы используем в основном такой же отложенный фрагментный шейдер для рисования сферы. При рисовании сферы фрагментный шейдер вызывается именно для тех пикселей, на которые влияет источник света, мы рендерим только нужные пиксели и пропускаем все остальные. Иллюстрация на картинке ниже:
Мы сделаем так для каждого источника света, результаты вычислений будут сложены все вместе. Результат будет именно такой же, как и раньше, но на этот раз мы рендерим только необходимые пиксели для каждого источника света. Это значительно снижаем сложность вычислений с количество_объектов*количество_источников_света до
количество_объектов + количество_источников_света, что делает отложенный рендеринг неимоверно эффективным в сценах с большим количеством источников света.
При этом подходе всё ещё есть проблема: отсечение обратных граней должно быть включено (чтобы не рассчитывать освещение дважды) и, когда оно включено, пользователь может оказаться внутри области источника света, из-за чего она не будет рисоваться (по причине отсечения обратных граней). Это может быть решено с помощью хитрого использования stenсil буфера.
Рендеринг областей действия источников света приводит к большим потерям производительности, и хотя это значительно быстрее, чем обычное отложенное освещение, это не является лучшим решением. Существуют ещё два популярных (и более эффективных) способа рассчёта освещения при отложенном рендеринге: отложенное оcвещение (deferred lighting) и потайловое отложенное затенение (tile-based deferred shading). Эти способы невероятно эффективны при рендеринге большого количества источников света и так же позволяют относительно эффективно использовать сглаживание MSAA. Ради размера этой статьи мы оставим эти оптимизации для рассмотрения в последующих статьях.
Отложенный рендеринг vs прямой
Отложенный рендеринг (без оптимизаций освещения) сам по-себе уже является хорошей оптимизацией, так как каждый пиксель только один раз требует вычисления фрагментного шейдера, в то время как при прямом рендеринге мы часто вычисляем освещения по нескольку раз для пикселя. Вместе с тем, отложенное освещение имеет недостатки — большое использование памяти, отсутствие сглаживания MSAA, смешивание можно использовать только при прямом рендеринге.
Для простой сцены с небольшим количеством источников света отложенный рендеринг не обязательно будет быстрее (иногда даже медленнее), так как дополнительные расходы (запись в g-буфер и т.п.) могут перевесить преимущества от меньшего количества рассчётов освещения. В более сложных сценах отложенный рендеринг становится значительной оптимизацией, особенно при использовании более продвинутых способов рассчёта освещения.
В заключение я хочу отметить: изначально все эффекты, которые могут быть получены прямым рендерингом, так же могут быть реализованны в отложенном рендеринге, зачастую это требует лишь небольших изменений. Например, если мы хотим использовать карты нормалей при отложенном рендеринге, мы можем изменить геометрическй проход так, чтобы шейдер возвращал нормаль на основе значений из карты нормалей вместо нормали геометрической поверхности. Проход освещения вообще не потребует изменений. Если вы хотите добавить parallax mapping, вы сначала немного измените текстурные координаты в геометрическом шейдере перед чтением из текстур значений цветов, отражающей способности и нормалей. Как только вы поймёте идею отложенного рендеринга, внесение изменений в него будет довольно простым.