В алгоритме обратной трассировки лучей. Обратная трассировка лучей. Развитие ускорителей с точки зрения рейтрейсинга

Методы трассировки лучей (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).

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

Что такое Nvidia RTX?

Nvidia RTX - платформа, содержащая ряд полезных инструментов для разработчиков, которые открывают доступ к новому уровню компьютерной графики. Nvidia RTX доступна только для нового поколения видеокарт Nvidia GeForce RTX, построенного на архитектуре Turing. Основная особенность платформы - наличие возможности трассировки лучей в реальном времени (также называемой рейтресингом).

Что за трассировка лучей?

Трассировка лучей - функция, которая позволяет имитировать поведение света, создавая правдоподобное освещение. Сейчас в играх лучи двигаются не в реальном времени, из-за чего картинка, зачастую, хоть и выглядит красиво, но всё равно недостаточно реалистична - используемые сейчас технологии требовали бы огромное количество ресурсов для рейтресинга.

Это исправляет новая серия видеокарт Nvidia GeForce RTX, обладающая достаточной мощностью для расчёта пути лучей.

Как это работает?

RTX проецирует лучи света с точки зрения игрока (камеры) на окружающее пространство и высчитывает таким образом, где какого цвета пиксель должен появиться. Когда лучи натыкаются на что-либо, они могут:

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

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

Это побудило Nvidia внедрить дополнительные ядра в видеокарты GeForce RTX, которые возьмут на себя большую часть нагрузки, улучшая производительность. Они также снабжены искусственным интеллектом, задача которого - высчитывать возможные ошибки во время процесса трассировки, что поможет их избежать заранее. Это, как заявляют разработчики, также повысит скорость работы.

И как трассировка лучей влияет на качество?

Во время презентации видеокарт Nvidia продемонстрировала ряд примеров работы трассировки лучей: в частности, стало известно, что некоторые грядущие игры, включая Shadow of the Tomb Raider и Battlefield 5 будут работать на платформе RTX. Функция эта, тем не менее, будет в игре необязательной, так как для трассировки нужна одна из новых видеокарт. Трейлеры, показанные компанией во время презентации, можно посмотреть ниже:

Shadow of the Tomb Raider , релиз которой состоится 14 сентября этого года:

Battlefield 5 , которая выйдет 19 октября:

Metro Exodus , чей выход намечен на 19 февраля 2019 года:

Control , дата выхода которой пока неизвестна:

Вместе с этим всем, Nvidia , какие ещё игры получат функцию трассировки лучей.

Как включить RTX?

Ввиду технических особенностей данной технологии, рейтресинг будут поддерживать только видеокарты с архитектурой Turing - имеющиеся сейчас устройства не справляются с объёмом работы, который требует трассировка. На данный момент, единственные видеокарты с данной архитектурой - серия Nvidia GeForce RTX, модели которой доступны для предзаказа от 48 000 до 96 000 рублей.

А есть ли аналоги у AMD?

У AMD есть свой собственный вариант технологии трассировки лучей в реальном времени, который присутствует в их движке Radeon ProRender. Компания анонсировала свою разработку ещё на GDC 2018, которая прошла в марте. Основное отличие метода AMD от Nvidia заключается в том, что AMD даёт доступ не только к трассировке, но и к растеризации - технологии, которая применяется сейчас во всех играх. Это позволяет как использовать трассировку, получая более качественное освещение, так и экономить ресурсы в местах, где трассировка будет излишней нагрузкой на видеокарту.

Технология, которая будет работать на API Vulkan, пока находится в разработке.

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

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

Мы не уверены, что все наши читатели знают или помнят, что такое трассировка лучей , чем в принципе отличаются разные методы рендеринга и какие у них существуют достоинства и недостатки. Поэтому для начала попробуем очень кратко, без сложной математики и более-менее понятно рассказать об этом. Перед тем, как перейти к трассировке лучей, нам нужно вспомнить основы классического алгоритма растеризации с 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. ОБРАТНАЯ ТРАССИРОВКА ЛУЧЕЙ

