Шейдеры не совместимы с быстрым рендером что делать

Оптимизация рендера под Mobile. Часть 3. Шейдеры

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

Шейдерные инструкции

Чтобы лучше ориентироваться в оптимизационных подходах, применяемых при написании шейдеров, полезно знать об основных категориях шейдерных инструкций. Первая категория — арифметические инструкции. Эти инструкции, как правило, работают с регистрами GPU и выполняются предсказуемое количество тактов. Обычно это 1 такт. При этом в современных конвейерах может выполняться по нескольку арифметических инструкций за 1 такт. Вторая категория — текстурные инструкции. Они осуществляют текстурную выборку — чтение из текстур с применением определенной фильтрации. Время выполнения этих инструкций значительно дольше, чем арифметических, и зависит от наличия запрашиваемых текселей в текстурном кэше. Современные архитектуры маскируют длительное время выполнения текстурных инструкций за счет переключения на другие шейдерные потоки и выполнения их арифметических инструкций. Рекомендуемое соотношение количества арифметических инструкций к текстурным может быть 10 к 1 и выше.

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

Учет количества используемых регистров

В типичной архитектуре GPU имеется общий банк регистров (register file), используемый множеством параллельно выполняемых потоков. Каждый такой поток рассчитывает один вертекс или пиксель. От количества регистров, требуемых для выполнения шейдера, зависит максимальное количество одновременно выполняемых потоков. Например, на архитектуре Mali Midgard имеется следующая зависимость:

Дальнейшее увеличение потребности в регистрах приводит к записи промежуточных значений во временную память (так называемый register spilling). Иногда компилятор Mali может предпочесть небольшой register spilling переходу в менее выгодную конфигурацию потоков.

Оценить количество используемых регистров для Mali можно при помощи Mali Offline Compiler:

Точность mediump

В OpenGL ES предусмотрена возможность задавать точность величин при помощи квалификаторов lowp, mediump и highp.

Применение пониженной точности позволяет задействовать меньше регистров и добиться повышенной плотности вычислений за такт. Как было рассказано в предыдущей статье, применение точности lowp сегодня нежелательно. Она поддерживается на аппаратном уровне только в устаревающих моделях PowerVR, а на всех современных GPU вместо lowp фактически используется mediump. Такая ситуация напрасно усложняет процессы QA, если в шейдерах используется lowp.

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

Как мы показали выше, в GLSL ES точность можно задать отдельным переменным — uniform-ам и varying-ам. Кроме того, есть возможность задать точность по умолчанию для всех величин определенного типа. Например, используя такую строчку в начале шейдера, можно задать точность mediump для всех float:

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

Приведем пример выдачи утилиты Mali Offline Compiler для архитектуры Midgard для шейдера, содержащего большое количество арифметики.

С точностью highp (precision highp float;) получаем 32 такта на выполнение шейдера:

С точностью mediump — 21 такт:

Отметим, что, несмотря на немного возросшее количество инструкций, оценочное время выполнения шейдера сократилось. Это связано с тем, что за 1 такт с точностью mediump выполняется больше инструкций, чем с highp.

Похожую картину можно наблюдать в PVRShaderEditor от Imagination для видеокарт PowerVR Rogue.

С «precision highp float;» получаем:

Используются умножения с полной точностью, выполняемые по 2 за такт.

Если же начинать такой же шейдер строчкой «precision mediump float», можно увидеть, что операции были упакованы в 16-битные суммы произведений (SOP). Это операции вида a * b + c * d. Архитектура PowerVR Rogue позволяет выполнять 2 такие операции за такт, что дает большую плотность операций по сравнению с точностью highp:

Вместо 20 тактов с точностью highp, с mediump получили 15 тактов.

Смешанное использование точностей

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

Перемещение вычислений выше по pipeline

Типичный сценарий рендера на GPU предполагает следующее соотношение сущностей:

Источник

Настройки рендера Cycles

