Rendering: Теория

"Частотный словарь", выданный Google:

3D - 333 000 000, render - 59 100 000, rendering - 43 200 000, modeling - 88 100 000, computer graphics - 274 000 000, computer animation - 83 700 000.

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

Render в переводе с английского означает "визуализировать, формировать изображение". Что же "визуализируется" в процессе рендеринга? А "визуализируется" та самая модель, которая получается в результате моделирования (а что еще, как не модель, могло получиться при моделировании? - да все, что угодно, "умельцы" получать "не совсем то" или "совсем не то" встречаются не так уж редко ;)). Описание модели представляется или в виде инструкций на каком-нибудь языке, специально для этого предназначенном, или в виде структур данных вроде массивов, всевозможных списков и т.д. Само описание содержит геометрические данные в виде трехмерных координат точек модели, а также параметры всевозможных "трансформаций" (перемещение, масштабирование, поворот, сдвиг), координаты и параметры "виртуальной" камеры, через которую мы "созерцаем" трехмерную сцену, координаты и параметры источников света, свойства поверхностей объектов (цвет, материал, текстуры и т.п.). Используя эти данные, специальная программа ("фамилия" которой, естественно, RENDER, а "имя" может быть совершенно любым - вы не поверите, но "семейка" RENDER насчитывает более полутысячи "членов"! Этот сайт, скорее всего, просто однофамилец :)) производит "визуализацию" трехмерной модели в виде "двухмерного" изображения, например, на экране компьютера. Исследованием того, КАК она это делает, мы сейчас и займемся. Поскольку рендеринг - это некий "симбиоз" всевозможных "методик" из разных наук и дисциплин (физика света, математика, вычислительная геометрия, физиология и "психология" зрения, программирование и др., а также изрядная доля магии, позволяющая практически из ничего, из каких-то там "абстракций" создавать нечто, вызывающее в нас порой целую бурю эмоций), то знание этих "методик" имеет как теоретическую (в плане расширения наших познаний об окружающем мире), так и вполне практическую (рендеринг у всех "компьютерных графиков" занимает бОльшую часть "рабочего времени") ценность.

Теоретические основы современного рендеринга заложены более 300 лет назад (а вы думали, что все придумано "на днях"?) Исааком Ньютоном (Isaac Newton), предложившем корпускулярную теорию света и обосновавшему с помощью этой теории такие ключевые для рендеринга явления, как отражение (reflection), преломление (refraction), рассеяние (diffusion, dispersion, scattering). Другим "краеугольным камнем" в рендеринге является закон сохранения энергии (в данном случае энергии света). По сути дела рендеринг - это попытка решения (с разной степенью точности) некоего уравнения, описывающего распространение света в трехмерной сцене, причем уравнение это учитывает только корпускулярные свойства света. Уравнение так и называется - уравнение рендеринга. В математическом представлении оно выглядит так:

где Lo - свет, излучаемый поверхностью в точке x в направлении вектора w, Le - обственные "излучательные способности" поверхности в той же точке и в том же направлении, а выражение под знаком интеграла - это бесконечная сумма излучений, пришедших в точку поверхности из пространственной полусферы и отраженных поверхностью в соответствии с ее "отражательной способностью", описываемой с помощью функции fr - функция эта настолько важна, что получила в теории рендеринга собственное название - bidirectional reflectance distribution function (BRDF), что в вольном переводе означает "двунаправленная функция распределения отражений". BRDF описывает отражательные оптические свойства поверхности, но будучи математической абстракцией не имеет "физических" измерений, так что для практического применения приходится использовать упрощенные математические модели вроде отражательной модели Фонга (не путать с затенением методом Фонга) или отражательной модели Фонга-Блинна. В "словесной" интерпретации уравнение рендеринга выглядит так: освещенность в точке поверхности складывается из энергии лучей, пришедших напрямую от источников света (direct illumination), и энергии лучей от тех же источников, но претерпевших отражения (в общем случае - бесконечное число отражений) от других поверхностей в трехмерной сцене (indirect illumination). Плюс, конечно, собственные свойства поверхности, как источника света - в 3D-программах (и, соответственно, их рендерах) "последнего поколения" источником света может быть не только "специальный" объект (как правило, или совсем не имеющий, или имеющий очень простую "геометрию"), но вообще ЛЮБОЙ объект в сцене (можно только представить, какой "напряг" на процессор оказывает "реалистичный" рендеринг сцен с такими источниками света).

Но вычисление цвета пиксела двухмерного изображения на экране - самая последняя "стадия" рендеринга (хотя при "реалистичном" рендеринге - самая трудоемкая), что же происходит с описанием трехмерной модели до этого? А происходит следующее: данные из описания модели проходят по своеобразному "конвейеру" или "каналу" (который так и называется - graphics pipeline), подвергаясь зачастую довольно изощренной "обработке".

 