Именно этому методу генерации реалистичных изображений посвящена эта работа.

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

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

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

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

Если объект прозрачный, то необходимо построить новый луч, такой, который при преломлении давал бы предыдущий трассируемый луч.

Для диффузного отражения интенсивность отраженного света, как известно, пропорциональна косинусу угла между вектором луча от источника света и нормалью.

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

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

Ограничения при реализации трассировки

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

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

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

При диффузном отражении учитываются только лучи от источников света. Лучи от зеркально отражающих поверхностей ИГНОРИРУЮТСЯ. Если луч, направленный на данный источник света, закрывается другим объектом, значит, данная точка объекта находится в тени. При диффузном отражении цвет освещенной точки поверхности определяется собственным цветом поверхности и цветом источников света.

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

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

Для завершения трассировки вводится ограничение количества итераций (глубины рекурсии).

Выводы по методу обратной трассировки

Достоинства:

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

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

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

Недостатки:

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

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

2. КОНСТРУКТОРСКАЯ ЧАСТЬ

Алгоритмы.

Обратная трассировка лучей.

Рис. 1 - Блок-схема рекуррентного алгоритма обратной трассировки лучей

трассировка луч программирование язык

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

Алгоритм:

Для расчета цвета каждого пиксела буфера кадра выполняются следующие действия:

Найти координаты пиксела в мировой системе координат.

Найти координаты первичного луча.

Запуск функции вычисления интенсивности первичного луча.

Найти пересечения луча со всеми примитивами сцены и выбрать ближайшее.

Если пересечение не найдено, значит, луч ушел в свободное пространство.

Для расчета цвета принимаем полную интенсивность равной фоновой интенсивности. Перейти на шаг 12. Если пересечение найдено, перейти на шаг 6.

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

Если материал отражает свет только диффузно, то считаем интенсивности отраженного и преломленного света нулевыми. Перейти на шаг 12. Иначе перейти на шаг 8.

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

Вычислить вектор отраженного луча. Запуск рекурсии для нахождения интенсивности отраженного луча.

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

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

Возврат в точку вызова функции вычисления интенсивности луча.

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

Построение теней.

Сплошные тени.

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

Принцип работы алгоритма.

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

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

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

проверяемый источник.

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

Математические и физические предпосылки алгоритма обратной трассировки лучей.

Освещение.

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

Интенсивность фоновой подсветки (IA) задается некоторой константой.

Интенсивность диффузно отраженного света (ID) вычисляется по классическому «закону косинуса».

ID = IL cos α,(2.2.1.6)

где IL - интенсивность источника света, α - угол между нормалью к поверхности и направлением на источник.

В случае освещения сцены несколькими источниками Id вычисляется для каждого из них и затем суммируются.

IDi =Σ ILi cos αi.(2.2.1.7)

Интенсивность блика от источника (IS) вычисляется в соответствии с моделью Фонга.

IS = IL cosp β,(2.2.1.8)

где IL - интенсивность источника света (0<=IL<=1), β - угол между отраженным лучом от источника света и направлением на точку, в которой расположена камера (центр проекции), p - некоторая степень от 1 до 200 -влияет на размытость блика. При

маленьких значениях p блик более размытый.

Как и при вычислении ID в случае освещения сцены несколькими источниками IS вычисляется отдельно для каждого источника, а затем результаты суммируются.

ISi =Σ ILi cosp β i.(2.2.1.9)

Интенсивности зеркально отраженного (IR) и преломленного (IT) света рассчитываются для отраженного и преломленного лучей на следующем шаге рекурсии. Если достигнут предел глубины рекурсии, то эти интенсивности берутся нулевыми. От интенсивности IR берется r процентов, а от IT - t = 1 - r (см. предыдущий раздел).

