Помощью технологии трассировки лучей в. Что такое трассировка лучей и нужна ли она нам в играх? Моделирование «зеркального» отражения

Трассировка лучей и растеризация — в чем разница?

Мы не уверены, что все наши читатели знают или помнят, что такое трассировка лучей , чем в принципе отличаются разные методы рендеринга и какие у них существуют достоинства и недостатки. Поэтому для начала попробуем очень кратко, без сложной математики и более-менее понятно рассказать об этом. Перед тем, как перейти к трассировке лучей, нам нужно вспомнить основы классического алгоритма растеризации с 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 и использованию его ресурсов, как при растеризации и вычислениях, что дает разработчикам контроль над оптимизацией выполнения всех типов работы: растеризация, трассировка лучей, вычисления, передача данных.

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

На самом высоком уровне DXR добавляет четыре новые концепции к DirectX 12 API:

1. Структура ускорения (acceleration structure ) — это объект, представляющий 3D-сцену в формате, оптимальном для обсчета лучей на графических процессорах. Представленная в виде двухуровневой иерархии, эта структура обеспечивает оптимизированный просчет лучей на GPU и эффективное изменение динамических данных.
2. Новый метод списка команд (command list ) под названием DispatchRays является основой для трассировки лучей в сцене. Именно таким образом игра передает рабочие задачи DXR в GPU.
3. Набор новых типов шейдеров для создания лучей, которые определяют, что именно будет вычислять DXR. При вызове DispatchRays, запускается шейдер генерации лучей. При использовании новой функции TraceRay в HLSL, шейдер генерации лучей отправляет луч в сцену, и в зависимости от того, куда луч попадает в сцене, в точке пересечения может быть вызван один из нескольких шейдеров попадания (hit ) или промаха (miss ), что позволяет назначать для каждого объекта собственный набор шейдеров и текстур и создавать уникальные материалы.
4. Состояние конвейера трассировки, добавленное к уже существующим состояниям графического и вычислительного конвейеров, переводящее шейдеры трассировки лучей и другие состояния, относящиеся к рабочим нагрузкам трассировки.

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

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

Второй шаг при использовании DXR — это создание состояния конвейера трассировки. Современные игры группируют вызовы отрисовки (draw calls ) для увеличения эффективности их исполнения в специальные группы — пакеты (batch ), например, отрисовывая все металлические объекты в одном батче, а все пластиковые — в другом. Но при трассировке невозможно заранее точно знать, на какой материал попадет конкретный луч, и батчи применить не получится. Вместо этого, состояние конвейера трассировки позволяет назначить несколько наборов шейдеров трассировки и текстурных ресурсов. Таким образом можно указать, к примеру, что все пересечения лучей с одним объектом должны использовать такой-то конкретный шейдер и такую-то текстуру, а пересечения с другим объектом — другой шейдер и другую текстуру. Это позволяет приложению использовать нужный шейдерный код с правильными текстурами для материалов, в которые попали лучи.

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

Почему бы для трассировки лучей не применять уже известные нам по DirectX вычислительные шейдеры? Во-первых, DXR позволяет запускать отдельные шейдеры при попадании (hit) и промахе (miss) лучей, во-вторых — процесс рендеринга может быть ускорен на графических процессорах (при помощи Nvidia RTX или аналогов у конкурентов), и в-третьих, новый API позволяет привязывать (binding) ресурсы при помощи шейдерных таблиц.

Nvidia RTX — это набор программных и аппаратных алгоритмов, ускоряющих трассировку на решениях компании Nvidia, основанных на графической архитектуре Volta . Почему не поддерживаются предыдущие архитектуры, которые не так уж сильно отличаются от Volta? Возможно, частично это маркетинговый ход, чтобы привлечь покупателей к новым продуктам, а возможно — в Volta есть какие-то аппаратные оптимизации, позволяющие серьезно ускорить трассировку лучей на GPU, о которых нам еще не рассказали. Да, в пока что единственном графическом процессоре с этой архитектурой есть тензорные ядра, ускоряющие задачи искусственного интеллекта, но он если и может применяться при рендеринге с трассировкой лучей, то лишь в процессе шумоподавления, да и то — по имеющимся данным, в существующих алгоритмах шумодавов такие возможности пока что не применяются.

В преимуществах DXR и RTX — мощная и гибкая программная модель, схожая с Nvidia OptiX, позволяющая относительно просто написать эффективные алгоритмы, использующие трассировку лучей. Для начала разработки приложений с использованием трассировки лучей DXR, аппаратно ускоренных при помощи RTX, вам потребуется видеокарта на основе архитектуры Volta (пока это только Titan V ) и драйвер версии 396 или выше, а также операционная система Windows 10 RS4 и пакет для разработчиков Microsoft DXR, содержащий все необходимое. Также для отладки будет полезен Microsoft PIX или NSight Graphics компании Nvidia, которые уже имеют поддержку DXR API.

Для удобства разработки и отладки, Microsoft сразу же выпустила новую версию утилиты PIX for Windows с поддержкой возможностей DXR. Этот инструмент позволяет захватывать и анализировать кадры, построенные при помощи DXR для того, чтобы разработчики понимали, как именно DXR работает с аппаратным обеспечением, отловили все ошибки и оптимизировали свой код. С помощью PIX программисты могут исследовать вызовы API, просматривать состояние объектов и ресурсы, связанные с работой трассировки, а также структуры ускорения. Все это сильно помогает при разработке DXR-приложений.

В итоге, DirectX Raytracing API дополняет возможности разработчиков специализированными шейдерами и структурами, удобными для трассировки лучей, возможностью одновременной работы с остальной частью традиционного графического конвейера и вычислительными шейдерами и т. д. Концептуально это мало отличается от того, что предлагала Imagination Tech еще несколько лет назад в OpenRL и своих аппаратных решениях. Увы, но ImgTec слишком сильно опередила время со своими чипами PowerVR Wizard, но нужно иметь достаточно средств не только на начальные разработки, но и продвижение своего детища. DXR же — это API такой большой и общепризнанной компании, как Microsoft, и оба производителя игровых GPU (Nvidia и AMD, а может, к ним вскоре добавится и Intel, кто знает) уже работают совместно с Microsoft над оптимизацией нового API для их аппаратных архитектур.

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

К слову, использованию DXR API есть и альтернатива — сотрудники компании Nvidia работают над расширением мультиплатформенного Vulkan API , предназначенным для трассировки лучей — VK_NV_raytracing . Команда разработчиков сотрудничает с коллегами из Khronos для создания мультиплатформенного открытого стандарта, и одной из главных задач является попытка сделать так, чтобы трассировка лучей в DirectX и Vulkan работала максимально похоже.

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

На данный момент полноценная аппаратная поддержка DirectX Raytracing есть только у решений Nvidia семейства Volta (при помощи технологии RTX), то есть на сегодня исключительно у дорогущего Titan V, а на предыдущих GPU этой компании, равно как и на графических процессорах AMD, трассировка лучей полностью выполняется при помощи вычислительных шейдеров — то есть доступна лишь базовая поддержка DXR с меньшей производительностью. Впрочем, в AMD уже заявили, что они работают совместно с Microsoft по внедрению аппаратного ускорения трассировки и скоро представят драйвер для его поддержки, хотя пока что складывается впечатление, что существующие архитектуры AMD вряд ли смогут предоставить высокий уровень ускорения аналогично Nvidia Volta. Технология аппаратного ускорения трассировки лучей RTX включает использование еще не анонсированных аппаратных возможностей архитектуры Volta по ускорению трассировки лучей, и игровые решения с ее поддержкой ожидаются ближе к осени этого года.

