Использование алгоритма обратной трассировки лучей при построении реалистичного изображения. Что такое Nvidia RTX? А есть ли аналоги у AMD

ВВЕДЕНИЕ

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

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

Окружающие нас объекты обладают по отношению к свету такими свойствами:

излучают;

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

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

Каждое из этих свойств можно описать некоторым набором характеристик.

Излучение можно охарактеризовать интенсивностью и спектром.

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

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

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

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

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

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 Зависимость времени генерации от глубины рекурсии

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

Алгоритм выглядит следующим образом: из виртуального глаза через каждый пиксел изображения испускается луч и находится точка его пересечения с поверхностью сцены (для упрощения изложения мы не рассматриваем объемные эффекты вроде тумана). Лучи, выпущенные из глаза называют первичными. Допустим, первичный луч пересекает некий объект 1 в точке H1 (рис. 1). Рисунок 1. Алгоритм трассировки лучей. Далее необходимо определить для каждого источника освещения, видна ли из него эта точка. Предположим пока, что все источники света точечные. Тогда для каждого точечного источника света, до него испускается теневой луч из точки H1. Это позволяет сказать, освещается ли данная точка конкретным источником. Если теневой луч находит пересечение с другими объектами, расположенными ближе чем источник чвета, значит, точка H1 находится в тени от этого источника и освещать ее не надо. Иначе, считаем освещение по некоторой локальной модели (Фонг, Кук-Торранс и.т.д.). Освещение со всех видимых (из точки H1) источников света складывается. Далее, если материал объекта 1 имеет отражающие свойства, из точки H1 испускается отраженный луч и для него вся процедура трассировки рекурсивно повторяется. Аналогичные действия должны быть выполнены, если материал имеет преломляющие свойства. // Алгоритм трассировки лучей // float3 RayTrace (const Ray & ray ) { float3 color (0,0,0); Hit hit = RaySceneIntersection (ray ); if (!hit .exist ) return color ; float3 hit_point = ray .pos + ray .dir *hit .t ; for (int i =0;i if (Visible (hit_point , lights )) color += Shade (hit , lights ); if (hit .material .reflection > 0) { Ray reflRay = reflect (ray , hit ); color += hit .material .reflection*RayTrace (reflRay ); } if (hit .material .refraction > 0) { Ray refrRay = refract (ray , hit ); color += hit .material .refraction *RayTrace (refrRay ); } return color ; } Листинг 1. Алгоритм обратной трассировки лучей. Поясним фрагмент программы (листинг 1). Луч представлен двумя векторами. Первый вектор – pos – точка испускание луча. Второй – dir – нормализованное направление луча. Цвет – вектор из трех чисел – синий, красный, зеленый. В самом начале функции RayTrace мы считаем пересечение луча со сценой (представленной просто списком объектов пока что) и сохраняем некоторую информацию о пересечении в переменной hit и расстояние до пересечения в переменной hit.t. Далее, если луч промахнулся и пересечения нет, нужно вернуть фоновый цвет (в нашем случае черный). Если пересечение найдено, мы вычисляем точку пересечения hit_point, используя уравнение луча (эквивалентное уравнению прямой с условием t>0). Когда мы вычислили точку пересечения в мировых координатах, приступаем к расчету теней. Пусть источники лежат в массиве lights. Тогда проходим в цикле по всему массиву и для каждого источника света проверяем (той же трассировкой луча), виден ли источник света из данной точки hit_point. Если виден, прибавляем освещение от данного источника, вычисленное по некоторой локальной модели (например модели Фонга). После, если у материала объекта, о который ударился луч, есть отражающие или преломляющие свойства, трассируем лучи рекурсивно, умножаем полученный цвет на соответствующий коэффициент отражения или преломления и прибавляем к результирующему цвету. Коэффициенты reflection и refraction могут быть как монохромными так и цветными. Всё зависит от того, какая используется математическая модель для представления материалов. Иногда теневые лучи бывают цветные. Такие лучи используются, если есть вероятность того, что один объект перекрывается другим прозрачным объектом. В таком случае рассчитывается толщина пути теневого луча внутри прозрачного объекта и тень может приобрести какой-либо оттенок (если объект им обладает). Разумеется, тени, рассчитанные таким образом корректны, только если прозрачный объект, отбрасывающий тень, имеет очень близкий к единице коэффициент преломления (считаем что коэффициент преломления воздуха равен 1). Если это не так, то под прозрачным объектом образуется сложная картина, называемая каустиком. Каустики рассчитываются отдельно с помощью метода фотонных карт . Типичный пример каустика – солнечный зайчик от стакана воды, когда через него просвечивает солнце. Следует отметить, что обратная трассировка лучей в том виде, в котором она здесь описана, не является фотореалистичным методом визуализации. Более того, по сравнению с методом растеризации она позволяет корректно рассчитать лишь четкие отражения, преломления и устранить ступенчатость при большом числе лучей на пиксел (что медленно). Для получения всего спектра видимых эффектов необходимо использовать более сложные алгоритмы, которые, однако, базируются именно на трассировке лучей. Рисунок 2. Изображение, полученное с помощью трассировки лучей. Даже при разрешении картинки 1024x768 количество первичных лучей равно 786432 - то есть приближается к миллиону. Каждый из этих лучей может уйти глубоко в рекурсию, увеличивая количество трассируемых лучей в несколько раз. Объем вычислений, которые надо при этом производить - громадный и обычно трассировка лучей работает довольно медленно. Причем, львиная доля процессорного времени затрачивается на поиск пересечений. Поэтому вопрос производительности здесь стоит на первом месте. Существуют классы алгоритмов, позволяющих на порядки ускорить поиск пересечений. Соотношение качество/скорость является основным критерием при выборе тех или иных алгоритмов, но эффективные алгоритмы в любом случае стараются использовать когерентность лучей в том или ином виде. Подробнее о них см. в разделе "Быстрая трассировка лучей". За последние несколько лет метод трассировки лучей (ray tracing), похоже, стал "мечтой номер один" мира 3D-графики в реальном времени. Интерес к этой технологии рендеринга вырос до максимума, когда молодой исследователь Дэниел Похл (Daniel Pohl) объявил о своём проекте в области этой технологии ещё в 2004 году. Причина интереса широких масс публики к работе заключалась, по большей мере, в том, что Похл сфокусировался на знаменитых играх id Software Quake III, Quake IV и шутере-франшизе Quake Wars 3D. Исследователь привлёк немало внимания со стороны прессы, а геймеры начали мечтать о светлом будущем, когда их любимые игры будут просчитываться по методу трассировки лучей и избавятся от растеризации. Intel довольно быстро обратила внимание на проект, и компании он показался идеальным способом для оправдания увеличения числа ядер в процессорах. Компания быстро запустила собственную исследовательскую программу, и сегодня Intel никогда не упускает возможность подчеркнуть, что трассировка лучей является будущим 3D-игр в реальном времени. Но так ли это на самом деле? Какие технологические реальности скрываются за маркетинговой шумихой? Каковы реальные преимущества метода трассировки лучей? Можем ли мы ожидать, что трассировка лучей заменит растеризацию? Мы попытаемся ответить на эти вопросы. Нажмите на картинку для увеличения. Основные принципы Основная идея метода трассировки лучей очень проста: для каждого пикселя на дисплее движок рендеринга проводит прямой луч от глаза наблюдателя (камеры) до элемента выводимой сцены. Первое пересечение используется для определения цвета пикселя как функции пересекаемой поверхности элемента. Но одного этого мало для вывода реалистичной сцены. Необходимо определить освещение пикселя, что требует проведения вторичных лучей (в отличие от первичных лучей, которые определяют видимость разных объектов, составляющих сцену). Чтобы рассчитать эффекты освещения сцены, проводятся вторичные лучи от точек пересечения к разным источникам света. Если эти лучи блокируются объектом, то данная точка находится в тени, которую отбрасывает рассматриваемый источник света. Иначе источник света влияет на освещение. Совокупность всех вторичных лучей, которые достигают источника света, определяет качество освещения, которое попадает на наш элемент сцены. Но и это ещё не всё. Чтобы получить наиболее реалистичный рендеринг, необходимо учитывать характеристики отражения и преломления материала. Другими словами, нужно знать, какое количество света отражается в точке пересечения первичного луча, а также количество света, которое проходит через материал в этой точке. Опять же, для расчёта финального цвета пикселя необходимо проводить лучи отражения и преломления. В итоге мы получаем несколько типов лучей. Первичные лучи используются для определения видимости объекта и напоминают своего рода Z-буфер, используемый в растеризации. А вторичные лучи разделяются на следующие: лучи тени/освещения; лучи отражения; лучи преломления. Классический алгоритм трассировки лучей. Нажмите на картинку для увеличения. Данный алгоритм трассировки лучей является результатом работы Тёрнера Виттеда (Turner Whitted), исследователя, который изобрёл алгоритм 30 лет назад. До того времени алгоритм трассировки лучей работал только с первичными лучами. И улучшения, внесённые Виттедом, оказались гигантским шагом в сторону реализма рендеринга сцены. Если вы знакомы с физикой, то наверняка обратили внимание на то, что алгоритм трассировки лучей работает "в обратную сторону" от явлений, протекающих в реальном мире. В отличие от распространённого в Средние века мнения, наши глаза не излучают лучи света, напротив, они получают лучи света от источников света, которые отражаются на различных объектах, окружающих нас. В принципе, так и работали самые первые алгоритмы трассировки лучей. Но главным недостатком первых алгоритмов было то, что они налагали огромную вычислительную нагрузку. Для каждого источника освещения вам нужно провести тысячи лучей, многие из которых вообще не будут влиять на выводимую сцену (поскольку они не пересекают плоскость построения изображения). Современные алгоритмы трассировки лучей являются оптимизацией базовых алгоритмов, при этом они используют так называемую обратную трассировку луча, поскольку лучи проводятся в обратном направлении по сравнению с реальностью. Оригинальный алгоритм трассировки лучей приводил к большому количеству ненужных расчётов. Нажмите на картинку для увеличения. Преимущества трассировки лучей Как вы уже видели, основным преимуществом метода трассировки лучей является его простота и элегантность. Алгоритм использует только один объект-примитив для отображения эффектов, которые часто требуют нетривиального подхода и сложных технологий стимуляции при использовании стандартного метода растеризации. Карта окружения (environment map) даёт хорошее приближение к симуляции отражений окружающей среды, однако метод трассировки лучей может симулировать даже отражения глаз машины Луиджи на капоте. Нажмите на картинку для увеличения. Отражения - это одна из областей, в которых метод трассировки лучей превосходно показывает себя. Сегодня в 3D-движках современных игр отражения рассчитываются с помощью карт окружений (environment map). Эта технология даёт хорошее приближение к отражениям объектов, расположенных "в бесконечности" или в окружающей среде (как можно видеть по названию), но для близко расположенных объектов подход показывает свои ограничения. Разработчики игр-гонок, в частности, создали свои трюки для симуляции отражений близких объектов с помощью так называемых динамических кубических карт (dynamic cube maps). Камера располагается на уровне машины геймера, после чего проводится рендеринг в основных направлениях. Затем результаты рендеринга сохраняются в кубических картах, которые и используются для вывода отражений. Динамические кубические карты могут симулировать отражения близких объектов, например, самолёта на чайнике. Но они не справляются с отражениями частей объекта друг на друге, например, носика чайника на его корпусе. Нажмите на картинку для увеличения. Конечно, у динамических кубических карт тоже есть свои недостатки. Довольно накладно по вычислительной мощности просчитывать несколько результатов рендеринга, и, чтобы производительность не падала слишком сильно, кубические карты не пересчитываются столько раз, сколько основная картинка. Это может привести к небольшой задержке отражений. Чтобы снизить нагрузку на скорость заполнения (fill rate), рендеринг выполняется с меньшим разрешением, что может привести к появлению пикселизации в отражениях. Наконец, эта технология часто ограничивается машиной геймера, а все другие объекты используют более простые (сферические) карты окружения. При методе трассировки лучей отражения отображаются идеально, причём без сложных алгоритмов, поскольку всё просчитывается основным алгоритмом рендеринга. Ещё одним преимуществом можно считать вывод отражений частей объекта друг на друге, например, отражение зеркала бокового вида на теле машины, что очень сложно получить с помощью метода растеризации - а здесь это отражение получается так же, как и другие. Метод трассировки лучей позволяет симулировать отражения частей объектов друг на друге, например, отражение зеркала бокового вида на корпусе машины. Нажмите на картинку для увеличения. Другим бесспорным преимуществом метода трассировки лучей является качественная обработка эффектов прозрачности. С помощью алгоритма растеризации крайне сложно выводить эффекты прозрачности, поскольку расчёт прозрачности напрямую зависит от порядка рендеринга. Чтобы получить хорошие результаты, необходимо отсортировать прозрачные полигоны в порядке самых дальних от камеры к самым близким, а уже потом выполнять рендеринг. Но на практике эта задача слишком тяжёлая с точки зрения вычислений, да и ошибки прозрачности тоже возможны, поскольку выполняется сортировка полигонов, а не пикселей. Существует несколько технологий, позволяющий обойти сортировку полигонов сцены (таких как depth peeling и A-буферы), но на данный момент ни одну из них нельзя назвать спасительной. Вместе с тем алгоритм трассировки лучей позволяет элегантно справиться с эффектами прозрачности. Правильная обработка эффектов прозрачности с помощью растеризатора требует использования сложных алгоритмов, например, A-буферов. Нажмите на картинку для увеличения. Другим важным преимуществом является расчёт теней. В мире растеризации стандартом стала технология карт теней (shadow mapping). Но у неё несть несколько проблем, такие как "лесенки" на контурах и объём используемой памяти. Алгоритм трассировки лучей позволяет решить проблему теней весьма элегантно, не прибегая к сложным алгоритмам, используя тот же объект-примитив и не требуя дополнительную память. Наконец, ещё одним сильным преимуществом метода трассировки лучей является "родная" возможность работы с искривлёнными поверхностями. Уже несколько лет у современных GPU есть поддержка искривлённых поверхностей (она то появляется, то исчезает по мере выхода новых драйверов и новых архитектур). Но если растеризаторам приходится выполнять изначальный проход тесселяции, чтобы создавать треугольники (это единственный примитив, с которым может работать движок растеризации), то движок методом трассировки лучей может просто работать с пересечением лучей, без точного математического определения поверхности. Мифы о трассировке лучей Но метод трассировки лучей всё же не стоит идеализировать, поэтому настало время разбить некоторые мифы, окружающие этот алгоритм. Начнём с того, что многие геймеры считают алгоритм трассировки лучей принципиально лучше, чем растеризации, поскольку его используют в фильмах. Это не так. Большинство фильмов с синтезированной/рисованной картинкой (например, все фильмы студии Pixar) используют алгоритм под названием REYES, который базируется на растеризации. Pixar добавила трассировку лучей к своему движку рендеринга RenderMan только позднее, во время производства мультфильма "Тачки/Cars". Но даже для этого фильма метод трассировки лучей использовался избирательно, чтобы не перегрузить существующие вычислительные мощности. До этого проекта Pixar использовала внешний модуль для ограниченного использования метода трассировки лучей, например, для эффектов затенения ambient occlusion (AO). Нажмите на картинку для увеличения. Второй распространённый миф среди защитников метода трассировки лучей касается сложности сцен, которые можно выводить с помощью метода трассировки лучей и с помощью растеризации. Чтобы разобраться, нам нужно внимательнее рассмотреть каждый алгоритм. Ниже показано, как алгоритм растеризации работает с каждым треугольником сцены. Определяется набор пикселей, который покрывает каждый треугольник; для каждого задействованного пикселя его глубина сравнивается с глубиной соседнего пикселя. Основное ограничение метода растеризации касается числа треугольников. Алгоритм имеет сложность O(n), где n - число треугольников. Алгоритм в данном случае имеет линейную сложность в зависимости от числа треугольников, поскольку для каждого кадра составляется список треугольников, которые нужно обработать, один за другим. Напротив, алгоритм трассировки лучей работает следующим образом. Для каждого пикселя кадра: проводится луч, определяющий, какой треугольник является самым близким; для каждого треугольника рассчитывается расстояние от треугольника до плоскости вывода изображения. Как видим, последовательность обработки стала обратной. В первом случае мы брали каждый полигон и смотрели, какие пиксели он покрывает. А во втором случае мы брали каждый пиксель и смотрели, какой полигон ему соответствует. Поэтому можно подумать, что метод трассировки лучей меньше зависит от числа полигонов, чем метод растеризации, поскольку число полигонов не влияет на основной цикл. Но на практике это не так. Фактически, чтобы определить, какой треугольник будет пересекаться с лучом, нам нужно обработать все треугольники сцены. Здесь, конечно, защитники метода трассировки лучей скажут, что не нужно обрабатывать все треугольники сцены с каждым лучом. Если использовать соответствующий тип структуры данных, то очень легко организовать треугольники таким образом, чтобы только небольшой их процент тестировался с каждым лучом, то есть мы получаем, что метод трассировки лучей имеет сложность O(log n), где n - число полигонов. Да, доводы можно признать верными. Но защитники метода трассировки лучей немного лукавят в том, что то же самое верно и для растеризации. Игровые движки уже многие годы используют BSP-деревья (binary space partitioning) и другие методы, ограничивающие число полигонов, которые нужно рассчитать для каждого кадра. Ещё один спорный момент - такие структуры более всего эффективны для статических данных. Всё, что нам нужно: рассчитать данные один раз, после чего просто обеспечивать к ним доступ, и это даёт очень хорошие результаты. Но что делать с динамическими данными? В данном случае данные придётся пересчитывать для каждого изображения, а для этого нет никаких чудесных формул. Всё равно придётся изучать каждый полигон. Простой алгоритм? Последний миф касается естественной простоты и элегантности алгоритма трассировки лучей. Конечно, алгоритм трассировки лучей можно написать несколькими строчками кода (некоторые алгоритмы умещаются на одной стороне "визитки"), но высокопроизводительный алгоритм трассировки лучей - совершенно иное дело. Дэвид Любке (David Luebke), инженер nVidia, сделал следующий комментарий, прекрасно отражающий реальность: "Растеризация выполняется быстро, но необходимо тщательно продумывать то, как выполнять сложные визуальные эффекты. Метод трассировки лучей поддерживает сложные визуальные эффекты, но необходимо тщательно продумывать то, как сделать его быстрым". Код минимального алгоритма трассировки лучей, написанный Полем Хекбертом (Paul Heckbert), чтобы уместить его на "визитке". Нажмите на картинку для увеличения. Всё, что вам нужно - прочитать несколько статей про оптимизации, которые необходимо внести в алгоритм трассировки лучей, чтобы оценить слова Любке. Например, самые мощные алгоритмы трассировки лучей не обрабатывают лучи независимо, они используют так называемые наборы лучей, что позволяет оптимизировать производительность с лучами, которые имеют одинаковое происхождение и одинаковое направление. Подобная оптимизация прекрасно подходит для функциональных блоков "одна инструкция много данных" (SIMD) внутри CPU и GPU, а также очень эффективна для основных лучей с некоторой степенью когерентности (сонаправленности) или для теневых лучей. Но, с другой стороны, оптимизация уже не подходит для лучей преломления или отражения. Более того, как указывает Даниэль Похл в своей статье по поводу Quake Wars RT , использование наборов лучей может стать проблематичным с прозрачными текстурами (знаменитые альфа-текстуры, используемые для деревьев), поскольку если все лучи в наборе не будут вести себя одинаково (некоторые затрагивают поверхность, другие проходят через неё), то возникающие дополнительные издержки могут стать намного больше, чем преимущества от оптимизаций, которые даёт использование наборов лучей. Визуализация "стоимости" рендеринга каждого пикселя, где красные пиксели являются самыми "дорогими". Как можно видеть, рендеринг деревьев стоит очень дорого в версии Quake Wars с методом трассировки лучей. Нажмите на картинку для увеличения. Наконец, как мы уже упоминали, метод трассировки лучей требует подходящей структуры данных, чтобы хранить разные элементы сцены, и как раз эта структура будет играть определяющую роль в итоговой производительности. Но выбор и затем работа с такой структурой данных не такие простые, как кажется на первый взгляд. Некоторые структуры обладают лучшими характеристиками для статических данных, а другие можно быстрее обновлять в случае с динамическими данными, или они занимают меньше памяти. Как обычно, всё сводится к поиску приемлемого компромисса. Чудес не бывает. Поэтому, как мы видим, алгоритм трассировки лучей не всегда можно назвать идеалом простоты и элегантности, как считают некоторые. Чтобы получить хорошую производительность от алгоритма трассировки лучей нужно найти ничуть не меньше нетривиальных решений программирования, чем в случае получения сложных визуальных эффектов в методе растеризации. Теперь, когда мы рассеяли некоторые мифы, связанные с трассировкой лучей, давайте обратимся на реальные проблемы, которые связаны с этой технологией. И начнём мы с основной проблемы, связанной с данным алгоритмом рендеринга: его медлительностью. Конечно, некоторые энтузиасты скажут, что это уже не проблема, поскольку алгоритм трассировки лучей хорошо распараллеливается, а число ядер процессора увеличивается каждый год, поэтому мы должны увидеть линейный рост производительности трассировки лучей. Кроме того, исследования по поводу оптимизаций, которые можно применить к трассировке лучей, всё ещё находятся в младенческом состоянии. Если посмотреть первые 3D-ускорители и сравнить их с тем, что доступно сегодня, то для оптимизма действительно есть поводы. Однако такая точка зрения не учитывает важный момент: самое интересное в методе трассировки лучей заключается во вторичных лучах. На практике расчёт картинки только с первичными лучами не даст особого улучшения качества изображения по сравнению с классическим алгоритмом с Z-буфером. Но проблема со вторичными лучами заключается в том, что у них абсолютно отсутствует когерентность (сонаправленность). При переходе от одного пикселя к другому нужно рассчитывать совершенно разные данные, что сводит на нет все обычные техники кэширования, очень важные для хорошей производительности. Это означает, что расчёт вторичных лучей очень сильно зависит от подсистемы памяти, в частности, от её задержек. Это наиболее худший сценарий из возможных, поскольку из всех характеристик памяти именно задержки менее всего улучшились за последние годы, и нет никаких поводов считать, что ситуация исправится в обозримом будущем. Довольно легко увеличить пропускную способность памяти, используя несколько чипов параллельно, но задержки всё равно останутся прежними. У видеокарт задержки памяти (latency) уменьшаются намного медленнее, чем увеличивается пропускная способность (bandwidth). Если последняя улучшается в 10 раз, то задержки улучшаются только в два раза. Причина популярности GPU кроется в том, что создание "железа", специализирующегося на растеризации, оказалось очень эффективным решением. При растеризации доступ к памяти выполняется когерентно (параллельно), независимо от того, работаем мы с пикселями, текселями или вершинами. Поэтому небольшие кэши, дополненные серьёзной пропускной способностью памяти, будут идеальным решением для получения великолепной производительности. Конечно, увеличение пропускной способности обходится весьма накладно, но такое решение вполне подходит при условии окупаемости. Напротив, сегодня нет каких-либо решений для ускорения доступа к памяти при расчёте нескольких лучей. Именно по этой причине метод трассировки лучей никогда не будет таким эффективным, как растеризация. Ещё одна характерная проблема метода трассировки лучей касается сглаживания (AA). Лучи проводятся в виде простой математической абстракции, и реального размера они не учитывают. Проверка на пересечение с треугольником является простой логической функцией, которая даёт ответ "да" или "нет", но не даёт таких деталей, как "луч на 40% пересекает треугольник". Прямым следствием такого эффекта будет появление "лесенок". Чтобы решить эту проблему, было предложено несколько технологий, таких как трассировка пучков (beam tracing) и трассировка конусов (cone tracing), которые учитывают толщину лучей, но их сложность не позволяет получить эффективную реализацию. И единственной технологией, которая может дать хорошие результаты, является расчёт большего числа лучей, чем есть пикселей, то есть суперсэмплинг (рендеринг при большем разрешении). Вряд ли стоит лишний раз упоминать, что эта технология намного более накладна по вычислительной мощности, чем мультисэмплинг, использующийся в современных GPU. Гибридный движок рендеринга? Если вы прочитали всю статью до этого места, то наверняка уже подумываете о том, что метод трассировки лучей пока что не может заменить растеризацию, но, возможно, стоит смешать две технологии вместе? И на первый взгляд кажется, что две технологии дополняют друг друга. Легко представить растеризацию треугольников для определения видимой картинки, получая преимущество от великолепной производительности данной технологии, после чего будет применяться трассировка лучей только для некоторых поверхностей, добавляя реализм там, где это необходимо, например, для добавления теней или получения хороших отражений и прозрачности. Собственно, такой подход Pixar и использовала для мультфильма "Тачки/Cars". Геометрические модели создаются с помощью REYES, а трассировка лучей используется "по требованию" там, где нужно симулировать определённые эффекты. Для мультфильма "Тачки/Cars" Pixar использовала гибридный движок рендеринга, сочетающий REYES для визуализации и трассировку лучей "по требованию" для отражений и ambient occlusion. Нажмите на картинку для увеличения. К сожалению, несмотря на то, что такой метод звучит обещающе, гибридные решения не так легко реализовать. Как мы уже видели, одним из важных недостатков метода трассировки лучей является необходимость организации структуры данных таким образом, чтобы ограничить количество проверок пересечения лучей и объектов. И использование гибридной модели вместо чистой трассировки лучей это не меняет. Нужно организовывать структуру данных вместе со всеми недостатками, которые с этим связаны. Например, предположим, что метод трассировки лучей основан на статических данных, а рендеринг динамических данных производится через растеризацию. Но в данном случае мы теряем все преимущества трассировки лучей. Поскольку для метода трассировки лучей динамических данных не существует, то нельзя будет заставить объекты отбросить тень или посмотреть отражения. Более того, что касается производительности, то самой большой проблемой является доступ к памяти, связанный со вторичными лучами, а эти лучи как раз и необходимы в нашем гибридном движке рендеринга. Так что прирост производительности не будет таким большим, как можно было бы ожидать изначально. Поскольку большая часть времени рендеринга будет уходить на вторичные лучи, то выигрыш от отсутствия просчёта основных лучей будет мизерным. Другими словами, пытаясь скомбинировать преимущества обоих методов, мы неизбежно комбинируем и их недостатки, теряя элегантность метода трассировки лучей и высокую производительность растеризации. Как мы уже неоднократно упомянули в нашей статье, предстоит решить немало проблем, прежде чем метод трассировки лучей станет достойной альтернативой растеризации в сфере рендеринга в реальном времени. И если вдуматься, то станет ли этот метод панацеей от всех бед? Преимущества метода трассировки лучей не такие революционные, чтобы оправдать существенное снижение производительности. Сильные моменты алгоритма связаны с отражениями и прозрачностью, поскольку два этих эффекта сложнее всего вывести на существующих алгоритмах растеризации. Но, опять же, такой ли это серьёзный недостаток? Мир вокруг нас не состоит целиком из очень прозрачных или сияющих объектов, поэтому наше зрение вполне может удовлетвориться грубым приближением. Если посмотреть на последние автосимуляторы, например, Gran Turismo и Forza, то там достаточно хорошо заметно вполне удовлетворительное качество рендеринга, пусть даже отражения на корпусе полностью лживые. И точное отражение зеркала заднего вида на краске вряд ли можно считать достаточным, чтобы признать ещё один шаг в сторону фотореализма. На самом деле отражений нет. Например, зеркало бокового вида на корпусе машины не отражается. Но нужен ли вам "честный" рендеринг Audi R8 с помощью метода трассировки лучей? Нажмите на картинку для увеличения. Большинство энтузиастов считают, что метод трассировки лучей по своей природе даёт лучшее изображение, чем растеризация - но они часто основывают своё мнение на картинке, произведённой оффлайновым движком, работающем не в реальном времени. Однако результаты таких движков намного лучше, чем способности современных игр. Кроме того, вокруг трассировки лучей наблюдается определённая путаница. Энтузиасты часто сравнивают с растеризацией фотореалистичные изображения, которые получены комбинацией нескольких техник, таких как трассировка лучей для прямых отражений, метод излучательности (radiosity) для диффузного отражения, фотонное отображение (photon mapping) для каустики и т.д. Все эти технологии сочетаются, чтобы обеспечить максимально фотореалистичное качество. Чтобы получить фотореалистичный рендеринг, необходимо сочетать несколько технологий. Трассировка лучей сама по себе недостаточна для симуляции сложных взаимодействий между материалами разных типов и света. Нажмите на картинку для увеличения. В своей базовой версии метод трассировки лучей, если рассматривать существующие попытки реализации в реальном времени, подходит только для идеальных отражений и жёстких (резких) теней. Игра Doom 3 несколько лет назад доказала, что можно создать надёжный 3D-движок, который идеально бы справлялся с динамическими тенями и через растеризацию, но если посмотреть в прошлое, то игра показала и то, что жёсткие тени не являются реалистичными. Нажмите на картинку для увеличения. Чтобы создавать мягкие тени или диффузные отражения (такие, какие вы видите на текстурированном металле, например), требуются более развитые техники трассировки лучей, такие как трассировка путей (path tracing) и или распределённая трассировка лучей (distributed ray tracing). Но подобные техники требуют существенно большего количества лучей, так что они пока ещё слабо подходят для реального времени. Некоторые пользователи считают, что рано или поздно будет доступна столь большая вычислительная мощность, что преимущество растеризации по производительности перестанет быть решающим фактором. По закону убывающей отдачи о приросте производительности при растеризации быстро забудут, получив элегантность трассировки лучей. Примерно так же, как и раньше было забыто преимущество кодирования на ассемблере по производительности, которое оказалось недостаточным, чтобы перевесить преимущества языков высокого уровня. Впрочем, нас это вряд ли убедит. В любом случае, мы ещё пока далеки до того времени, когда мы сможем пожертвовать производительностью из-за элегантности и простоты. Просто посмотрите, что произошло за последние 10 лет в мире оффлайнового рендеринга. Если рендеринг одного кадра мультфильма "История игрушек/Toy Story" выполнялся, в среднем, за два часа, то кадр из мультфильма "Рататуй/Ratatouille" - уже за шесть с половиной часов, несмотря на вычислительную мощность, которая увеличилась в промежутке между двумя картинами более чем в 400 раз. Другими словами, чем больше вычислительной мощности и ресурсов вы предоставляете компьютерным художникам, тем быстрее они их поглощают. Если даже компания, подобная Pixar, которая может позволить себе выделить несколько часов вычислений для создания одного кадра, решила использовать трассировку лучей только время от времени из-за негативного влияния на производительность, это значит, что времена, когда мы получим достаточную вычислительную мощность в 3D-играх реального времени для выполнения всего рендеринга методом трассировки лучей, очень и очень далеки. Да и в будущем у энтузиастов наверняка будет, куда потратить такую вычислительную мощность.

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

