DirectX Raytracing: трассировка лучей в реальном времени
Трассировка лучей и растеризация — в чем разница?
Мы не уверены, что все наши читатели знают или помнят, что такое трассировка лучей, чем в принципе отличаются разные методы рендеринга и какие у них существуют достоинства и недостатки. Поэтому для начала попробуем очень кратко, без сложной математики и более-менее понятно рассказать об этом. Перед тем, как перейти к трассировке лучей, нам нужно вспомнить основы классического алгоритма растеризации с Z-буфером.
В методе растеризации, общепринятом сейчас в современной графике реального времени, для отрисовки каждого объекта находится проекция на плоскость экрана от геометрических примитивов (полигонов, чаще всего треугольников), из которых состоит объект. Треугольники отрисовываются по пикселям с использованием буфера глубины, который содержит значения расстояния до плоскости экрана и необходим для того, чтобы ближние к камере треугольники перекрывали дальние при рендеринге.
Кроме вершин и соединяющих их полигонов, также хранится информация о цвете, текстурных координатах и нормалях, необходимых для того, чтобы определить лицевую и обратную части каждой поверхности. Цвет пикселей определяется в результате сложных вычислений в вершинных и пиксельных шейдерах, а такие эффекты, как тени, отрисовываются при помощи дополнительных проходов, но также с применением растеризации.
Процесс затенения (shading) заключается в расчете количества освещения для пикселя с учетом наложения одной или нескольких текстур на пиксель, что и определяет его конечный цвет. Все это требует большого количества вычислений, ведь в сценах современных игр содержится по несколько миллионов полигонов и по несколько миллионов пикселей в экранах высокого разрешения, а обновление информации на экране должно быть с частотой хотя бы 30 кадров в секунду, а лучше — 60 FPS. Не говоря уже о шлемах виртуальной реальности, где нужно одновременно рисовать изображения для двух глаз с частотой в 90 FPS.
Но так как графические процессоры работают на очень высокой тактовой частоте и имеют большое количество аппаратных блоков, специализированных на определенных вычислениях, а растеризация очень хорошо поддается распараллеливанию, то особых проблем с производительностью рендеринга нет, и подавляющее большинство компьютерных 3D-игр использует именно растеризацию. В реальности дела обстоят несколько сложнее, так как используется множество дополнительных оптимизаций для того, чтобы не отрисовывать множество невидимых треугольников, но суть растеризации в общем и целом именно такова.
При разработке графических процессоров за все время их развития, огромное количество времени ушло на оптимизацию работы по отбрасыванию невидимой геометрии и снижению вычислительной нагрузки. Сначала отбросили отрисовку объектов вне зоны видимости, потом объекты закрытые другими, более близкими к камере и т. д. Наработанные оптимизации при растеризации довольно эффективны, в современных играх невидимые объекты почти не потребляют вычислительные ресурсы, значительно снижая объемы работ по растеризации сцены. Вы поймете далее, для чего мы касаемся темы невидимых объектов.
Для расчета глобального освещения, отрисовки теней и других эффектов приходится использовать хитрые хаки, основанные на той же растеризации. В результате, за все эти годы GPU стали весьма сложными, научились ускорять обработку геометрии в вершинных шейдерах, качественно отрисовывать пиксели при помощи пиксельных шейдеров и даже применять универсальные вычислительные шейдеры для расчета физики, постэффектов и множества других вычислений. Но основа работы GPU все время оставалась той же.
У трассировки же лучей основная идея совершенно другая, но в теории чуть ли не проще. При помощи трассировки имитируется распространение лучей света по 3D-сцене. Трассировка лучей может выполняться в двух направлениях: от источников света или от каждого пикселя в обратном направлении, далее обычно определяется несколько отражений от объектов сцены в направлении камеры или источника света, соответственно. Просчет лучей для каждого пикселя сцены менее требователен вычислительно, а проецирование лучей от источников света дает более высокое качество рендеринга.
Обратная трассировка была впервые описана в 1969 году сотрудником компании IBM в работе «Some Techniques for Shading Machine Renderings of Solids» и эта техника просчитывает путь луча света для каждого пикселя на экране в зависимости от 3D-моделей в сцене. Через 10 лет произошел еще один рывок в технологиях, когда исследователь Turner Whitted (ныне работающий в Nvidia Research, к слову) опубликовал работу «An Improved Illumination Model for Shaded Display», показавшую как можно при трассировке рассчитывать тени, отражение и преломление света.
Еще пара работ в 1980-х дополнительно описала основы трассировки лучей для компьютерной графики, которые вылились в целую революцию построения синтетического изображения в киноиндустрии. Так, в 1984-м несколько сотрудников Lucasfilm описали, как при помощи трассировки лучей создать такие эффекты, как смазывание в движении (motion blur), глубина резкости (depth of field), мягкие тени, размытые отражения и преломления. Еще через пару лет профессор Калифорнийского технологического института Jim Kajiya в своей работе «The Rendering Equation» описал более точный способ рассеивания света в сцене. И с тех пор трассировка лучей в киноиндустрии применялась буквально повсеместно.
Итак, в распространенном методе обратной трассировки лучей, для каждого пикселя на экране проводится воображаемый луч от камеры до объекта в сцене. Таким образом имитируется луч света, пришедший в камеру от источника света по этому направлению, и первое пересечение с объектом используется для определения цвета пикселя. Первичные лучи определяют видимость объектов (вроде Z-буфера в растеризации), а для определения цвета нужно провести дальше вторичные лучи от точек пересечения к разным источникам света (если лучи блокируются объектом, то источник света не будет влиять на освещение пикселя), а совокупность вторичных лучей определяет освещение, попадающее на пиксель.
Но все самое интересное происходит еще дальше — для достижения фотореалистичности нужно учитывать характеристики материалов в виде количества отражаемого и преломляемого ими света, и для расчета цвета пикселя нужно провести еще лучи отражения и преломления. На рисунке выше они не указаны, но их можно мысленно вообразить как лучи, отраженные от поверхности шара и преломленные ей. Такой улучшенный алгоритм трассировки лучей был изобретен уже несколько десятков лет назад, и эти дополнения стали большим шагом по увеличению реалистичности синтетической картинки. К сегодняшнему дню метод обрел множество модификаций, но в их основе всегда лежит нахождение пересечения лучей света с объектами сцены.
Первые практические опыты по реализации трассировки лучей в реальном времени начались довольно давно, на известной конференции SIGGraph подобные разработки появлялись нередко. Демонстрации трассировки в реальном времени появились еще в конце 80-х годов прошлого века и обеспечивали скорость в несколько кадров в секунду, используя высокооптимизированные техники и несколько вычислительных систем с общей памятью для обсчета. С тех пор появилось множество разработок, предназначенных для ускорения трассировки для работы, в том числе и на одном ПК.
Не говоря уже о многочисленных 3D-движках энтузиастов демо-сцены в конце 90-х и далее, которые воодушевились возможностями и принципиальной простотой метода, привнеся множество полезных оптимизаций в трассировку лучей. У нас на сайте в свое время была опубликована целая серия материалов, посвященных одному из программных движков трассировки лучей, весьма специфическому и с массой серьезных ограничений, не позволяющих создать на его основе серьезные игровые проекты:
Не отставали и производители аппаратного обеспечения, которые еще давно показывали на выставках экспериментальные прототипы ускорителей трассировки и оптимизированные для них демонстрационные программы. Так, в июне 2008 года компания Intel показала специальную версию игры Enemy Territory: Quake Wars (Quake Wars: Ray Traced), использующую трассировку лучей при рендеринге в разрешении 1280×720 на скорости 15–30 кадров в секунду, что уже считается реальным временем. Та демонстрация не использовала аппаратные ускорители, а работала на 16 ядрах Xeon на частоте под 3 ГГц.
Проект Intel наглядно показывал плюсы рендеринга, использующего трассировку лучей, демонстрируя реалистичную воду, тени от объектов сквозь прозрачные поверхности, а также отражения. Развитием демонстрации стал проект Wolfenstein: Ray Traced, да и различные энтузиасты частенько берут движок серии Quake для добавления трассировки — так с подачи моддеров в Quake 2 появились реалистичные отражения, которые портил очень сильный шум и высочайшие системные требования.
А прототипы уже аппаратных ускорителей трассировки несколько лет (начиная с 2012-го и заканчивая 2016-м) показывала компания Imagination Technologies, предлагающая даже открытый API для трассировки лучей — OpenRL. Заявлялось, что аппаратный ускоритель разработки этой компании способен работать в Autodesk Maya и обеспечивать трассировку лучей в реальном времени. Впрочем, средств на продвижение аппаратного ускорения трассировки лучей у компании для успеха не хватило, как и «веса» этой компании на графическом рынке, чтобы быть его локомотивом. Да и демонстрационные программы были не самыми впечатляющими, честно говоря, хотя и показывали некоторые преимущества трассировки:
Гораздо лучше дело пошло у компании Nvidia, которая еще на SIGGraph 2009 анонсировала технологию OptiX, предназначенную для трассировки лучей в реальном времени на графических процессорах их производства. Новый API открыл доступ к выполнению трассировки лучей в профессиональных приложениях с необходимой гибкостью, в частности — двунаправленному path tracing и другим алгоритмам.
Основанные на технологии OptiX рендереры уже существуют для многочисленного профессионального ПО, вроде Adobe AfterEffects, Bunkspeed Shot, Autodesk Maya, 3ds max и других приложений, и используются профессионалами в работе. К рендерингу реального времени это можно отнести лишь с определенными допущениями, потому что при высокой частоте кадров получалась очень шумная картинка. Лишь через несколько лет индустрия вплотную подошла к применению аппаратного ускорения трассировки лучей уже в играх.
Плюсы и минусы трассировки лучей
Техника рендеринга с трассировкой лучей отличается высоким реализмом, по сравнению с растеризацией, так как она имитирует распространение лучей света очень похоже на то, как это происходит в реальности (естественно, все равно не на 100% точно). Трассировка позволяет воссоздать весьма реалистичные тени, отражения и преломления света, и поэтому она давно ценится в архитектурных приложениях и промышленном дизайне. Технология помогает специалистам этой сферы задолго до физического воплощения понять, как будут смотреться материалы при различном освещении в реальном мире.
В явные достоинства трассировки можно также включить то, что вычислительная сложность метода мало зависит от геометрической сложности сцены, а вычисления отлично распараллеливаются — можно легко и независимо трассировать несколько лучей одновременно, разделяя поверхность экрана на зоны для их трассировки на разных вычислительных ядрах. Также очень полезно и то, что отсечение невидимых поверхностей является логическим следствием работы алгоритма.
Но важнее все же именно то, что метод имитирует реальное распространение лучей света, получая итоговую картинку более высокого качества, по сравнению с растеризацией. У растеризации есть явные недостатки — к примеру, не входящий в сцену объект не будет отрисовываться на GPU, но ведь он может отбрасывать видимую тень или должен быть виден в отражающей поверхности (зеркале), а оптимизации растеризации его отбросили и не приняли во внимание. Не говоря уже о том, что этот невидимый объект может сильно влиять на глобальное освещение сцены, отражая свет на видимые поверхности. Частично эти проблемы решаются, в частности, применение карт теней позволяет отрисовать тени от невидимых в сцене объектов, но отрисованная в результате картинка все равно далека от идеала. И дело тут в самом принципе, ведь растеризация работает совсем не так, как человеческое зрение.
Такие эффекты, как отражения, преломления и тени, довольно сложные для качественной реализации при растеризации, являются натуральным результатом работы алгоритма трассировки лучей. Возьмем отражения — это лишь одна из областей, в которых метод трассировки лучей заметно лучше растеризации. В современных играх отражения обычно имитируются при помощи карт окружения (environment map, статических или динамических) или отражениями в экранном пространстве (Screen-Space), которые дают неплохую имитацию отражений в большинстве случаев, но все же имеют очень большие ограничения, в частности — не подходят для близко расположенных объектов.
Расчет отражений в экранном пространстве позволяет получить более-менее похожие на правду отражения при некоторых ограничениях, зато при аппаратном ускорении на GPU с использованием растеризации. А при трассировке лучей отражения всегда отображаются идеально без необходимости в дополнительных сложных алгоритмах. Еще одним важным преимуществом трассировки является вывод отражений частей одного и того же объекта друг на друге (к примеру, чтобы ручка чайника или его носик отражались на нем самом), что куда сложнее сделать при помощи растеризации.
Еще одним примером явного преимущества метода трассировки лучей является рендеринг прозрачных объектов. При помощи растеризации очень непросто имитировать эффекты прозрачности, так как ее расчет зависит от порядка рендеринга и для этого приходится предварительно сортировать прозрачные полигоны, да и то возможно появление визуальных артефактов. Придумано несколько хаков для того, чтобы миновать сортировку полигонов, но это все выливается в усложнения метода и дополнительные сложности. А вот алгоритм трассировки лучей сам по себе позволяет отрисовать любые эффекты прозрачности с идеальным качеством.
Ну и последний (для начала) пример — отрисовка теней. При растеризации в большинстве случаев используются карты теней (shadow mapping), которые также основаны на растеризации, просто рендеринг делается из другой точки сцены и с другими параметрами. Силуэты объекта рисуются в отдельный буфер от источника света, содержимое буфера фильтруется и накладывается на поверхность, куда тень должна отбрасываться. У таких методов есть несколько проблем, включая неровности («лесенки») на контурах, которые вы все видели в играх, а также увеличенный расход видеопамяти. Трассировка же лучей позволяет решить проблему теней автоматически, не требуя дополнительных алгоритмов и объемов памяти. Более того, в случае хака растеризации получится в любом случае некорректная физически тень, а вот отрисованная при помощи трассировки лучей мягкая тень будет реалистичной.
Но есть у трассировки лучей и недостаток. Один, но очень важный — отрисовать все вышеописанное с вычислительной точки зрения в несколько раз сложнее. Низкая производительность на существующем «железе» — главный недостаток метода трассировки, который долгое время перечеркивал все его плюсы. Нахождение пересечения лучей с объектами сцены не ускоряется столь же легко, как сравнительно простые операции при растеризации треугольников, для которых много лет используются специальные 3D-ускорители, именно поэтому в графике реального времени до сих пор используется метод растеризации, который позволяет довольно быстро нарисовать картинку, хоть и несколько уступающую в качестве полноценной трассировке, но достаточно реалистичную при этом.
При трассировке вам нужно просчитать тысячи лучей для каждого источника освещения, большая часть из которых будет слабо влиять на итоговую картинку, поэтому нужны как дополнительные оптимизации для алгоритма трассировки лучей, так и новое аппаратное обеспечение, способное ускорять соответствующие операции. Плюс к этому, само по себе использование трассировки не гарантирует фотореализма. Если применять простые алгоритмы, то результат будет неплохим, но все равно недостаточно реалистичным, а для полноценной имитации реальности нужно применять дополнительные техники, вроде photon mapping и path tracing, которые точнее имитируют распространение света в мире.
С другой стороны, так как алгоритм трассировки лучей хорошо распараллеливается, то его можно решить самым простым технически методом — увеличением числа вычислительных ядер (графического) процессора, рост количества которых происходит каждый год. При этом обеспечен линейный рост производительности при трассировке. А если учесть явную недостаточность оптимизации как аппаратного, так и программного обеспечения для трассировки лучей на GPU сейчас, можно предположить потенциально быстрый рост возможностей по аппаратной трассировке лучей.
Но тут возникают более мелкие проблемы. Просчет только первичных лучей сам по себе не слишком сложен, но и не даст заметного улучшения качества рендеринга, по сравнению с классической растеризацией, да еще с хитрыми хаками. А вторичные лучи просчитывать куда сложнее потому, что у них нет когерентности — однонаправленности. Для каждого пикселя приходится рассчитывать полностью новые данные, что не очень хорошо для их кэширования, важного для достижения высокой скорости. Поэтому обсчет вторичных лучей сильно зависит от задержек памяти, которые почти не снижаются, в отличие от пропускной способности памяти (ПСП), растущей стремительными темпами.
Трассировка лучей хоть и кажется довольно простым и элегантным методом, который можно реализовать буквально несколькими строками кода, но это будет совершенно неоптимизированный алгоритм, а высокопроизводительный код для трассировки лучей сделать крайне сложно. Если при растеризации алгоритм работает быстро, но приходится придумывать хитрые методы для сложных визуальных эффектов, то трассировка лучей умеет отрисовывать их все изначально, но заставляет очень тщательно оптимизировать код для того, чтобы он исполнялся достаточно быстро для реального времени.
Есть множество методов для ускорения трассировки, самые производительные алгоритмы трассировки лучей обрабатывают лучи не по одному, а используют наборы лучей, что ускоряет процесс обработки лучей одинакового направления. Такие оптимизации отлично подходят для исполнения на современных SIMD-блоках CPU и на GPU, они эффективны для основных сонаправленных лучей и для теневых лучей, но все равно не подходят для лучей преломления и отражения. Поэтому приходится серьезно ограничивать количество лучей, рассчитываемых для каждого пикселя сцены, а повышенную «шумность» картинки убирать при помощи специальной фильтрации.
Кроме этого, метод трассировки лучей требует подходящей структуры данных для хранения элементов сцены, и она может иметь определяющее значение для производительности. Какие-то структуры лучше подходят для статических данных, другие — для динамически изменяющихся. Так что трассировка лучей только при поверхностном взгляде кажется простым и максимально элегантным методом, но для получения от нее нужной производительности придется очень много поработать для оптимизации — не меньше, чем для имитации сложных эффектов при растеризации. И эта работа только началась, по сути.
Нужно решить несколько проблем перед тем, как трассировка лучей станет реальной альтернативой растеризации для игр. Сейчас кажется, что преимущества трассировки не так уж велики, как существенное снижение производительности при ее использовании. Да, у трассировки есть очень важные плюсы в виде реалистичных отражений, теней и обработки прозрачных объектов, что сложно сделать при растеризации, но… достаточно ли много таких объектов в играх, чтобы недостаток реализма для них стал серьезным? С одной стороны, большинство объектов в мире отражают свет, с другой — играми доказано, что наши глаза и мозг довольствуются всего лишь приближением к реалистичности. В большинстве современных игр отражения на объектах хоть и не полностью фотореалистичные, но их чаще всего достаточно для обмана нашего мозга.
Да, трассировка лучей может дать лучшее качество, чем растеризация, но какими силами? Если стремиться к полной реалистичности, то полноценная трассировка с расчетом множества лучей для освещения и отражений, а также комбинацией техник вроде radiosity и photon mapping, будет сверхтребовательной к вычислительной мощности. Зачастую даже офлайновые рендеры, работающие не в реальном времени, используют упрощения. Конечно, через какое-то время достаточно высокая вычислительная мощность станет доступна для того, чтобы получить преимущество перед растеризацией в том числе и по производительности, но пока что мы еще очень далеки от этого момента.
Даже при офлайновом рендеринге для киноиндустрии при росте вычислительной мощности время рендеринга со временем не снижается, так как аппетиты художников растут еще быстрее! И даже лидирующие в производстве анимационных картин компании, вроде Pixar, стараются оптимизировать процесс рендеринга, используя трассировку лучей только для части эффектов — именно из-за значительного влияния на производительность. Так что надо понимать, что времена полноценной трассировки для всей сцены в играх реального времени еще очень далеки. И для полноценного рендеринга в реальном времени методом трассировки лучей в играх вычислительных мощностей пока что точно не хватит. Это длинный путь даже при том развитии GPU, которое продолжается до сих пор.
Но в любом случае, именно трассировка лучей является тем самым физически корректным путем, который способен решить множество больших и мелких проблем существующего подхода. При помощи различных хаков и трюков, применяемых сейчас в растеризации, можно добиться неплохого результата, но это точно нельзя назвать универсальным и идеальным методом для визуализации 3D-графики. Уже довольно скоро, стремясь к реализму, 3D-разработчики приложений реального времени достигнут предела существующего метода растеризации, и им придется перейти на метод с продвинутой моделью освещения, похожей на то, что происходит в реальности. Скорее всего, это будет именно трассировка лучей. Но так как трассировка лучей весьма затратный метод и ее вряд ли потянут даже самые мощные системы, то поначалу стоит рассчитывать на гибридные методы рендеринга, сочетающие производительность растеризации и качество трассировки лучей.
Гибридный рендеринг для переходного периода
Исходя из требовательности трассировки лучей даже с малым количеством рассчитываемых лучей для каждого пикселя, этот метод вряд ли можно применять исключительно, и пока что он не заменит растеризацию. Но есть вариант смешения двух методик. К примеру, основу геометрии можно растеризовать с высокой производительностью, а затем при помощи трассировки лучей просчитывать только мягкие тени и отражения. Хотя растеризация продолжит играть важнейшую роль и в ближайшие годы с появлением гибридного рендеринга, доля алгоритмов трассировки лучей в таких движках будет постепенно расти исходя из роста вычислительных возможностей будущих GPU.
Такой подход давно используется в тех же мультфильмах компании Pixar, несмотря на то, что у них в требованиях вроде бы нет жестких ограничений по времени рендеринга. Тем не менее, проще и быстрее отрисовывать геометрию при помощи тех же микрополигонов системы рендеринга Reyes, а трассировку использовать только там, где нужны конкретные эффекты. Практически все анимационные фильмы студии Pixar использовали ранее микрополигоны и растеризацию, а трассировку лучей к движку рендеринга RenderMan добавили позднее для мультфильма «Тачки», где она использовалась избирательно — для расчета глобального затенения (ambient occlusion) и отрисовки отражений.
Но на деле гибридные решения не так просты, ведь для эффективной трассировки лучей нужно организовать структуру данных специальным образом, чтобы снизить количество проверок пересечения лучей с объектами сцены. Поэтому и при гибридном рендеринге придется создавать оптимизированную структуру данных. А в вопросе производительности большой проблемой является доступ к памяти, связанный с вторичными лучами, которые нужны при гибридном рендеринге. Получается, что при комбинации двух методов рендеринга объединяются и многие их недостатки, в частности — уходит простота метода трассировки лучей и высокая производительность растеризации.
Но когда достоинства все же перевешивают, то подобный гибридный подход имеет смысл. Уже сейчас доступно сочетание некоторых возможностей растеризации и трассировки, включая аппаратно-ускоренную на GPU подготовку карт освещения, рендеринг динамических карт освещения и части теней, отрисовку отражений и полупрозрачных объектов с преломлением. Уже это является большим достижением, так как подобный подход вот уже много лет был доступен лишь при офлайновом рендеринге. Еще в конце 90-х гибридный рендеринг применялся при создании анимационных фильмов, чтобы улучшить эффективность, а сейчас он становится доступным и для приложений реального времени.
Но это лишь самое начало перед грядущей «Золотой эрой» рендеринга реального времени. В будущем подобный гибридный подход разовьется в нечто большее, и вместо выборочных эффектов можно будет использовать полноценные техники с продвинутым освещением, затенением и различными сложными эффектами.
Примерно так же, как офлайновый рендеринг за несколько лет прошел путь от «Bug«s Life» к куда более сложным анимационным фильмам, вроде «Coco», использующим уже полноценный path tracing с десятками, а то и сотнями просчитываемых лучей на пиксель. В отличие от прошлых лет, там уже не было карт теней, отдельных проходов для расчета освещения, а только полноценная трассировка — к этому же стремятся и разработчики игр, просто их путь будет несколько длиннее, но цель то одинакова.
А до того, как процесс перехода от растеризации к полной трассировке произойдет, нужно использовать гибридный рендеринг и во многом менять подход к разработке. Например, отдать часть работы по предварительной подготовке и «запекании» некоторых данных в GPU, переделать свой производственный конвейер и готовить движки рендеринга к тому, что все большая часть расчетов будет постепенно переходить на трассировку. А частичные преимущества трассировки получится использовать уже сейчас, хоть и с крайне малым количеством лучей на пиксель и с обязательным шумоподавлением.
Но даже при постепенном переходе к трассировке, не нужно отбрасывать необходимость оптимизаций, не специфичных для растеризации. Высокоуровневые оптимизации вроде уровней детализации (level of detail — LOD), отбрасывания невидимых поверхностей (occlusion culling), тайлинга и стриминга отлично будут работать и при трассировке лучей. И пока индустрия не перейдет к полноценной трассировке, нужно продолжать применять эффективные техники с использованием экранного пространства там, где необходима высокая производительность и не критично качество.
Ну и рендеринг с применением трассировки лучей нужно оптимизировать. К примеру, при рендеринге динамических лайтмапов при помощи DXR, эффективно кэшировать освещение в картах освещения, а затем использовать накопление данных во времени для следующего кадра. Процесс относительно быстр и его нужно использовать, так как трассировка лучей в пространстве лайтмапа обеспечивает лучший результат, по сравнению с трассировкой лучей в экранном пространстве. Правда, придется использовать шумоподавление, так как особенно много лучей просчитать в реальном времени не удастся.
Даже обычные фильтры для подавления шумов с настройкой именно под особенности работы трассировки лучей работают неплохо, а если применить шумоподавление, использующее возможности нейросетей, которое уже демонстрировала та же Nvidia, да еще и аппаратно ускоренное на тензорных ядрах графических процессоров архитектуры Volta, то будущее гибридного рендеринга видится довольно ясным — по крайней мере, некоторые из эффектов, которые можно легко добавить в существующие движки (расчет теней или глобального освещения и затенения), использующие растеризацию, будут добавлены в игры уже довольно скоро.
Итак, очевидный способ применения гибридного рендеринга заключается в растеризации сцены и применении трассировки лучей лишь для части расчетов ее освещения, а также для расчетов отражений с преломлениями. Такой подход дает скорость растеризации и качество трассировки в виде аккуратной имитации освещения, в том числе глобального, отражений и преломлений лучей света и отрисовке оптически корректных теней. Более того, симуляция этих эффектов при помощи хаков в растеризации и их усложнение когда-то приведет к тому пределу, когда это станет настолько ресурсоемко, что проще будет заменить вычисления настоящей трассировкой лучей. И в целом это — единственно правильный путь, если смотреть в будущее развития графики.
DirectX Raytracing — стандартный API для трассировки лучей
Итак, со временем растеризацию научились делать весьма впечатляющей, добавляя различные алгоритмы и хаки, вроде параллакс маппинга, добавляющего объема к не слишком сложным поверхностям, а также при помощи карт теней. Для улучшения графики требовалось лишь увеличивать скорость графических процессоров и делать их чуть более универсальными, оставляя основу в виде растеризации практически нетронутой (не считая методы оптимизации в виде разбиения кадра на тайлы и т. п.).
Современные техники вроде отражений в экранном пространстве и имитации глобального освещения практически подвели растеризацию к ее практическим пределам, так как эти алгоритмы требуют хитрых хаков при обработке и сложных вычислений, порой выполняемых асинхронно с рендерингом. И в ближайшее время сложность и ресурсоемкость таких алгоритмов еще продолжит рост. Трассировка лучей же позволяет делать сложные эффекты простым способом, также открывая двери для внедрения совершенно новых техник, невозможных ранее при рендеринге реального времени. Но как этого добиться, если GPU умеют только растеризацию?
Текущая версия DirectX 12 лишь кажется довольно новой, а на деле этот графический API был анонсирован еще на выставке GDC 2014, а вышел публично в составе Windows 10 годом позже. До сих пор применение этой версии далеко от желаемого и так получилось сразу по многим причинам. Во-первых, цикл разработки игр и движков довольно большой, а то, что DirectX 12 работает только в последней версии Windows и имеет ограниченную поддержку в консолях нынешнего поколения, лишь уменьшает число доводов в пользу его использования на ПК. Тем не менее, применение низкоуровневого API мы уже увидели в нескольких играх, но что же дальше? А дальше линия развития DirectX резко повернула еще раз, представив средства для поддержки трассировки лучей.
В рамках конференции игровых разработчиков GDC 2018 компания Microsoft представила новое дополнение к DirectX API, в котором так или иначе поучаствовало множество партнеров, занимающихся разработкой программного и аппаратного обеспечения. Дополнение называется DirectX Raytracing и его имя говорит о том, что это — стандартный API для программной и аппаратной поддержки трассировки лучей в DirectX-приложениях, позволяющее разработчикам использовать алгоритмы и эффекты с применением упомянутой техники. DirectX Raytracing (далее DXR для краткости) обеспечивает стандартизированный подход для внедрения трассировки лучей, которая ускоряется при помощи графических процессоров. Это расширение сочетается с возможностями существующего DirectX 12 API, позволяя использовать как традиционную растеризацию, так и трассировку лучей, а также смешивать их в желаемых пропорциях.
Вся работа DXR API, связанная с трассировкой лучей, управляется при помощи списков команд, отправляемых приложением. Трассировка лучей тесно интегрирована с растеризацией и вычислительными командами и может запускаться многопоточно. Шейдеры трассировки лучей (целых пять новых типов шейдеров!) управляются аналогично вычислительным шейдерам, что позволяет использовать их параллельную обработку на GPU, управляя их выполнением на сравнительно низком уровне. Приложение при этом полностью отвечает за синхронизацию работы GPU и использованию его ресурсов, как при растеризации и вычислениях, что дает разработчикам контроль над оптимизацией выполнения всех типов работы: растеризация, трассировка лучей, вычисле
Полный текст статьи читайте на iXBT