[ Этапы "обработки" могут выполняться как центральным процессором компьютера (CPU), так и специализированными процессорами графических карт или специальных "ускорителей" (GPU, DSP и т.п. - стишок :)!). Зачастую "вклад", вносимый в рендеринг процессором видеокарты, настолько ничтожен, что у большинства "пользователей" складывается впечатление, что видеокарта вообще не участвует в рендеринге. Это, конечно же, не так: рендеринг настолько требовательный к ресурсам компьютера процесс, что игнорировать "вычислительные" возможности современных видеокарт просто неразумно и этого не может себе позволить ни один разработчик программ рендеринга. Другое дело, что видеокарты, "ориентированные" в основном на игровые приложения, с "геометрическими", например, вычислениями справляются гораздо хуже, чем CPU, но все совсем по-другому с "профессиональными" видеокартами с аппаратным OpenGL-ускорением. Правда, и цена таких "решений" очень высока, гораздо эффективней ''экстенсивный" путь - простое увеличение задействованных при рендеринге CPU путем использования "многоядерных" процессоров или сетевого рендеринга, а еще лучше того и другого вместе. ]

 

Типичный graphics pipeline практически не отличается в realtime и в не-realtime рендеринге и включает в себя следующие "стадии":

- преобразования в "мировой" системе координат, учитывающие такие "трансформации" объектов, как перемещение, вращение, масштабирование, сдвиг;

- преобразования в координатном простанстве "виртуальной" камеры (в пространстве "наблюдателя трехмерной сцены"), которые переводят "мировые" координаты объектов в координаты "поля зрения" наблюдателя;

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

Математический аппарат первых трех "стадий" основан на матричных преобразованиях - именно матрицы (возможно, "младшие братья и сестры" той самой The MATRIX - кто знает?) размерностью 4х4 и выполняют все эти фокусы с трехмерными координатами точек объектов, переводя их в двухмерные координаты пикселов будущего "отрендеренного" изображения.

Матрица, "ответсттвенная" за перемещение объекта на расстояние x, y, z вдоль соответствующих координатных осей:

 

А эти матрицы выполняют вращение объекта на соответствующий угол вокруг осей x, y, z:

 

Для полноты картины надо добавить еще матрицу масштабирования вдоль осей x, y, z. Вот она:

 

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

Не пугайтесь ее "грозного" вида - это пока только теория, на практике все выглядит гораздо проще.

 

Подобные матрицы существуют и для преобразований в координатном пространстве камеры (наблюдателя) и для перспективных преобразований. Не будем себе забивать голову, а сразу приведем "результирующее" преобразование точки с координатами x, y, z в трехмерном виртуальном пространстве сцены в пиксел с координатами x', y', z', w' (координата w' используется для придания координатной системе "однородности" с размерностью матриц, а координата z' используется для построения "карты глубины" (или Z-буфера), которая понадобится на следующих стадиях рендеринга):

 

На практике, конечно, все эти формулы с синусами-косинусами преобразуют к более удобному для вычислений виду, например, такому:

 

Таким образом, после первых трех стадий (которые на практике объединяются в одну) рендеринга в дополнение к описанию модели получается "черновик" (в прямом смысле, потому как цвет вычисленных пикселов еще не определен) будущего "отрендеренного образа" и карта глубины. Теперь самое время заняться решением проблемы видимости (или удалением невидимых поверхностей), которая заключается в следующем: объекты располагаются в виртуальном пространстве сцены на разном удалении от "наблюдателя" (виртуальной камеры), поэтому одни объекты могут полностью или частично "заслонять" другие от "наблюдателя" (или, говоря языком вычислительной геометрии, две точки в пространстве называются видимыми друг для друга, если соединяющий их отрезок прямой не встречает никаких "препятствий").Алгоритмы удаления невидимых поверхностей (hidden surface removal - HSR) можно разделить на "работающие" в координатном пространстве "наблюдателя" (в этом случае точность алгоримов ограничена разрешением получаемой "картинки") и на "работающие" в виртуальном пространстве трехмерной сцены (в этом случае получается геометрически точное описание видимых примитивов, не зависящее от разрешения конечной "картинки" и именно эти методы используются при рендеринге сцен с высоким уровнем реалистичности и детализации). К первой группе методов относятся painter's algorithm, scanline method и z-buffering, ко второй - метод трассировки лучей (ray tracing). Все методы имеют достоинства и недостатки: главные недостатки painter's algorithm и scanline - низкая точность и ошибки в некоторых "специфических" случаях, самый большой недостаток ray tracing - вычислительная "трудоемкость", z-buffering располагается где-то между ними, имея достаточно высокую скорость работы и программируемую точность, зависящую от разрядности z-буфера, поэтому z-buffering получил самое большое распространение среди методов HSR.

 

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

 

