Часть 1: обработка вершин
В этой статье мы подробнее рассмотрим то, что происходит с 3D-миром после завершения обработки всех его вершин. Нам снова придётся стряхнуть пыль с учебников по математике, освоиться в геометрии пирамид усечения и решить загадку перспектив. Также мы ненадолго погрузимся в физику трассировки лучей, освещения и материалов.
Главная тема этой статьи — важный этап рендеринга, на котором трёхмерный мир точек, отрезков и треугольников становится двухмерной сеткой разноцветных блоков. Очень часто этот процесс кажется незаметным, потому что преобразование из 3D в 2D оказывается невидимым, в отличие от процесса, описанного в предыдущей статье, где мы сразу же могли увидеть влияние вершинных шейдеров и тесселяции. Если вы пока не готовы к этому, то можете начать с нашей статьи 3D Game Rendering 101.
Подготовка к двум измерениям
Подавляющее большинство читателей читают этот веб-сайт на совершенно плоском мониторе или экране смартфона; но даже если у вас есть современная техника — изогнутый монитор, то отображаемая им картинка тоже состоит из плоской сетки разноцветных пикселей. Тем не менее, когда вы играете в новую Call of Mario: Deathduty Battleyard, изображения кажутся трёхмерными. Объекты движутся по сцене, становятся больше или меньше, приближаясь и отдаляясь от камеры. Взяв в качестве примера Fallout 4 компании Bethesda, вышедшую в 2014 году, мы можем легко увидеть, как обрабатываются вершины, создавая ощущение глубины и расстояния; особенно хорошо это заметно в каркасном режиме (см. выше).
Если взять любую 3D-игру за последние два десятка лет, то почти каждая из них для преобразования 3D-мира вершин в 2D-массив пикселей выполняет одинаковую последовательность действий. Такое преобразование часто называют растеризацией, но это только один из множества этапов во всём процессе.
Нам нужно разобрать разные этапы и исследовать применяемые в них техники и вычисления. В качестве справочного материала мы воспользуемся последовательностью, применяемой в Direct3D. На изображении ниже показано, что происходит с каждой вершиной мира:
Конвейер преобразований Direct3D
В первой статье [перевод на Хабре] мы увидели, что происходит в мировом пространстве (World space): здесь при помощи различных матричных вычислений преобразуются и окрашиваются вершины. Мы пропустим следующий этап, потому что в пространстве камеры выполняется только преобразование вершин и их настройка после перемещения, чтобы опорной точкой стала камера.
Следующие этапы слишком сложны, чтобы их пропускать, потому что они абсолютно необходимы для выполнения перехода от 3D к 2D — при правильной реализации наш мозг будет смотреть на плоский экран, но «видеть» сцену, обладающую глубиной и масштабом. Если сделать всё неправильно, то картинка окажется очень странной!
Всё дело в перспективе
Первый этап этой последовательности заключается в задании области видимости с точки зрения камеры. Для этого сначала нужно задать углы горизонтальной и вертикальной области видимости — в играх часто меняется первая, потому что у людей горизонтальное периферийное зрение развито лучше, чем вертикальное.
Мы можем разобраться в этом, посмотрев на изображение с областью зрения человека:
Два угла области видимости (field of view, fov) задают форму пирамиды усечения (frustum) — 3D-пирамиды с квадратным основанием, исходящей из камеры. Первый угол задаёт вертикальную fov, второй — горизонтальную; мы обозначим их символами α и β. На самом деле мы видим мир не совсем так, но с точки зрения вычислений гораздо проще работать с пирамидой усечения, а не пытаться сгенерировать реалистичный объём видимости. Также нужно задать ещё два параметра — расположение ближней (или передней) и дальней (задней) плоскостей усечения (clipping planes). Первая отрезает вершину пирамиды, но по сути определяет, насколько близко к позиции камеры всё отрисовывается; последняя делает то же самое, но определяет на какое расстояние от камеры будут рендериться примитивы.
Размер и расположение ближней плоскости усечения очень важны, потому что она становится тем, что называется окном просмотра (viewport). По сути, это то, что мы видим на мониторе, т.е. отрендеренный кадр, и в большинстве графических API окно просмотра отрисовывается начиная с левого верхнего угла. На показанном ниже изображении точка (a1, b2) будет точкой начала координат плоскости: ширина и высота плоскости измеряются относительно неё.
Соотношение сторон (aspect ratio) окна просмотра важно не только для отображения отрендеренного мира, но и для соответствия aspect ratio монитора. Многие годы стандартом было 4:3 (или 1.3333… в десятичном виде). Однако сегодня большинство играет в соотношении сторон 16:9 или 21:9, называемых widescreen и ultra widescreen.
Координаты каждой вершины в пространстве камеры должны быть преобразованы таким образом, чтобы все они помещались на ближней плоскости усечения, как показано ниже:
Пирамида усечения сбоку и сверху
Преобразование выполняется при помощи ещё одной матрицы, называемой матрицей перспективного проецирования (perspective projection matrix). В примере ниже для выполнения преобразований мы используем углы области видимости и позиции плоскостей усечения; однако вместо них можно применить размеры окна просмотра.
Вектор позиции вершины умножается на эту матрицу, что даёт нам новое множество преобразованных координат. Вуаля! Теперь все вершины записаны таким образом, что исходный мир представлен как 3D-перспектива, а примитивы рядом с передней плоскостью усечения кажутся больше, чем те, которые ближе к дальней плоскости.
Хотя размер окна просмотра и углы области видимости связаны, их можно обрабатывать по отдельности. Другими словами, можно задать пирамиду усечения таким образом, чтобы получить ближнюю плоскость усечения, отличающуюся по размеру и соотношению сторон от окна просмотра. Чтобы это сделать, в цепочке операций нужен дополнительный этап, на котором вершины в ближней плоскости усечения должны быть снова преобразованы для учёта этого различия.
Однако это может привести к искажению видимой перспективы. На примере игры 2011 года Skyrim компании Bethesda мы можем увидеть, как изменение горизонтального угла области видимости β при сохранении того же соотношения сторон окна просмотра сильно влияет на сцену:
На этом первом изображении мы задали β = 75°, и сцена выглядит при этом совершенно обычной. Давайте попробуем теперь задать β = 120°: Сразу заметны два отличия — во-первых, теперь мы видим гораздо больше по бокам нашего «поля зрения»; во-вторых, объекты теперь кажутся гораздо более далёкими (особенно деревья). Однако визуальный эффект на поверхности воды теперь выглядит неправильным, потому что процесс не был рассчитан на такую область видимости.
Теперь давайте представим, что у нашего персонажа глаза инопланетянина, и зададим β = 180°!
Такая область видимости создаёт почти панорамную сцену, но за это приходится расплачиваться серьёзной величиной искажения объектов, рендерящихся по краям. Это опять-таки произошло из-за того, что дизайнеры игры не предусматривали такой ситуации и не создавали ресурсы и визуальные эффекты игры для такого угла обзора (стандартное значение примерно равно 70°).
Может показаться, что на показанных выше изображениях камера переместилась, но это не так — единственное изменение заключается в модификации пирамиды усечения, которая в свою очередь изменила размеры ближней плоскости усечения. На каждом изображении соотношение сторон окна просмотра остаётся одинаковым, поэтому к вершинам применена матрица масштабирования, чтобы в него всё помещалось.
Главные проблемы рейтрейсинга в играх
«Ок, рейтрейсинг – это круто! Но неужели всё так гладко?
» — резонно скажете Вы. Да, действительно, трассировка лучей – важная составляющая графики в играх. Она выводит качество картинки на совершенно новый уровень, добавляет кинематографичности для создания насыщенных визуальных эффектов, о которых раньше никто и мечтать не мог. Но всё-таки у рейтрейсинга есть несколько глобальных проблем:
- Очень большая «нагрузка» на производительность.
- Не так много игр с поддержкой трассировки лучей RTX
Рейтрейсинг, как мы уже упоминали ранее, требует больших вычислительных мощностей. Даже оптимизированные специально под эту задачу видеокарты GeForce RTX
не всегда справляются с трассировкой в играх, особенно на высоких разрешениях. Разумеется,
NVIDIA
совместно с разработчиками игр регулярно выпускает обновления драйверов, улучшающих работу рейтрейсинга, но порой даже самая мощная видеокарта в линейке,
RTX 2080 Ti
, не всегда справляется с нагрузкой при включенном
RTX
, в 4К-разрешении и на максимальных графических настройках.
«Но там, где стол был яств, там гроб стоит» — если первая проблема решается усердной работой над оптимизацией игр, то вторая проблема куда более глобальная – на сегодняшний день существует не так много игр с полной реализацией рейтрейсинга. Мы специально подчеркнули слово «полной» т.к. на сегодня есть всего пара игр, где трассировка лучей представлена по максимуму. Остальным повезло чуть меньше. К примеру, в Battlefield V
реализованы только отражения и эффекты преломления, в
Shadow of the Tomb Raider
есть только реалистичные тени, обрабатывающиеся по технологии
RTX
, а в
Metro: Exodus
– глобальное освещение и затенение.
Та самые игры, где рейтрейсинг представлен полностью и во всей красе – Control
и
Quake II RTX
, которую разработчики выпустили совместно с
NVIDIA
. И если с
Control
всё более-менее ясно, ведь это относительно недавняя новинка, то с
Quake II RTX
ситуация интереснее. В значительно улучшенном переиздании легендарной классики, были обновлены не только текстуры и перерисованы все модели (не без помощи пользовательских модификаций), со стороны трассировки здесь есть и реалистичные отражения, и преломления, и тени с глобальным освещением. Т.е. полный набор, какой и должен быть по умолчанию во всех играх с поддержкой рейтрейсинга. К сожалению, сейчас количество игр, оснащенных трассировкой лучей можно пересчитать по пальцам одной руки, разумеется, если не учитывать технодемки, созданные исключительно для демонстрации технологии публике.
Так ты остаёшься или уходишь?
После выполнения преобразований на этапе проецирования мы переходим к тому, что называется пространством усечения (clip space). Хотя это делается после проецирования, проще показать, что происходит, если мы выполним операции заранее: На рисунке выше мы видим, что у резиновой уточки, одной из летучих мышей и части деревьев треугольники находятся внутри пирамиды усечения; однако другая летучая мышь и самое дальнее дерево находятся вне пределов пирамиды усечения. Хотя вершины, из которых состоят эти объекты, уже были обработаны, в окне просмотра мы их не увидим. Это означает, что они усечены (clipped).
При усечении по пирамиде (frustum clipping) все примитивы за пределами пирамиды усечения полностью удаляются, а лежащие на границах преобразуются в новые примитивы. Усечение не очень сильно повышает производительность, потому что все эти невидимые вершины уже были обработаны до этого этапа в вершинных шейдера и т.п. При необходимости весь этап усечения даже можно полностью пропустить, но эта возможность поддерживается не всеми API (например, стандартный OpenGL не позволит пропустить его, однако это можно сделать при помощи расширения API).
Стоит заметить, что позиция дальней плоскости усечения в играх не всегда равна расстоянию отрисовки (draw distance), потому что последней управляет сам игровой движок. Также движок выполняет отсечение по пирамиде (frustum culling) — он запускает код, определяющий будет ли объект отрисовываться в пределах пирамиды усечения и будет ли он влиять на видимые объекты; если ответ отрицательный, то объект не передаётся на рендеринг. Это не то же самое, что усечение по пирамиде (frustrum clipping), потому что при нём тоже отбрасываются примитивы вне пирамиды, но они уже прошли этап обработки вершин. При отсечении (culling) они вообще не обрабатываются, что экономит довольно много ресурсов.
Мы выполнили все преобразования и усечение, и кажется, что вершины наконец готовы к следующему этапу в последовательности рендеринга. Но на самом деле это не так, потому что все вычисления, проводимые на этапе обработки вершин и в операциях преобразования из мирового пространства в пространство усечения, должны выполняться в однородной системе координат (т.е. каждая вершина имеет 4 компоненты, а не 3). Однако окно просмотра полностью двухмерно, то есть API ожидает, что информация вершин содержит только значения для x, y (хотя значение глубины z и сохраняется).
Чтобы избавиться от четвёртой компоненты, выполняется перспективное деление (perspective division), при котором каждая компонента делится на значение w. Эта операция ограничивает x и y интервалом возможных значений [-1,1], а z — интервалом [0,1]. Они называются нормализованными координатами устройства (normalized device coordinates) (NDC).
Если вы хотите подробнее разобраться с тем, что мы только что объяснили, и вам нравится математика, то прочитайте превосходный туториал по этой теме Сон Хо Ана. А теперь давайте превратим эти вершины в пиксели!
GeForce RTX SUPER – еще более производительная трассировка лучей в играх!
Недавно NVIDIA
представила и выпустила на рынок новые видеокарты
RTX
с приставкой «
SUPER
» в названии. Обновление получили три модели –
RTX 2060
,
RTX 2070
и
RTX 2080
. Все refresh-версии отличаются от «стандартных» более мощным графическим процессором, а также увеличенным количеством RT-ядер для обработки трассировки лучей. Всё это помогло увеличить производительность в играх в среднем на 15%, а в некоторых играх прирост доходит вплоть до 24%.
По всей видимости, NVIDIA
, выпуская на рынок обычные
GeForce RTX
оставили скрытый запас мощности, который как раз-таки и пригодился для того, чтобы спустя определенное время полностью раскрыть видеокарты линейки
RTX
. К слову, компании
AMD
, главным конкурентам
NVIDIA
на рынке игровых видеокарт, не чем ответить на видеокарты
GeForce RTX
.
NVIDIA
первой удалось внедрить рейтрейсинг в массы, в то время как
AMD
только-только изучает возможности данной технологии. Именно поэтому игровые решения «красных» без поддержки
RTX
стоят дешевле, чем карты «зеленых», которые наделены тензорными RT-ядрами.
Подробнее об RTX SUPER
Осваиваем растеризацию
Как и в случае с преобразованиями, мы рассмотрим правила и процессы, используемые для превращения окна просмотра в сетку пикселей, на примере Direct3D. Эта таблица напоминает электронную таблицу Excel со строками и столбцами, в которой каждая ячейка содержит различные значения данных (такие как цвет, значения глубины, координаты текстур и т.п.). Обычно эта сетка называется растровым изображением (raster), а процесс её генерации — растеризацией (rasterization). В статье 3D rendering 101 мы упрощённо рассматривали эту процедуру: Изображение выше создаёт впечатление, что примитивы просто разрезаются на мелкие блоки, но на самом деле операций намного больше. Самый первый этап — это определение того, обращён ли примитив в сторону камеры — например, на показанном выше изображении с пирамидой усечения примитивы, из которых состоит задняя часть серого кролика, не будут видимыми. Поэтому хотя они присутствуют в окне просмотра, рендерить их не нужно.
Мы можем приблизительно представить, как это выглядит, посмотрев на схему ниже. Куб прошёл различные преобразования для помещения 3D-модели в 2D-пространство экрана и с точки зрения камеры часть граней куба не видна. Если мы считать, что все поверхности непрозрачны, тогда часть этих примитивов можно игнорировать.
Слева направо: мировое пространство > пространство камеры > пространство проецирования > экранное пространство
В Direct3D это можно реализовать, сообщив системе, каким будет состояние рендера, и эта инструкция даст ей понять, что нужно удалить (отсечь) стороны каждого примитива, смотрящие вперёд или назад (или не отсекать совсем, например, в каркасном (wireframe) режиме). Но как она узнает, какие из сторон смотрят вперёд или назад? Когда мы рассматривали математику обработки вершин, то видели, что треугольники (или скорее вершины) имеют векторы нормалей, сообщающие системе, в какую сторону он смотрит. Благодаря этой информации можно выполнить простую проверку, и если примитив её не пройдёт, то он удаляется из цепочки рендеринга.
Теперь настало время применения пиксельной сетки. Это снова неожиданно сложный процесс, потому что система должна понять, находится ли пиксель внутри примитива — полностью, частично или вообще не внутри. Для этого выполняется процесс проверки покрытия (coverage testing). На рисунке ниже показано, как растеризируются треугольники в Direct3D 11:
Правило довольно простое: пиксель считается находящимся внутри треугольника, если центр пикселя проходит проверку, которую Microsoft называет правилом «верхнего левого угла» («top left» rule). «Верхний» относится к проверке горизонтальной линии; центр пикселя должен находиться на этой линии. «Левый» относится к негоризонтальным линиям, и центр пикселя должен находиться слева от такой линии. Существуют и другие правила, относящиеся к непримитивам, например, простым отрезкам и точкам, а при использовании мультисэмплирования (multisampling) в правилах появляются дополнительные условия if.
Если внимательно присмотреться к документации Microsoft, то можно увидеть, что создаваемые пикселями фигуры не очень похожи на исходные примитивы. Так происходит потому, что пиксели слишком велики для создания реалистичного треугольника — растровое изображение содержит недостаточно данных об исходных объектах, что вызывает явление под названием алиасинг (aliasing).
Давайте рассмотрим алиасинг на примере UL Benchmark 3DMark03:
Растеризация размером 720 x 480 пикселей
На первом изображении растровое изображение имеет очень низкое разрешение — 720 на 480 пикселей. Алиасинг чётко заметен на перилах и тени, отбрасываемой оружием верхнего солдата. Сравните это с результатом, получаемым при растеризации с увеличенным в 24 раза количеством пикселей:
Растеризация размером 3840 x 2160 пикселей
Здесь мы видим, что алиасинг на перилах и тени совершенно исчез. Похоже, что следует всегда использовать большое растровое изображение, но размеры сетки должны поддерживаться монитором, на котором будет отображаться кадр. А с учётом того, что все эти пиксели нужно обработать, очевидно, что возникнет снижение производительности.
Здесь может помочь мультисэмплирование. Вот как оно работает в Direct3D:
Вместо того, чтобы проверять соответствие центра пикселя правилам растеризации, проверяются несколько точек внутри каждого пикселя (называемых субпиксельными сэмплами или субсэмплами), и если какие-то из них удовлетворяют требованиям, то они образуют часть фигуры. Может показаться, что здесь нет никакой выгоды и алиасинг даже усиливается, но при использовании мультисэмплирования информация о том, какие субсэмплы покрыты примитивом, и результаты обработки пикселей сохраняются в буфер в памяти.
Этот буфер затем используется для смешения данных субсэмплов и пикселей таким образом, чтобы края примитива были менее рваными. Подробнее мы рассмотрим алиасинг в другой статье, но пока этой информации нам достаточно, чтобы понять, что может делать мультисэмплирование, когда используется для растеризации слишком малого количества пикселей:
Как видите, величина алиасинга на краях разных фигур значительно снизилась. Растеризация с большим разрешением определённо лучше, но снижение производительности может подтолкнуть вас с использованию мультисэмплирования.
Также в процессе растеризации выполняется проверка перекрытия (occlusion testing). Она необходима, потому что окно просмотра будет заполнено наложенными друг на друга примитивами — например, на рисунке выше смотрящие вперёд треугольники, составляющие солдата, стоящего на переднем плане, перекрывают те же треугольники другого солдата. Кроме проверки того, покрывает ли примитив пиксель, можно также сравнить относительные глубины, и если одна поверхность находится за другой, то её нужно удалить из оставшегося процесса рендеринга.
Однако если ближний примитив прозрачен, то дальний останется видимым, хотя и не пройдёт проверку перекрытия. Именно поэтому почти все 3D-движки выполняют проверки перекрытия до отправки данных в GPU и вместо этого создают нечто под названием z-буфер, являющийся частью процесса рендеринга. Здесь кадр создаётся обычным образом, но вместо сохранения готовых цветов пикселей в памяти GPU сохраняет только значения глубин. Позже их можно использовать в шейдерах для проверки видимости и с большим контролем и точностью аспектов, касающихся перекрытия объектов.
На показанном выше изображении чем темнее цвет пикселя, тем ближе объект к камере. Кадр рендерится один раз для создания z-буфера, а затем рендерится снова, но на этот раз во время обработки пикселей запускается шейдер, проверяющий их на значения в z-буфере. Если он невидим, то цвет пикселя не записывается в буфер готового кадра.
Пока нашим основным последним этапом будет интерполяция атрибутов вершин — в исходной упрощённой схеме примитив был полным треугольником, но не забывайте, что окно просмотра заполняется только углами фигур, а не самими фигурами. То есть система должна определить, какие цвет, глубина и текстура примитива должны находиться между вершинами, и эта операция называется интерполяцией. Как вы уже догадались, это ещё одно вычисление, и оно не такое уж простое.
Несмотря на то, что растеризованный экран представлен в 2D, структуры внутри него представляют собой 3D-перспективу. Если бы линии действительно были двухмерными, то для вычисления цветов и прочего мы бы могли использовать простое линейное уравнение, потому что мы переходим от одной вершины к другой. Но из-за 3D-аспекта сцены интерполяция должна учитывать эту перспективу; чтобы подробнее узнать об этом процессе, прочитайте превосходную статью Саймона Юна.
Итак, задача выполнена — так 3D-мир вершин превращается в 2D-сетку разноцветных блоков. Но мы ещё не совсем закончили.
Спереди назад (за некоторыми исключениями)
Прежде чем мы завершим рассматривать растеризацию, нужно рассказать о порядке последовательности рендеринга. Мы не говорим о том этапе, где, например, в последовательности обработки появляется тесселяция; мы имеем в виду порядок обработки примитивов. Объекты обычно обрабатываются в порядке, в котором они находятся в буфере индексов (блоке памяти, сообщающем системе, как сгруппированы между собой вершины) и это может значительно влиять на способ обработки прозрачных объектов и эффектов.
Причина этого сводится к тому, что примитивы обрабатываются по одному за раз, и если сначала отрендерить находящиеся впереди, то все находящиеся за ними будут невидимыми (именно здесь в действие вступает отсечение перекрытий (occlusion culling)) и могут быть выброшены из процесса (помогая сохранять производительность). Обычно это называется рендерингом «спереди назад», и для этого процесса буфер индексов должен быть упорядочен таким образом.
Однако если некоторые из этих примитивов прямо перед камерой прозрачны, то рендеринг спереди назад приведёт к потере объектов, находящихся за прозрачным. Одно из решений заключается в рендеринге сзади вперёд, при котором прозрачные примитивы и эффекты рассчитываются последними.
Слева направо: порядок в сцене, рендеринг спереди назад, рендеринг сзади вперёд
То есть во всех современных играх рендеринг выполняется сзади вперёд? Как бы не так — не забывайте, что рендеринг каждого отдельного примитива приведёт к гораздо большему снижению производительности по сравнению с рендерингом только того, что мы видим. Существуют другие способы обработки прозрачных объектов, но в общем случае идеального решения, подходящего к любой системе, нет, и каждую ситуацию нужно рассматривать отдельно.
По сути, это даёт нам понять основные плюсы и минусы растеризации — на современном оборудовании это быстрый и эффективный процесс, но он всё ещё является приближенным отображением того, что мы видим. В реальном мире каждый объект может поглощать, отражать, а иногда и преломлять свет, и всё это влияет на конечный вид отображаемой сцены. Разделив мир на примитивы и выполняя рендеринг только их части, мы получаем быстрый. но очень приблизительный результат.
Вот если бы существовал ещё какой-то способ…
Другой способ есть: ray tracing!
Почти пятьдесят лет назад компьютерный учёный по имени Артур Эппел работал над системой для рендеринга изображений на компьютере, в которой из камеры испускался по прямой линии до столкновения с объектом один луч света. После столкновения свойства материала (его цвет, отражающая способность и т.п.) изменяли яркость луча света. На каждый пиксель в отрендеренном изображении приходился один испущенный луч, а алгоритм выполнял цепочку вычислений для определения цвета пикселя. Процесс Эппела называют ray casting.
Примерно десять лет спустя ещё один учёный по имени Джон Уиттед разработал математический алгоритм, реализующий процесс Эппела, но при столкновении луча с объектом он генерировал дополнительные лучи, расходящиеся в разных направлениях, зависящих от материала объекта. Так как эта система генерировала новые лучи при каждом взаимодействии с объектами, алгоритм по своей природе был рекурсивным и вычислительно гораздо более сложным; однако он имел значительное преимущество по сравнению с методикой Эппела, поскольку мог правильно учитывать отражения, преломления и тени. Эту процедуру назвали трассировкой лучей (ray tracing) (строго говоря, это обратная трассировка лучей, потому что мы следуем за лучом из камеры, а не от объектов) и с тех пор она стала священным Граалем для компьютерной графики и фильмов.
Из показанного выше изображения можно понять, как работает алгоритм Уиттеда. Для каждого пикселя в кадре из камеры испускается один луч и перемещается, пока не достигнет поверхности. В данном примере поверхность просвечивающая, поэтому свет может отражаться и преломляться сквозь неё. В обоих случаях генерируются вторичные лучи, которые перемещаются, пока не столкнутся с поверхностью. Также генерируются новые вторичные лучи для учёта цвета источников освещения и создаваемых ими теней.
Рекурсивность процесса заключается в том, что вторичные лучи могут генерироваться каждый раз когда новый испущенный луч пересекается с поверхностью. Это может быстро выйти из-под контроля, поэтому количество генерируемых вторичных лучей всегда ограничивается. После завершения пути луча вычисляется цвет в каждой конечной точке на основании свойств материала этой поверхности. Это значение затем передаётся по лучу предыдущему, изменяя цвет для этой поверхности, и так далее, пока мы не достигнем начальной точки первичного луча, а именно пикселя в кадре.
Такая система может быть чрезвычайно сложной и даже простые сцены могут генерировать большой объём вычислений. К счастью, существуют трюки, упрощающие работу — во-первых, можно использовать оборудование, специально спроектированное для ускорения этих математических операций, аналогично тому, как это происходит с матричной математикой в обработке вершин (подробнее об этом чуть позже). Ещё один важнейший трюк — это попытка ускорения процесса определения объекта, в который попал луч, и точного места их пересечения — если объект состоит из множества треугольников, то эта задача может быть на удивление трудной:
Источник: Трассировка лучей в реальном времени при помощи Nvidia RTX
Вместо того, чтобы проверять каждый отдельный треугольник в каждом объекте перед выполнением трассировки лучей генерируется список ограничивающих объёмов (bounding volumes, BV) — это обычные параллелепипеды, описывающие объект. Для различных структур внутри объекта циклически создаются меньшие ограничивающие объёмы.
Например, первым BV будет весь кролик целиком. Следующая пара будет описывать его голову, ноги, тело, хвост и т.д.; каждый из объёмом в свою очередь будет ещё одной коллекцией объёмов для меньших структур головы, тела и т.д., а последний уровень объёмов будет содержать небольшое количество треугольников для проверки. Все эти объёмы часто выстраиваются в упорядоченный список, (называемый BV hierarchy или BVH); благодаря этому система каждый раз проверяет относительно небольшое количество BV:
Хотя использование BVH, строго говоря, не ускоряет саму трассировку лучей, генерация иерархии и требуемый последующий алгоритм поиска в общем случае гораздо быстрее, чем проверка наличия пересечения одного луча с одним из миллионов треугольников в 3D-мире.
Сегодня такие программы, как Blender и POV-ray используют трассировку лучей с дополнительными алгоритмами (такими как photon tracing и radiosity) для генерации очень реалистичных изображений:
Может возникнуть очевидный вопрос: если трассировка лучей так хороша, почему же она не используются повсюду? Ответ лежит в двух областях: во-первых, даже простая трассировка лучей создаёт миллионы лучей, которые нужно вычислять снова и снова. Система начинает всего с одного луча на пиксель экрана, то есть при разрешении 800 x 600 она генерирует 480 000 первичных лучей, а затем каждый из них генерирует множество вторичных лучей. Это очень сложная работа даже для современных настольных PC. Вторая проблема заключается в том, что простая трассировка лучей не особо реалистична и для её правильной реализации нужна целая куча дополнительных очень сложных уравнений.
Даже на современном оборудовании объём работы в 3D-играх недостижим для реализации в реальном времени. В статье 3D rendering 101 мы видели, что бенчмарку трассировки лучей для создания одного изображения с низким разрешением требуются десятки секунд.
Как же первый Wolfenstein 3D выполнял ray casting ещё в 1992 году и почему игры наподобие Battlefield V и Metro Exodus, выпущенные в 2020 году, предлагают возможности трассировки лучей? Они выполняют растеризацию или трассировку лучей? Понемногу и того, и другого.
Обзор бета-версии игры Minecraft RTX с применением трассировки лучей
Компания Nvidia впервые рассказала о своих видеокартах серии GeForce RTX в августе-сентябре 2020 года, и они были не совсем однозначно приняты игровым сообществом. Хотя эти решения стали первыми графическими процессорами с аппаратной поддержкой трассировки лучей, цена новинок некоторым показалась слишком завышенной, да и мощности первых GPU с поддержкой трассировки хватало лишь на какие-то отдельные эффекты с ее применением. Критики наперебой утверждали, что они не слишком то заметны и нужны, ведь хитрыми хаками в растеризации добились неплохой имитации этих же эффектов без всяких трассировок.
Первые проекты со спешно внедренной в них трассировкой лучей действительно могли показаться спорными в этом смысле. Да, в них добавились такие эффекты, как физически корректные отражения, но эти вещи в пылу сражений не так уж и заметны, а вот производительность падала довольно сильно. Но затем вышли игры с более заметным применением трассировки для отрисовки теней (Shadow of the Tomb Raider) и глобального освещения (Metro Exodus), и во всех были проведены дополнительные оптимизации, позволившие снизить негативное влияние включения этих эффектов на общую производительность.
Позднее появились и такие проекты, как игра Control, в которой была сделана чуть ли не лучшая поддержка аппаратной трассировки лучей (для современных игр), а также специальная версия Quake II RTX от Nvidia, отличающаяся не просто парой эффектов, использующих трассировку лучей, но имеющая полную трассировку пути, которая вывела реализм освещения на новый уровень. Да, в целом хорошо видно, что это старая игра, но реалистичное освещение в ней выглядит просто потрясающе. А уж после того, как поддержка аппаратной трассировки лучей была заявлена и в будущих консолях, в важности и значимости этой технологии перестали сомневаться многие из былых скептиков.
И когда в августе прошлого года было объявлено о грядущей поддержке трассировки лучей в игре Minecraft, большинством это было воспринято позитивно. Эта игра имеет графику намеренно упрощенную, в стиле этакого кубизма и примитивизма, и она не требует молниеносных действий от игрока при сотне-другой кадров в секунду, поэтому неудивительно, что она отлично подошла для внедрения трассировки. Тем более что Microsoft также заинтересована в продвижении DirectX 12 и DXR API — именно этот индустриальный стандарт и использует новая версия игры для поддержки трассировки лучей.
Minecraft — это наиболее массовая игра вообще, она была продана в количестве 176 миллионов копий на всех платформах. И хотя эта игра вышла уже 10 лет назад, она остается в топе популярных проектов. И сообщество Minecraft в целом довольно неплохо относится к разнообразным графическим модам, а физически корректные освещение, тени, отражения и преломления в реальном времени желанны для ценителей качественной компьютерной графики. А если кто еще не стал ценителем, то RTX-версия им поможет в этом. С аппаратной трассировкой лучей все перечисленные эффекты, изрядно меняющие восприятие игры, вполне возможны даже не на самых мощных системах с GeForce RTX (а в будущем — и не только на них, Microsoft уже показывала работу модифицированной версии игры на следующем поколении консоли Xbox).
Специалисты компании Nvidia работали с Mojang Studios и Microsoft для добавления поддержки трассировки лучей в игру уже довольно продолжительное время, и вот наконец-то они решили поделиться бета-версией игры и с публикой. Тестовая версия Minecraft RTX доступна в Microsoft Store с сегодняшнего дня, и хотя она до сих пор еще не идеальна, но уже позволяет начать создавать впечатляющие новые миры с внедрением реалистичных отражений и преломлений, качественного освещения и теней.
Для начала RTX-экспансии на рынке Minecraft Marketplace открыт доступ к шести бесплатным новым RTX-мирам, созданным компанией Nvidia в партнерстве с сообществом любителей этой игры. В них вы найдете открытые пространства и помещения, красочные ночью и днем, красивые замки, пещеры и поля, и даже целое подводное царство. Кроме этого, предлагаются утилиты от Nvidia для создания RTX-карт, наборы текстур и другие качественные ресурсы, помогающие при создании материалов, основанных на физических свойствах.
Трассированные кубики
Как и Quake II RTX, специализированная версия Minecraft RTX включает полноценные эффекты, которые используют все возможности по аппаратному ускорению трассировки лучей, в отличие от гибридного подхода с применением растеризации в основной части рендеринга и трассировке, используемой лишь для части эффектов, как это сделано в других играх. И разница между растеризованной и трассированной версиями тут просто потрясающая — чуть ли не еще больше, чем в Quake II RTX!
Реалистичные освещение, тени, отражения и применение физически корректных материалов очень серьезно изменяет визуальную часть игры. Давайте для начала рассмотрим несколько примеров применения трассировки в целом, сравнив картинку обычной версии игры (слева) с трассированной (справа), а далее уже разберем всё отдельно по эффектам:
Одна из самых важных вещей в компьютерной графике — освещение. От его реалистичности зависит восприятие картинки в целом. Никакие детализированные текстуры и сложнейшая геометрия не позволят сделать виртуальный мир реалистичным без достоверного освещения. Люди видят несоответствие освещения тому, что должно быть в реальности чисто подсознательно, даже не осознавая полностью, почему конкретно оно выглядит нереалистично. Мозг просто сопоставляет увиденное с полученным ранее опытом и делает выводы — он не просчитывает все лучи, но как чувствует, с какой стороны объекты должны быть освещены и насколько сильно.
В играх, использующих растеризацию, применяются хитрые методы для рендеринга освещения, не имеющие отношения к тому, как лучи света должны расходиться по виртуальной сцене, и мозг видит этот обман. Хотя, надо признать, что в последние годы было придумано множество хитрых хаков для минимизации этих недостатков, и иногда вполне получается обмануть наш мозг хотя бы частично, подсунув ему похожий на реальность суррогат. Тем не менее, при его смене на физически корректную модель расчета освещения, любой человек почувствует разницу.
Расчет освещения и других вещей при помощи трассировки лучей серьезно увеличивают реалистичность отрисованной картинки в целом. Даже в намеренно упрощенном кубическом мире игры Minecraft. То же самое реалистичное освещение позволяет показать день и ночь в игре именно так, как они и должны быть в реальности, добавляя попиксельное динамическое освещение во всю сцену, включая глобальное. Например, лучи солнечного света, проникающие сквозь разноцветные витражи внутрь светлого замка в «Imagination Island RTX» выглядят довольно интересно:
И этот эффект полностью динамический, пятна на полу следуют по ходу солнца. Или можно взять эффект глобального освещения в виде освещения от отраженных лучей света от цветных стекол на полу. Они слабо подсвечивают находящиеся рядом поверхности разными цветами, реалистично смешиваясь друг с другом. Посмотрите на разницу в итоговом изображении — без трассировки лучей картинка абсолютно плоская, а при добавлении глобального освещения она приобретает объем и реализм, когда все поверхности освещаются физически корректно:
И источники лавы в различных пещерах не просто сами по себе отрисованы красным цветом, как при растеризации. В RTX-версии они сами излучают свет, как и происходит в реальности. Свет от этих поверхностей с физически корректными характеристиками освещает соседние блоки в игре, от них отражается дальше и всё вместе это дает эффект реалистичной пещеры с тенями и освещенными участками именно там, где они и должны быть:
В общем, без трассировки лучей получается типичное плоское освещение без реалистичных теней, с явно меньшей детализацией и без объема, а трассировка всё это добавляет. Если говорить о других эффектах освещения, то можно вспомнить объемные источники света, которые так любят в современных играх. Полная трассировка позволяет выполнить их на другом уровне, по сравнению с привычными хаками растеризации (также часто использующими зачатки трассировки, к слову). Особенно хорошо этот эффект виден в подводных мирах, например в «Crystal Palace RTX», хотя и не только там:
Оба скриншота сняты с включенной трассировкой, потому что под водой вообще нет смысла сравнивать трассированную версию с обычной, уж слишком разница велика. Лучше всего можно ее оценить по обычной комнате, освещенной солнечным светом через небольшие окна. Мало того, что в трассированной версии само по себе освещение реалистичное (все поверхности освещены физически корректно) и оно полностью динамическое, так еще и имитируются видимые объемные лучи света (эффект godrays):
Следующий важный эффект, при отрисовке которого очень сильно помогает достичь реалистичности именно трассировка — это отражения. Мы неоднократно разбирали все проблемы, преследующие хаки растеризации при попытках имитации отражений — по сути, при растеризации реалистичные отражения просто невозможно отрисовать на 100% корректно и без каких-либо ограничений.
Трассировка же лучей позволяет любым поверхностям с соответствующими характеристиками отражать все остальные объекты реалистично, под любым углом и без ограничений по видимым объектам в кадре (на что не способен алгоритм отрисовки отражений, использующий экранное пространство при растеризации), с любым коэффициентом отражения и с максимальным количеством деталей (чего не могут обеспечить отражения, отрисованные при помощи динамического обновления кубических карт среды), ну и т. д. А трассировка лучей позволяет визуализировать отражающие поверхности без особых ограничений. Вот самый простой пример с самосветящимися блоками, отражающимися на поверхности пола:
Отражающие поверхности в Minecraft RTX способны в отражениях любую динамическую геометрию (модель игрока или другие) на них без каких-то ограничений, что может серьезно изменить подход к реализации новых миров. В качестве лишь одного из подобных примеров можно привести комнату из карты «Color Light and Shadow» с бесконечными (ну, почти) отражениями. Подобный эффект рекурсивных отражений практически невозможно сделать без применения трассировки лучей:
Подобные эффекты дают создателям миров в этой игре совершенно новые возможности, и кто знает, до чего додумается их созидательные головы. Кроме отражений, в Minecraft RTX также поддерживаются еще и преломления — для их отрисовки даже используется отдельный проход при рендеринге, о чем мы поговорим ниже. Это один из самых впечатляющих, но и ресурсоемких эффектов, доступный с применением трассировки лучей, и в игре он также используется, показывая самую большую разницу между растеризацией и трассировкой. При взгляде из-под воды, например:
Конечно же, мы не могли обойти и тему теней, которые, вместе с освещением, являются важнейшей частью графики. Трассированные тени всегда будут более точными и реалистичными, по сравнению с тенями, полученными с использованием еще одного хака растеризации — картами теней, имеющими важные недостатки в виде конечного их разрешения. Трассировка лучей в Minecraft позволяет реализовать физически корректные тени с мягкими краями от всех объектов игрового мира. Детализация трассированных теней принципиально ограничена лишь разрешением итоговой картинки, а не разрешением карты теней.
Результат работа трассировки вы можете видеть на экране (хотя ей в плюс сработали не только тени, конечно же, но и освещение в целом) — почти абсолютно плоский мир растеризации и объемный реалистичный мир трассировки, подсвеченный и затененный именно там, где нужно. Лучше всего разница в детализации теней видна при длинных тенях на рассвете или закате. Вот еще один пример (все скриншоты сняты в одно и то же игровое время без смены погоды, естественно):
Нам остается затронуть еще одну важную тему — для реализации подобного уровня графики было необходимо перейти от привычных простых материалов к физически корректным, имеющим все необходимые характеристики, аналогичные тому, что мы видим в реальности. Какой-то материал отражает свет, какой-то имеет более шероховатую поверхность, ну и т. д.
Большинство текстур в базовой версии Minecraft используют только два слоя (цвет и прозрачность), чего явно мало для реалистичного рендеринга различных поверхностей. Поэтому в RTX-версии к уже упомянутым слоям были добавлены текстурные слои, описывающие характеристики отражательной способности, светимости, степень шероховатости, а также карты нормалей и высот для имитации различных материалов, встречающихся в реальности.
Всё это гораздо ближе к тому, что мы видим в реальном мире, это и позволяет повысить качество отрисовки таких поверхностей, как металл, мрамор и дерево, например. Ведь все материалы в жизни имеют сильно отличающиеся характеристики, от матовой поверхности необработанного дерева, почти не отражающего свет, до гладкого полированного металла, похожего на зеркало. Эти возможности позволяют создать более реалистичные миры в Minecraft RTX, как бы странно это ни звучало. Ну хорошо — может и не особо реалистичные, но уж точно более разнообразные.
С физически корректными материалами, стекло, металл и другие поверхности в созданных энтузиастами мирах будут выглядеть более натурально и детализированно, мы уж и не говорим про самосветящиеся поверхности, вроде лавы, которую уже упоминали выше. Также в представленных Nvidia игровых мирах есть и другие самостоятельно излучающие свет блоки, показывающие сильные стороны трассировки лучей.
Реализация трассировки
Компания Nvidia внедрила в Minecraft RTX полноценный трассировщик путей с расчетом отражений, преломлений, теней и глобального освещения. Применение физически корректных материалов позволило реализовать всё это, и в частности из самых заметных отличий от растеризации — попиксельное освещение от излучающих свет (самосветящихся) материалов и корректное объемное освещение.
Рендерер в трассированной версии игры многопроходный, им рассчитывается отдельно рассеянная (diffuse) и отраженная (specular) составляющие освещения, а также есть отдельные проходы для отрисовки преломления лучей света и объемного освещения. Затем все буферы комбинируются в процессе постобработки, а частицы вроде дождя дополнительно пририсовываются при помощи растеризации.
Главное в рендерерах с трассировкой — качественная оптимизация, в том числе по количеству лучей, ведь трассировка очень ресурсоемка. И тупой результат, полученный при малом количестве рассчитываемых на пиксель лучей, всегда получается слишком шумным, требующим максимально эффективного шумоподавления. В частности, в бета-версии Minecraft RTX используется три специфических фильтра шумоподавления — отдельно для diffuse, specular и теней.
Основной проход в этой игре довольно типичен, за исключением дополнительного (и очень «шумного») буфера, содержащего тени от солнца, который и отличает этот проход от типичного процесса растеризации, обычно использующей карты теней.
Далее следуют проходы расчета непрямого рассеянного и отраженного освещения — это составляющие расчета глобального освещения. Следующий проход с отрисовкой преломлений для поверхности воды и стекла, учитывающий в том числе шероховатость поверхностей. Ну и последним идет проход, рассчитывающий объемные эффекты видимых лучей света (godrays) и тумана.
После этого информация из созданных буферов комбинируется в финальное изображение: буфер прямого освещения с тенями от солнца после дополнительного шумоподавления, буферы непрямого (глобального) освещения, также после обработки шумодавами, и буферы преломлений и объемного освещения. В процессе добавляются также и мелкие детали, использующие растеризацию, вроде частиц.
С общим принципом построения изображения мы разобрались, но какая же из указанных составляющих процесса рендеринга больше всего бьет по производительности конкретно в Minecraft RTX? Мы знаем, что трассировка лучей в целом очень ресурсоемкая штука, но сколько времени занимают разные стадии процесса? Nvidia дает конкретную раскладку:
15% времени построения кадра занимает обновление кэшей светимости (интенсивности излучения — irradiance) и объемных эффектов, а сама по себе трассировка занимает лишь 40% времени кадра (из них расчет прямых лучей отнимает 8%, а непрямое освещение — 32%).
А на что тратится еще почти половина времени рендеринга? Так как рендер реального времени в Minecraft RTX очень сильно оптимизирован по количеству лучей и отскоков из-за высокой ресурсоемкости трассировки в целом, то разработчикам пришлось использовать хитрые методы шумоподавления. До и после специальной фильтрации шумов изображение выглядит так:
Можно сказать, что на первой картинке виден один сплошной шум, а крайне редкие поверхности без него являются просто слишком гладкими, идеально подходящими для трассировки. Поэтому неудивительно, что такая большая часть времени построения кадра уходит на алгоритм шумоподавления Spatiotemporal Variance-Guided Filtering (SVGF) для двух буферов (diffuse и specular) — целых 39%, а еще 6% — на подавление шумов в буфере теней от прямого освещения.
Остальные, еще гораздо более глубокие технические детали рендерера Minecraft RTX можно узнать из ролика Nvidia, предназначенного для разработчиков:
Поддержка DLSS 2.0
Ну хорошо, о плюсах трассировки мы поговорили достаточно. А недостатков нет, получается? Куда без них. Чуть ли не единственной слабой стороной трассировки лучей является высокая ресурсоемкость процесса рендеринга. Да, появление графических процессоров серии GeForce RTX позволило реализовать аппаратную поддержку трассировки и внедрить некоторые эффекты, но возможностей даже самых мощных GPU из существующих всё еще явно недостаточно.
Но очень вовремя им подоспела помощь со стороны всё той же архитектуры Turing. Как известно, в составе новых чипов есть специализированные тензорные блоки для ускорения операций глубокого обучения. Технология улучшения производительности DLSS использует возможности этих чипов по ускорению нейросетей для быстрого и качественного апскейла — повышения разрешения рендеринга от более низкого к высокому. Мы уже рассказывали о работе этой технологии, но с тех пор она была так серьезно улучшена, что получила версию DLSS 2.0.
Новая версия DLSS использует Neural Graphics Framework (NGX) и нейросеть, специально натренированную на суперкомпьютерах на десятках тысяч изображений для того, чтобы из картинки низкого разрешения и буфера векторов движения реконструировать изображение в высоком разрешении и максимальном качестве. Эти задачи в теории можно выполнить и на универсальных вычислительных блоках, но с гораздо меньшей производительностью и эффективностью, а именно тензорные ядра и позволяют выполнить подобный алгоритм в реальном времени.
Из улучшений именно второй версии DLSS особо отметим повышенное качество изображения. DLSS 2.0 использует новые техники накопления информации из предыдущих кадров для повышения четкости и детализации при сохранении высокой стабильности изображения. При этом, новая версия DLSS отлично масштабируется на всех поддерживаемых GPU при разных разрешениях, что было проблемой первой версии. Новая модель ИИ вдвое эффективнее использует тензорные ядра, что убирает ограничения по разрешениям и моделям видеокарт.
Кроме этого, DLSS 2.0 теперь использует одну нейросеть для всех игр, тогда как первая версия требовала тренировки для каждой игры по отдельности. Универсальная нейросеть означает ускоренное внедрение технологии DLSS в будущие игры, а в списке поддерживаемых уже есть Control, MechWarrior 5: Mercenaries, Deliver Us the Moon и Wolfenstein: Youngblood, в которых новая технология уже показала свои достоинства.
DLSS 2.0 предлагает три режима качества: Quality, Balanced и Performance. Некоторые из них имеют свои ограничения, но режим Performance можно использовать вплоть до четырехкратного увеличения разрешения! Конкретно в бета-версии Minecraft RTX технология DLSS 2.0 включается при помощи пункта «Upscaling» в меню продвинутых графических настроек и включена по умолчанию.
Важно, что режим DLSS 2.0 жестко привязан к разрешению, как минимум пока что. При выходном разрешении Full HD используется качественный режим Quality, при 2560×1440 — режим Balanced, а при 4K-разрешении режим безальтернативно выставляется в Performance. Возможно, в дальнейшем нам позволят управлять режимами, но пока приходится мириться с тем, что есть.
DLSS 2.0 неплохо масштабируется по всем этим разрешениям, и в Full HD технология дает ускорение порядка 70%, в зависимости от применяемой модели GPU. В частности, следующие измерения компании Nvidia были полностью нами подтверждены, у нас получились примерно такие же значения частоты кадров на видеокарте GeForce RTX 2080 Ti при аналогичных условиях:
Вот такие приличные приросты получаются с DLSS 2.0 в разных разрешениях и режимах качества в Minecraft RTX. Именно применение этой технологии и позволяет всей линейке видеокарт GeForce RTX показывать достаточную производительность для достижения хорошей играбельности в бета-версии Minecraft с применением аппаратной трассировки лучей.
И что даже еще более важно, включение DLSS 2.0 позволяет серьезно повысить производительность при сохранении достаточно высокого качества изображения, по сравнению с рендерингом в родное (полное) разрешение. Включение продвинутого апскейла с применением нейросети второй версии позволяет повысить скорость рендеринга без явных потерь в качестве. Рассмотрим несколько примеров:
DLSS off
DLSS on
DLSS off
DLSS on
DLSS off
DLSS on
Очень неплохо! Конечно, при попиксельном сравнении можно увидеть небольшую разницу в качестве на некоторых гранях при определенных условиях (плохое освещение и растительность, например), а гладкость и четкость линий выше при нативном разрешении, но в любом случае для повышенного разрешения результат выглядит весьма достойно и визуальные недостатки подобного апскейла практически не заметны в динамике.
DLSS off
DLSS on
Правда, иногда видны артефакты, возникающие из-за того, что алгоритм использует информацию из предыдущих кадров — например, вы можете увидеть на скриншоте справа смазанные грани зеленых пикселей с эффектом ореолов в виде линий из предшествующих кадров. Но это видно, только если специально искать недостатки и внимательно вглядываться, а в остальном технология работает просто отлично. Кроме этого, DLSS явно будет еще тренироваться и дорабатываться и дальше, ведь это всего лишь бета-версия игры.
Оценка производительности и выводы
После того, как мы подробно рассмотрели плюсы трассировки лучей и процесс рендеринга с применением аппаратного ускорения трассировки, нам остается узнать, что у Nvidia получилось с производительностью. Хотя Minecraft в силу жанра и не предъявляет жестких требований к частоте кадров и плавности, но игрокам на ПК всегда хочется комфортной игры как минимум со стабильными 30 FPS, а еще лучше — 60 FPS.
Специально для бета-версии Minecraft RTX компания Nvidia выпустила оптимизированный драйвер версии 445.87, который мы и использовали при ознакомлении с игрой. В минимальных системных требованиях трассированной версии игры указана модель GeForce RTX 2060, так как это самый слабый GPU с аппаратной поддержкой DXR API и наличием тензорных ядер, необходимых для работы DLSS 2.0. Так как полная трассировка пути очень требовательна, то запуск трассированной версии на решениях семейства Pascal невозможен, поскольку даже мощная GeForce GTX 1080 Ti не даст необходимой производительности при включенной трассировке.
Включить трассировку в бете можно в продвинутых настройках графики «Advanced Video», за это отвечает пункт «DirectX Ray Tracing». А включить DLSS 2.0 можно при помощи параметра «Upscaling». Игра Minecraft при рендеринге всегда использует разрешение рабочего стола, в отличие от большинства других игр, и для того, чтобы изменить разрешение рендеринга, приходится менять разрешение в Windows 10 целиком, что не очень удобно.
Есть тут и еще один важный пункт настроек, изменяющий дальность отрисовки от 8 до 24 условных единиц, выставленный по умолчанию в минимальное значение. При максимальном же в большинстве случаев с производительностью также не происходит ничего страшного, но в некоторых гигантских мирах наблюдаются приличные притормаживания, не позволяющие использовать повышенную дальность отрисовки. К слову, от растеризованной версии с дальностью отрисовки до 160 пунктов трассированная версия всё равно отличается довольно сильно — очень далекие блоки просто не будут видны:
Но давайте перейдем к результатам тестов. Мы протестировали топовую модель GeForce RTX 2080 Ti в трех разрешениях, с включенным DLSS 2.0 и без апскейла, в полном разрешении вывода. Для своих тестов мы выбрали «подводную» комнату с аквариумами в мире «Color, Light and Shadow RTX». Вот видеоролик с процессом:
Как минимум 30 FPS топовая модель Nvidia обеспечивает везде, кроме 4K-разрешения без применения DLSS 2.0. Но с учетом того, что применение качественного апскейла тут практически незаметно, можно считать 40-48 FPS в этом разрешении также весьма комфортными. Не говоря уже о более низком разрешении, ведь в Full HD даже без включения DLSS наша видеокарта была близка к 60 FPS, а в промежуточном разрешении 2560×1440 включение DLSS 2.0 позволяет обеспечить максимальный комфорт.
Avg | Min | |
1920×1080 + DLSS | 95 | 80 |
1920×1080 | 57 | 47 |
2560×1440 + DLSS | 75 | 64 |
2560×1440 | 36 | 28 |
3840×2160 + DLSS | 48 | 40 |
3840×2160 | 17 | 13 |
При этом в обычном режиме растеризации эта же RTX 2080 Ti показала порядка 120-160 FPS в 4K-разрешении. За неимением в наличии остальных решений линейки GeForce RTX, приведем данные от самой Nvidia еще по паре моделей их видеокарт для Full HD-разрешения. Удивительно, как близки их результаты к нашим в случае модели RTX 2080 Ti, хотя мы с ними и использовали разные комнаты одного и того же мира:
Получается, что в разрешении 1920×1080 даже без включения DLSS минимально допустимую производительность обеспечит и GeForce RTX 2060, а уж с DLSS 2.0 она будет близка даже к более комфортной планке 60 FPS. У модификации Super этой же видеокарты дела обстоят еще чуть лучше. Может они обе даже и разрешение 2560×1440 потянут — только с DLSS, конечно. Не забываем также, что Minecraft RTX находится в бета-стадии разработки и наверняка программисты найдут еще возможности для дальнейшей оптимизации к релизу улучшенной версии игры.
Результаты в целом неплохие для полной трассировки пути, но с учетом относительной простоты миров в Minecraft это приводит нас к тому простому выводу, что пока полная трассировка пути доступна лишь для подобных упрощенных сцен, довольно простых геометрически, а также по материалам и эффектам. По меркам современных игр, разумеется. Но результат очень хорошо заметен, и он впечатляет — наконец-то мы видим освещение именно таким, каким оно должно быть, а не в виде довольно примитивной его имитации, выполненной при помощи хаков растеризации.
Освещение и тени в Minecraft RTX максимально правдоподобны, глобальное освещение также придает реализма, как и правильные отражения на проработанных материалах с физически корректными свойствами. А представьте себе, когда всё это будет уже в играх со сложными сценами, геометрией и текстурами. Возможно, для всего этого потребуется подождать еще парочку поколений GPU, но аппаратная трассировка точно этого стоит. Тем более, что она скоро будет и в консолях.
Если же говорить конкретно про Minecraft, то кто-то наверняка задастся вопросом, а нужна ли трассировка лучей подобной «кубической» игре, для которой графика — вроде как далеко не самое важное дело? Во-первых, судя по большому количеству графических дополнений (текстуры, эффекты, постфильтры) к этой игре — многим игрокам графика таки важна. Во-вторых, никто же не заставляет всех срочно переходить на RTX-версию, а возможность выбора — это всегда хорошо. Кто-то любит реалистичную графику, пусть и в таком нарочито кубическом мире, а для кого-то это вообще не важно. К слову, вполне возможно, что кто-то именно на примере Minecraft RTX ей и заинтересуется. Хотя, конечно же, уже существует множество модификаций с улучшенной графикой в этой игре, но трассировка на таком уровне качества в ней появилась впервые.
Ну и в-третьих, трассировка лучей и физически корректные материалы позволяют влиять в том числе и на игровой процесс. Вспомните полностью зеркальную комнату из примеров Minecraft RTX. Кто-то из фанатов сможет создать уникальные миры, использующие подобные зеркальные поверхности, другие пользователи найдут варианты применения достоинств прозрачной воды с отражениями и преломлениями. Фантазия создателей ограничена уже меньшим количеством условностей. А главное, что прогресс в графике реального времени очевиден, и рано или поздно трассировка пути придет практически во все 3D-игры.
Отдельно отметим то, как хорошо показала себя технология повышения разрешения (или производительности, как больше нравится Nvidia) в виде DLSS 2.0. Вторая версия технологии выгодно отличается как большей гибкостью и универсальностью, так и обеспечивает достаточно высокое качество даже при повышении разрешения вчетверо! Конечно, некоторые артефакты при ее работе всё же проявляются, но они практически не видны при игре, а не попиксельном сравнении скриншотов. Именно DLSS и помогает обеспечить играбельность в Minecraft RTX на всех видеокартах серии GeForce RTX.
Гибридный подход для современности и будущего
В марте 2020 года Microsoft объявила о выпуске нового расширения API для Direct3D 12 под названием DXR (DirectX Raytracing). Это был новый графический конвейер, дополняющий стандартные конвейеры растеризации и вычислений. Дополнительная функциональность обеспечивалась добавлением шейдеров, структур данных и так далее, но не требовала аппаратной поддержки, кроме той, которая уже была необходима для Direct3D 12. На той же Game Developers Conference, на которой Microsoft рассказывала о DXR, Electronic Arts говорила о своём Pica Pica Project — эксперименте с 3D-движком, использующим DXR. Компания показала, что трассировку лучей можно использовать, но не для рендеринга всего кадра. В основной части работы используются традиционные техники растеризации и вычислительных шейдеров, а DXR применяется в специфических областях. То есть количество генерируемых лучей намного меньше, чем оно было бы для целой сцены. Такой гибридный подход использовался в прошлом, хотя и в меньшей степени. Например, в Wolfenstein 3D использовался ray casting для рендерига кадра, однако он выполнялся с одним лучом на столбец пикселей, а не на пиксель. Это всё равно может показаться впечатляющим, если только не вспоминать, что игра работала с разрешением 640 x 480 [прим. пер.: на самом деле 320 x 200], то есть одновременно испускалось не больше 640 лучей.
Графические карты начала 2020 года наподобие AMD Radeon RX 580 или Nvidia GeForce 1080 Ti удовлетворяли требованиям DXR, но даже при их вычислительных возможностях существовали опасения, что они будут недостаточно мощны для того, чтобы использование DXR имело смысл.
Ситуация изменилась в августе 2020 года, когда Nvidia выпустила свою новейшую архитектуру GPU под кодовым названием Turing. Важнейшей особенностью этого чипа стало появление так называемых RT Cores: отдельных логических блоков для ускорения вычислений пересечения луч-треугольник и прохождения иерархии ограничивающих объёмов (BVH). Эти два процесса — затратные по времени процедуры для определения точек взаимодействия света с треугольниками, составляющими объекты сцены. С учётом того, что RT Cores были уникальными блоками процессора Turing, доступ к ним мог выполняться только через проприетарный API Nvidia.
Первой игрой с поддержкой этой функции стала Battlefield V компании EA. Когда мы протестировали в ней DXR, то были впечатлены улучшением отражений в воды, на траве и металлах, а также соответствующим снижением производительности:
Если честно, то последующие патчи улучшили ситуацию, но снижение скорости рендеринга кадров всё равно присутствовало (и до сих пор есть). К 2020 году появились некоторые другие игры, поддерживающие этот API и выполняющие трассировку лучей для отдельных частей кадра. Мы тестировали Metro Exodus и Shadow of the Tomb Raider, столкнувшись с той же ситуацией — при активном использовании DXR заметно снижает частоту кадров.
Примерно в то же время UL Benchmarks объявила о создании теста функций DXR для 3DMark:
DXR используется в графической карте Nvidia Titan X (Pascal) — да, в результате получается 8 fps
Однако исследование игр с поддержкой DXR и теста 3DMark показало, что трассировка лучей даже в 2020 году по-прежнему остаётся очень сложной задачей для графического процессора, даже по цене в 1000 с лишним долларов. Значит ли это, что у нас нет реальных альтернатив растеризации?
Прогрессивные функции в потребительских технологиях 3D-графики часто оказываются очень дорогими, а их изначальная поддержка новых возможностей API бывает довольно фрагментарной или медленной (как мы это выяснили при дестировании Max Payne 3 на разных версиях Direct3D в 2012 году). Последняя проблема обычно возникает, потому что разработчики игр пытаются включить в свои продукты как можно больше современных функций, иногда не имея для этого достаточного опыта.
Однако вершинные и пиксельные шейдеры, тесселяция, HDR-рендеринг и screen space ambient occlusion тоже когда-то были затратными техниками, подходящими только для мощных GPU, а теперь они являются стандартом для игр и поддерживаются множество графических карт. То же самое станет и с трассировкой лучей; со временем она просто превратится в ещё один параметр детализации, включенный по умолчанию у большинства игроков.
NVIDIA GeForce RTX 2080 Ti — наконец-то тестируем трассировку лучей и немного DLSS
Недавно я делал полноценный обзор на GeForce RTX 2080 в версии от ASUS, но из-за отсутствии долгожданного обновления для Windows 10 так и не смог тогда оценить инновационную технологию трассировки лучей в реальном времени. К счастью, сегодня мне наконец-то удалось поиграть в Battlefield V с Ray Tracing благодаря российскому отделению компании NVIDIA — они уже успели получить все необходимые апдейты.
Тест проходил на системе с флагманской вариацией видеокарты — NVIDIA GeForce RTX 2080 Ti Founders Edition. Новый графический ускоритель позволяет добиться небывалого уровня производительности и, в отличие от обычной версии 2080, обладает 11 ГБ ультраскоростной памяти нового поколения GDDR6 вместо 8.
Архитектура NVIDIA Turing с аппаратной поддержкой трассировки лучей в реальном времени делает возможным создание киношных эффектов с физически корректными отражениями, бликами и световыми эффектами, которые ранее создавались лишь покадрово на топовых графических станциях.
Кроме этого, NVIDIA представила новую умную систему сглаживания DLSS (Deep Learning Super-Sampling), которое использует нейросети для создания более четкого изображения. Это отдельная технология, которая не имеет отношения к рейтрейсингу и выполняется на специальных тензорных ядрах видеокарты — для ИИ. DLSS – как раз является первым опытом применения этих ядер.
Battlefield V пока еще не поддерживает DLSS, но я смог оценить DLSS в бенчмарках Final Fantasy XV и Epic Games Infiltrator. В обоих случаях изображение очень четкое и не видно никаких артефактов или мыла, при этом фреймрейт на одной NVIDIA GeForce RTX 2080 Ti Founders Edition на очень высоком уровне. В FFXV у персонажей наконец-то пропали все пиксели на стильных прическах. А вторая демонстрация выглядит просто сногсшибательно. После чего становиться особенно грустно, учитывая то, что мы могли получить новую интересную франшизу в этом сеттинге, а не Fortnite.
Но больше всех меня невероятно поразила технологическая демка по “Звездным войнам” на Unreal Engine 4, которую я принял за фрагмент из фильма. В ней солдаты Империи разговаривают и ходят по базе, в то время как окружение и свет красиво бликуют на их броне и интерьерах. При этом все источники света, эффекты, модели и окружение идеально гармонируют друг с другом, не пересвечивая и не излишне затеняя картинку. Графика здесь настолько запредельного уровня, что сложно поверить, что перед тобой движковая заставка, а не фильм. При этом производительность в формате 4K отличная — система выдавала в среднем 55 кадров в секунду на одной NVIDIA GeForce RTX 2080 Ti.
Что же касается непосредственно реальных игр, то на данном этапе разработчики только учатся внедрять технологии в свои свежие проекты и движки. Пока это только уровень альфа-версии, но результат уже сейчас выглядит хорошо. Авторы Shadow of the Tomb Raider используют RTX для освещения с мягкими тенями. В свою очередь DICE применяют лучи для создания красивых реалистичных отражений в Battlefield V.
Когда в BF5 взрываются бочки с горючим или стреляет танк, пламя эффектно отражается на всех объектах, где это возможно: лужи с водой и бензином, кузова автомобилей, мокрые камни, стекла домов, мраморный пол и даже стальные элементы винтовки героя.
Эти же элементы начинают отражать все окружающие объекты, вроде листвы деревьев и пробегающих рядом персонажей вне зависимости от положения камеры. При этом, если выстрелить в автомобиль, то отражения на капоте начинают красиво искривляться, следуя форме искореженного металла.
Но меня особенно удивило то, что можно заметить лицо моего персонажа на маленькой линзе оптического прицела снайперской винтовки. Или отражение засевшего где-то в левой части комнаты напарника — на шершавом потерном мачете в руках главного героя.
Подобные моменты делают картинку более живой и динамичной. Было бы интересно увидеть то, как игровые дизайнеры могли бы использовать эти возможности для создания элементов геймплея, скажем, в стелс-экшенах.
Конечно, всех особенно интересовала производительность NVIDIA GeForce RTX 2080 Ti с рейтрейсингом и без него. Мне удалось оценить работу BFV со всеми обновлениями на сборке с Founders Edition. На данный момент в игре есть несколько положений ползунка трассировки лучей — минимальное, среднее, высокое и ультра. Удивительно, но разница в графике между ними незаметна. Сотрудники NVIDIA говорят, что все отличия — в количестве отражений, но на самом деле я этого не увидел. Даже на минимальных значениях лужи, мрамор и металлические объекты все так же реалистично отражали мир, персонажей и эффекты, как и при максимальном значении. При этом разница в производительности между низким и ультра значениями огромная. Скорее всего, DICE просто еще не занималась оптимизацией среднего, высокого и ультра параметров, и необходимо ждать свежих обновлений игры. Тем не менее, я сделал замеры в том числе и при максимальном уровне Ray Tracing.
Для тестирования фреймрейта в 4K я включил Battlefield V на 4K/HDR мониторе ASUS ROG Swift PG27U с программой GeForce Experience и переключался между несколькими пресетами графики внутри самой игры, в том числе при отключенных лучах, перезагружая первый уровень с самого начала:
- Максимальные Ультра-настройки графики, включая AA. 4K. Вертикальная синхронизация отключена. Трассировка лучей отключена.
- Максимальные Ультра-настройки графики, включая трассировку лучей и AA. 4K. Вертикальная синхронизация отключена.
- Максимальные Ультра-настройки графики, включая AA. Трассировка лучей на минимуме. 1440p. Вертикальная синхронизация отключена.
В первом случае мне было интересно узнать насколько 2080 Ti мощнее 2080 и 1080 Ti в визуализации графики без лучей. Показатели последних двух я скопировал из своего теста по ASUS ROG Strix RTX 2080 — 08G — Gaming при базовом использовании — без дополнительного разгона. А сборка с RTX 2080 Ti в офисе NVIDIA соответствовала моему компьютеру.
CPU: Intel Core i7-7700 GPU: NVIDIA GeForce RTX 2080 Ti RAM: 16 GB DDR4 2133 MHz Motherboard: ASUS ROG Strix Z270I Gaming SSD: 1TB Samsung 850 Evo
GTX 1080 Ti / Максимальные Ультра-настройки графики, включая AA. 4K. Вертикальная синхронизация отключена. Трассировка лучей отключена:
- Первый уровень, Норвегия: 40-50 FPS с лагами до 20 FPS
- Первый уровень, Ливия: 60-72 FPS с лагами до 25 FPS
- Первый уровень, Алжир: 55-62 FPS с лагами до 25 FPS
- Первый уровень, Германия: 70-80 FPS лагами до 33 FPS
- Первый уровень, Нидерланды: 40-64 FPS с лагами до 20 FPS
RTX 2080 / Максимальные Ультра-настройки графики, включая AA. 4K. Вертикальная синхронизация отключена. Трассировка лучей отключена:
- Первый уровень, Норвегия: 48-64 FPS без лагов
- Первый уровень, Ливия: 60-80 FPS с лагами до 45 FPS
- Первый уровень, Алжир: 55-80 FPS с лагами до 45 FPS
- Первый уровень, Германия: 70-93 FPS лагами до 45 FPS
- Первый уровень, Нидерланды: 40-66 FPS с лагами до 30 FPS
RTX 2080 Ti Founders Edition / Максимальные Ультра-настройки графики, включая AA. 4K. Вертикальная синхронизация отключена. Трассировка лучей отключена:
- Первый уровень, Норвегия: 55-84 FPS без лагов
- Первый уровень, Ливия: 76-103 FPS без лагов
- Первый уровень, Алжир: 76-90 FPS без лагов
- Первый уровень, Германия: 84-144 FPS без лагов
- Первый уровень, Нидерланды: 48-81 FPS без лагов
Как видно из теста, RTX 2080 Ti отлично справляется со все еще неоптимизированной игрой на ультра-настройках в 4K без лучей, значительно превосходя как 1080 Ti, так и обычную 2080. Если поставить AA на минимум (четкость картинки не изменится, так как высокие уровни AA в 4K из-за высокой плотности пикселей не нужны) и включить вертикальную синхронизацию, то можно ощутимо улучшить показатели.
Но что же случается, если включить трассировку лучей (на максимум)?
GTX 1080 Ti / Максимальные Ультра-настройки графики, включая трассировку лучей и AA. 4K. Вертикальная синхронизация отключена:
- НЕ РАБОТАЕТ
RTX 2080 Founders Edition / Максимальные Ультра-настройки графики, включая трассировку лучей и AA. 4K. Вертикальная синхронизация отключена:
- Первый уровень, Норвегия: 19-33 FPS с лагом до 4 FPS
- Первый уровень, Ливия: 18-34 FPS без лагов
- Первый уровень, Алжир: 18-41 FPS без лагов
- Первый уровень, Германия: 30-60 FPS без лагов
- Первый уровень, Нидерланды: 14-40 FPS с лагом до 5 FPS
RTX 2080 Ti Founders Edition / Максимальные Ультра-настройки графики, включая трассировку лучей и AA. 4K. Вертикальная синхронизация отключена:
- Первый уровень, Норвегия: 27-44 FPS без лагов
- Первый уровень, Ливия: 33-50 FPS без лагов
- Первый уровень, Алжир: 22-44 FPS без лагов
- Первый уровень, Германия: 40-65 FPS без лагов
- Первый уровень, Нидерланды: 20-47 FPS с лагом до 13
FPS у RTX 2080 Ti с максимально включенным рейтрейсингом сразу падает примерно в два раза относительно производительности с отключенным рейтрейсингом. Если выключить AA, то можно выровнять фреймрейт до более стабильных 30 FPS в 4K, но очевидно, что на данном этапе полировки движка и драйверов ни одна видеокарта не сможет обеспечить Battlefield V 60 кадрами в секунду при таких настройках.
Конечно, надо ждать новых обновлений, особенно учитывая тот факт, что сейчас режим DXR в игре находится в альфа-версии и производительность будет улучшаться в ближайшие несколько месяцев и разницы в графике между внутриигровой настройкой трассировки лучей на максимум и на минимум в BF5 нет, но как показали тесты, FPS при максимальном положении рейтрейсинга падает сразу кадров на 15 относительно минимального.
Тем не менее, все еще можно играть в стабильных 60 FPS с трассировкой лучей на “Ультра”. Для этого надо снизить разрешение с 2160p (4K) до 1440p (2K) и выставить ползунок с лучами до минимального значения. В этом случае, при включенном AA, четкость изображения на 4K экране уменьшается незначительно, но зато FPS поднимается в два-три раза и пропадают лаги. При этом все эффекты трассировки, как я писал выше, остаются на месте:
RTX 2080 Ti Founders Edition / Максимальные Ультра-настройки графики, включая AA. Трассировка лучей на минимуме. 1440p. Вертикальная синхронизация отключена:
- Первый уровень, Норвегия: 60-87 FPS без лагов
- Первый уровень, Ливия: 70-92 FPS без лагов
- Первый уровень, Алжир: 78-90 FPS без лагов
- Первый уровень, Германия: 94-127 FPS без лагов
- Первый уровень, Нидерланды: 54-90 FPS без лагов
В этом случае вы получите максимально красивую графику, плавное управление и стабильную производительность. DICE и NVIDIA все еще работают над движком, и в новых обновлениях ситуация станет лучше, но уже сейчас можно наслаждаться реалистичными эффектами с трассировкой лучей даже владельцам экранов формата 2-4K на базовой Ti-версии Founders Edition от самой NVIDIA.
Мне будет также очень интересно оценить работу Shadow of the Tomb Raider и посмотреть, можно ли получить 60 FPS в 4K на “Ультра” в Battlefield 5 при разгоне видеокарты. Но это будет уже в другом тесте, а пока спасибо за внимание. Оставайтесь с Gamemag.ru!
Автор: ACE, редактирование: SkyerIst