Если говорить о еще более дальнем будущем, то появление API для ускорения растеризации идет несколько вразрез с общей универсализацией графических процессоров, которые становятся все более похожими на обычные процессоры, предназначенные для вычислений любых типов. Долгие годы идут разговоры о том, чтобы вообще убрать из GPU все блоки, выполняющие фиксированные функции, хотя это пока что не очень хорошо получалось (можно вспомнить не самый удачный Intel Larrabee ). Но в целом более высокая программируемость графических процессоров сделает возможности смешивания растеризации и трассировки еще более простой, да и для полной трассировки никаких API для поддержки аппаратного ускорения может уже не потребоваться. Но это взгляд уж слишком далеко вперед, пока что мы разбираемся с DXR.

DirectX Raytracing и поддержка этого расширения API разработчиками программного и аппаратного обеспечения дают практическую возможность применения трассировки лучей в сочетании с привычным «растеризационным» API. Зачем это нужно, ведь современные GPU и так способны выполнять почти любые вычисления при помощи вычислительных шейдеров и разработчики могут выполнять трассировку лучей с их помощью? Все дело в стандартизации возможностей аппаратного ускорения трассировки на специализированных блоках в составе GPU, которой не будет в случае использования не предназначенных для этого универсальных вычислительных шейдеров. Некоторые новые аппаратные возможности современных графических архитектур позволяют ускорить трассировку лучей и эта функциональность не может быть раскрыта при помощи существующего DirectX 12 API.

Microsoft остается верной себе — как и растеризационная часть DirectX, новый API не определяет то, как именно аппаратное обеспечение должно работать, а позволяет разработчикам GPU ускорять лишь определенные Microsoft стандартизированные возможности. Разработчики же аппаратного обеспечения вольны делать поддержку выполнения команд DXR API так, как им угодно, Microsoft не указывает им как именно должны это делать графические процессоры. Microsoft представляет DXR как вычислительную задачу, которую можно запускать параллельно с «растеризационной» частью, также DXR привносит несколько новых типов шейдеров для обработки лучей, а также оптимизированную структуру для 3D-сцены, удобную для трассировки лучей.

Так как новый API предназначен для разработчиков ПО, Microsoft предоставляет им базовый уровень поддержки трассировки лучей в DXR, который может использовать все существующее аппаратное обеспечение, поддерживающее DirectX 12. И первые опыты с DXR можно начинать на существующих GPU, хоть это и не будет достаточно быстро для применения в реальных приложениях. Все аппаратное обеспечение с поддержкой DirectX 12 будет поддерживать и трассировку лучей и какие-то несложные эффекты можно будет делать даже с расчетом на уже имеющуюся базу видеокарт на руках у игроков. Какие-то эффекты с применением DXR мы увидим в играх уже в этом году, ну а в 2019-м уже совершенно точно — хотя бы в качестве ранней демонстрации возможностей новых технологий.

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

Наглядное сравнение растеризации и трассировки

Давайте попробуем посмотреть на конкретных примерах, что может дать трассировка лучей. На самом деле, она используется в играх уже сейчас, но в несколько иных, более примитивных формах. В частности, в алгоритмах с использованием экранного пространства или алгоритме voxel cone tracing при расчете глобального освещения, в том числе в известном алгоритме Voxel Ambient Occlusion (VXAO) компании Nvidia. Но это все же не полноценная трассировка лучей, а скорее хаки с ее использованием в том или ином виде при растеризации, а мы сегодня говорим о полноценной трассировке лучей для всей геометрии сцены.

Современные графические процессоры уже сейчас довольно мощны и способны трассировать лучи света с высокой скоростью при помощи такого ПО, как Arnold (Autodesk), V-Ray (Chaos Group) или Renderman (Pixar) , и многие архитекторы и дизайнеры уже используют аппаратно ускоренную трассировку лучей для быстрого создания фотореалистичных изображений их продукции, что снижает затраты на общий процесс разработки. Вот уже более десятка лет компания Nvidia участвует в разработке аппаратно-ускоренных техник с использованием трассировки лучей в профессиональной сфере, и теперь настал момент для переноса этих возможностей и в игры.

Чтобы помочь игровым разработчикам с внедрением трассировки лучей, Nvidia анонсировала грядущее добавление в GameWorks SDK таких возможностей, как специфические алгоритмы шумоподавления, качественное глобальное затенение, тени от площадных источников света (area lights ) и алгоритм отрисовки качественных отражений.

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

Есть, если дополнительно обработать полученное изображение (а ведь мы хотели уйти от хаков растеризации, но похоже, пока что придется мириться с другими). В частности, выполнение трассировки на производительном решении архитектуры Volta позволяет обеспечить производительность реального времени при обсчете 1-2 сэмплов на пиксель с обязательным применением шумоподавления. Уже существующие алгоритмы шумодавов, которые позволяют значительно улучшить качество изображения после трассировки лучей, и это лишь первые разработки, которые продолжаются.

Требования к алгоритмам шумоподавления в реальном времени довольно высоки, нужно уметь обрабатывать очень шумные входные изображения с экстремально низким количеством лучей на пиксель (вплоть от 1 сэмпла), обеспечивать стабильное качество в движении, используя информацию из предыдущих кадров и исполняться крайне быстро, не тратя больше 1 мс времени GPU. Существующие алгоритмы Nvidia позволяют добиться очень неплохих результатов при визуализации отражений, мягких теней и глобального затенения. Для каждого эффекта используются специфические алгоритмы, также использующие информацию о 3D-сцене.

Для рендеринга теней использовалась трассировка лучей с одним сэмплом на пиксель и включенным шумоподавлением

Для расчета глобального затенения (ambient occlusion) использовался обсчет двух лучей на пиксель с шумоподавлением

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

Ray Tracing Denoiser в составе GameWorks SDK — это набор библиотек для использования нескольких техник быстрой трассировки лучей, использующих шумоподавление, весьма важное для трассировки при малом количестве лучей на пиксель, так как результат обычно получается крайне шумный. В состав алгоритмов входит отрисовка мягких теней от площадных источников света и алгоритмы отрисовки отражений и глобального затенения ambient occlusion. Использование шумоподавления позволяет добиться высокой скорости при малом количестве выборок на пиксель, но качество изображения при этом остается отличным — гораздо лучше используемых сейчас техник с имитацией распространения света по сцене и использованием экранного пространства.

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

Тени, полученные при помощи трассировки лучей

Тени, полученные при помощи растеризации и карт теней

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

Для расчета глобального затенения (Ambient Occlusion ) также хотелось бы применять трассировку лучей, так как она обеспечивает значительно более высокое качество, по сравнению со всеми существующими техниками в экранном пространстве (все эти SSAO , HBAO и даже VXAO ). Практически все используемые сейчас алгоритмы просто добавляют темноты по найденным на плоской картинке углам, лишь имитируя распространение света, а применение трассировки позволяет сделать это физически корректным образом.

Глобальное затенение, полученное при помощи трассировки лучей

Глобальное затенение при помощи имитации эффекта с использованием экранного пространства

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

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

Отражения, полученные при помощи трассировки лучей