Наконец все предварительные стадии завершены и настал черед самой "трудоемкой" с вычислительной точки зрения стадии рендеринга - определение цвета пикселов "отрендеренного" изображения. Точное решение уравнения рендеринга (прослеживание распространения ВСЕХ лучей света в трехмерной сцене) практически невозможно (или нецелесообразно, так как потребует бесконечного времени), все существующие методы - приближение с той или иной погрешностью к точному решению. В современных рендерах используются (порознь или в комбинациях друг с другом) четыре основных метода: rasterization (и его разновидность - scanline rendering), ray casting, radiosity и ray tracing. А что же Global Illumination, спросите вы, с ней-то как? Дело в том, что Global Illumination - это обобщенное название алгоритмов решения уравнения рендеринга, учитывающих как прямое излучение источников света (direct illumination), так и отраженное другими поверхностями в сцене (indirect illumination) (в некоторых рендерах Global Illumination - синоним метода radiosity). Для расчета глобальной освещенности кроме основных методов используют и "вспомогательные", как то: beam tracing, cone tracing, path tracing, metropolis light transport, ambient occlusion, photon mapping и некоторые другие. Процесс изобретения методов решения уравнения рендеринга далеко не закончен, каждый год добавляется что-то новенькое (а "старенькое" отмирает), но уже достигнутой сейчас точности решения уравнения рендеринга (помноженной на все возрастающую мощность компьютеров) вполне достаточно для получения высокореалистичных "отрендеренных" изображений за "приемлемое" время.

 

Растеризация (rasterization) в общем случае - процесс преобразования векторного описания объекта (той же трехмерной модели или, к примеру,"плоского" набора кривых, описывающих форму буквы алфавита) в набор пикселов (растр). Трехмерная модель состоит из множества треугольников, положение и форма треугольника в виртуальном пространстве задается трехмерными координатами его вершин. При рендеринге используют две "разновидности" растеризации. Первая "разновидность" учитывает тот факт, что треугольник - плоская фигура (все точки треугольника лежат в одной плоскости, а проекция треугольника на любую плоскость - тоже треугольник), поэтому нет никакой нужды "обсчитывать" все точки треугольника, достаточно выполнить преобразования над его вершинами, а все "промежуточные" точки вычисляются методами интерполяции. Scanline rendering (этот метод попутно еще удаляет невидимые поверхности) создает "отрендеренное" изображение построчно, для чего все примитивы в сцене сортируются в соответствии со значениями координат X и Y. "Сканирующая строка" перемещается сверху вниз, по дороге определяя, какие примитивы она пересекает (для повышения эффективности этого процесса примитивы и сортируют). Ежели пересечений не обнаруживается, то в качестве цвета соответствующего пиксела берется цвет фона, в противном случае пиксел будет окрашен в цвет примитива. "Оттенок" (shade) цвета пиксела может "уточняться" с использованием разнообразных методов, вроде метода "затенения" Гуро (Gouraud shading) или Фонга (Phong shading).

 

Ray casting (метод "бросания" луча) используется в realtime-рендеринге (например, в компьютерных играх), где скорость "создания картинок" важнее их "качества". Суть метода в следующем: из "точки наблюдения" в направлении пиксела, цвет которого определяется, "выстреливается" воображаемый луч. Если луч пересекает какой-нибудь примитив, то этот примитив "окрашивает" соответствующий пиксел в свой цвет. Существуют вариации метода, когда "бросаются" дополнительные лучи от примитива в "точку наблюдения" или от источника света в сторону примитива (для вычисления освещенности и теней). Для вычисления освещенности примитива могут использоваться и данные, полученные методом radiosity.

 

Radiosity (или метод излучения) часто называют Global Illumination, хотя, сторого говоря, radiosity всего лишь один из алгоритмов вычисления этой самой "глобальной освещенности", который используется, как правило, в сочетании с другими алгоритмами. Методом radiosity пытаются моделировать путь отраженного от поверхности света, который в реальности отражается не в одном направлении ("угол отражения равен углу падения"), а рассеивается (diffusion) в простанственную полусферу, "освещая" целую область вокруг точки падения, при этом цвет рассеянного света изменяется в соответствии с цветом поверхности в точке падения луча. Сложность и точность метода radiosity варьируется в очень широких пределах. В realtime-рендеринге и при рендеринге outdoor-сцен глобальную освещенность имитируют с помощью нехитрого трюка, слегка "освещая" всю сцену воображаемым источником света, называемым ambiance (окружающая среда). А вот в сочетании с методом трассировки лучей (ray tracing) radiosity позволяет получить очень реалистичные изображения, особенно при рендеринге indoor-сцен, правда, ценой увеличения во много раз времени рендеринга :(. Впрочем, многие 3D-программы позволяют "вручную" дать "указания" рендеру, какие объекты будут участвовать в рассчете глобальной освещенности, а какие нет, при этом можно получить очень хороший (в смысле реалистичности) результат гораздо быстрей.

[ Различных способов имитировать глобальную освещенность придумано довольно много, некоторые дают весьма неплохой результат, но резкое увеличение производительности процессоров (за счет "многоядерности" прирост получается не 5-10-20%, а буквально В РАЗЫ) при весьма умеренном их удорожании делает использование "окольных путей" для высокореалистичного рендеринга нецелесообразным - "сравнительно честные" способы решения уравнения рендеринга ("абсолютно честных" способов не существует) дают более точный результат при тех же временнЫх затратах, что и у "нечестных способов". ]

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

Как же "функционирует" алгоритм radiosity? Если выражаться корректно, то алгоритм "оперирует" не лучами, а световой энергией, "циркулирующей" в трехмерной сцене. В общем случае трехмерная сцена состоит их бесконечного множества точек, "обменивающихся" световой энергией. Проследить все эти "взаимодействия" не представляется возможным, поэтому бесконечное множество точек заменяют на конечное число "участков" (patches) поверхностей, образующих трехмерную сцену. Способов "разбиения" на участки довольно много, но универсального, пригодного "на все случаи жизни", пока не изобрели. Алгоритм radiosity многопроходный, на каждом проходе для каждого "участка" вычисляется световая энергия, пришедшая к нему от других участков. Часть этой энергии поглощается участком, остальное "отражается" обратно в сцену и учитывается при следующем проходе. В математическом виде это выглядит так:

Bi - это энергия, излучаемая i-тым участком, Ei - собственные "излучательные способности" участка, Ri - "отражательные способности", n - количество участков в сцене (в разных реализациях метода может изменяться "по ходу дела"). Самая интересная часть в этом достаточно тривиальном уравнении - Fij, называется она "коэффициентом формы" (form factor), и учитывает взаимное расположение в пространстве двух участков. Способов вычисления коэффициента формы тоже достаточно много, но наибольшее распространение получили способы, использующие проецирование одного участка на другой. Но именно проецированием текстур на полигоны (texture mapping) и занят GPU любой современной видеокарты! Это может показаться невероятным, но один из самых "зрелищных" алгоритмов "реалистичного" рендеринга легко обсчитывается самой дешевенькой видеокартой.

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

А как же одни объекты умудряются окрашивать в свой цвет соседние (одна из самых "прикольных фенечек" метода radiosity)? А очень просто: приведенное выше уравнение - "монохромное", оно вычисляется для каждой из трех цветовых составляющих RGB, только и всего. (Ну скажите после этого, что магия здесь не присутствует :)!).

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