Кроме того, вводятся следующие коэффициенты: KD - коэффициент диффузного отражения поверхности, KS - коэффициент блика.- этот коэффициент является характеристикой неровности отражающей поверхности. Чем больше неровность поверхности, тем меньше света отражается от неё зеркально и меньше света она пропускает, и соответственно больше света она отражает диффузно. 0 <= KD <= 1.

При KD = 0 - весь свет, падающий на поверхность, отражается и преломляется. KD = 1 - весь свет отражается диффузно. На этот коэффициент умножаются интенсивность диффузно отраженного света и интенсивность фоновой подсветки. Интенсивности зеркально отраженного и преломленного света умножаются на (1 - KD).- этот коэффициент отвечает за яркость блика от источника. 0<=KS<=1.

При KS = 0 - блик не виден, при KS = 1 - яркость блика максимальна.

Таким образом, окончательная формула для расчета интенсивности объекта в какой-либо точке будет выглядеть следующим образом:

I = IAKD + Σ(ILiKDcos αi + ILiKScosp β i) + (1 - KD)(IRr + IT(1 - r)).(2.2.1.10)

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

Для получения цветного изображения необходимо провести расчеты отдельно для красной, зеленой и синей компоненты света. Цвет пиксела изображения будет вычисляться путем умножения каждой компоненты интенсивности на число, определяющее максимальное количество градаций интенсивности изображения. Для 32-битного изображения оно равно 255 на каждый из цветов(R,G,B).

255*IR,= 255*IG,= 255*IB.

Здесь IR (не путать с интенсивностью зеркально отраженного света), IG, IB - интенсивности трех компонент света в точке, полученная по формуле, указанной выше.

Коэффициенты KD, KS, p - это индивидуальные характеристики объекта, отражающие его свойства. Кроме этого имеется еще один коэффициент - абсолютный показатель преломления n. n = c / v, где c - скорость света в вакууме, v - скорость света в среде (внутри объекта). Для абсолютно непрозрачных тел этот коэффициент равен ∞ (т.к. скорость света внутри тела нулевая). В программе для задания абсолютно непрозрачного тела необходимо поставить этот коэффициент >> 1 (порядка 10 000). При этом доля зеркально отраженного света r будет стремиться к единице, а преломленного, соответственно, к нулю.

Вычисление нормалей.

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

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

Вычисление нормали к полигону (треугольнику).

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

XA, YA, ZA, XB, YB, ZB, XC, YC, ZC.

Вычислим координаты двух векторов, например AB и AC:

XB - XA,= XB - XA,

ZAB = XB - XA,(2.2.2.1)= XC - XA,= XC - XA,= XC - XA.

Координаты вектора нормали будут вычисляться по формулам:

YABZAC - YACZAB,= XABZAC - XACZAB,(2.2.2.2)= XABYAC - XACYAB.

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

Вычисление нормали к поверхности второго порядка.

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

Q(x,y,z) = a1x2 + a2y2 + a3z2 + b1yz + b2xz + b3xy + c1x +c2y +c3z + d =0.

Но мы будем использовать другую форму записи. Так уравнение эллипсоида будет выглядеть следующим образом:

(x-x0)2/A2 + (y-y0)2/B2 + (z-z0)2 /C2 = 1,(2.2.2.3)

где x0, y0, z0 - координаты центра эллипсоида, A, B, C - длины полуосей эллипсоида.

Уравнение параболоида:

(x-x0)2/A2 + (y-y0)2/B2 - (z-z0)2 /C2 = 1,(2.2.2.4)

где x0, y0, z0 - координаты центра параболоида, A, B, C - длины полуосей параболоида. Ось параболоида расположена вдоль оси Oz мировой системы координат. Для вычисления координат вектора нормали необходимо вычислить частные производные по x, y, z.

Координаты вектора нормали эллипсоида:

Yn = 2(y-y0)/B2,= 2(z-z0)/С2.