Отражения, полученные при растеризации с использованием экранного пространства

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

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

Но это лишь начальные версии техник, использующих фильтры шумоподавления, которые будут улучшаться и по качеству, и по производительности. Кроме этого, в будущем возможно применение шумоподавления с использованием технологий искусственного интеллекта, который уже есть в составе Nvidia OptiX 5.0 , но пока что не используется при трассировке при помощи RTX. Вполне вероятно, что в будущем будет использоваться единый шумодав сразу для всех компонент освещения (а не три отдельных, как это делается сейчас) для снижения затрат памяти и производительности. Также ничто не мешает использовать гибридный подход к рендерингу, используя элементы алгоритмов экранного пространства с дополнительной трассировкой лучей.

Кроме применения трассировки лучей в игровых движках реального времени, возможности DXR с аппаратным ускорением на GPU можно использовать и при создании контента. Например, для качественного расчета освещения, которое затем помещается в карты освещения, для создания заранее отрендеренных сцен на игровом движке, но с более высоким качеством и т. д. Более того, можно использовать трассировку лучей вообще не для рендеринга, а в звуковых движках для виртуальной реальности (Nvidia VRWorks Audio ), при физических расчетах или даже в алгоритмах искусственного интеллекта.

Трассировка лучей полезна в процессе создания контента: точной настройке характеристик материалов с качественным и быстрым рендерингом, добавлении и настройке характеристик источников света, отладке алгоритмов шумоподавления и т. п. Также можно сравнительно небольшими силами получить еще более качественный офлайн-рендер, использующий те же структуры и ресурсы, что и движок реального времени. К примеру, это уже сделано в Unreal Engine 4 — сама Nvidia написала экспериментальный Path Tracer сразу после интеграции в движок возможностей DXR, который хоть и не обеспечивает пока что достаточного качества для полноценного офлайн-рендера, но показывает такую возможность.

Мы уж не говорим о возможности быстрой и качественной подготовки карт освещения — «запекания» света в специальные карты освещения (лайтмапы) для статических объектов сцены. Такой движок может использовать один тот же код в игре и редакторе и обеспечивать подготовку различных видов карт освещения (2D, 3D) и кубических карт окружения.

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

Напоследок предлагаем посмотреть все преимущества трассировки лучей в динамике. Nvidia выпустила целую коллекцию технологических демонстраций, показывающих преимущества аппаратно-ускоренной трассировки лучей с применением технологии Nvidia RTX при помощи DXR API (только в виде ролика на Youtube, увы).

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

Демонстрация возможностей трассировки лучей

Чтобы показать возможности DirectX Raytracing API и технологии Nvidia RTX, сразу несколько ведущих разработчиков игровых движков и бенчмарков выпустили к GDC 2018 свои технологические демонстрации, показывающие некоторые возможности новых технологий с применением трассировки лучей: 4A Games, Electronic Arts, Epic Games, Remedy Entertainment, Unity и другие. Увы, пока что они доступны лишь в виде скриншотов, презентаций и роликов на Youtube.

Если ранее подобные демонстрации трассировки лучей в реальном времени показывали или в очень простых сценах с простыми эффектами или при низкой производительности, то возможности будущих GPU способны сделать трассировку лучей реальной даже в игровых условиях с приемлемой производительностью. Разработчики из Epic Games и Remedy Entertainment считают, что возможности DXR и RTX принесут более качественную графику в игры будущего, а внедрение базовой поддержки нового API в их движки оказалась относительно несложным делом.

DirectX Raytracing tech demo (Futuremark)

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

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

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

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

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

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

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

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

Главное, что по словам разработчиков из Futuremark, им было довольно легко внедрить поддержку трассировки лучей в существующий DirectX 12 движок из бенчмарка 3DMark Time Spy , используя модели и текстуры из своих тестов. Вместе с технодемкой, известные разработчики 3D-тестов анонсировали применение возможностей DirectX Raytracing в их следующем бенчмарке 3DMark, который планируется выпустить ближе к концу текущего года.

Reflections Real-Time Ray Tracing Demo (Epic Games)

Компания Epic Games совместно с ILMxLAB и Nvidia также показала свой вариант включения возможностей по трассировке лучей в реальном времени в движок Unreal Engine 4 . Показ состоялся на открытии GDC 2018, где три указанные компании презентовали экспериментальную кинореалистичную демонстрацию на тематику киносериала «Star Wars» с использованием персонажей из серий «The Force Awakens» и «The Last Jedi» .

Демонстрационная программа Epic Games использует модифицированную версию Unreal Engine 4 и технологию Nvidia RTX, возможности которой раскрываются через DirectX Raytracing API. Для построения 3D-сцены разработчики использовали реальные ресурсы из фильмов Star Wars: The Last Jedi с Captain Phasma в блестящих доспехах и двумя штурмовиками со сценой в лифте корабля First Order .

Рассматриваемая технодемка отличается динамически изменяющимся освещением, которое можно регулировать в процессе, а также эффектами, полученными при помощи трассировки лучей, включая качественные мягкие тени и фотореалистичные отражения — все это отрисовывается в реальном времени и с очень высоким качеством. Подобное качество картинки попросту недоступно без использования трассировки лучей, а теперь его может обеспечить и привычный движок Unreal Engine, чем был очень впечатлен основатель и президент компании Epic Games Тим Свини .

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

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

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

При создании этой демки, Epic Games тесно работали с художниками из ILMxLAB и инженерами из Nvidia для показа возможностей технологии Nvidia RTX, работающей через DXR API. Демка на Unreal Engine работает в реальном времени на рабочей станции DGX Station компании Nvidia, включающей аж четыре графических процессора архитектуры Volta. Объединение возможностей движка Unreal Engine, графического API для трассировки лучей DXR и технологии Nvidia RTX, работающей на графических процессорах семейства Volta, позволило приблизиться к кинореализму в реальном времени.

Кроме технологической демонстрации, на GDC специалисты из Epic Games провели большую часовую сессию «Cinematic Lighting in Unreal Engine» , посвященную новым возможностям их движка. А сама демка показана всем желающим с возможностью посмотреть сцену в различных режимах, включая wireframe-рендеринг. Можно предположить, что все это рано или поздно будет доступно в играх, ведь движок Unreal Engine весьма популярен. Epic Games обещала дать доступ к возможностям DXR API уже в этом году — вероятно, ближе к осени, когда выйдут новые GPU Nvidia.

Поддержка DirectX Raytracing и Nvidia RTX открывает для Unreal Engine 4 путь к новому классу техник и алгоритмов, которые не были доступны ранее при засилье растеризации. В скором будущем, разработчики игр смогут использовать гибридный подход с частичным использованием качественной трассировки лучей для некоторых эффектов и высокопроизводительной растеризацией для большей части работы. Это неплохой задел на будущее, ведь возможности GPU, связанные с эффективным ускорением трассировки лучей, будут только расти.

Pica Pica — Real-time Raytracing Experiment (Electronic Arts/SEED)

Очередным разработчиком, заинтересовавшимся трассировкой лучей через DXR, стала студия SEED из Electronic Arts , которая создала специальную демо-программу Pica Pica , применяющую экспериментальный движок Halcyon , использующий гибридный рендеринг, как и предыдущие демонстрационные программы. Также эта демка интересна тем, что в нем был создан процедурный мир без каких-либо предварительных расчетов.