Как уже упоминалось, метод radiosity дает "частное" решение уравнения рендеринга, поэтому при "реалистичном" рендеринге radiosity используется в компании с другими методами, в первую очередь с ray tracing.

 

Ray tracing (трассировка лучей) - самый "трудоемкий" в плане вычислений алгоритм "реалистичного" рендеринга, но без него просто никуда: геометрически точное удаление невидимых поверхностей, отражения, преломления, дисперсия, "жесткие" тени, anti-aliasing, "объемные эффекты" - вот только некоторые (впрочем, самые важные) его "амплуа". А в паре с radiosity метод этот составляет львиную долю всего "реалистичного" рендеринга.

Вычислительная "трудоемкость" метода ray tracing связана прежде всего с тем, что он, по сути дела, является попыткой решить уравнение рендеринга "в лоб", с как можно меньшей погрешностью. Зато "наградой" за эту попытку является очень высокий уровень "реализма" отрендеренных сцен (в основном благодаря "учету" таких оптических явлений, которые не попадают в "поле зрения" других алгоритмов рендеринга). Проследить все лучи в сцене не представляется возможным ввиду их бесконечного числа, поэтому "трассируются" не все лучи, а только те, которые участвуют в "формировании" пиксела "отрендеренного" изображения. И самыми естественными "кандидатами" на трассировку являются лучи, попадающие в глаз "наблюдателю" (объектив "виртуальной" камеры). Метод трассировки лучей как бы "вывернут наизнанку": прослеживаются не лучи, "испущенные" источником света, а воображаемые лучи, "испущенные" глазом "наблюдателя" (объективом камеры). Именно из-за этого "базовый" метод трассировки не учитывает "диффузные" отражения, при которых направление отраженного от поверхности луча непредсказуемо, а учитывает только "зеркально" отраженные и преломленные лучи (а в последних версиях многих рендеров еще и "дисперсно" преломленные (dispersion), а также "подповерхностно рассеянные" (subsurface scattering)). Трассировка лучей, исходящих от источника света, тоже используется - для "уточнения" результатов трассировки лучей от глаза "наблюдателя", из-за этого возникла путаница в терминологии: что считать "прямой", а что "инверсной" трассировкой. В большинстве рендеров ray tracing "имеет в виду" именно лучи, исходящие от глаза "наблюдателя", а лучи, исходящие от источника света, трассируются алгоритмами с другими названиями (хотя программа "трассер" у них одна и та же).

Для того, чтобы метод трассировки лучей мог работать, все поверхности в сцене должны быть математически описаны (в виде формул). "Забота" по математическому описанию возложена на программы моделирования, хотя можно делать и "вручную" на "встроенных" языках 3D-программ. Рассмотрим на примере сферы, как работает типичный "трассер". На языке аналитической геометрии это "звучит" так: найти точки пересечения сферы радиусом Sr и центром (Sx, Sy, Sz), описываемой уравнением

и прямой, проходящей через точку (0, 0, 0) и описываемой уравнениями x = d * lx, y = d * ly, z = d * lz, в котрых l - направление прямой, d - расстояние вдоль прямой от точки (0, 0, 0). Опустим, как говорят математики, промежуточные "выкладки" ввиду их тривиальности и сразу приведем результат:

Если значение выражения под знаком корня отрицательно, то прямая и сфера не пересекаются, если равно нулю - прямая "касается" сферы в одной точке, если положительно - прямая "протыкает" сферу в двух точках. Вычислить координаты точек пересечения вообще не составляет трудности.(Я ж говорю - магия :)! ).

 