Данная статья раскроет все параметры присутствующие в меню: Sampling, Volume Sampling и Light Paths. С помощью данных меню производится большинство настроек качества и скорости рендера Cycles. Применяя их на практике Вы сможете добиться лучшего качества за меньше время.

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

Sampling

Render Samples
Количество путей трассировки для каждого пикселя в финальной визуализации. Чем большее значение, тем меньше шума.

Preview Samples
Количество путей трассировки для каждого пикселя в окне 3D-вида.

При значении 0 рендеринг будет происходить до тех пор, пока Вы его не прервете.

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

На изображении ниже сцена с отключенным параметром Clamp (оба в значении 0). Яркое пятно на полу — это прямой свет, падающий на него от источника света. Практически все остальное — это отраженный свет. Плоскости слева назначен шейдер Glossy, а той что в воздухе — Diffuse.

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

При использовании режима branched path tracing у Вас есть возможность установить количество отскоков луча для каждого типа шейдера. Это очень полезно в сценах, где, например, доминируют диффузные шейдеры и отсутствуют шейдеры объема. Вы можете установить нужное количество проходов для диффузного щейдера и добиться хорошего качества и убрать полностью объем, тем самым сохранив время рендеринга. Чтобы добиться такого же качества диффузного шейдера как при 250 семплах (режим path tracing), вам необходимо установить 10 AA samples и 25 diffuse samples. 25 diffuse samples — это количество отскоков луча для каждого AA семпла (10 Х 25 = 250). К счастью, арифметикой заниматься не придется, потому как все итоговые значения выводятся внизу данного меню. А теперь немного подробнее…

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

Сюзанну освещает три лампы типа Point:

Очень удобно устанавливать высокие значения семплов не вводя большие числа. 4 AAx3 Glosyy = 12 samples. 12×12=144:

Также в данном меню присутствуют две предустановленные настройки (Final и Preview), которые Вы можете дополнить любым количеством собственных, чтобы каждый раз не проделывать одно и тоже.

Volume Sampling

Для наглядности я увеличил Step Size до 1. Как видите качество огня и дыма плохое, но и рендер занял всего 6,8 секунды:

А теперь сравните два изображения со значением по умолчанию (0,1) и очень низким значением (0,01):

Step Size 0.1 (35,8 секунд)


Step Size 0.01 (5,27 минут)

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

На изображении ниже рендер со значением по умолчанию (1024). На него потребовалось 35,2 секунды:

А теперь еще два рендера с более низкими значениями:

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

Light Paths

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

Ниже изображение из 20 прозрачных паралелепипедов. При значении 8 мы видим лишь сквозь 8 плоскостей (тоесть через 4 паралелепипеда), а дальше свет не проходит. При значении 30 все объекты становятся прозрачными:

На изображении ниже оба типа каустики: Белые пиксели вокруг зеркального куба — это Reflective каустика. Белые пиксели за диамантом — это Refractive каустика.

Результаты с отключением каустик:

Данная опция не плохая альтернатива полному отключению каустики.

Также рекомендуется устанавливать минимум и максимум идентичными.

При значении 0 свет будет попадать на объект и полностью им поглощаться. На картинке ниже красный куб никак не влияет на свое окружение (красный цвет присутствует лишь на нем). В реальности же такого не бывает:

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

На изображении ниже две плоскости с шейдером Glossy (два зеркала направленных друг на друга). В зависимости от того, сколько отскоков Вы установите, столько раз они отразятся друг в друге:

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

На изображении два куба с шейдером Volume Scatter. Чем больше отскоков, тем реалистичнее объем:

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

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

Источник

Как изменить графику в любой игре с помощью ReShade

Немного о ReShade

ReShade поддерживает таки API как Direct3D 9, Direct3D 10, Direct3D 11 и OpenGL.
Требуется компьютер с Windows Vista с пакетом обновления 1 (SP1) или выше (Windows 7, 8, 8.1, 10) так же необходим уже установленый DirectX.

Установка ReShade

1. Для начала качаем утилиту ReShade 3.0.8 вот по этой ссылке.