Почему исследователи из SEED решили использовать гибридный рендеринг с трассировкой лучей? Опытным путем они установили, что такой метод способен дать куда более реалистичное изображение, по сравнению с растеризацией, весьма близкое к полноценной трассировке лучей (path tracing), которая сверхтребовательна к ресурсам или дает слишком шумную картинку при малом количестве просчитанных выборок. Все это отлично видно по сравнительным скриншотам:

Полноценная трассировка

Гибридный рендеринг

Растеризация

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

И так как полноценная трассировка пока невозможна, в движке Halcyon применяется гибридный подход. Для расчета отложенного затенения используется растеризация, для расчета прямых теней можно использовать или растеризацию или трассировку лучей при необходимости, для прямого освещения используются вычислительные шейдеры, для отражений также можно использовать как традиционный подход, так и трассировку, для глобального освещения всегда используется трассировка, а для имитации глобального затенения (ambient occlusion) можно или положиться на обычные экранные методы типа SSAO или также включить трассировку лучей. Для рендеринга прозрачных объектов используется только трассировка, а для постобработки — вычислительные шейдеры.

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

Трассировка лучей при расчете отражений происходит в половинном разрешении, то есть используется 0,25 луча/пиксель для отражений и 0,25 луча/пиксель для расчета теней. И тут проявляется проблема малого количества просчитанных лучей в виде крайне шумной картинки с отражениями, когда без специальной дополнительной обработки результат трассировки лучей выглядит слишком грубо:

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

Но может быть привычные методы в экранном пространстве дадут не худший результат и «дорогая» нам трассировка просто не нужна? Посмотрите сами на наглядное сравнение: слева показаны отражения в экранном пространстве, посередине — гибридная трассировка лучей, а справа — референсный рендер с полной трассировкой лучей:

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

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

Глобальное освещение выключено

Глобальное освещение включено

Глобальное освещение значительно влияет на некоторые объекты в сцене, добавляя реалистичности их освещению. В демке можно дополнительно использовать также и техники имитации глобального затенения, придающие дополнительные тени. Поддерживаются в том числе и алгоритмы в экранном пространстве — Screen Space Ambient Occlusion (SSAO):

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

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

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

Жесткие тени, мягкие нефильтрованные и мягкие фильтрованные тени

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

На данный момент в демо-программе Pica Pica вычисляется лишь 2,25 лучей на каждый пиксель (всего, включая все эффекты), и в результате получается фотореалистичная картинка с качеством, близким к полноценной трассировке, хоть и с некоторыми ограничениями. А теперь — ложка дегтя: как и в случае демки Epic Games, для ускорения процесса рендеринга пока что приходится использовать возможности сразу нескольких топовых GPU одновременно и с передачей минимального объема данных по относительно медленной шине PCI Express. Но дальнейшее развитие аппаратного ускорения на графических процессорах должно помочь избавить нас от подобных системных требований в будущем.

Experiments with DirectX Raytracing in Northlight (Remedy Entertainment)

Очередной демонстрационной программой для продвижения DXR и RTX, представленной на GDC 2018, стали эксперименты с игровым движком Northlight Engine финской компании Remedy Entertainment , известной публике по таким играм, как Max Payne, Alan Wake и Quantum Break . Движок Northlight Engine интенсивно разрабатывается компанией, известной своим интересом к последним графическим технологиям. Поэтому немудрено, что они заинтересовались и аппаратно-ускоренной трассировкой лучей.

На GDC компания показала разработки, над которыми они работали с Nvidia и Microsoft. В числе нескольких разработчиков, Remedy получила ранний доступ к возможностям Nvidia RTX и DXR API, которые воплотились в специальной версии движка Northlight. Главный графический программист компании Tatu Aalto представил на конференции выступление «Experiments with DirectX Raytracing in Remedy’s Northlight Engine» , в котором рассказал об особенностях принятого ими гибридного подхода.

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

Для проведения опытов по внедрению трассировки лучей, в Remedy создали новую сцену, никак не связанную с играми компании. Как мы уже говорили, DXR API поддерживает два уровня структур ускорения: нижний и верхний. Идея заключается в том, что структура нижнего уровня предназначена для хранения геометрии, а верхний уровень содержит структуры нижнего уровня. То есть каждая полигональная сетка — это одна структура нижнего уровня, а каждый верхний уровень содержит несколько структур нижнего уровня с возможными геометрическими преобразованиями (повороты и т. п.).

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

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

Для начала возьмем ambient occlusion — основанный на определении видимости алгоритм, который можно легко выполнить с применением трассировки лучей. Следующее изображение получено при помощи просчета четырех лучей на пиксель, максимальная длина которых установлена на четыре метра, и результат точно выглядит лучше, чем при методе SSAO, использующем лишь экранное пространство.

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

Увы, производительность трассировки лучей относительно низка и она обходится гораздо «дороже» методов в экранном пространстве. По данным Remedy, в их демо-программе просчет одного луча на пиксель для глобального затенения с максимальной длиной в 4 метра при разрешении Full HD занимает примерно 5 мс и производительность масштабируется почти линейно, так что просчет 16 лучей будет занимать уже под 80 мс. При постоянном улучшении качества, конечно:

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

Кроме глобального затенения, в демке Remedy трассировка лучей используется и для рендеринга обычных теней, которые при растеризации сейчас чаще всего используют каскадные карты теней (cascaded shadow maps — CSM ). Разработчики отмечают, что если движок заполняет тени от направленных источников освещения до просчета освещения, то очень легко будет заменить шейдер каскадных карт теней кодом с применением трассировки, которая запишет рассчитанные данные в тот же самый буфер.

При этом разница в качестве будет явно в пользу трассировки (показана справа). Изображение с трассировкой лучей использует просчет 8 лучей на пиксель без дополнительной фильтрации, а техника CSM использует 16 Percentage Closer Filtering (PCM) выборок со специальным фильтром, применяемым к буферу. Правда, нужно учитывать то, что разработчики явно не оптимизировали работу CSM в этом случае, ведь можно было отрегулировать разрешение карт теней и их фильтрацию, чтобы получить более качественные тени, а это просто тень при настройках их движка по умолчанию.

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

Что касается производительности, то в этой демо-программе просчет одного луча для разрешения Full HD составляет менее 4 мс, что несколько быстрее, чем для глобального затенения, даже при том, что лучи тут длиннее. Чтобы внедрить трассировку лучей в имеющийся DX12-движок для рендеринга теней, придется потратить несколько дней работы программистов, но результат стоит того, если производительности в итоге будет достаточно.

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

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

В движке Northlight Engine уже используется расчет глобального освещения (GI ) — в частности, в игре Quantum Break, и этот эффект включен в движке по умолчанию. Для расчета GI используются воксели с размером примерно в 25 см, которые комбинируются с результатом работы техники глобального затенения SSAO, использующей экранное пространство. В качестве эксперимента, в Remedy заменили SSAO аналогичным эффектом с использованием трассировки лучей и результат стал лучше.

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

А зачем вообще нужно рассчитывать глобальное освещение/затенение, и можно ли обойтись без этого крайне ресурсоемкого шага? Посмотрите на наглядном примере, как выглядит результат расчета одного только прямого освещения:

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

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