[ Как видим, найти точки пресечения луча с самой замысловатой поверхностью с "вычислительной" точки зрения не представляет никаких трудностей. По крайней мере, для центрального процессора (CPU). Попытки возложить "тяготы" трассировки на специализированные устройства ("усовершенствованную" видеокарту, например) предпринимаются постоянно, достигнуты определенные успехи, но до "широкого внедрения" подобных устройств пока далеко. И опять же, для чего нужен будет CPU, если всю работу за него будут выполнять "подмастерья" :)? ]

 

Итак, мы (вернее, алгоритм трассировки лучей) "бабахнули" воображаемым лучом из камеры (нашего "глаза" в виртуальном пространстве) в направлении пиксела, цвет которого хотим определить. Если этот луч никого (ничего) не "заденет", то цветом пиксела будет цвет фона. (Аналогичное происходит в методе ray casting, "развитием" которого ray tracing, собственно говоря, и является). Ежели какой нибудь поверхности не повезло (вернее, не повезло в этом случае нам - лучи начинают "размножаться" со скоростью снежной лавины, что самым "драматичным" образом сказывается на времени рендеринга), то в точке "попадания" происходит следующее луч "расщепляется" в общем случае на три - отраженный (reflection), преломленный (refraction) и "теневой" (shadow). "Теневой" луч, как понятно из названия, используется для формирования теней: "теневым" лучом "выстреливают" в направлении источника света и если по дороге попадется какой-нибудь объект, то стало быть наша поверхность (вернее, точка "попадания" "исходного" луча) лежит в тени этого объекта. С отраженным лучом тоже все понятно - он отразился "зеркально" от поверхности и пошел "блуждать" по трехмерной сцене. Преломленный луч "ушел" вглубь объекта под углом, определяемым коэффициентом преломления материала объекта. Преломление (refraction), естественно, имеет смысл только для прозрачных (transparent) объектов. Но есть еще материалы, которые ведут себя по другому, не как transparent - называются они translucent ("просвечивающий", "полупрозрачный"). В чем же состоит их "полупрозрачность"? Та "часть" "упавшего" на поверхность луча, которая "пошла" вглубь объекта, начинает совершать под поверхностью объекта в слое определенной толщины хаотичные движения, "выскакивая" обратно на поверхность в точке, отличной от точки "падения" исходного луча, т.е. луч внутри "транслюцентного" материала претерпевает диффузное рассеяние (как в методе radiosity). Рассеяние это моделируется с помощью вероятностных методов (метод Монте-Карло, еще называемый методом русской рулетки - хоть здесь нам удалось "засветиться":)) и называется subsurface scattering ("подповерхностное рассеяние") или SSS. К транслюцентным материалам относят воск, некоторые вязкие жидкости, молоко, мрамор, а что самое важное - человеческую кожу. Именно придание материалу кожи "транслюцентных" свойств позволяет добиться поразительного реализма при рендеринге (увы, за счет того самого "драматического" увеличения времени этого самого рендеринга :(, но результат превосходит самые смелые ожидания :)).

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

Но в таком виде метод ray tracing дает в конечном изображении много "артефактов", поэтому для более точного ("правильного") определения цвета пиксела используют дополнительно "выстреливаемые" лучи. По существу сцена рендерится с разрешением, бОльшим заданного, а полученная "картинка" потом "ужимается" до нужных размеров с помощью самых разнообразных способов. Алгоритмы "генерации" дополнительных лучей носят общее название anti-aliasing, количество их достаточно велико и в разных рендерах они используются во всевозможных сочетаниях (например, дополнительные лучи могут "генерироваться" не для всех пикселов, а только для соответствующих контурам объектов - так называемый Object anti-aliasing, или, наоборот, для пикселов внутри контура - Texture anti-aliasing, причем количество "дополнительных" лучей (samples) может задаваться в настройках рендера).

Дополнительные лучи "генерятся" также для "обсчета" таких эффектов, как "трехмерный" motion blur, Depth of Field, "объемных" эффектов и других.

В "базовом" методе ray tracing мы (вернее, разработчики метода) заменили лучи, идущие от источника света (как оно имеет место в природе), на лучи, "испускаемые" глазом "наблюдателя". Замена эта, сторого говоря, не совсем эквивалентная, поэтому в "реалистичном" рендеринге "трассируются" также лучи, испускаемые источником света, только лучи эти, в отличие от "испускаемых" глазом "наблюдателя", имеют внутреннюю "структуру" - они "состоят" из фотонов. Фотон - "частица света" - обладает определенными "свойствами", вроде энергии, цвета, направления движения и некоторыми другими. При столкновении с поверхностью "свойства" фотона изменяются, а "точки столкновения" регистрируются в фотонных картах. Фотоны "живут", пока не покинут сцену, "поглотятся" какой-нибудь поверхностью или пока их "энергия" не упадет до определенного "порога". Полученные фотонные карты используются затем для формирования "окончательной засветки" "отрендеренной" сцены.