4.Дальше нажимаем на кнопку «Да» и сразу после этого начнётся загрузка шейдеров.

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

7.Что бы открыть меню ReShade нажимаем сочетание клавиш Shift+F2. После того как откроется меню ReShade нажимаем на кнопку Continue\Продолжить. Нажимаем на «+» чтобы добавить новый Preset, даём ему любое название, желательно на английском языке, и нажимаем кнопку «Enter» на клавиатуре.

8. Теперь вы можете включать и отключать любые эфекты из списка которые вам предлагают, там их более 50-ти. В случаи если вам этого мало тогда снова нажимаем на кпопку «Continue\Продолжить», снизу появится полная регулеровка всех эфектов.

9. Во вкладке «Settings/Настройки» можно включить FPS и время.

Источник

Как работает рендеринг в 3D-играх: сглаживание

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

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

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

Алиасинг возникает из того факта, что отрендеренное изображение должно каким-либо образом отображаться на экране. И независимо от того, сделан ли он из электронно-лучевой трубки (ЭЛТ), жидкокристаллического дисплея (ЖКД) или плазменной панели, этот экран создает изображение с помощью набора цветных элементов.

Разрешения 10 х 7 пикселей недостаточно для отображения этого треугольника без алиасинга

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

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

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

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

Приведенное выше изображение (оригинал) из теста Wings of Fury было снято с разрешением 1280×720 пикселей. Четырнадцать лет назад, когда Radeon 9800 XT и GeForce FX 5900 Ultra были лучшими из доступных видеокарт, самые большие мониторы имели разрешение около 1600×1200 пикселей — так что разрешение, которое мы используем для тестов сейчас, можно было бы принять за среднее либо низкое (сродни сегодняшнему 1080p).

Беглый взгляд на крылья самолетов ясно указывает на проблему алиасинга, и особенно это заметно в движении. Большой контраст между цветом пикселей на крыле и фоном неба и облаков создает мерцание при движении самолета по небу. Виной всему относительно низкая частота дискретизации, а потому наиболее очевидным решением было бы ее увеличение. Давайте снова посмотрим ту же сцену в разрешении 4K, или 3840×2160 пикселей (оригинал):

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

Каждый пиксель требует обработки, если не указало иное: к нему нужно применить несколько текстур и обработать его многочисленными шейдерами для расчета окончательного цвета. Обычно это узкое место в большинстве игр, и общая частота кадров обратно пропорциональна разрешению. Если верить столь старому бенчмарку, как 3DMark03, переход с 1280х768 до 3840×2160 пикселей снижает среднюю частоту кадров с 1670 до 1274 кадров в секунду — то есть, увеличение количества обрабатываемых пикселей на 740% приводит к снижению производительности всего на 24%. Однако с новыми бенчмарками все выглядит несколько иначе. Это можно легко продемонстрировать, запустив последний 3DMark в различных разрешениях. На графике ниже показана средняя частота кадров первого графического теста в бенчмарке Time Spy.

Переход от 720p к 4K означает увеличение разрешения на 800%, но частота кадров при этом падает на 81%. Хотя игры не обязаны соответствовать этой закономерности, современные AAA-тайтлы, скорее всего, покажут схожие результаты. Это говорит о том, что если мы хотим максимально уменьшить влияние алиасинга, нам понадобится метод получше, чем просто повышение разрешения — ведь чем ниже частота кадров, тем хуже временной алиасинг.

Избыточная выборка сглаживания, или суперсэмплинг (Supersampling anti-aliasing, SSAA)

Это самый старый и самый простой метод сглаживания. Он включает в себя рендеринг сцены с более высоким разрешением, чем заданная настройка, а затем сэмплинг и смешивание результата до меньшего числа пикселей. Например, монитор может быть иметь разрешение 1920×1080 пикселей, а игру можно настроить для рендеринга с разрешением 3840×2160, после чего происходит масштабирование обратно до меньшего разрешения и вывод результата на экран. Обычно в этом алгоритме используется метод ближайшего соседа, а математика смешивания является ни чем иным, как средним арифметическим сэмплов.

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