Направление вектора не изменится, если все его координаты разделить на 2:

Xn = (x-x0)/A2,= (y-y0)/B2,(2.2.2.5)

Zn = (z-z0)/С2.

Координаты вектора нормали параболоида вычисляются аналогично:

Xn = (x-x0)/A2,= (y-y0)/B2,(2.2.2.6)

Zn = - (z-z0)/С2.

Нормаль для поверхности второго порядка придется вычислять непосредственно в теле трассировки, так как в разных точках фигуры нормали разные.

Вычисление отраженного луча.

Пусть задан вектор падающего луча S, а также известен вектор нормали N. Требуется найти вектор отраженного луча R.

Рассмотрим единичные векторы R1, S1и N1. Поскольку векторы нормали, падающего луча и отраженного луча находятся в одной плоскости, то можно записать R1 + S1 = N`, где N` - это вектор, соответствующий диагонали ромба и совпадающий по направлению с нормалью. Длина вектора N` равна 2cosθ. Так как вектор N` по направлению совпадает с N1, то

N` = N`2cosθ.

Отсюда найдем единичный вектор отраженного луча:

R1 = N1 2cosθ - S1 = N/|N| 2cosθ - S/|S|.

Найдем cosθ. Это можно сделать, используя скалярное произведение векторов N и S:

Полагая, что искомый вектор отраженного луча будет иметь такую же длину, что и вектор падающего луча, то есть R = |S| R1, получим

N 2NS/|N|2 - S.

Это решение в векторной форме. Запишем координаты вектора:

2xN(xNxS+yNyS+zNzS)/(xN2+yN2+zN2) - xS,= 2yN(xNxS+yNyS+zNzS)/(xN2+yN2+zN2) - yS,(2.2.3.1)= 2zN(xNxS+yNyS+zNzS)/(xN2+yN2+zN2) - zS.

Вычисление преломленного луча.

Пусть даны два единичных вектора: S1 - вектор падающего луча, и N1 - вектор нормали к границе раздела двух сред. Также должны быть известны два коэффициента преломления для данных сред - n1 и n2 (или их отношение).

Требуется найти единичный вектор преломленного луча T1. Для решения выполним некоторые геометрические построения.

Искомый вектор T1 равен сумме двух векторов:

Найдем вначале вектор NT. Он противоположен по направлению вектору нормали, а его длина равна |T1| cos α2 = cos α2 (поскольку T1 - единичный). Таким образом, NT = -N1 cos α2. Необходимо определить cos α2. Запишем закон преломления n1 sin α1 = n2 sin α2 в виде:

sin α2 = n sin α1,

где n = n1 / n2.

Воспользуемся тождеством cos2α + sin2α = 1. Тогда

cos α2 = √ 1 - sin2α2 = √ 1 - n2 sin2α1