Методом фотонных карт (photon mapping) моделируются такие оптические явления, как каустические пятна (caustics), диффузные "межотражения" (как в методе radiosity) и некоторые другие. Как и в методе radiosity, "засветка" трехмерной сцены фотонами не зависит от положения "наблюдателя" и этот факт можно использовать для "реалистичной" анимации сцен, единственным движущимся объектом в которых является камера. А вот "картинка", получаемая методом ray tracing, целиком зависит от положения "наблюдателя", поэтому при рендеринге анимации трассировку в каждом кадре приходится начинать "по новой".

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

 

© by Yuri Buyskikh 2007
yurab@VirtualVision.ru
www.VirtualVision.ru

689 0 850 36
43
2007-03-29
алгоритмы генерации дополнительных лучей, конечно же не носят общего названия - антиализинг. и вообще и по логике изложения: моушион блюр, мягкие тени - и т.п. - никакого отношение к антиа... - не имеют. антиа... - это устранение ступенчатого эффекта и только.
2007-03-29
Устранять "ступенчатый эффект" (антиа...) тоже можно многими способами, в том числе и способом "генерации дополнительных лучей", а можно обойтись без доп.лучей, а "просто" интерполировать уже "вычисленные" пикселы. В этом смысле алгоритмы антиа... можно разделить на работающие в "координатном пространстве трехмерной сцены" (именно о них и шла речь) и "работающие в координатном пространстве наблюдателя (виртуальной камеры)" (о чем говорите Вы). Этим алгоритмы антиа..., "работающие в виртуальном пространстве трехмерной сцены", схожи с 3D-motion blur, depth of field и т.п., для "корректного просчета" которых тоже "испускаются" дополнительные лучи (но можно похожее получить и методами интерполяции уже "вычисленных" пикселов; но только "похожее" - про "физическую корректность" речь в данном случае не идет).
2007-03-30
Ничего не понял. 5\5 за заумность.
2007-03-30
Давайте сюда еще рендер основаный на теории единого поля и искревленного пространства :) P.S. если кто не понял я про физ корректность :)
2007-03-30
Зайдите в раздел "Конкурсы:Подсчет голосов" и полюбуйтесь: формул раза в три больше, чем у меня в статейке. А там речь идет всего лишь о подсчете голосов, а не о таком "оснвополагающем процессе", как рендеринг :).
2007-03-30
To SHIDOXX Вы совсем недалеки от истины: рендеринг ведь используется не только (даже не столько) в "комп. графике", но и во многих "точных" технических "дисциплинах" и "фундаментальных науках" (проектирование оптических приборов, например, вообще все, что связано с распространением световой энергии). Тамошние рендеры учитывают не только корпускулярные, но и волновые свойства света, вообще энергии. (Метод radiosity, кстати, "позаимствован" из термодинамики). Там на первом месте как раз "физ. корректность", а "шоб было красиво" - это "критерий" "чисто" "компьютернографический".
2007-03-30
Несмотря на то, что при виде уравнений и матриц я с ужасом вспоминаю "вышку" и мне срочно хочется застрелиться из шотгана, должен сказать, что статья интересная и полезная. Некоторые основы совсем не помешают (так сказать, для общего развития).
2007-03-30
мозг взорвался...)
2007-03-30
антиализинг - устранение ступенчатости, достигается в том числе(чаще всего) и большим количеством лучей: вот такое направление, а не наоборот: большее количество лучей - значит антиализинг. например: сферический источник света требует большее количества лучей для отображения его действия, но к антиализингу - это никакого отношения не имеет.
2007-03-30
To IgoTM В принципе согласен с Вами - построение фразы искажает заложенный в ней смысл - праввильннее было бы сформулировать так: "дополнительные" лучи могут "генерироваться" для anti-aliasing, 3D-motion blur, depth of field, "объемных" эффектов и т.д. как правило с использованием вероятностных методов (метод Монте-Карло); в некоторых рендерах возможно выбирать "стратегию" генерации "дополнительных" лучей. Спасибо за замечание. (А вот сферический (или любой другой формы) источник света имеет к "антиалиазингу методом трассировки лучей" самое прямое отношение - и выбор "кандидатов" на трассировку, и сама трассировка выполняются одними и теми же "подпрограммами", как и в 3D-motion blur или depth of field, хотя "природа" этих "явлений", конечно же, различна. Это лишний раз показывает "универсальность" метода трассировки лучей и его "незаменимость", ну и "напряг", который этот метод оказывает на компьютер :().
2007-03-30
Ха, "прикололо" написание слова "праввильннее" в предыдущем посте :).
2007-03-30
Absent, жжошь! :))) Большинство художникоав интересует только инструменты программ, это все равно, что кисть и краски, работай ими, а не забивай голову из чего они сделаны.
2007-03-30
Отличная статья. Не описан, правда, Final Gathering (как я понимаю, он отличается от Radiocity) и масса других методов, но вообще здорово все сформулировано. Автору - большой респект и пятерки %)
2007-03-30
Final Gather - разновидность метода ray tracing, в которой лучи отражаются от поверхности "диффузно" (во всех направлениях). В принципе, и Final Gather, и Radiosity вычмсляют одно и то же - "диффузную" составляющую глобальной освещенности - но разными математическими методами: Radiosity - методом конечных элементов, Final Gather - вероятностными методами (метод Монте-Карло). В плане "трудоемкости" (в смысле быстродействия) radiosity предпочтительней, потому как реализуется "аппаратно" (GPU видеокарты). Опять же Final Gather - "чисто" mentalray-евская "фича" (в других рендерах применяется в видоизмененном виде) и ее "интерфейс" не совсем (совсем не) "интуитивен" - поди догадайся, каким образом влияют "настройки" на конечный результат и как выбрать "оптимальные".
2007-03-30
Страшные цифры и буквы, побоялся читать))...
2007-03-30
- говорят по эльфийски!
2007-03-31
ни асилил лично мне все равно какие процессы происходят после нажатия ф9 главное представлять че изменится в картинке после изменения параметра в настройках врая ((мое имхо ))
2007-03-31
Да, ментал не умеет радиосити. И его Final Gathering , в отличие, от радиосити, зависит от положения камеры. Считается же он не совсем Монте-Карло, а так называемым квази-Монте-Карло методом (как я понял, лучи стараются посылать не хаотично, а стараясь попасть в те точки, которые уже были "засвечены"). И еще вопрос - а новые статьи будут? Хотелось бы еще чего-нибудь подобного %) [/quote]Final Gather - разновидность метода ray tracing, в которой лучи отражаются от поверхности "диффузно" (во всех направлениях). В принципе, и Final Gather, и Radiosity вычмсляют одно и то же - "диффузную" составляющую глобальной освещенности - но разными математическими методами: Radiosity - методом конечных элементов, Final Gather - вероятностными методами (метод Монте-Карло). В плане "трудоемкости" (в смысле быстродействия) radiosity предпочтительней, потому как реализуется "аппаратно" (GPU видеокарты). Опять же Final Gather - "чисто" mentalray-евская "фича" (в других рендерах применяется в видоизмененном виде) и ее "интерфейс" не совсем (совсем не) "интуитивен" - поди догадайся, каким образом влияют "настройки" на конечный результат и как выбрать "оптимальные".[quote]
2007-03-31
Вообще-то "статейка" эта - всего лишь маленький "кусочек" того "учебного курса", который я год назад пытался организовать, вернее, предложил для "преподавания" некоторым "компьютерным курсам", но, есно, получил полный "отлуп". "Курс" назывался DIGITAL CINEMA, если в двух словах - как самому сделать стереоскопическое "компьютерное кино" (и неплохо заработать на его "прокате", причем "прокат" предполагает "происходить" в "стереокинотеатрах" собственной разработки - "железо" для них у меня уже два года пылится в ожидании готовых "стереофильмов" :().
2007-04-01
Замудренно как-то все...
2007-04-01
Супер! Молодец мыжик, немного замудрено.. На теорию рендера должен знать каждый.. Иначе только и будут уметь тыкать Ф9 в максе =)
2007-04-01
Все. Прочитал. Сел писать свой рендер. Формулы-то лёгкие оказались ;) FLOGISTONE render 1.0 - ждите на прилавках с 5 апреля ;)) Продам бетку за шакалатку ;)
2007-04-01
Ха... матрицы преобразований я еще в 99 году успешно применял в программинге, а в шейдингах добрался до фонга и рейтрейсовых теней... и потом мне принесли четвертый 3д студио, и программинг приказал долго жить
2007-04-02
А, кажется я видел демо-материалы для этих потенциальных стерео-театров. Что, дело так и не сдвинулось? Жаль, красивые были презенташки...
2007-04-02
Отличная статья
2007-04-04
Гммм... this._y = y-(+)z*(y-camy)/(focus+z) this._x = x+(-)z*(camx-x)/(focus+z); У меня только так))) более ли меннее правильно перспектива получается)) А если камера смотрит не парралельно оси? ... Тогда надо перейдти к новой плоскости проекции. ООО, помогите мне. dy = Math.sqrt(Math.pow(this._y-lookaty, 2)); dx = Math.sqrt(Math.pow(this._x-lookatx, 2)); //переходим к новому eyeDistance (у меня почемуто фокус)))) newfocus = Math.sqrt(Math.pow((looky)*(focus+z)/focus, 2)+Math.pow(focus, 2)); need = dy*Math.sqrt(looky*looky+Math.pow(z+focus, 2))/(focus+z); //К новому расстояниюZ относительно камуры в новой системе... newz = Math.sqrt(looky*looky+Math.pow(z+focus, 2))-newfocus+Math.sqrt(Math.pow(dy, 2)-need*need); ///////////this._y = camy+need*newfocus/(newfocus+newz); АФФТАР, помогай пожалуйста!) Или я туплю?
2007-04-05
Отличная и нужная статья!!!!!!!! 5+
2007-04-05
Ухш, пилят-шшайтан, какие формулы и паринципы, слющай!! Вспомнил строительную механику, метод конечных элементов, мартицы жОсткости и прочие не менее матричные матрицы... Помню, после прочтения означенного курса Профессор спросил "Ну как, понятно?" На что один студент с первого ряда, внимательно прослушавший все лекции, ответил "Непонятно, но как интересно.." Конечно, чтобы включать свет в ванной не надо знать уравнения Максвелла, но закон Ома освоить не помешает. Хорошая статья, я бы поставил 5 и нажал F9.
2007-04-05
сферический... да не, имхо, ну где там антиализинг... от антиализинга тут глобальное отличие: антиализинг (ну.. - раньше, может сейчас мода другая) живет в экранной плоскости, там проявляется - то, что он должен устранять. а расчет сфериче... живет в трех координатах и только как очень частный случай иногда работает похоже на антиализинг - эффект ссужения тени у основания столба, например. статья хорошая
2007-04-05
КЛАСС!!! Огромное Спасибо! Ну очень полезная статейка! А еще какие-нибудь материалы из вашего курса не будете выкладывать? Очень хотелось бы почитать! Теорию немного усвоили... хотелось бы практикой заняться ) я больше кодер чем 3дешник, поэтому очень интересно
2007-04-05
Бээ, ненавижу математику O-0
2007-04-06
Мне статья кажется довольно тривиальной. Имхо любой визуализавтор должен знать теорию (хотябы в общих чертах) GlobalIllumination AntiAlaisiing математрику приобразования моделей в пространстве, и подсчёт перспективы. Поэтому даже не читал увидев банальные матрицы поворота и подсчёт растояний)
2007-04-06
Круууууууууууть блин
2007-04-09
Есть одна замечательная книжка, причем вышедшая так же и на русском языке. Называется "Компьютерная анимация. Теория и алгоритмы". Автор Рик Пэрент. В ней очень здорово описаны все математические основы компьютерной графики. Тем кому это интересно советую поискать.
2007-04-10
To CHUR "Стереокинотеатры" вовсе не "потенциальные", а вполне реальные. Вернее, стереокинотеатр - это только одно из возможных применений "презентационных систем виртуальной реальности", "изысканиями" в области которых я и занимаюсь последние 4 года ("проект" называется Real Virtual Reality - RVR). Другие применения: - так любимая многими 3D-шниками "визуализация интерьеров/экстерьеров", причем в не в виде банальных "фотографий" формата А4, а в НАТУРАЛЬНУЮ ВЕЛИЧИНУ, причем с возможностью "путешествовать" вполне РЕАЛЬНЫМ способом - переставляя ноги - внутри (или вокруг) такого ВИРТУАЛЬНОГО интерьера/экстерьера (причем цена "железа" такой "системы визуализации" начинается с $1500-2000 - вполне по карману многим "визуализаторам", а "отобъется" все с 1-2 заказов); - "виртуальные выставочные стенды" (выставочный стенд в виде стереоскопического "кинотеатра" с соответствующим фильмом-презентацией); - "виртуальные" учебные пособия (например, школьный кабинет виртуальной реальности, легко "трансформируемый" ... да во что угодно - все зависит от "контента"); - динамически изменяемые интерьеры для клубов, дискотек, спорзалов, "присутственных мест" и т.д. Так уж получается, что только 20-25% всего "проекта" упирается в "железо", а все остальное - "контент", т.е. то, что на "железе" "крутится". "Контент" для систем виртуальной реальности логичней делать "виртуальными" же средствами - с помощью компьютерных программ, в первую очередь, есно - 3D (кстати, "стерео" и "3D" - синонимы, только одно по-гречески, а другое - по-английски). Так что кино и комп. игры - далеко не единственное поле деятельности для 3D-шника. Причем если "киношное" и "игрушечное" "поля" заселены очень плотно и "втиснуться" туда практически невозможно, то "поле виртуальной реальности" - совершенно "непаханное", конкуренция отсутствует напрочь (пока, во всяком случае, но америкосы, в отличие от нас, не дремлют и вовсю готовятся к полномасштабной "возделке").
2007-04-11
<> Математика - это филосовское учение!
2007-04-11
А я думал что у нас в универе матан дют для прикола...
2007-04-11
Это, ребатя., не математика, а арифметика - для многих, возможно это будет откровением, но вся современная "цифровая" техника "базируется" на всего лишь ТРЕХ арифметических операциях: логическое умножение (операция "И", не путать с "Ы" :)), логическое сложение ("ИЛИ") и инверсия (отрицание, "НЕ"). И усе! Все остальное - многочисленные "наслоения", чтобы у "непосвященных" не снесло крышу от простоты и гармонии (ну и чтобы "повысить значимость" "посвященных", что, пожалуй, даже важнее первого).
2007-04-16
Наконец-то "реанимировал" свой сайт (вернее, восстанавливаю его "с нуля" у другого провайдера), так что желающие могут продолжить "обсуждение" ПРАКТИЧЕСКИХ вопросов на форуме http://realVR.ru/Forum/phpBB3CVS (ну и познакомиться с моим "проектом" Real Virtual Reality, который после некоторого "застоя" начинает набирать "обороты" ;))
2007-04-24
О перспективные преобразование 8-) как раз то что мне нужно :) теперь надо матрицы вспомнить ;)
2007-07-07
Автару огромное спасибо!!! :) Узнал много нового, некоторые непонятные вещи стали понятными, ну вообщем волезная статья! :)))
2008-01-03
побольше бы таких статей
2009-04-20
Еще б по Metropolis Light Transport статейку :) хорошая статья =)
RENDER.RU