На изображении ниже показан классический 4x SSAA в действии. 4x указывает на смешение четырех сэмплов путем вычисления среднего арифметического значения цвета для вывода его на экран. Для этого разрешение увеличивается в 2 раза по обеим осям.

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

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

Сейчас суперсэмплинг используется уже редко, хотя и нашел новое применение в качестве настроек в драйверах для видеокарт AMD и NVIDIA: в первых эта технология называется виртуальное суперразрешение (Virtual Super Resolution, VSR), во второй — динамическое суперразрешение (Dynamic Super Resolution, DSR). Их можно использовать для сглаживания в некоторых старых играх, в которых нет никакой встроенной системы, или просто для улучшения уже имеющегося изображения.

Множественная выборка сглаживания, или мультисэмплинг (Multisample anti-aliasing (MSAA)

Этот метод впервые появился в исследовательских лабораториях Silicon Graphics в начале 90-х годов. По сути, это тот же SSAA, но с выборочным применением только там, где это действительно необходимо. Ладно, пожалуй, это все-таки не просто SSAA, но такая формулировка должна помочь в понимании, как работает этот алгоритм.

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

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

Эта информация может храниться в z-буфере (или буфере глубины), а затем использоваться для определения видимости краев. В приведенном выше примере все крайне просто: белый цвет обозначает фон, черный — примитив.

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

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

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

Таким образом, для мультисэмплинга необходимо большее количество VRAM и более высокая пропускная способность памяти (а также возможность быстрого чтения/записи в z-буферы), но зато он не требует большой мощности от шейдеров. Давайте для сравнения с SSAA воспользуемся старым примером кода AMD.

Код запускает простую сцену с базовыми текстурами и освещением, но большим количеством геометрии, так что алиасинг по краям видно особенно хорошо. Если приблизить изображение, то в верхнем левом углу можно увидеть следующую информацию: каждому кадру требуется в среднем 0,18 миллисекунды на рендеринг и всего 0,02 мс на смешивание для окончательного вывода. Цветовой буфер имеет размер 7,4 МБ, как и буфер глубины.

Также можно увеличить определенные области кадра, чтобы увидеть алиасинг во всех деталях. Напомним, что можно отрендерить все это с более высоким разрешением, но это увеличит время рендеринга. Если мы применим к сцене 4x SSAA, именно это и произойдет.

Обратите внимание, что на изображении выше время рендеринга увеличилось до 0,4 мс (то есть, на 122%), а время смешивания удвоилось. Кроме того, размер буферов цвета и глубины увеличился в 4 раза. Такова стоимость использования SSAA, и хотя современному графическому процессору не составит особой проблемы произвести такое сглаживание на столь простом примере, но современные 3D-игры — совсем другое дело.

Теперь взгляните на увеличенный фрагмент. Обратите внимание на гладкость линий. Да, осталось еще много «лесенок», но результат выглядит заметно лучше. Было бы это еще не так дорого.

Но теперь рассмотрим MSAA:

Здесь время рендеринга сцены почти вернулось к тому значению, каким оно было без применения сглаживания (что хорошо), хотя время вывода еще больше увеличилось. Общий объем памяти — где-то на полпути между отсутствием AA и 4x SSAA, отчего может показаться, что MSAA определенно лучший вариант, чем SSAA. Можно сказать, что даже уменьшение алиасинга на краях примитивов выглядит лучше, хотя это больше связано с выбором шаблона сэмплинга, а не с природой самого MSAA. Но если посмотреть на текстуру стены в увеличенной области, станет очевидным один недостаток MSAA.

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

Так что же делать, если методы супер- и мультисэмплинга — не лучший выбор?

Быстрое приблизительное сглаживание (Fast approximate anti-aliasing, FXAA)

В 2009 году Nvidia представила новый метод очистки неровных краев фигур в 3D-сценах. В отличие от SSAA и MSAA, реализация FXAA был разработана полностью при помощи шейдеров. С момента выпуска он претерпел не одно улучшение и сегодня активно используется в играх.

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

Последовательность FXAA: найти пиксели на границе, определить ее ориентацию, сдвинуть их, размыть конечное изображение

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

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

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

Пример использования FXAA представлен ниже:

Без AA (слева) и FXAA (справа) — обратите внимание, что деревья и элероны на крыле выглядят намного более гладкими

Какие же минусы? При заполнении кадра высококонтрастными областями, такими как яркие пиксели на темном фоне, они будут смешаны независимо от того, было ли это нужно или нет.

Метод имеет меньшую точность, чем в SSAA или MSAA, ведь он не улавливает детали субпикселей и по сути просто является своеобразным фильтром, который размывает некоторые текстуры. Но принимая во внимание его дешевизну при относительной эффективности, нетрудно понять, почему FXAA все еще часто применяют 12 лет спустя, пусть и переработанный.

Существуют и другие полноэкранные алгоритмы обнаружения границ, аналогичные этому: морфологическое сглаживание (MLAA), разработанное Intel, в свое время послужило вдохновением для создания FXAA; далее оно было доработано разработчиком игр Crytek и университетом Сарагосы в Испании и получило новое название Enhanced Sub-pixel MLAA (SMAA). Самое лучшее во всех этих алгоритмах — что, в отличие от SSAA и MSAA, они могут постоянно обновляться и модифицироваться программистами, настраивающими их в соответствии с приложениями или играми, которые они создают.

Временное сглаживание (Temporal anti-aliasing, TAA)

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

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

Основная предпосылка временного сглаживания

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

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

Самый распространенный алгоритм TAA

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

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

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

Так выглядит результат TAA:

Без AA (слева) и TAA (справа) — обратите внимание на размытие деталей на крыле

Для разработчиков запрограммировать все это гораздо сложнее, чем добавить в игру SSAA или MSAA. Но современные графические процессоры могут довольно быстро обрабатывать все требуемые шейдеры, и там, где алгоритмы супер- и мультисэмплинга требуют множество сэмплов для каждого кадра (а значит, большей работы модуля вывода рендеринга (ROP) и пропускной способности памяти), TAA эффективно распределяет эти сэмплы по нескольким кадрам. Это значит, что для игр, не сильно ограниченных количеством затенения, можно включить TAA с относительно небольшой потерей производительности.

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

И это еще не все!

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

Например, когда NVIDIA выпустила видеокарты серии GeForce 9, она также анонсировала модифицированную версию MSAA под названием Multi-Frame Sampled Anti-aliasing (MFAA). По сути, в этом алгоритме с каждым кадром графический процессор изменяет шаблон сэмплирования, и таким образом каждый раз берется и смешивается меньшее количество сэмплов. При усреднении по нескольким кадрам эффект оказывается такой же, как и при обычном MSAA, но с меньшими затратами на производительность. К сожалению, этот алгоритм можно было реализовать только в играх, разработанных под руководством NVIDIA. Тем не менее, он все еще существует, и вы можете получить к нему доступ, включив опцию в панели управления драйвером GeForce.

Совсем недавно та же компания вложила значительные ресурсы в разработку алгоритма AA, использующего искусственный интеллект. Алгоритм, появившийся в 2018 вместе с чипами Turing, имеет название суперсэмплинг при помощи глубокого обучения (DLSS).

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

Сравнение оригинального 1080p и с применением DLSS:

Сейчас AMD работает над собственным аналогом DLSS. Можно предположить, что со временем алгоритмы глубокого обучения AA заменят традиционные, но сейчас до этого еще далеко. Такие системы не легче внедрить, чем, скажем, TAA, а визуальные результаты при этом не всегда идеальны.

Мы прошли уже долгий путь со времен Riva TNT и Half-Life, когда просто приходилось мириться с неровными полигонами повсюду, ведь не было никаких технологий, чтобы можно было что-то с этим сделать, но исследования улучшенных методов сглаживания продолжаются и продолжаются.

Источник