Отражения и затенение в сцене выглядят весьма реалистично, на наш взгляд. В частности, лампа отражает все объекты, в том числе невидимое для основной камеры яркое окно. А кружка справа отражает свою собственную ручку — так невозможно сделать при помощи растеризации без хитрых хаков. Единственной явной проблемой трассировки здесь является сильный пиксельный шум, который в Remedy пока что особо не старались убрать. А ведь тот же алгоритм из Nvidia GameWorks мог бы изрядно помочь, не говоря уже о шумодаве с использованием искусственного интеллекта.

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

Важно, что интеграция поддержки DXR и RTX в движок Northlight прошла довольно быстро и безболезненно. Финские разработчики были поражены тем, как быстро у них получилось сделать прототипы улучшенного освещения, затенения и отражений при помощи трассировки лучей — все это с куда лучшим качеством, по сравнению с привычными хаками растеризации. Хотя на данный момент показанные технологии находятся на стадии ранней разработки и далеки от того, чтобы быть включенными в игры прямо сейчас, это отличное начало для их будущего внедрения.

Real-Time Ray Tracing in Metro Exodus (4A Games)

Вполне вероятно, что в ближайшие годы мы увидим не одну игру, использующую гибридный рендеринг с трассировкой лучей для отрисовки части эффектов. В частности, первой (ну или одной из первых, как минимум) должна стать игра Metro Exodus , в которой трассировка лучей через DXR с применением технологии Nvidia RTX будет использоваться для расчета глобального освещения и затенения.

Предполагается, что такой метод расчета GI будет доступен в игре в виде альтернативы более привычным алгоритмам SSAO и IBL (image based lighting, освещение на основе текстуры окружения). Конечно, пока что это крайне ограниченное использование трассировки, но качество глобального освещения/затенения с трассировкой лучей гораздо выше, чем даже у VXAO , не говоря уже о SSAO . Вот наглядное видеосравнение методов экранного пространства с трассировкой, снятое нашими немецкими коллегами с экрана выставочной системы (поэтому заранее извиняемся за качество):

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

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

Выводы

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

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

Естественно, что первые попытки использования трассировки будут гибридными и серьезно ограниченными по количеству и качеству эффектов, а полноценной трассировки придется ждать еще не один десяток лет. Во всех показанных демо-программах используется 1-2 луча на пиксель, а то и менее, в то время как в профессиональных приложениях их сотни! И чтобы получить качество офлайновых рендеров в реальном времени, нужно еще очень долго ждать. Но уже сейчас настало время для начала разработок по внедрению трассировки в существующие движки, и кто будет первым в освоении возможностей DXR, тот может получить определенное преимущество в будущем. Кроме того, трассировка лучей способна облегчить разработку виртуальных миров, так как она избавит от множества мелких задач по ручной доработке теней, лайтмапов и отражений, чем приходится заниматься при неидеальных алгоритмах растеризации. Уже сейчас аппаратно-ускоренную трассировку можно использовать в самом процессе разработки — для ускорения таких вещей, как предварительный просчет лайтмапов, отражений и статических карт теней.

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

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

А ведь с физически корректными глобальным освещением, затенением и отражениями, рассчитанными при помощи трассировки лучей, отрисованная картинка становится реалистичнее даже без наличия эффектных зеркал и других явно отражающих поверхностей. В современных играх почти всегда используют физически корректный рендеринг, в котором материалы имеют свойства шероховатости и отражающих способностей, а также и кубические карты среды, поэтому отражения всегда в наличии, даже если их не видно невооруженным взглядом. В такой игре можно довольно быстро заменить кубические карты среды трассировкой, предложив такую возможность обладателям высокопроизводительных систем. Тени с трассировкой также выглядят лучше и позволяют решить принципиальные проблемы карт теней, хотя некоторые из них и решены в хитрых продвинутых алгоритмах, вроде Nvidia Hybrid Frustum Traced Shadows (HFTS) , также использующих трассировку в определенном виде, но все равно лучше всего будет унифицированный подход. А отрисовка очень мягких теней от площадных источников света способна дать идеальные сверхреалистичные тени в большинстве случаев.

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

Пока что в следующие пару лет мы получим возможность включения одной-двух новых техник, использующих трассировку лучей в дополнение к растеризации или на замену лишь части ее работы. Так делается всегда в начале жизненного пути новых технологий, когда есть возможность отключить новые алгоритмы, слишком тяжелые для среднего игрового ПК. Но если ориентироваться только на них, то никакого прогресса просто не будет. А поддержка аппаратной трассировки со стороны Nvidia важна тем, что они умеют помогать разработчикам внедрять новые технологии. И есть уверенность в том, что Metro Exodus — далеко не единственная игра, в которой Nvidia продвигает трассировку, ведь они сотрудничают с игровыми разработчиками сразу по нескольким проектам. Небезызвестный Тим Свини из Epic Games спрогнозировал, что года через два года GPU обретут достаточную производительность уже для массового использования трассировки лучей в играх и в это можно поверить.

Самые близкие к Microsoft разработчики начали изучение возможностей DXR почти год назад и это лишь начало пути нового API. Тем более, что сейчас на рынке просто еще нет доступных графических решений с поддержкой аппаратного ускорения трассировки. Анонс DXR предназначен для того, чтобы разработчики аппаратного и программного обеспечения начали работу по изучению и оптимизации трассировки лучей и начали раннюю стадию внедрения новых технологий в игры. Заинтересованные разработчики уже начали опыты с DXR и современными GPU, и такие компании, как Epic Games, Futuremark, DICE, Unity и Electronic Arts, даже анонсировали планы по использованию возможностей DXR в будущих версиях игровых движков и игр.

Вполне вероятно, что энтузиастам придется подождать (такова наша доля) появления доступных GPU с аппаратным ускорением, чтобы увидеть даже самые первые эффекты с применением трассировки лучей, так как базовый уровень поддержки через вычислительные шейдеры может оказаться слишком медленным даже для простых алгоритмов. Игры с толковым применением DXR потребуют аппаратной поддержки трассировки, которая будет поначалу только у Nvidia Volta, но грозит активно улучшаться со временем. Возможно также и появление сравнительно простых игр со стилизованной графикой, которые будут использовать исключительно трассировку лучей.

Еще один важный момент заключается в том, что текущее поколение игровых консолей не имеет поддержки аппаратного ускорения трассировки лучей, компания Microsoft ничего не сказала по поводу DXR в Xbox One. Скорее всего, такой поддержки просто не будет, что может стать еще одним тормозом для активного использования возможностей трассировки лучей в играх. Хотя Xbox One имеет почти полноценную поддержку DirectX 12, никаких аппаратных блоков для ускорения трассировки в нем нет, поэтому есть немалая вероятность того, что как минимум до следующего поколения консолей дело ограничится парой-тройкой эффектов с трассировкой лучей в нескольких игровых проектах, поддерживаемых компанией Nvidia, продвигающей свою технологию RTX. Очень хотелось бы ошибиться, ведь энтузиасты компьютерной графики уже заждались подобных глобальных улучшений в рендеринге реального времени.

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

Рисунок 1. Алгоритм трассировки лучей.

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

// Алгоритм трассировки лучей

//

float3 RayTrace (const Ray & ray )