Недавно в интернете я наткнулся на трассировщик лучей на визитке Пола Гекберта. Для тех, кто не в курсе: это очень известная задача, изначально предложенная Полом Гекбертом 4-ого мая 1984 на comp.graphics. Ее суть в том, чтобы написать демонстрацию метода бросания лучей, которая бы… умещалась на визитной карточке (больше об этом читайте в разделе «Трассировка лучей» из книги «Графические драгоценности IV»)!

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

Обратная сторона визитки

Вот так выглядит сам код:

#include // card > aek.ppm #include #include typedef int i;typedef float f;struct v{ f x,y,z;v operator+(v r){return v(x+r.x ,y+r.y,z+r.z);}v operator*(f r){return v(x*r,y*r,z*r);}f operator%(v r){return x*r.x+y*r.y+z*r.z;}v(){}v operator^(v r){return v(y*r.z-z*r.y,z*r.x-x*r.z,x*r. y-y*r.x);}v(f a,f b,f c){x=a;y=b;z=c;}v operator!(){return*this*(1/sqrt(*this%* this));}};i G={247570,280596,280600, 249748,18578,18577,231184,16,16};f R(){ return(f)rand()/RAND_MAX;}i T(v o,v d,f &t,v&n){t=1e9;i m=0;f p=-o.z/d.z;if(.01 0){f s=-b-sqrt(q);if(s.01)t=s,n=!(p+d*t),m=2;}}return m;}v S(v o,v d){f t ;v n;i m=T(o,d,t,n);if(!m)return v(.7, .6,1)*pow(1-d.z,4);v h=o+d*t,l=!(v(9+R(),9+R(),16)+h*-1),r=d+n*(n%d*-2);f b=l% n;if(b<0||T(h,l,t,n))b=0;f p=pow(l%r*(b >0),99);if(m&1){h=h*.2;return((i)(ceil(h.x)+ceil(h.y))&1?v(3,1,1):v(3,3,3))*(b *.2+.1);}return v(p,p,p)+S(h,r)*.5;}i main(){printf("P6 512 512 255 ");v g=!v (-6,-16,0),a=!(v(0,0,1)^g)*.002,b=!(g^a)*.002,c=(a+b)*-256+g;for(i y=512;y--;) for(i x=512;x--;){v p(13,13,13);for(i r =64;r--;){v t=a*(R()-.5)*99+b*(R()-.5)* 99;p=S(v(17,16,8)+t,!(t*-1+(a*(R()+x)+b *(y+R())+c)*16))*3.5+p;}printf("%c%c%c" ,(i)p.x,(i)p.y,(i)p.z);}}

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