cos α2 = √ (1 + n2 (cos2α1 - 1)

Значение cos α1 можно выразить через скалярное произведение единичных векторов S1 и N1, то есть cos α1 = S1N1. Тогда мы можем записать такое выражение для вектора NT:

N1√1+n2((S1N1)2 - 1).

Осталось найти выражение для вектора B. Он располагается на одной прямой с вектором A, причем A = S1 - NS. Учитывая, что NS равен N1 cos α1, то A = S1 - N1 cos α1. Так как cos α1 = S1N1, то A = S1 - N1 (S1N1).

Поскольку длина вектора A равна sin α1, а длина вектора B равна sin α2, то

|B|/|A| = sin α2/ sin α1 = n2/n1 = n,

откуда |B| = n |A|. Учитывая взаимное расположение векторов A и B, получим

NA =n(N1(S1N1) - S1).

Теперь мы можем записать искомое выражение для единичного вектора луча преломления T1:

T1 = nN1 (S1N1) - nS1 - N1√1 + n2 ((S1N1)2 - 1).(2.2.4.1)

Вычисление точки пересечения с примитивами.

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

R = A + Vt,(2.2.5.1)

где R - радиус вектор произвольной точки, принадлежащей лучу, A - радиус- вектор начальной точки луча, V - направляющий вектор луча, t - параметр.

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

Можно записать это уравнение в координатном виде:

x = x1 + at,= y1 + bt,(2.2.5.2)= z1 + ct.

Здесь x1, y1, z1 - координаты начальной точки луча в прямоугольной декартовой мировой системе координат, a,b,c - координаты направляющего вектора луча.

Вычисление точки пересечения луча с поверхностью второго порядка.

Для нахождения точки пересечения луча, заданного уравнениями (2) с поверхностью второго порядка, заданной уравнениями (2.2.2.3) или (2.2.2.4):

(x-x0)2/A2 + (y-y0)2/B2 + (z-z0)2 /C2 = 1 (эллипсоид)

(x-x0)2/A2 + (y-y0)2/B2 - (z-z0)2 /C2 = 1 (параболоид),

нужно подставить в уравнение поверхности второго порядка вместо x, y и z соответствующие уравнения луча. В результате этого после раскрытия всех скобок и приведения подобных мы получим квадратное уравнение относительно параметра t. Если дискриминант квадратного уравнения меньше нуля, то луч и поверхность второго порядка общих точек пересечения не имеют. В противном случае можно будет вычислить два значения параметра t. Дискриминант может быть равен нулю - это соответствует предельному случаю касания луча поверхности, и мы получим два совпадающих значения параметра t.

Для нахождения координат точек пересечения луча и поверхности достаточно подставить найденные значения параметра t в уравнения луча (2).

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

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

Для этого после нахождения точки пересечения анализируется ее z-координата.

Вычисление точки пересечения луча с полигоном (треугольником).

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

Уравнение плоскости выглядит следующим образом:

Q(x, y, z) = Ax + By + Cz +D = 0.(2.2.5.3)

Здесь коэффициенты A, B, C совпадают с координатами нормали к этой плоскости. Координаты нормали плоскости совпадают с координатами нормали треугольника, которые мы посчитали на этапе загрузки сцены.

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

Ax -By - Cz.(2.2.5.4)

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

Теперь для нахождения точки пересечения подставим уравнения луча (2) в

уравнение плоскости.

(x1 + at) + B (y1 + bt) + C (z1 + ct) + D = 0

Откуда получим

= - (Ax1 + By1 + Cz1 + D) / (Aa + Bb + Cc)(2.2.5.5)

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

Для нахождения координат точки пересечения надо подставить найденное значение параметра t в уравнения луча (2). Назовем точку пересечения D. Мы получим координаты xD, yD, zD.

Теперь необходимо определить, попала ли точка D внутрь треугольника. Найдем координаты векторов AB, BC, CA (A, B, C - вершины треугольника) и координаты векторов AD, BD, CD. Затем найдем три векторных произведения:

nA = AB x AD,= BC x BD,(2.2.5.6)= CA x CD.

Эти вектора будут коллинеарны. Если все три вектора сонаправлены, то точка D лежит внутри треугольника. Сонаправленность определяется равенству знаков соответствующих координат всех трех векторов.

Операцию проверки принадлежности точки D треугольнику ABC можно ускорить. Если ортогонально спроецировать треугольник ABC и точку D на одну из плоскостей xOy, yOz или xOz, то попадание проекции точки в проекцию треугольника будет означить попадание самой точки в треугольник (конечно же, если уже известно, что точка D лежит в плоскости, содержащей треугольник ABC). При этом число операций заметно сокращается. Так для поиска координат всех векторов нужно искать по две координаты на каждый вектор, а при поиске векторных произведений нужно искать только одну координату (остальные равны нулю).

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

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

Остается добавить, что для проецирования лучше выбирать ту из плоскостей, площадь проекции треугольника на которую больше. При таком условии исключается случай проецирования треугольника в отрезок (при условии, что проверяемый треугольник не вырожден в отрезок). Кроме того, при увеличении площади проекции уменьшается вероятность ошибки. Для определения такой плоскости проецирования достаточно проверить три координаты нормали треугольника. Если z-координата нормали больше (по абсолютному значению) x и y, то проецировать надо на плоскость xOy. Если y больше чем x и z, то проецируем на xOz. В оставшемся случае - на yOz.

Описание типов данных. Структура программы.

Описание модулей программы

Список модулей:.h-описание структуры TTex.h-описание структур TPlaneTex и TEllipsoidTex.h-описание структур TPoint2d и TPoint3d.h-описание страктуры TRGBColor.h-описание класса TLamp.h-описание класса TCam.h-описание класса TPrimitive.h-описание класса TFrstSurface.h-описание класса TScndSurface.h-описание класса TTriangle.h-описание класса TEllipsoid.h-описание класса TCylinder.h-описание класса THyperboloidVert.h-описание класса THyperboloidHor.h-описание класса TScene.h-описание класса TTracer

Модули реализующие, интерфейс программы:

Options.h-модуль формы «Опции»

ExtraCamOptions.h-модуль формы «Свойства камеры»

MainUnit.h-модуль главной формы программы

Краткое описание структур и классов программы:TPoint3d - структура, описывающая точку в мировой системе координат,TPoint2d - структура, описывающая точку на плоскости (в текстуре) с целочисленными координатами,TRGBColor - структура, описывающая цвет по трем составляющим (RGB),TTex - структура, описывающая текстуру - содержит адрес массива пикселей и его размеры,TPlaneTex - структура, описывающая привязку текстуры к плоскости.

Содержит три точки, к которым привязывается текстура:TLamp - класс, описывающий источник освещения.

Содержит объект TPoint3d coord с координатами источника и три переменные типа float (Ir, Ig, Ib) для хранения интенсивности трех компонент света.TCam - класс, описывающий камеру.

Содержит два угла (a, b), указывающих направление зрения камеры, точку, на которую направлена камера (viewP) и расстояние от камеры до этой точки (r). TPrimitive - абстрактный класс примитива. От него наследуются поверхности первого и второго порядка.TFrstSurface - абстрактный класс поверхности первого порядка. От него наследуется класс треугольника.TScndSurface - абстрактный класс поверхности второго порядка. От него наследуются классы эллипсоида и параболоида.TTriangle - класс треугольника. Содержит три вершины треугольника и его нормаль.TCylinder - класс цилиндра.THyperboloidVert - класс однополостного гиперболоида, лежащего вдоль оси oZ.THyperboloidHor -класс однополостного гиперболоида, лежащего вдоль оси oX.TEllipsoid - класс эллипсоида.TScene - класс сцены. Содержит информацию о всех примитивах, источниках и камере.TTracer - класс, отвечающий за построения изображения. Содержит буфер (buffer) разметом 400x400 пикселей, в котором формируется изображение сцены. Перед генерацией необходимо вызвать функциюпередав ей в качестве параметра указатель на сцену, которую необходимо сгенерировать. Для генерации вызвать функцию render.

Все классы - потомки TPrimitive предоставляют следующие функции:getT(TPoint3d p0, TPoint3d viewDir) - возвращает расстояние от точки начала(p0) луча viewDir до ближайшей точки пересечения с примитивом.

void getTArr(float* arr, int& n, TPoint3d p0, TPoint3d viewDir) - заполняет массив arr расстояниями от точки начала(p0) луча viewDir до ближайшей всех точек пересечения с примитивом.

void getNormal(TPoint3d& n, const TPoint3d& p) - возвращает координаты вектора нормали к примитиву в точке p.

void getColor(TRGBColor& c, const TPoint3d& p) - возвращает цвет примитива точке p (с учетом текстуры).

3. ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

Выбор языка программирования.

При разработке программы был использован язык программирования высокого уровня C++ в составе среды визуального программирования CodeGear RAD Studio for Windows.

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

Кроме того, среда визуального программирования CodeGear RAD Studio for Windows

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

Форма «опции». Вкладка «освещение».

На этой вкладке находятся средства по настройке освещения сцены.

Координаты источника - координаты в мировой системе координат источника света, выбранного в выпадающем списке.

Интенсивность источника - значения трех компонент интенсивности источника света, выбранного в выпадающем списке.

Фоновая интенсивность - значения трех компонент фоновой интенсивности.

Кнопка “+” (рядом с выпадающим списком) - добавление нового источника света.

Кнопка “-” (рядом с выпадающим списком) - удаление источника света, выбранного в выпадающем списке.

Форма «опции». Вкладка «камера».

На этой вкладке находятся средства по настройке опций камеры.

Предосмотр - здесь можно увидеть примерный вид изображения до его генерации.

Навигация - настройки положения камеры.

Дополнительно - при нажатии на эту кнопку появляется форма

Свойства камеры с дополнительными параметрами камеры.

Форма «свойства камеры».

Радиус - расстояние от камеры до точки, на которую она направлена.

Шаг изменения радиуса - приращение радиуса камеры при однократном нажатии кнопки “-” на вкладке “Камера” формы “Опции” (или уменьшение при однократном нажатии кнопки “+”).

Форма «опции». вкладка «материалы».

В данном меню отображаются параметры материала стола, на котором стоит сцена.

Цвет - цвет материала стола.

Коэф. диффузного отражения - коэффициент Kd материала стола (см. раздел 2.2.1).

Текстура - если галочка установлена, то на столе будет отображаться текстура

Выбрать текстуру - выбор файла изображения (*.bmp), который будет использоваться как текстура стола.

Дополнительно - при нажатии на эту кнопку появляется форма Свойства стола с дополнительными параметрами материала стола.

Форма «свойства стола».

Коэффициент блика - коэффициент KS материала стола (см. раздел 2.2.1).

Размытость блика - показатель степени p материала стола.

Повторения текстуры - сколько раз текстура стола будет повторяться вдоль осей OX и OY.

Форма «опции». Вкладка «системные».

На этой вкладке можно настраивать алгоритмы, реализованные в программе.

Глубина рекурсии - этот параметр устанавливает глубину рекурсии в алгоритме трассировки. При бОльших значениях этого параметра качество сгенерированного изображения улучшается.

ВНИМАНИЕ!

Глубина рекурсии СИЛЬНО влияет на скорость генерации изображения. Не рекомендуется ставить значения этого параметра больше 10.

Анитиалиазинг - включение алгоритма сглаживания изображения.

Тип тени - выбор алгоритма построения теней.

4. ИССЛЕДОВАТЕЛЬСКАЯ ЧАСТЬ

Исследования проводились на компьютере со следующей конфигурацией:

CPU - Intel Core 2 Duo T5850- 2048Mb DDR2 - Nvidia GForce 9300M 256Mb- Windows 7

4.1 Зависимость времени генерации от глубины рекурсии

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

4.2 Зависимость времени генерации от количества источников

4.3 Анализ результатов исследований

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Роджерс Д. Алгоритмические основы машинной графики: пер. с англ.- М.: Мир, 1989.- 512 с.

Порев В. Н. Компьютерная графика. - СПб.: БХВ-Петербург, 2002. - 432 с.

Никулин Е.А. Компьютерная геометрия и алгоритмы машинной графики. СПб.: БХВ-Петербург, 2003. - 560 с.

Эйнджел Э. Интерактивная компьютерная графика. - «Вильямс», 2001. - 592 с.: ил. - Парал. Тит. С англ.

Авдеева С.М., Куров А.В. Алгоритмы трехмерной машинной графики: Учебное пособие. - М.: Изд-во МГТУ им. Н.Э. Баумана, 1996. - 60 с.