{

float3 color (0,0,0);

Hit hit = RaySceneIntersection (ray );

if (!hit .exist )

return color ;

float3 hit_point = ray .pos + ray .dir *hit .t ;

for (int i =0;i

if (Visible (hit_point , lights ))

color += Shade (hit , lights );

if (hit .material .reflection > 0)

{

Ray reflRay = reflect (ray , hit );

color += hit .material .reflection*RayTrace (reflRay );

}

if (hit .material .refraction > 0)

{

Ray refrRay = refract (ray , hit );

color += hit .material .refraction *RayTrace (refrRay );

}

return color ;

}

Листинг 1. Алгоритм обратной трассировки лучей.

Поясним фрагмент программы (листинг 1). Луч представлен двумя векторами. Первый вектор – pos – точка испускание луча. Второй – dir – нормализованное направление луча. Цвет – вектор из трех чисел – синий, красный, зеленый. В самом начале функции RayTrace мы считаем пересечение луча со сценой (представленной просто списком объектов пока что) и сохраняем некоторую информацию о пересечении в переменной hit и расстояние до пересечения в переменной hit.t. Далее, если луч промахнулся и пересечения нет, нужно вернуть фоновый цвет (в нашем случае черный). Если пересечение найдено, мы вычисляем точку пересечения hit_point, используя уравнение луча (эквивалентное уравнению прямой с условием t>0). Когда мы вычислили точку пересечения в мировых координатах, приступаем к расчету теней. Пусть источники лежат в массиве lights. Тогда проходим в цикле по всему массиву и для каждого источника света проверяем (той же трассировкой луча), виден ли источник света из данной точки hit_point. Если виден, прибавляем освещение от данного источника, вычисленное по некоторой локальной модели (например модели Фонга). После, если у материала объекта, о который ударился луч, есть отражающие или преломляющие свойства, трассируем лучи рекурсивно, умножаем полученный цвет на соответствующий коэффициент отражения или преломления и прибавляем к результирующему цвету. Коэффициенты reflection и refraction могут быть как монохромными так и цветными. Всё зависит от того, какая используется математическая модель для представления материалов.

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

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

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

Рисунок 2. Изображение, полученное с помощью трассировки лучей.

Даже при разрешении картинки 1024x768 количество первичных лучей равно 786432 - то есть приближается к миллиону. Каждый из этих лучей может уйти глубоко в рекурсию, увеличивая количество трассируемых лучей в несколько раз. Объем вычислений, которые надо при этом производить - громадный и обычно трассировка лучей работает довольно медленно. Причем, львиная доля процессорного времени затрачивается на поиск пересечений. Поэтому вопрос производительности здесь стоит на первом месте. Существуют классы алгоритмов, позволяющих на порядки ускорить поиск пересечений. Соотношение качество/скорость является основным критерием при выборе тех или иных алгоритмов, но эффективные алгоритмы в любом случае стараются использовать когерентность лучей в том или ином виде. Подробнее о них см. в разделе "Быстрая трассировка лучей".

Методы трассировки лучей (Ray Tracing ) на сегодняшний день считаются наиболее мо­щными и универсальными методами создания реалистичных изображений. Известно много примеров реализации алгоритмов трассировки для качественного отображения самых слож­ных трехмерных сцен. Можно отметить, что универсальность методов трассировки взначительной мере обусловлена тем, что в их основе лежат простые и ясные понятия, кото­рые отражают наш опыт восприятия окружающего мира.

Рис. 8.12. Модели отражения: а – идеальное зеркало, б - неидеальное зеркало, в – диффузное, г – сумма диффузного и зеркального, д – обратное, е - сумма диффузного, зеркального и лбратного

Как мы видим окружающую реальность? Во-первых, нужно определиться с тем, что мы вообще способны видеть. Это изучается в специальных дисциплинах, а до некоторой степе­ни, это вопрос философский. Но здесь мы будем считать, что окружающие объекты обла­дают такими свойствами относительно света:

излучают;

отражают и поглощают;

пропускают сквозь себя.

Рис. 8.13. Излучение – а – раномерно во все тороны, б - направленно

Каждое из этих свойств можно описать некоторым набором характеристик. Например, излучение можно охарактеризовать интенсивностью, направленностью, спектром. Излуче­ние может исходить от условно точечного источника (далекая звезда) или от источника рас­сеянного света (скажем, от расплавленной лавы, извергающейся из кратера вулкана). Рас­пространение излучения может осуществляться вдоль довольно узкого луча (сфокусиро­ванный луч лазера) или конусом (прожектор), или равномерно во все стороны (Солнце), или еще как-то. Свойство отражения (поглощение) можно описать характеристиками диффуз­ного рассеивания и зеркального отражения. Прозрачность можно описать ослаблением ин­тенсивности и преломлением.

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

В предшествующих параграфах мы с вами уже ознакомились с видами отражения, которые упоминаются наиболее часто - зеркальным и диффузным. Реже в литературе поминается обратное зеркальное или антизеркальное от­ ражение, в котором максимум интенсивности отражения соответствует направлению на источник. Обратное зеркальное отражение имеют некоторые виды растительности на по­верхности Земли, наблюдаемые с высоты рисовые поля.

Два крайних, идеализированных случая пре­ломления изображены на рис. 8.13.

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

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

Рис. 8.14. Преломление а – идеальное, б - дифузное

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

Теперь рассмотрим то, как формируется изображение некоторой сцены, которая содер­жит несколько пространственных объектов. Будем считать, что из точек поверхности (объ­ема) излучаемых объектов выходят лучи света. Можно назвать такие лучи первичными -они освещают все другое.

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

От источников излучения исходит по разным направлениям бесчисленное множество первич­ных лучей (даже луч лазера невозможно идеально сфокусировать - все равно свет будет распро­страняться не одной идеально тонкой линией, а конусом, пучком лучей). Некоторые лучи уходят в свободное пространство, а некоторые (их также бесчисленное множество) попадают на другие объекты. Если луч попадет в прозрачный объект, то, преломляясь, он идет дальше, при этом неко­торая часть световой энергии поглощается. Подобно этому, если на пути луча встречается зеркально отражающая поверхность, то он также изменяет направление, а часть световой энергиипоглощается. Если объект зеркальный и одновременно прозрачный (например, обычное стекло), то будут уже два луча - в этом случае говорят, что луч расщепляется.

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

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

Рис. 8.15. Схема обратной трассировки лучей

Непосредственная реализация данной лучевой модели формирования изображения представляется затруднительной. Можно попробовать разработать алгоритм построения изображения указанным способом. В таком алгоритме необходимо предусмотреть перебор всех первичных лучей и определить, какие из них попадают в объекты и в камеру. Потом выполнить перебор всех вторичных лучей, и также учесть только те, которые попадают в объекты и в камеру. И так далее. Можно назвать такой метод прямой трассировкой лучей. Практическая ценность такого метода вызовет сомнение. В самом деле, как учитывать бес­конечное множество лучей, идущих во все стороны? Очевидно, что полный перебор беско­нечного числа лучей в принципе невозможен. Даже если каким-то образом свести это к ко­нечному числу операций (например, разделить всю сферу направлений на угловые секторы и оперировать уже не бесконечно тонкими линиями, а секторами), все равно остается глав­ный недостаток метода - много лишних операций, связанных с расчетом лучей, которые потом не используются. Так, во всяком случае, это представляется в настоящее время.

Метод обратной трассировки лучей позволяет значительно сократить перебор свето­вых лучей. Метод разработан в 80-х годах, основополагающими считаются работы Уитте-да и Кэя . Согласно этому методу отслеживание лучей осуществляется не от источ­ников света, а в обратном"направлении - от точки наблюдения. Так учитываются только те лучи, которые вносят вклад в формирование изображения.

Рассмотрим, как можно получить растровое изображение некоторой трехмерной сцены методом обратной трассировки. Предположим, что плоскость проецирования разбита на множество квадратиков - пикселов. Выберем центральную проекцию с центром схода на некотором расстоянии от плоскости проецирования. Проведем прямую линию из центра схода через середину квадратика (пиксела) плоскости проецирования (рис. 8.15). Это будетпервичный луч обратной трассировки. Если прямая линия этого луча попадает в один или несколько объектов сцены, то выбираем ближайшую точку пересечения. Для определения цвета пиксела изображения нужно учитывать свойства объекта, а также то, какое световое излучение приходится на соответствующую точку объекта.

Рис. 8.16. Обратная трассировка для объектов, имеющих свойства зеркального отражения и преломления

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

Для идеального зеркала дос­таточно потом проследить лишь очередную точку пересечения вторичного луча с некоторым объектом. Что означает термин "идеальное зеркало"? Будем считать, что такое зеркало имеет идеально равную отполированную поверхность, поэтому одному отраженному лучу соответствует только один падающий луч. Зеркало может быть затемненным, то есть поглощать часть световой энергии, но все равно выполняется правило: один луч падает - один отражается. Можно рассматривать также "неидеальное зеркало".Это будет означать, что поверхность неровная. Направлению отраженного луча будут соот­ветствовать несколько падающих лучей (или наоборот, один падающий луч порождает не­сколько отраженных лучей), которые образуют некоторый конус, возможно, несимметрич­ный, с осью вдоль линии падающего луча идеального зеркала. Конус соответствует некото­рому закону распределения интенсивностей, простейший из которых описывается моделью Фонга - косинус угла, возведенный в некоторую степень. Неидеальное зеркало резко ус­ложняет трассировку - нужно проследить не один, а множество падающих лучей, учиты­вать взнос излучения от других видимых из данной точки объектов.

Если объект прозрачный, то необходимо построить новый луч, такой, который при пре­ломлении давал бы предшествующий трассируемый луч. Здесь также можно воспользо­ваться обратимостью, которая справедлива и для преломления. Для расчета вектора иско­мого луча можно применить рассмотренные выше формулы для вектора луча преломления,считая, что преломление происходит в обратном направлении (рис. 8.16).

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

Если выясняется, что текущий луч обратной трассировки не пересекает любой объект, а направляется в свободное пространство, то на этом трассировка для этого луча заканчива­ется.

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

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

1. Среди всех типов объектов выделяются некоторые, которые назовем источниками све­та. Источники света могут только излучать свет, но не могут его отражать или прелом­лять (будем рассматривать толькоточечные источники света).

2. Свойства отражающих поверхностей описываются суммой двух компонентов - диф­фузного и зеркального.

3. В свою очередь, зеркальность также описывается двумя составляющими. Первая (reflection ) учитывает отражение от других объектов, которые не являются источниками света. Строится только один зеркально отраженный лучr для дальнейшей трассировки.Вторая составляющая ( Specular ) означает световые блики от источников света. Для этого направляются лучи на все источники света и определяются углы, образованные этими лучами с зеркально отраженным лучом обратной трассировки(r ). При зеркальном отра­жении цвет точки поверхности определяется цветом того, что отражается. В простейшем случае зеркало не имеет собственного цвета поверхности.

4. При диффузном отражении учитываются только лучи от источников света. Лучи от зеркально отражающих поверхностей игнорируются. Если луч, направленный на данный источник света, закрывается другим объектом, значит, данная точка объекта находится в тени. При диффузном отражении цвет освещенной точки поверхности определяется соб­ственным цветом поверхности и цветом источников света.

5. Для прозрачных (1гап5рагеп() объектов обычно не учитывается зависимость коэффици­ента преломления от длины волны. Иногда прозрачность вообще моделируют без пре­ломления, то есть направление преломленного луча I совпадает с направлением падаю­щего луча.

Для учета освещенности объектов светом, который рассеивается другими объектами, вводится фоновая составляющая(ат bient ).

7. Для завершения трассировки вводят некоторое предельное значение освещенности, ко­торое уже не должно вносить взнос в результирующий цвет, или ограничивают количе­ство итераций.

Согласно модели Уиттеда цвет некоторой точки объекта определяется суммарной интенсивностью

I( ) = KaIa( )C( ) + KdId( )C( ) + KsIs( ) + KrIr( ) + KtIt( )

где λ - длина волны,

С (λ) - заданный исходный цвет точки объекта,

К а,K d ,K s ,K r и К t - коэффициенты, учитывающие свойства конкретного объекта через параметры фонового подсвечивания, диффузного рассеивания, зеркальности, отражения и прозрачности,

I a - интенсивность фонового подсвечивания,

I d - интенсивность, учитываемая для диффузного рассеивания,

I s - интенсивность, учитываемая для зеркальности,

I r - интенсивность излучения, приходящего по отраженному лучу,

I t - интенсивность излучения, приходящего по преломленному лучу.

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

I d =

где I i (λ) - интенсивность излученияi - ro источника света, θ i - угол между нормалью к по­верхности объекта и направлением наi - vi источник света.

Для зеркальности:

I d =

где р - показатель степени от единицы до нескольких сотен (согласно модели Фонга),α i -угол между отраженным лучом (обратной трассировки) и направлением на г"-й источник света.

Интенсивности излучений проходящих по отраженному лучу (I r ), а так же по преломленному лучу (I t ) , умножают на коэффициент, учитывающий ослабление интенсивности в зависимости от расстояния, пройденного лучом. Такой коэффициент записывается в виде е -  d где d - пройденное расстояние,  – параметр ослабления, учитывающий свойства среды, в которой распространяется луч.

Для первичного луча необходимо задать направление, которое соответствует избранной проекции. Если проекция центральная, то первичные лучи расходятся из общей точки, для параллельной проекции первичные лучи - параллельные. Луч можно задать, например, ко­ординатами начальной и конечной точек отрезка, координатой начальной точки и направле­нием, или еще как-нибудь.Задание первичного луча однозначно определяет проекцию изображаемой сцены . При обратной трассировке лучей любые преобразования координат вообще не обязательны. Проекция получается автоматически - в том числе, нетолько плоская, но и, например, цилиндрическая или сферическая. Это одно из проявлений универсальности метода трассировки.

В ходе трассировки лучей необходимо определять точки пересечения прямой линии лу­ча с объектами. Способ определения точки пересечения зависит от того, кокой это объект, и каким образом он представлен в определенной графической системе. Так, например, для объектов, представленных в виде многогранников и полигональных сеток, можно использо­вать известные методы определения точки пересечения прямой и плоскости, рассмотренные в аналитической геометрии. Однако, если ставится задача определения пересечения лу­ча с гранью, то необходимо еще, чтобы найденная точка пересечения лежала внутри конту­ра грани.

Известно несколько способов проверки произвольной точки на принадлежность полиго­ну. Рассмотрим две разновидности, в сущности, одного и того же метода (рис. 8.17).

Первый способ. Находятся все точки пересечения контура горизонталью, которая соответствует координатеYзаданной точки. Точки пересечения сортируются по возрастанию значений координат Х. Пары точек пересечения образуют отрезки. Если точка, которая проверяется, принадлежит одному из отрезков (для этого сравниваются координаты Х заданной точки и концов отрезков), то она – внутренняя.

Рис. 8.17. Точка – внутренняя, если: а - точка принадлежит секущему отрезку, б – число пересечений нечетное

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

Если луч пересекает несколько объектов, то выбирается ближайшая точка по направлению текущего луча.

Сделаем общие выводы о относительно метода обратной трассировки лучей.

Положительные черты

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

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

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

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

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

Недостатки

1. Проблемы с моделированием диффузного отражения и преломления

2. Для каждой точки изображения необходимо выполнять много вычислительных операций. Трассировка лучей принадлежит к числу самых медленных алгоритмов синтеза изображений.

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

Рассмотрим, как формируется изображение. Изображение получается из-за того, что свет попадает в камеру. Выпустим из источников света множество лучей. Назовем их первичными лучами. Часть этих лучей улетит в свободное пространство, а часть попадет на объекты. На них лучи могут преломиться, отразится. При этом часть энергии луча поглотится. Преломленные и отраженные лучи образуют множество вторичных лучей. Далее эти лучи опять же преломятся и отразятся и образуют новое поколение лучей. В конечном итоге часть лучей попадет в камеру и сформирует изображение.

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

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

Предположим, что у нас есть камера и экран, находящийся на расстоянии h от нее. Разобьем экран на квадратики. Дальше будем по очереди проводить лучи из камеры в центр каждого квадратика (первичные лучи). Найдем пересечение каждого такого луча с объектами сцены и выберем среди всех пересечений самое близкое к камере. Далее, применив нужную модель освещения, можно получить изображение сцены. Это самый простой метод трассировки лучей. Он позволяет лишь отсечь невидимые грани.

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

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

Таким образом, первичный луч, найдя пересечение с объектом, делится в общем случае на два луча (отраженный и преломленный). Далее эти два луча делятся еще на два и так далее.

Главной процедурой обратной трассировки лучей в моей программе является процедура Ray. Она имеет следующую структуру:

Если поколение луча равно максимальной глубине рекурсии, то возвращаем среднюю яркость по всем составляющим. Если нет, то идем дальше

Определяем ближайший треугольник, с которым пересекается луч.

Если такого треугольника нет, возвращаем цвет фона, если есть, идем дальше.

Если поверхность, с которой было найдено пересечение, отражает, то формируем отраженный луч и вызываем рекурсивно процедуру Ray с поколением луча, увеличенным на 1.

Если поверхность, с которой было найдено пересечение, преломляет, то формируем преломленный луч и вызываем рекурсивно процедуру Ray с поколением луча, увеличенным на 1.

Определяем итоговую освещенность пиксела, учитывая расположение источников, свойства материала, а так же интенсивности отраженного и преломленного луча.

Я уже рассмотрели ряд ограничений метода трассировки, когда говорили о диффузном преломлении и о неровном зеркале. Рассмотрим и некоторые другие.

Освещать сцену могут только специальные объекты - источники света. Они точечные и не могут поглощать, преломлять и отражать свет.

Свойства отражающей поверхности состоят из двух компонент - диффузной и зеркальной.

При диффузном отражении учитываются только лучи от источников света. Если источник освещает точку, через зеркало (зайчиком), то считается, что точка не освещена.

Зеркальность тоже делится на две составляющие.

reflection - учитывает отражение от других объектов (не источников света)

specular - учитывает блики от источников света

В трассировке не учитываются зависимости от длины волны света:

коэффициента преломления

коэффициента поглощения

коэффициента отражения

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

Алгоритм трассировки позволяет рисовать очень качественные тени. Это не потребует большой переделки алгоритма. В него придется кое-что добавить. При расчете освещенности точки необходимо пустить в каждый из источников света "Теневой фронт". "Теневой фронт" - это луч, с помощью которого проверяется, лежит ли что-нибудь между точкой и источником. Если между ними лежит непрозрачный объект, то точка находится в тени. Это значит, что данный источник, не делает свой вклад в итоговую освещенность точки. Если лежит прозрачный объект, то интенсивность источника уменьшается. Прорисовка теней является очень затратной по времени. Так что, в некоторых ситуациях их отключают.

В моей программе есть возможность включить сглаживание изображения. Сглаживание заключается в том, что для определения цвета пиксела. пускается не один луч, а четыре и определяется среднее значение цвета у этих лучей. Если необходимо найти цвет пиксела (i,j), то пускаются 4 луча в точки экранной плоскости с координатами (i-0.25,j-0.25), (i-0.25,j+0.25), (i+0.25,j-0.25), (i+0.25,j+0.25).

Прямая трассировка . В методе прямой трассировки генерируется пучок лучей, выходящих из источника во всевозможных направлениях.

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

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

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

Обратная трассировка. Метод обратной трассировки разработан в 80-х годах. Основополагающими считаются работы Уиттеда и Кея.

Для отсекания лучей, не попавших в приемник, достаточно рассматривать наблюдателя в качестве источника обратных лучей. Первичным лучом будет считаться луч V от наблюдателя к какой-либо точке на поверхности объекта.

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

● луч выходит за пределы сцены,

● луч встречается с непрозрачным телом, поглощающим свет,

● луч попадает в источник света,

● интенсивность луча падает ниже порога чувствительности,

● число расщеплений первичного луча становится слишком большим для имеющихся машинных ресурсов.

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

Метод обратной трассировки фактически аккумулирует все лучи, в действительности приходящие в приемник из определенного направления независимо от их начала. Это позволяет видеть и изображать на экране:

● непрозрачные объекты, поглощающие обратные лучи;

● прозрачные объекты, через которые благодаря преломлению наблюдателю видны другие объекты;

● отражения объектов на зеркальных поверхностях, в том числе и блики, соответствующие попаданию обратных лучей в источник света;

● тени, образующиеся в точках поверхности, заслоненных от источника другими объектами;

● другие разнообразные оптические эффекты.

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

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

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

Ограничения метода обратной трассировки:

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

2. Свойства отражающих поверхностей описываются суммой двух компонентов: диффузного и зеркального.

3. Зеркальность, в свою очередь, также описывается двумя составляющими. Первая (reflection) учитывает отражение от других объектов, не являющихся источниками света. Строится только один зеркально отраженный луч r для дальнейшей трассировки. Вторая компонента (specular) означает световые блики от источников света. Для этого направляются лучи на все источники определяются углы, образуемые этими лучами с зеркально отраженным лучом обратной трассировки (r ). При зеркальном отражении цвет точки поверхности определяется цветом того, что отражается. В простейшем случае зеркало не имеет собственного цвета поверхности.

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

5. Для прозрачных (transparent) объектов обычно не учитывается зависимость коэффициента преломления от длины волны. Иногда прозрачность вообще моделируют без преломления, т.е. направление преломленного луча t совпадает с направлением падающего луча.

6. Для учета освещенности объектов светом, рассеиваемым другими объектами, вводится фоновая составляющая (ambient).

7. Для завершения трассировки вводят некоторое пороговое значение освещенности, которое уже не должно вносить вклад в результирующий цвет, либо ограничивают число итераций.

Положительные черты метода обратной трассировки:

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

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

● все преобразования координат (если таковые есть) линейны, поэтому достаточно просто работать с текстурами;

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

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

Недостатки метода обратной трассировки:

● проблемы с моделированием диффузного отражения и преломления;

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