C++ -O3 -o card card.cpp ./card > card.ppm

Через 27 секунд на экране появится следующее изображение:

Возможности визитки-трассировщика лучей

Возможности просто поражают!

• мир, состоящий из строго организованных сфер;
• текстурированный пол;
• небо с градиентом;
• мягкие тени;
• OMG, глубина резкости! Вы шутите?!

И все это на одной стороне визитной карточки! Посмотрим, как это работает.

Класс Vector

Рассмотрим первую часть кода:

#include // card > aek.ppm #include #include typedef int i;typedef float f;struct v{ f x,y,z;v operator+(v r){return v(x+r.x ,y+r.y,z+r.z);}v operator*(f r){return v(x*r,y*r,z*r);}f operator%(v r){return x*r.x+y*r.y+z*r.z;}v(){}v operator^(v r){return v(y*r.z-z*r.y,z*r.x-x*r.z,x*r. y-y*r.x);}v(f a,f b,f c){x=a;y=b;z=c;}v operator!(){return*this*(1/sqrt(*this%* this));}};

Главная хитрость здесь - это сокращение ключевых слов типов int и float до i и f с помощью typedef . Другой ход, с помощью которого можно можно уменьшить количество кода - это класс v , используемый не только в качестве вектора, но и для обработки пикселей.

#include // card > aek.ppm #include #include typedef int i; // Экономим место с помощью сокращения int до i typedef float f; // Экономим еще больше места с f вместо float // Класс вектора с конструктором и операторами struct v{ f x,y,z; // Три координаты вектора v operator+(v r){return v(x+r.x,y+r.y,z+r.z);} // Сумма векторов v operator*(f r){return v(x*r,y*r,z*r);} // Масштабирование векторов f operator%(v r){return x*r.x+y*r.y+z*r.z;} // Скалярное произведение векторов v(){} // Пустой конструктор v operator^(v r){return v(y*r.z-z*r.y,z*r.x-x*r.z,x*r.y-y*r.x);} // Векторное произведение векторов v(f a,f b,f c){x=a;y=b;z=c;} // Конструктор v operator!(){return *this*(1 /sqrt(*this%*this));} // Нормализация вектора };

Rand() и данные для генерации мира

i G={247570,280596,280600, 249748,18578,18577,231184,16,16};f R(){ return(f)rand()/RAND_MAX;}

Следующий код также экономит много места с помощью объявления функции R , которая возвращает случайное значение от 0 до 1 типа float. Это полезно при стохастическом сэмплировании, использующемся для blur-эффекта и мягких теней.

Массив G содержит в себе закодированное целыми числами положение сфер в мире. Совокупность всех чисел - это битовый вектор из 9 строк и 19 столбцов.

Вот код, приведенный выше, но отформатированный и с комментариями:

// Набор позиций сфер, описывающий мир // Все эти числа, по сути, являются по сути битовым вектором i G={247570,280596,280600,249748,18578,18577,231184,16,16}; // Генератор случайных чисел, возвращающий число с плавающей точкой в диапазоне 0-1 f R(){return(f)rand()/RAND_MAX;}

Главный метод

i main(){printf("P6 512 512 255 ");v g=!v (-6,-16,0),a=!(v(0,0,1)^g)*.002,b=!(g^a)*.002,c=(a+b)*-256+g;for(i y=512;y--;) for(i x=512;x--;){v p(13,13,13);for(i r =64;r--;){v t=a*(R()-.5)*99+b*(R()-.5)* 99;p=S(v(17,16,8)+t,!(t*-1+(a*(R()+x)+b *(y+R())+c)*16))*3.5+p;}printf("%c%c%c" ,(i)p.x,(i)p.y,(i)p.z);}}

Главный метод использует простой известный основанный на тексте формат изображений PPM. Изображение состоит из заголовка вида P6 [Ширина] [Высота] [Максимальное значение] , за которым следует RGB-значение каждого пикселя.

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

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

Вот код, приведенный выше, но отформатированный и с комментариями:

// Главная функция. Выводит изображение. // Использовать программу просто: ./card > erk.ppm i main(){ printf("P6 512 512 255 "); // Заголовок PPM // Оператор "!" осуществляет нормализацию вектора v g=!v(-6,-16,0), // Направление камеры a=!(v(0,0,1)^g)*.002, // Вектор, отвечающий за высоту камеры... b=!(g^a)*.002, // Правый вектор, получаемый с помощью векторного произведения c=(a+b)*-256+g; // WTF? Вот здесь https:// news.ycombinator.com/item?id=6425965 написано про это подробнее. for(i y=512;y--;) // Для каждого столбца for(i x=512;x--;){ // Для каждого пикселя в строке // Используем класс вектора, чтобы хранить цвет в RGB v p(13,13,13); // Стандартный цвет пикселя - почти черный // Бросаем по 64 луча из каждого пикселя for(i r=64;r--;){ // Немного меняем влево/вправо и вверх/вниз координаты начала луча (для эффекта глубины резкости) v t=a*(R()-.5)*99+b*(R()-.5)*99; // Назначаем фокальной точкой камеры v(17,16,8) и бросаем луч // Аккумулируем цвет, возвращенный в переменной t p=S(v(17,16,8)+t, // Начало луча!(t*-1+(a*(R()+x)+b*(y+R())+c)*16) // Направление луча с небольшим искажением // ради эффекта стохастического сэмплирования)*3.5+p; // +p для аккумуляции цвета } printf("%c%c%c",(i)p.x,(i)p.y,(i)p.z); } }

Сэмплер

v S(v o,v d){f t ;v n;i m=T(o,d,t,n);if(!m)return v(.7, .6,1)*pow(1-d.z,4);v h=o+d*t,l=!(v(9+R(),9+R(),16)+h*-1),r=d+n*(n%d*-2);f b=l% n;if(b<0||T(h,l,t,n))b=0;f p=pow(l%r*(b >0),99);if(m&1){h=h*.2;return((i)(ceil(h.x)+ceil(h.y))&1?v(3,1,1):v(3,3,3))*(b *.2+.1);}return v(p,p,p)+S(h,r)*.5;}

Сэмплер S - это функция, возвращающая цвет пикселя по данным координатам точки начала луча о и его направлению d . Если она натыкается на сферу, то она вызывает себя рекурсивно, а в ином случае (если луч не имеет препятствий на своем пути) в зависимости от направления возвращает либо цвет неба, либо цвет пола (базируясь на его клетчатой текстуре).

Обратите внимание на вызов функции R при расчете направления света. Таким образом создается эффект «мягких теней».

Вот код, приведенный выше, но отформатированный и с комментариями:

// (S)эмплируем мир и возвращаем цвет пикселя по // по лучу, начинающемуся в точке o (Origin) и имеющему направление d (Direction) v S(v o,v d){ f t; v n; // Проверяем, натыкается ли луч на что-нибудь i m=T(o,d,t,n); if(!m) // m==0 // Сфера не была найдена, и луч идет вверх: генерируем цвет неба return v(.7,.6,1)*pow(1-d.z,4); // Возможно, луч задевает сферу v h=o+d*t, // h - координата пересечения l=!(v(9+R(),9+R(),16)+h*-1), // "l" = направление света (с небольшим искажеем для эффекта мягких теней) r=d+n*(n%d*-2); // r = полувектор // Расчитываем коэффицент Ламберта f b=l%n; // Рассчитываем фактор освещения (коэффицент Ламберта > 0 или находимся в тени)? if(b<0||T(h,l,t,n)) b=0; // Рассчитываем цвет p (с учетом диффузии и отражения света) f p=pow(l%r*(b>0),99); if(m&1){ // m == 1 h=h*.2; // Сфера не была задета, и луч уходит вниз, в пол: генерируем цвет пола return((i)(ceil(h.x)+ceil(h.y))&1?v(3,1,1):v(3,3,3))*(b*.2+.1); } // m == 2 Была задета сфера: генерируем луч, отскакивающий от поверхности сфера return v(p,p,p)+S(h,r)*.5; // Ослабляем цвет на 50%, так как он отскакивает от поверхности (* .5) }

Трэйсер

i T(v o,v d,f &t,v&n){t=1e9;i m=0;f p=-o.z/d.z;if(.01 0){f s=-b-sqrt(q);if(s.01)t=s,n=!(p+d*t),m=2;}}return m;}

Функция T (Tracer) отвечает за бросание луча из данной точки (o) в данном направлении (d). Она возвращает целое число, которое является кодом для результата бросания луча. 0 - луч ушел в небо, 1 - луч ушел в пол, 2 - луч наткнулся на сферу. Если была задета сфера, то функция обновляет переменные t (параметр, используемый для вычисления дистанции пересения) и n (полу-вектор при отскакивании от сферы).

Вот код, приведенный выше, но отформатированный и с комментариями:

// Тест на пересечение для линии // Возвращаем 2, если была задета сфера (а также дистанцию пересечения t и полу-вектор n). // Возвращаем 0, если луч ничего не задевает и идет вверх, в небо // Возвращаем 1, если луч ничего не задевает и идет вниз, в пол i T(v o,v d,f& t,v& n){ t=1e9; i m=0; f p=-o.z/d.z; if(.010){ // Да. Считаем расстояние от камеры до сферы f s=-b-sqrt(q); if(s.01) // Это минимальное расстояние, сохраняем его. А также // вычиваем вектор отскакивающего луча и записываем его в "n" t=s, n=!(p+d*t), m=2; } } return m; }

Число Leet

Многие программисты пытались сократить код еще больше. Сам автор остановился на версии, предоставленной в этой статье. Знаете, почему?

Fabien$ wc card.cpp 35 95 1337 card.cpp - много математики, но все очень подробно и ясно объясняется.

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

 

---

Читайте:
Самостоятельные заговоры на удачу и деньги Завершился вывод войск ссср из афганистана Новое направление: инноватика Сложно ли учиться на инноватике К чему снится племянница Репейник: толкование сновидения