ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ МОДЕЛЬ
фотореалистичной визуализации сложных сцен
Д. Жданов1, 2, 3, С. Ершов1, Н. Дерябин1
1 Институт Прикладной Математики им. М.В. Келдыша РАН, Москва, Россия
2 Санкт-Петербургский Национальный Исследовательский Университет ИТМО, Санкт-Петербург, Россия
3 Государственный Оптический Институт им. С.И. Вавилова, Санкт-Петербург, Россия
ddzhdanov@mail.ru
Оглавление
2. Основы объектно-ориентированной организации рендеринга
3. Применение двунаправленной стохастической трассировки лучей для решения уравнения рендеринга
4. Базовые интерфейсы основных объектов сцены
5. Специальные оптические элементы и их программные интерфейсы
6. Объектно-ориентированная реализация метода двунаправленной трассировки лучей
Аннотация
Данная статья посвящена разработке объектно-ориентированной компьютерной модели фотореалистичной визуализации геометрически и оптически сложных сцен. Актуальность объектно-ориентированной организации становится очевидной в случае проектирования сложных компьютерных систем, предназначенных для выполнения физически корректных светотехнических расчетов и построения фотореалистичных изображений. В этом случае усилия, затраченные на объектно-ориентированное проектирование, окупаются сокращением времени на расширение элементной базы объектно-ориентированной модели. Например, добавление нового типа геометрического объекта или изменение алгоритма обработки лучей не требует никаких дополнительных изменений в программном продукте.
В работе рассматриваются основные принципы объектно-ориентированной организации, применяемые для построения компьютерной системы фотореалистичной визуализации сложных сцен. Выделяются основные компоненты объектно-ориентированной модели, а именно: объекты сцены и рендерер. Вводится понятие базовых интерфейсов, ограничивающих все взаимодействия между объектами сцены и между объектами сцены и рендерером. Для объектов сцены предлагается два уровня базовых интерфейсов: первый уровень – уровень конечного пользователя и второй уровень – уровень светотехнических вычислений. Реализация базовых интерфейсов на уровне пользователя сводится к интерфейсу структур данных, представляющих собой элементарные сущности, которые имеют средства визуализации и программного и пользовательского редактирования и взаимодействия со скриптом. Для светотехнических расчетов определяются основные типы объектов, участвующие в этих вычислениях, и для каждого из типов объектов определяется минимальный базовый интерфейс, обеспечивающий физическую корректность и эффективность вычислений. Кроме того, для реализации поведения объектов, являющихся результатом инновационных технологий, вводится понятие оптического элемента, интерфейс которого объединяет в себе программные интерфейсы всех основных объектов сцены. За программную основу фотореалистической визуализации сцены выбрана двунаправленная стохастическая трассировка лучей, которая обеспечивает физическую корректность изображения. Трассировка лучей и рендерер также построены на принципах объектно-ориентированной организации, когда взаимодействие между объектами рендерена и между сценой и рендерером ограничивается базовым программным интерфейсом.
Объектно-ориентированная модель сцены и ее фотореалистической визуализации, основанной на алгоритме двунаправленной стохастической трассировки лучей, была реализована в программном комплексе Lumicept. В качестве примера работы программы приводится результат моделирования изображения, наблюдаемого на жидкокристаллическом дисплее автомобиля при разных условиях наружного и салонного освещения. Основная специфика данного примера заключается в физической корректности всех элементов модели. Модель жидкокристаллического дисплея была задана без каких-либо упрощений, включая рассеивающие микроструктуры, поляризационные фильтры и TFT матрицу.
Разработанная объектно-ориентированная модель фотореалистичной визуализации основывается на физически корректных моделях сцены, включающих спектральные и поляризационные преобразования световых лучей, и на уровне базовых интерфейсов позволяет осуществить физически корректный и эффективный рендеринг оптически и геометрически сложных сцен. Введенная концепция оптического элемента расширяет объектно-ориентированную модель рендеринга специальными объектами, которые не могут быть представлены в рамках базовой модели сцены. В отличии от существующих программных решений единая объектно-ориентированная концепция была реализована для целого программного комплекса фотореалистичной визуализации, что значительно облегчает его расширение новыми моделями объектов сцен и способов трассировки лучей.
Ключевые слова: фотореалистичная визуализация, сцена, объект сцены, оптический элемент, программный интерфейс, рендеринг, стохастическое лучевое моделирование, двунаправленная трассировка лучей, фотореалистичное изображение.
1. Введение
Фотореалистичная визуализация сложных сцен, содержащих объекты со специальными свойствами пропускания, отражения и рассеивания, требует применения математически сложных моделей преобразования светового излучения на объектах сцены. Как правило, для физически корректного моделирования распространения светового излучения в сложных трехмерных сценах достаточно использовать лучевые методы, учитывая то, что данные методы обеспечивают высокую эффективность моделирования.
Решение задачи построения физически корректного изображения включает два основных программно-методических компонента. Во-первых, это методические, алгоритмические и программные модели трассировки лучей и построения изображения сцен с потенциально сложными компонентами. Во-вторых, это методические, алгоритмические и программные модели объектов сцены, используемые в программных алгоритмах трассировки лучей и решениях уравнения рендеринга, то есть базовые компоненты модели рендеринга. Оба программных компонента должны обеспечивать эффективную и физически корректную трассировку лучей в сценах, содержащих десятки и сотни миллионов геометрических объектов, допускающих сложные условия освещения (например, карты пространственного распределения яркости) и имеющих сложные оптические свойства, такие как двунаправленное рассеивание, поляризационное рассеивание, объемное рассеивание, двойное лучепреломление и т.п.
Необходимо отметить, что модели объектов сцены имеют, как минимум, два различных представления, ориентированные на различные аспекты использования этих объектов. Первое представление ориентированно на конечного пользователя и служит для наглядной визуализации и модификации исходных данных. Причем модификация исходных данных возможна как в графическом пользовательском интерфейсе, так и программно, например, с помощью скрипта. И если «ручная» модификация исходных данных, как правило, применяется для формирования исходной сцены, то программная модификация позволяет выполнять специальные манипуляции с исходными данными, например, анимационные действия или оптимизацию параметров сцены. Второе представление объектов сцены ориентировано на выполнение светотехнических вычислений и собственно построение изображения. Принципиальное отличие между первым и вторым представлением объектов сцены это их программный интерфейс, а именно то, как эти объекты определены с точки зрения программной среды, которая их использует. Если с точки зрения конечного пользователя объект сцены — это, как правило, набор параметров, определяющий данный объект (например, сферическая поверхность определяется ее радиусом), то с точки зрения светотехнических вычислений объект сцены — это набор программных методов, определяющих взаимодействие данного объекта сцены с другими объектами сцены, методами трассировки лучей и рендерингом. Например, сферическая поверхность (как и поверхность любого другого типа) это не просто поверхность, определенная радиусом, а объект, позволяющий найти точку пересечения с произвольным лучом и сформировать необходимую информацию о локальных параметрах поверхности в точке встречи луча с поверхностью. Естественно, что для задач фотореалистичной визуализации основными критериями формирования вычислительной модели объектов сцены является их эффективность (минимальное время обработки запроса со стороны рендеринга или другого объекта сцены) и физическая корректность (обработка запроса со стороны рендеринга или другого объекта сцены осуществляется в соответствии с физическими законами распространения света).
Однако эффективность и физическая корректность моделей отдельных программных компонентов рендеринга не гарантирует высокую эффективность и физическую корректность общей программной реализации рендеринга. Обязательным условием общей высокой эффективности и физической аккуратности рендеринга является согласованность программных интерфейсов всех объектов, формирующих единый программный продукт. А именно, программные интерфейсы объектов сцены должны быть полностью согласованы с программными интерфейсами, обеспечивающими трассировку лучей и вычисление световых характеристик изображения сцены [1]. Отсутствие согласованности может привести к потере физической корректности или эффективности вычислений. Например, если модель рассеивания света на поверхности обеспечивает физически корректное спектрально-поляризационное преобразование излучения, а программа трассировки лучей не позволяет передать состояние поляризации света от одного объекта сцены до другого, то физическая корректность модели данного объекта просто теряется. С другой стороны, для повышения эффективности рендеринга программа трассировки лучей может потребовать от объекта сцены определенный тип преобразования лучей, например, рассеивание света на поверхности с заданной плотностью вероятности углового рассеивания, которую модель поверхности или среды не в состоянии обеспечить.
Специфика взаимодействия объектов сцены с вычислительными компонентами рендеринга требует специальной программной организации. Известно, что задача физически корректного построения изображения сводится к вычислению значений яркости (освещенности) в точках изображения. Хотя компьютерная графика ограничивается геометрическими моделями распространения света, имеется большое количество методов трассировки лучей, используемых для вычисления яркости (освещенности) изображения. Это с одной стороны стохастические и детерминистические методы, а с другой стороны методы прямой и обратной трассировок лучей. Кроме того, современные вычислительные методы допускают комбинирование различных вычислительных методов, например, двунаправленная трассировка стохастических лучей. Разнообразие программных методов трассировки лучей и обработки ее результатов естественным образом расширяет программный интерфейс объектов сцены и тем самым усложняет как проектирование данного интерфейса, так и программную реализацию данных интерфейсов. Поэтому алгоритм рендеринга должен быть зафиксирован в некоторых рамках модели, например, в рамках стохастической трассировки лучей с использованием метода «русской рулетки».
Правильное проектирование программных интерфейсов должно быть ориентировано не только на текущее состояние программного продукта, но и предполагать возможное расширение программных моделей объектов сцены, программных моделей трассировки лучей и самого рендеринга. Естественно, что расширение всех программных моделей допускается в пределах выбранной общей модели рендеринга. Кроме того, программный интерфейс должен учитывать сложную организацию сцены. Организация сцены в данном случае предполагает не только тривиальную иерархию геометрических объектов сцены, но и существование объектов, программная организация которых отличается от организации основных объектов сцены (так называемых оптических элементов [2], которые являются «черным ящиком», видимым только посредством определенного программного интерфейса).
Важным аспектом проектирования программных интерфейсов является обеспечение визуального представления результатов вычисления. Несмотря на то, что основная задача компьютерного моделирования фотореалистичных изображения — это собственно построение и визуализация изображения, необходимо обеспечить ряд методов для анализа сформированного изображения. К таким «вспомогательным» методам необходимо отнести методы оценки точности построения изображения, фильтрации изображения, построения отдельных компонентов изображения (например, карты первичного или вторичного освещения), построения графиков (яркости или освещенности) сечений изображения и т.п.
Данная работа ориентирована главным образом на проектирование программных интерфейсов объектов сцены и рендеринга, оставляя за кадром вопросы, связанные с импортом исходных данных сцены. При этом основной упор делается на минимизацию программных интерфейсов как программных объектов сцены, так и программных объектов рендеринга (естественно, минимизация программных интерфейсов никоим образом не влияет на физическую корректность моделирования). Программная реализация интерфейсов объектов сцены и рендеринга поддерживает практически все физические эффекты, связанные с распространением света и его взаимодействием с объектами сцены. Единственным исключением на данный момент является невозможность применения эффекта рассеивания и распространения поляризационного излучения для трасс обратных лучей. Данное ограничение вызвано, главным образом, техническими проблемами, связанными с увеличением объема хранения данных фотонных карт в 16 раз.
2. Основы объектно-ориентированной организации рендеринга
Как уже отмечалось, реализация эффективных и физически аккуратных моделей отдельных программных компонентов рендеринга не гарантирует высокую эффективность и физическую корректность общей программной реализации рендеринга. Обязательным условием общей высокой эффективности и физической аккуратности рендеринга является согласованность всех программных интерфейсов объектов, формирующих программный продукт. Согласованность программных интерфейсов не предполагает тривиальной согласованности интерфейсов в рамках одной фиксированной программной реализации. Например, ограничиваясь одним представлением сцены, как правило, зеркально-диффузным преобразованием света на поверхностях сцены и RGB цветовым пространством, невозможно осуществить расширение программной модели и добавление таких эффектов, как поляризация света, спектральное цветовое пространство, объемное рассеивание света и т.п. С другой стороны фиксация программных интерфейсов конечных объектов сцены и рендеринга в общей программной модели может привести к потере возможности расширения программной модели новыми объектами сцены и рендеринга. Например, в компьютерной графике наиболее частым случаем описания формы поверхности является треугольная сетка. И если интерфейс треугольной сетки, содержащий такие параметры, как индекс вершины или индекс треугольника, выбран в качестве базового интерфейса описания геометрического объекта, то введение нового геометрического представления объекта, например, аналитического, становится невозможным. Можно привести огромное количество примеров, когда отсутствие продуманной организации программных интерфейсов приводило к полному перепроектированию программных продуктов компьютерной графики.
Принимая во внимание обилие возможных объектов сцены (как геометрических, так и оптических) и способов реализации алгоритмов рендеринга, необходимо осуществить стандартизацию и унификацию интерфейсов всех программных компонентов общей модели и создать единую объектно-ориентированную модель рендеринга [3]. При этом объектно-ориентированная организация должна, с одной стороны, отражать физическую сущность объектов сцены и физические аспекты распространения светового излучения в сцене, а с другой стороны – полную согласованность всех объектов рендеринга на уровне их базовых интерфейсов.
Общая схема организации процесса построения фотореалистичного изображения представлена на рисунке 1.
Рис. 1. Общая схема процесса построения фотореалистичного изображения
Очевидно, что согласованность интерфейсов объектов сцены возможна только на уровне программных интерфейсов пользователя и ниже. Исходные данные сцены не подлежат никакой унификации, поскольку они являются внешними данными, например, геометрические объекты, подготовленные в CAD программах, оптические свойства объектов сцены, измеренные на специализированных установках, модели источников света, поставляемые в виде набора цифровых фотографий, и т.п. Поэтому все исходные данные должны быть преобразованы в унифицированное представление сцены, используемое в компьютерной системе фотореалистичной визуализации сложных сцен. Как отмечалось выше, данные сцены имеют два основных представления: внешнее представление для работы конечного пользователя (ориентированное на модификацию и создание новых объектов сцены) и внутреннее представление (ориентированное на выполнение светотехнических вычислений и рендеринга).
Возникает вопрос, для чего нужна объектно-ориентированная организация рендеринга. Очевидно, что унификация программных интерфейсов и объектно-ориентрованная организация не гарантирует высокую эффективность вычислений. Специализированное программное решение, ориентированное, например, на специфику работы процессора, может быть более эффективным. Кроме того, объектно-ориентированная организация не обеспечивает физической корректности вычислений. Однако существование и развитие большого программного комплекса невозможно без его объектно-ориентированной организации. Объектно-ориентированная организация — это типизация объектов сцены и рендеринга и формирование базовых классов этих объектов. Отличие базового класса объекта сцены или рендеринга от частного (производного) класса заключается в том, что базовый класс не несет в себе никакой специфики объекта. Например, базовый класс сферической поверхности не несет никакой информации о параметрах ее формы, однако он может ответить на более общие вопросы, например, с какой стороны поверхности находится заданная точка или пересекает ли луч данную поверхность. В результате все базовые классы объектов сцены и рендеринга не несут никакой частной информации о структуре и организации производного объекта и все объекты сцены и рендеринга становятся однородными с точки зрения их базовых интерфейсов. На рисунке 2 показан принцип взаимодействия объектов сцены с рендерингом.
Рис. 2. Общая схема взаимодействия объектов сцены
с вычислительной моделью рендеринга
Все объекты сцены и рендеринга взаимодействуют исключительно на уровне базовых интерфейсов, при этом реализация базового интерфейса для объекта конечного типа должна учитывать всю специфику данного объекта и обеспечивать максимальную эффективность и физическую корректность вычислений. Например, трассировка лучей в сцене, содержащей геометрические объекты различных типов, это процесс нахождения точек пересечения лучей с поверхностями сцены. Поэтому с точки зрения интерфейса базовых объектов геометрии сцены и трассировщика лучей тип геометрического объекта совершенно не важен, а важен факт самого пересечения и дополнительная обобщенная информация о свойствах поверхности в точке пересечения (дистанция до поверхности, локальная нормаль и т.п.).
Хотя реализация поведения объекта находится в конечном (производном) классе, она не может обеспечить всю эффективность и «физичность» вычислений. Базовый класс должен быть разработан таким образом, чтобы его интерфейс передавал все физические характеристики модели. Например, если объект обеспечивает поляризационное преобразование световых лучей, то базовый интерфейс должен включать поляризационную составляющую светового излучения. Поэтому при разработке базового программного интерфейса необходимо четко сформулировать ограничения модели рендеринга. Для моделирования фотореалистичных изображений сцен, как правило, достаточно ограничиться спектральной лучевой моделью, включающей поляризационную составляющую в виде вектора Стокса. Принятая модель должна поддерживаться всеми объектами сцены и рендеринга. Применяя ограничения (например, установленные выше), мы должны понимать, что такие эффекты, как интерференция и дифракция исключаются из процесса построения изображения, и если даже эти эффекты реализованы в ряде производных классов, то действие этих эффектов будет локальным и может потеряться в общем процессе построения изображения. Что касается вычислительной эффективности объектно-ориентированного решения, то оно, как правило, ограничено эффективностью реализации конечных объектов модели сцены и рендеринга.
Рассмотрим, какие преимущества дает объектно-ориентированная организация модели сцены и рендеринга. Основное преимущество — это минимизация затрат на модификацию, развитие и расширение моделей объектов сцены и рендеринга. Простейший пример это добавление нового конечного объекта в сцену. Например, у нас имеется базовый класс геометрических объектов и необходимо добавить к уже имеющимся реализациям геометрических объектов торическую поверхность. В данном случае достаточно реализовать интерфейсы нахождения точки встречи луча с поверхностью и определение принадлежности точки внешнему или внутреннему полупространству объекта. При этом программные изменения минимальны и никакие другие программные реализации (объектов сцены и рендеринга) не затрагиваются.
Обязательным условием проектирования объектно-ориентированных программных интерфейсов является детальная проработка всех возможных случаев программного взаимодействия объектов сцены и рендеринга. Очевидно, что перепроектирование программного интерфейса приедет к огромным затратам, связанным с перепрограммированием всех программных реализаций конечных классов объектов сцены и рендеринга, которые были затронуты в результате модификации программного интерфейса. Детальная проработка программных интерфейсов так же требует минимизации количества интерфейсов. Избыточные интерфейсы, с одной стороны, требуют дополнительных усилий для их реализации, а с другой стороны это программный шум, который в дальнейшем приводит к усложнению поддержки и развития всего программного продукта.
Отдельный аспект объектно-ориентированной организации — это поддержка технологий параллельных и распределенных вычислений. Схема взаимодействия объектов сцены и рендеринга зависит от вычислительного метода и, если за основу принимается стохастический подход, то схема приобретает вид, показанный на рисунке 3.
Рис. 3. Схема
взаимодействия объектов сцены и
рендеринга для
случая распределенных и параллельных вычислений
В данной схеме клиент инициализирует ряд однородных независимых расчетов на каждом сервере, а сервер, при необходимости, запускает расчет на отдельных процессах сервера. Если взаимодействие сервера и клиента однородно и его унификация не вызывает никаких проблем, то распределение вычислений между процессами одного сервера зависит от его архитектуры, что затрудняет его объектно-ориентированную организацию на базе абстрактных программных интерфейсов. Например, единый программный интерфейс для CPU и GPU процессоров практически невозможен без снижения эффективности вычислений.
Естественно, алгоритмическая реализация всех интерфейсов должна быть максимально эффективна, а организация взаимодействий объектов рендеринга на уровне базовых интерфейсов обеспечивает возможность:
- Во-первых, используя готовую элементную базу объектов сцены, расширять и строить новые модели рендеринга (например, используя различные комбинации прямой и обратной, детерминистической и стохастической трассировок лучей), ориентированные на решение конкретного класса задач. Например, построение фотореалистичных изображений, учитывающих сложные условия освещения или эффекты рассеивания, возникающие в объективах приемных устройств.
- Во-вторых, сохраняя готовые модели рендеринга, наполнять реализацию базовых интерфейсов моделей объектов сцены и рендеринга новыми физическими эффектами и алгоритмическими решениями. Например, базовый интерфейс геометрической поверхности, реализованный для случая треугольной сетки, при необходимости может быть расширен для случая аналитической или сплайн поверхности. Или базовый интерфейс преобразования лучей на поверхности, реализованный для случая двунаправленной функции рассеивания поверхности, может быть расширен моделями подповерхностного или дифракционного рассеивания.
Применение объектно-ориентированной модели рендеринга позволяет создать адаптивную и высокоэффективную систему компьютерного моделирования фотореалистичных изображений трехмерных сцен. Объектно-ориентированное построение данной системы дает возможность оптимизировать алгоритмы рендеринга для решения конкретных задач компьютерной графики и оптического моделирования. Кроме того, расширение реализации базовых интерфейсов новыми типами объектов сцены, например, импортируемыми из CAD систем, или создаваемыми специализированными моделлерами, или являющимися результатом программной реализации моделей, соответствующих новым технологическим процессам производства (например, производство рассеивающих микро- и нано-структур), расширяет физические возможности и аккуратность компьютерного моделирования изображений трехмерных сцен.
Объектно-ориентированная организация модели рендеринга охватывает следующие аспекты работы и взаимодействия программных компонентов модели:
· Базовые программные интерфейсы взаимодействия световых лучей с объектами сцены. Данные интерфейсы являются основополагающими с точки зрения физической корректности и эффективности вычислительной модели рендеринга, поскольку, если физический эффект напрямую не включен в базовый интерфейс объекта сцены, то и рендеринг не в состоянии обеспечить физическую реализацию данного эффекта. Основными объектами сцены являются: геометрические объекты, ответственные за нахождение точки пересечения луча с границей объекта; источники излучения, позволяющие испускать лучи с заданной плотностью и вычислять интенсивность и яркость излучения в заданной точке источника; приемники излучения, позволяющие испускать лучи наблюдателя и накапливать лучи, попадающие на приемник излучения; поверхностные и объемные оптические свойства объектов сцены, осуществляющие преобразование (отражение, преломление и рассеивание) световых лучей на геометрических поверхностях сцены и внутри оптических материалов и позволяющие вычислять значения яркости в точках рассеивания света.
· Базовые программные интерфейсы взаимодействия световых лучей со специальными оптическими элементами сцены. Данные интерфейсы определяют объекты сцены, которые не попадают под категорию стандартных объектов сцены, перечисленных выше, и зарезервированы для объектов сцены, являющихся результатом инновационных технологий. Например, микроструктурные рассеивающие объекты, специальные источники и приемники излучения. Данные объекты могут сочетать в себе свойства всех стандартных объектов сцены и поэтому интерфейс данных объектов является комбинацией интерфейсов всех возможных объектов сцены, а конкретная реализация затрагивает только необходимую функциональную часть объекта. Например, объект микроструктурного рассеивания реализует только интерфейсы геометрического объекта и его оптических свойств. Нереализованные интерфейсы оптических свойств среды, источника и приемника излучения будут указывать на то, что объект не обладает данными свойствами.
· Обязательным программным компонентом системы компьютерной графики является организация ввода и модификации исходных данных. Поскольку направления ввода данных могут быть достаточно произвольными (например, импорт данных из CAD систем, специализированных установок изменения оптических свойств поверхностей, измерения световых характеристик источников света и т.п.), то абсолютная унификация интерфейсов данных невозможна. Однако система компьютерной графики в конечном счете переводит исходные данные во внутреннее представление и на данном этапе унификация и создание базовых интерфейсов становятся возможными. Хотя необходимость унификации интерфейсов в данном случае не является очевидной, эта необходимость обуславливается унификацией преобразования исходного представления данных в представление данных (базовых интерфейсов), используемое в процессе вычислений (рендеринга).
· Базовый интерфейс рендерера (методы построения изображения), состоящий из двух основных уровней. Программные методы верхнего уровня позволяют запустить процесс построения изображения, осуществлять его промежуточный анализ (визуализировать промежуточное изображение, анализировать точность и прогресс вычисления), прервать моделирование, получить результирующее изображение (включая все статистические характеристики, включая оценку точности построения изображения) и при необходимости продолжить вычисления. Программные методы нижнего уровня — это собственно базовые методы алгоритма рендеринга. Они включают методы трассировки лучей, накопления карт освещенности, яркости и т.п., анализа точности, расчета световых характеристик (яркости, освещенности и т.п.) и т.д. Изменение реализации методов нижнего уровня равносильно изменению алгоритма рендеринга и позволяет переориентировать рендеринг на решение светотехнических задач, например, проектирование осветительных систем или анализ рассеивания света в оптических приборах. При этом все интерфейсы рендеринга полностью сохраняются.
3. Применение двунаправленной стохастической трассировки лучей для решения уравнения рендеринга
Разработка программных интерфейсов рендеринга должна
базироваться на выбранном подходе решения уравнения рендеринга. Уравнение
рендеринга определяет яркость в направлении наблюдения как сумму собственной
яркости наблюдаемого объекта и яркости, рассеянной данным объектом в
направлении наблюдения [4]. Для статических сцен уравнение рендеринга,
определяющее яркость объекта в точке 
, направлении 
и для
цветовой компоненты с, можно записать следующим образом:
(1)
где:
– собственная яркость объекта в точке наблюдения,
– пропускание (прозрачность) среды между наблюдателем
и точкой наблюдения,
– функция двунаправленного рассеивания от источника
освещения в направлении 
на наблюдателя,
– локальная освещенность объекта в точке наблюдения
по направлению 
, созданная источником света в телесном угле dω.
Основным методом решения уравнения рендеринга является метод трассировки лучей. В лучевом подходе интегрирование по сфере выполняется посредством трассировки лучей в направлении всех возможных источников излучения, и уравнение рендеринга принимает следующий вид:
(2)
где:
– локальная освещенность объекта в точке наблюдения
по направлению , созданная i-м лучом.
Данное интегрирование может быть проведено детерминистическим или стохастическим способами. Кроме того, интегрирование может проводиться при помощи трассировки как прямых лучей (от источников света), так и обратных лучей (от приемников излучения). На данный момент наиболее эффективным и универсальным решением является двунаправленная стохастическая трассировка лучей, когда составляющая прямой яркости вычисляется на трассах обратных лучей, а составляющая вторичной яркости – в областях пересечения трасс прямых и обратных лучей. Кроме того, данное решение является физически корректным, поскольку учитывает условия освещения и наблюдения в точках интегрирования яркости и в состоянии корректно выполнить интегрирование бесконечного цикла лучей на трассе от источников освещения до наблюдателя [5-7].
Двунаправленная стохастическая трассировка лучей схематично представлена на рисунке 4.
Рис. 4. Двунаправленная стохастическая трассировка лучей
Пример алгоритма двунаправленной стохастической трассировки лучей представлен на рисунке 5:
Рис. 5. Пример алгоритма двунаправленной стохастической трассировки лучей
Приведенный алгоритм показывает частную схему процесса построения изображения, ориентированную на посторенние карт видимости объектов сцены. Возможно и обратное решение, заключающиеся в том, что первоначально трассируются световые луче (лучи, испущенные источниками света), а лучи зрения собирают вторичную яркость со световых лучей. Однако содержание (интерфейсы) программных компонентов что в первом, что во втором случае практически одинаково и это позволяет нам применить принципы объектной организации к формированию базовых алгоритмов и интерфейсов рендеринга. Такое решение позволяет легко переключаться с прямой на обратную трассировку лучей и комбинировать результаты вычислений наиболее оптимальным образом для решения задач физически корректной визуализации изображения.
Основные программные интерфейсы в данном случае это:
· Методы трассировки лучей (прямых и обратных).
· Методы формирования и обработки фотонных карт (карт прямых и обратных лучей).
· Методы вычисления прямых, каустических и диффузных яркостей точек изображения.
· Методы оценки качества изображения.
Основополагающими методами модели рендеринга, отвечающими за физическую корректность визуализации изображения, являются методы трассировки лучей. Методы трассировки лучей напрямую базируются на методах объектов сцены. То есть, интерфейс методов объектов сцены полностью определяется тем, какие возможности имеет алгоритм трассировки луча. Однако справедливо и противоположное утверждение, алгоритм трассировки луча должен строиться исходя из физических возможностей (выраженных в виде программного интерфейса) объектов сцены. То есть алгоритм трассировки луча может реализовать только те функции, которые заложены в программных интерфейсах объектов сцены.
Фактически, алгоритм трассировки луча и программные интерфейсы объектов сцены формируются совместно, исходя из требований к «физичности» процесса визуализации. На рисунке 6 приведен базовый алгоритм стохастической трассировки лучей (в случае отсутствия поляризации света алгоритмы прямой и обратной стохастической трассировки лучей практически идентичны):
Рис. 6. Базовый алгоритм стохастической трассировки лучей
Данный алгоритм использует метод «русской рулетки» как одну из разновидностей метода Монте-Карло. Основное преимущество данного метода: он позволяет математически корректно решать уравнение рендеринга (2), являющееся бесконечной суммой сегментов трассы луча. С алгоритмической точки зрения специфика данного решения — это:
· Трассируется только один луч (рекурсивное деление луча на отдельные лучи не допускается).
· Поглощение луча это событие, которое приводит к окончанию его трассировки.
Остальные методы рендеринга, такие как вычисление и обработка фотонных карт, вычисление яркостей, формирование изображения и оценка точности, не влияют на физическую корректность визуализации и отвечают главным образом за скорость сходимости изображения к заданному уровню качества.
4. Базовые интерфейсы основных объектов сцены
Организация данных сцены (как программный интерфейс, так и собственно данные сцены) для пользовательского программного интерфейса и для выполнения светотехнических расчетов принципиально различны. Если данные пользователя это скорее «сырые» данные, представленные в том виде, в котором они оптимальны для визуализации и модификации пользователем, то для выполнения светотехнических расчетов данные обрабатываются и переводятся в специальное представление, которое обеспечивает максимальную эффективность вычислений. Естественно, программный интерфейс для двух представлений объектов сцены будет различен.
4.1. Модель пользователя
Источники формирования данных объектов сцены могут быть различны. Во-первых, это может быть импорт данных из внешних источников (например, геометрия объектов сцены поступает из CAD систем, двунаправленные функции рассеивания (ДФР) поверхностей и пространственно-гониометрические параметры источников света поступают со специализированных измерительных установок, а параметры камер определяются по данным из соответствующих каталогов). Поскольку этот сорт данных очень разнороден, то говорить о какой-либо унификации и объектно-ориентированной организации здесь невозможно. Все эти данные должны быть приведены в более унифицированное представление сцены. Рисунок 7 иллюстрирует процесс преобразования внешних данных во внутреннее представление данных сцены.
Рис. 7. Преобразование исходных данных в представление сцены
На данном этапе используются специализированные конверторы, которые проектируются для каждого типа внешних данных отдельно и переводят импортируемые данные во внутреннее представление сцены. Естественно, появление нового типа данных требует проектирования нового конвертора.
Второй источник формирования исходных данных это собственно пользовательский интерфейс. Унификация объектов сцены в пользовательском интерфейсе затруднена главным образом в связи с обилием различных типов исходных данных и способов их представления. Поэтому объектом унификации становятся не типы исходных данных, а сами исходные данные [8]. То есть исходные данные разбиваются на элементарные сущности, которыми могут быть простые числа (целые или вещественные), переключатели, флаги, вектора, матрицы, таблицы и т.п. элементарные объекты. Для обеспечения графического пользовательского интерфейса каждый элементарный объект имеет средства для собственной визуализации и редактирования, а для обеспечения программного интерфейса – средства доступа (чтение и запись) к этим элементарным данным. Рисунок 8 демонстрирует диалог редактирования свойств части геометрии сцены. Все элементарные поля данного диалога являются элементарными сущностями объекта геометрических свойств сцены.
Рис. 8. Диалог редактирования свойств части геометрии сцены
Естественно, не все объекты сцены могут быть выражены в виде элементарных сущностей. Большинство объектов сцены включают в себя другие (не элементарные) объекты сцены. Поэтому объект сцены представляет собой сущность, аналогичную элементарной и состоящую из других элементарных и составных сущностей. Визуализация такой составной сущности представляет собой дерево объектов, содержащихся в этом объекте. Естественно, каждая из составных сущностей имеет соответствующие средства визуализации, редактирования и доступа к ее содержимому. Используя рекурсивное сканирование данного дерева, можно для любого объекта найти все его элементарные данные. Рисунок 9 иллюстрирует процесс сканирования дерева сцены в графическом интерфейсе пользователя.
Рис. 9. Сканирование дерева сцены в графическом интерфейсе пользователя
Поскольку даже элементарные данные сцены могут быть достаточно сложными, например, быть параметрическими объектами и зависеть от данных других объектов сцены или каких-либо внешних условий, то простые средства графического редактирования элементарных параметров сцены могут быть недостаточными для определения таких зависимостей. Наиболее оптимальным представлением таких сложных объектов сцены является скрипт. С помощью скриптового представления, как элементарного языка программирования, можно описать практически любые зависимости между объектами сцены. С программной точки зрения, скрипт интегрируется с понятием сущности объекта сцены. То есть, новая сущность может быть определена в скрипте и доступ (чтение и запись) к параметрам сущности объекта сцены также реализуется в скрипте. В результате, пользователь может создавать собственные параметрические объекты сцены, представленные в виде классов скриптовых объектов, или проектировать внешние скрипты, модифицирующие сцену и выполняющие заданный список светотехнических расчетов. На рисунке 10 представлен пример создания цилиндрического параметрического объекта с помощью Python скрипт. Объект имеет 4 параметра (радиус, длина, радиальное и продольное разбиение) и создает соответствующий объект треугольной сетки.
Рис. 10. Пример определения цилиндрического объекта с помощью Python скрипт
Объектно-ориентированная организация данных пользовательского интерфейса основана на понятии сущности объекта (элементарной или составной). Сущность — это абстрактный класс, базовый интерфейс которого обеспечивает основные операции взаимодействия (пользовательского и программного) с параметрами объекта сцены:
· Визуализация данных в виде элементарных данных (чисел, векторов, матриц, таблиц, диалогов и т. п.) или дерева данных сложного объекта.
· Средства графического редактирования и извещения всех зависимых программных объектов о произведенных изменениях.
· Программный доступ с возможностью чтения и записи элементарных данных или составляющих сложного объекта.
· Поддержка скрипта на уровне создания собственных сущностей, определенных в скрипте, и соответствующие возможности чтения записи параметров объекта сцены в скрипте.
В результате такой организации все данные сцены выглядят абсолютно однородно, что обеспечивает доступ к данным (как программный, включая скрипт, так и на уровне пользовательского интерфейса) на уровне базовых интерфейсов объектов сцены. Такая программная организация позволяет создавать новые объекты сцены на уровне базовых интерфейсов, не затрагивая при этом внутреннюю сущность объекта.
Поскольку данная объектно-ориентированная организация данных пользователя практически не ограничивает количество их типов, то возникает сложность преобразования данных пользователя в вид, оптимальный для светотехнических вычислений. Основная проблема заключается в том, что данные пользователя не могут быть преобразованы в данные, используемые в вычислениях, поскольку они не обязаны ничего знать о применяемых вычислительных методах. Поэтому, объекты вычислительной модели создают себя сами, имея на входе данные пользователя. Естественно, объекты вычислительной модели не в состоянии поддержать все типы данных пользователя, и поэтому, вводится ограничение количества типов данных пользователя, которые понимают вычислительные модели. Этот ограниченный (промежуточный) уровень данных называется уровнем канонических данных. Канонические данные это структуры данных ограниченного набора типов, для которых, с одной стороны, объекты данных пользователя имеют соответствующие конверторы, а с другой стороны, объекты вычислительной модели умеют создавать себя из этих данных. В результате процесс создания данных вычислительной модели приобретает вид, показанный на рисунке 11.
Рис. 11. Создание объектов вычислительной модели
4.2. Вычислительная модель
Несмотря на то, что алгоритм трассировки лучей, приведенный в предыдущей главе, достаточно схематичен, видно, что работа с конкретными объектами сцены осуществляется на уровне базовых интерфейсов. Например, при определении длины свободного пробега в среде сцены алгоритм трассировки лучей не знает (и не должен знать), чем вызвано ограничение данной длины (поглощением в среде, рассеиванием на микрочастицах среды, плавным изменением траектории луча в среде с переменным показателем преломления или каким-нибудь другим эффектом). Аналогично, при поиске пересечения траектории луча с одним из геометрических объектов сцены алгоритм не знает (и не должен знать), геометрический объект какого типа оказался на пути луча (элемент треугольной сетки, поверхность сплайна, аналитическая поверхность и т.п.). Алгоритму достаточно знать координаты точки пересечения луча с поверхностью, нормаль к поверхности в точке пересечения, ссылку на оптические свойства поверхности и ряд другой вспомогательной информации. Взаимодействие алгоритма трассировки лучей (как и других программных компонентов рендеринга) с объектами сцены происходит на уровне базовых интерфейсов. Данный тип взаимодействия имеет два неоспоримых преимущества:
· Возможность изменения реализации объектов сцены без изменения алгоритма работы программы. Например, изменение способа хранения данных, определяющих двунаправленную функцию рассеивания, ограничивается данным объектом и не затрагивает компоненты рендеринга.
· Возможность реализации принципиально новых объектов сцены без изменения алгоритма работы программы. Например, если текущее программное решение допускает определение геометрии сцены только в виде треугольной сетки, то включение аналитического представления геометрии сцены не вызывает каких-либо изменений в программе рендеринга. Для того, чтобы добавить новый тип геометрии, достаточно лишь реализовать базовый интерфейс геометрии сцены для данного типа аналитической геометрии.
Реализация алгоритмов на уроне базовых интерфейсов приводит к тому, что рендеринг становится не зависимым от данных сцены и зависит только от программных интерфейсов ее объектов. Как следствие упрощается алгоритм и программная реализация рендеринга, поскольку отпадает необходимость проверки типов объектов сцены и ветвлений алгоритма в зависимости от типа объекта сцены (упрощение алгоритма всегда приводит к большей надежности и устойчивости работы программы).
Естественно, проектирование базовых интерфейсов объектов сцены непростая задача. Основная сложность данного проектирования заключается в том, что оно должно исходить не только из текущих потребностей рендеринга, но и основываться на понимании принципа физической корректности построения изображения, и интерфейсы объектов сцены и рендеринга должны отражать физическую сущность процесса распространения света в сцене и физические принципы взаимодействия светового излучения с объектами сцены. Нарушение данного принципа приводит к тому, что появление нового физического эффекта в алгоритме рендеринга требует не только полного перепроектирования большинства объектов сцены (их интерфейсов и программной реализации), но и перепроектирования самой программы рендеринга. Например, если алгоритм рендеринга был рассчитан только на прямолинейное распространение света, то появление рассеивающей среды в списке объектов сцены требует перестройки алгоритмов, интерфейсов и реализации всех объектов рендеринга, связанных с распространением света в среде. Поэтому программный интерфейс рендеринга и объектов сцены это своего рода парадигма, на которой строится процесс построения физически корректного изображения. То есть модель рендеринга и степень его физической корректности полностью определяется программными интерфейсами его компонентов.
Рассмотрим основные типы объектов сцены и их базовые интерфейсы. Основными типами объектов сцены, участвующими в трассировке лучей и построении изображения, являются:
· Геометрия сцены. Базовыми методами объекта данного типа являются:
o Поиск пересечения луча с поверхностью. Кроме факта пересечения данный метод должен возвращать дополнительную информацию (дистанцию до поверхности, нормаль в точке пересечения, ссылку на оптические свойства поверхности и т.п.).
o Определение принадлежности точки сцены или начала луча внутренней области геометрического объекта.
Рисунок 12 схематично иллюстрирует данные базовые методы:
Рис. 12. Базовые методы геометрии сцены
Для ускорения трассировки лучей геометрия может иметь пространственную иерархию [9], в которой каждая область пространства хранит информацию о геометрических объектах внутри этой области. Данная иерархия может быть многоуровневой, то есть внешний уровень иерархии — это пространственное распределение объектов сцены, а внутренние уровни иерархии это пространственное распределение элементов геометрии объекта. Внутреннее разбиение объекта это внутреннее дело каждого объекта и потому не предполагает внешнего программного интерфейса. Внешнее разбиение объекта требует специального базового интерфейса, который возвращает внешнюю границу объекта.
· Источники света. Базовый интерфейс источников света для алгоритма двунаправленной стохастической трассировки луча имеет вид:
o Определение мощности излучения источника света.
o Формирование случайного луча, испускаемого источником света в соответствии с заданной функцией распределения вероятностей (функция распределения вероятностей может быть определена либо снаружи, либо внутри объекта источника света).
o Вычисление интенсивности излучения источника света в заданном направлении.
o Вычисление яркости источника света в заданной точке и в заданном направлении.
o Поиск пересечения луча с источником света (для ускорения вычислений источники света могут быть включены в пространственную иерархию геометрических объектов сцены).
Рисунок 13 схематично иллюстрирует основные базовые методы источника света:
Рис. 13. Базовые методы источника света
· Приемник излучения. Базовый интерфейс приемника излучения для алгоритма двунаправленной стохастической трассировки луча имеет вид:
o Накопление световых лучей, приходящих от источников света.
o Формирование вторичных лучей (испускание луча с поверхности приемника излучения осуществляется в соответствии с заданной функцией распределения вероятностей, определенной либо снаружи, либо внутри объекта). Этот метод говорит о том, что приемник излучения может рассматриваться и как источник вторичного излучения.
o Вычисление значений световых величин (освещенность, яркость, интенсивность) для луча, заданного направлением и координатами начальной точки на приемнике излучения.
Рисунок 14 схематично иллюстрирует основные базовые методы приемника излучения:
Рис. 14. Базовые методы приемника излучения
· Оптические свойства поверхности. Базовый интерфейс оптических свойств поверхности для алгоритма двунаправленной стохастической трассировки луча содержит два основных метода:
o Вычисление направления рассеянного луча на поверхности (направление рассеивания определяется двунаправленной функцией рассеивания и может иметь «зеркальный» и «диффузный» характер).
o Вычисление яркости (первичной и вторичной).
Рисунок 15 схематично иллюстрирует основные базовые методы оптических свойств поверхности:
Рис. 15. Базовые методы оптических свойств поверхности
· Свойства оптических сред. Базовый интерфейс оптических сред для алгоритма двунаправленной стохастической трассировки луча имеет вид:
o Преломление / отражение луча на гладкой границе раздела двух сред (так называемое «Френелевское» отражение).
o Вычисление прямолинейной длины свободного пробега луча (ограничение длины свободного пробега может быль вызвано поглощением, рассеиванием на микрочастицах, флюоресценцией или переменным показателем преломления среды и т.п.).
o Вычисление цветового ослабления луча на заданной дистанции.
o Перенос луча на заданную дистанцию.
o Преобразование направления луча в среде (рассеивание на микрочастицах, флюоресценция, искривление трассы, вызванное переменным показателем преломления среды и т.п.).
Рисунок 16 схематично иллюстрирует основные базовые методы свойств оптических сред:
Рис. 16. Базовые методы свойств оптических сред
Для упрощения модели сцены и придания реализма изображению сцены системы компьютерной графики используют текстуры. Текстуры могут варьировать оптические свойства поверхности, например, менять цвет диффузного отражения, менять геометрию поверхности, например, варьировать нормаль к поверхности, менять яркость источника света и т.п.
С точки зрения объектно-ориентированной организации текстура состоит из двух объектов, это, во-первых, оператор, проецирующий координаты точки или (и) вектор направления луча в систему координат текстуры и, во-вторых, собственно текстура (может быть изображение, функция или процедура). Текстура осуществляет модификацию объекта, к которому она прикреплена.
Оператор проецирования и объект текстуры агрегированы внутрь объекта, к которому они прикреплены, и поэтому их программный интерфейс не виден в алгоритме рендеринга. Причина агрегирования текстуры внутрь конкретного объекта сцены заключается в том, что текстура оперирует со специфическими данными объектов сцены, скрытыми во внешнем программном интерфейсе.
Приведенный базовый программный интерфейс является достаточным для визуализации физически корректного изображения. Конечно, в реальной программной системе построения фотореалистичного изображения базовые интерфейсы объектов сцены несколько шире, что связано, главным образом, с алгоритмическими приемами, ориентированными на ускорение сходимости вычислений, однако, в рамках стохастического алгоритма трассировки лучей принципиально новых интерфейсов не существует.
5. Специальные оптические элементы и их программные интерфейсы
В ряде случаев, объекты сцены являются физически более сложными элементами и не могут быть описаны в рамках текущего объектно-ориентированного программного интерфейса. Возможное решение для таких объектов — это расширение объектно-ориентированной модели, создание новых типов объектов и т.п. Однако в большинстве случаев такой подход неоправдан, поскольку перепроектирование объектно-ориентированного программного интерфейса является слишком дорогим решением.
В качестве альтернативного решения данной проблемы предлагается использовать специализированные объекты, которые, с одной стороны, позволяют решать задачи физически аккуратного моделирования, а с другой стороны, могут быть интегрированы в существующую объектно-ориентированную систему фотореалистичной визуализации изображения. Для решения этой проблемы вводится концепция оптических элементов.
Оптический элемент – это объект программно-моделируемой оптической системы или устройства, который позволяет использовать оптически более сложные модели взаимодействия света с объектами сцены, чем модели, предлагаемые текущим объектно-ориентированным программным интерфейсом [2].
Оптический элемент расширяет функциональность систем компьютерной графики, но при этом не раскрывает собственную функциональность. Поэтому с точки зрения сцены оптический элемент – это «черный ящик», который принимает на вход лучи, преобразует их и затем выдает их назад программе построения изображения, трассирующей лучи в сцене. Схематично процесс взаимодействия лучей с оптическим элементом показан на рисунке 17.
Рис. 17. Схема распространение лучей в сцене, содержащей оптический элемент
Поскольку оптический элемент является «черным ящиком», его содержимое скрыто от рендеринга, то есть изображение сцены не будет содержать изображения деталей оптического элемента. Такое поведение напоминает взгляд сквозь линзу. Мы не видим поверхности линзы, но видим изображение, которое она формирует.
По местоположению в сцене оптический элемент может быть независимым компонентом с собственной внешней границей или быть присоединенным к поверхности сцены. В первом случае внешняя граница оптического элемента позволяет трассировщику лучей детектировать его местоположение в сцене, и если луч пересекает его внешнюю границу, то происходит поиск пересечения луча с собственно «черным ящиком». Если пересечение было найдено, то включается функциональность оптического элемента, которая меняет параметры луча (состояние (поглощен или не поглощен), цвет и состояние поляризации) и переносит его (с новыми координатами начала и направления) на выход из «черного ящика». На рисунке 18 представлен пример оптического элемента, являющегося линзовой камерой.
Рис. 18. Оптический элемент в виде линзовой камеры
В данном примере линзовый объектив типа «рыбий глаз» и приемник излучения объединены в единый оптический элемент, имеющий собственную внешнюю границу в сцене.
Если оптический элемент присоединен к поверхности сцены, то трассировщик лучей детектирует его после попадания луча на соответствующую поверхность, после чего идет проверка на попадание луча в область «черного ящика». Далее включается функциональность оптического элемента, которая меняет параметры луча (состояние (поглощен или не поглощен), цвет и состояние поляризации) и переносит его (с новыми координатами начала и направления) на выход из «черного ящика». При этом координата начала луча переносится на поверхность, к которой он был присоединен. На рисунке 19 представлены примеры микроструктурных рассеивающих оптических элементов.
Рис. 19. Микроструктурные рассеивающие оптические элементы
Особенностью данных элементов является сложность рассеивающей микроструктуры, содержащей десятки (и сотни) миллионов независимых рассеивающих геометрических элементов сложной формы.
В обоих примерах внутренняя структура оптического элемента несущественна с точки зрения визуального восприятия. В первом случае линза является оператором, который преобразует излучение, падающее на поверхность приемника, а во втором случае размер микроэлементов на поверхности светопроводящей пластины настолько мал, что визуально невидим.
С точки зрения программной реализации оптический элемент это независимая специализированная сцена и ее базовый программный интерфейс должен покрывать все базовые интерфейсы объектов сцены:
· Поиск пересечения луча с границей оптического элемента.
· Преобразование луча (состояние (поглощен или не поглощен), цвет и состояние поляризации, направление и координаты) на оптическом элементе.
· Вычисление мощности излучения оптического элемента (как источника света).
· Формирование случайного луча, испускаемого оптическим элементом (как источником света).
· Вычисление интенсивности излучения оптического элемента (как источника света) в заданном направлении.
· Вычисление яркости оптического элемента (как источника света) в заданной точке и в заданном направлении.
· Накопление световых лучей (как приемник излучения), распространяющийся от источников света.
· Формирование вторичного луча (как с приемника излучения).
· Вычисление значений световых величин (освещенность, яркость, интенсивность), сохраненных на оптическом элементе (как на приемнике излучения), для луча, заданного направлением и координатами начальной точки.
Необходимо отметить, что базовый интерфейс оптического элемента не предполагает методов расчета первичной и вторичной яркости, поскольку оптический элемент «прозрачен» для падающих на него лучей. Кроме того, методы, соответствующие распространению луча в среде, так же отсутствуют в оптическом элементе, поскольку распространение луча внутри «черного ящика» есть внутренние дело оптического элемента.
6. Объектно-ориентированная реализация метода двунаправленной трассировки лучей
Объектно-ориентированный алгоритм двунаправленной стохастической трассировки лучей был реализован в программном комплексе Lumicept [10]. Отличительными чертами разработанной программной модели, с точки зрения физической корректности моделирования, являются:
· Реализация моделей объектов сцены и алгоритмов трассировки лучей в спектральном пространстве.
· Реализация поляризационных вычислений в моделях объектов сцены и методах прямой трассировки луча. Это позволяет физически корректно вычислять вторичную яркость поляризованного излучения при ее наблюдении в неполяризованном пространстве.
· Включение моделей оптических элементов как специальных объектов сцены и их поддержка в методах прямой и обратной стохастической трассировки лучей.
Реализованная модель позволяет вычислять фотореалистичные изображения геометрически и оптически сложных сцен. В качестве примера приводятся результаты моделирования изображения экрана жидкокристаллического дисплея в салоне автомобиля, показанного на рисунке 20, при различных условиях внешнего освещения.
Рис. 20. Жидкокристаллический дисплей в салоне автомобиля
В качестве источников освещения использовались источники салонного освещения автомобиля и внешнее освещение, определенное с помощью HDRI источника света, показанного на рисунке 21. Мощность HDRI источника света соответствовала мощности солнца и неба в яркий солнечный день.
Рис. 21. Внешний источник освещения
Схематично, модель жидкокристаллического дисплея с торцевой подсветкой показана на рисунке 22. Модель включает светодиодные источники, излучающие свет в торец светопроводящей пластины, на дне которой расположена рассеивающая микроструктура. Микроструктура была задана с помощью соответствующего оптического элемента, присоединенного к нижней поверхности светопроводящей пластины. Пластину покрывает ряд светорассеивающих пленок и фильтров, которые замыкаются поляризационным фильтром и активной матрицей на жидких кристаллах (в качестве TFT матрицы при моделировании использовалась обычная текстура, модулирующая цвет диффузного пропускания).
Рис. 22. Модель жидкокристаллического дисплея
Результаты моделирования при различных условиях внешнего и салонного освещения автомобиля представлены на рисунках 23 – 26.
На рисунке 23 показаны результаты моделирования для случая, когда использовалось исключительно внешнее освещение, формируемое HDRI источником света.
Рис. 23. Результаты моделирования при внешнем HDRI освещении
На рисунке 24 показаны результаты моделирования в случае, когда салонное освещение использовалось совместно с внешним освещением, формируемым HDRI источником света.
Рис. 24. Результаты моделирования при салонном
и HDRI освещении одновременно
На рисунке 25 показаны результаты моделирования для случая исключительно салонного освещения.
Рис. 25. Результаты моделирования при салонном освещении
На рисунке 26 показаны результаты моделирования в случае отсутствия какого-либо освещения.
Рис. 26. Результаты моделирования при отсутствии внешнего освещения
Шум на изображении экрана дисплея был вызван спецификой работы алгоритма двунаправленной стохастической трассировки лучей и объясняется относительно малой мощностью (по отношению к внешнему освещению) светодиодных источников света жидкокристаллического дисплея.
7. Заключение
В рамках программного комплекса Lumicept был реализован объектно-ориентированный алгоритм двунаправленной стохастической трассировки лучей. Данный алгоритм базируется на физически корректных моделях сцены и на уровне базовых интерфейсов позволяет осуществить физически корректный и эффективный рендеринг оптически и геометрически сложных сцен. Введенная концепция оптического элемента расширяет объектно-ориентированную модель рендеринга специальными объектами, которые не могут быть представлены в рамках базовой модели сцены.
Объектно-ориентированная модель рендеринга была реализована в спектральном пространстве, а поляризационные эффекты были поддержаны только для прямой трассировки лучей. Хотя данная модель и не является в полном смысле физически корректной, однако она в состоянии обеспечить физически корректное моделирование сцен, не содержащих поляризационные элементы в пространстве наблюдения (вычисление первичной яркости), все поляризационные эффекты сосредоточены в пространстве, формирующем вторичную яркость.
8. Благодарности
Работа поддержана грантами РФФИ № 12-01-00560 и 13-01-00454, а также компанией Integra Inc.
Авторы выражают свою признательность В.Г. Соколову и А.А. Гарбулю за предоставленные примеры.
Список литературы
[1] Khodulev A.B., Kopylov E.A., Zdanov D.D. Requirements to the Scene Data Base // Proc. 8th International Conference on Computer Graphics and Visualization, Russia, Moscow, September 7-11, 1998, p. 189-195.
[2] Волобой А.Г., Галактионов В.А., Ершов С.В., Жданов Д.Д. Оптические элементы как средство расширения функциональности программ оптического моделирования // Труды 16-ой межд. конф., ГрафиКон' 2006, Россия, Новосибирск, июль 1-5, 2006, с. 182-191.
[3] Гради Буч и др. Объектно-ориентированный анализ и проектирование с примерами приложений (UML 2). Третье издание. // «Вильямс», Москва – 2010.
[4] Kajiya, J. T. The rendering equation / Siggraph 1986: 143.
[5] Henrik Wann Jensen, Per Christensen. High quality rendering using ray tracing and photon mapping /SIGGRAPH '07.
[6] Matt Pharr, Greg Humphreys. Physically Based Rendering - From Theory to Implementation // Morgan Kaufmann, 2004.
[7] Toshiya Hachisuka and Henrik Wann Jensen. Stochastic progressive photon mapping. ACM Trans. Graph., 28(5):1–8, 2009.
[8] Андрей Александреску. Современное проектирование на С++. // «Вильямс», Москва – 2004.
[9] Ingo Wald, Carsten Benthin, and Philipp Slusallek. A Simple and Practical Method for Interactive Ray Tracing of Dynamic Scenes / report, Saarland University, 2002.
[10] Integra. URL: http://www.integra.jp/en/index.html
Object-oriented
model of photorealistic
vizualizatioln of complex scenes
D. Zhdanov1, 2, 3, S. Ershov1, N. Deryabin1
1 Keldysh Institute for Applied Mathematics RAS, Moscow, Russian Federation
2 St. Petersburg National Research University ITMO, St. Petersburg, Russian Federation
3 Vavilov State Optical Institute, St. Petersburg, Russian Federation
Abstract
The article is devoted to design of the object-oriented model of physically accurate visualization of the geometrically and optically complex scenes. The actuality of the object-oriented organization becomes clear if we design complex platforms for accurate light simulations and photorealistic rendering. In this case, all extra efforts spent to object-oriented design of the rendering and its database are overplayed because of time to extend the database are significantly reduced. For example, the addition of new type of geometrical element to the database or modification of the algorithm of photon map processing do not touch other components of the scene and renderer and require any addition modification in the software package.
The article considers basic principles of the object-oriented organization to design software for photorealistic visualization of complex scenes and discriminates two main components of the objet-oriented model: scene database and renderer. The article introduces conception of basic interfaces, which restrict all interactions between scene objects and between scene objects and renderer. For scene database, two levels of basic interfaces are proposed. The first level is a level of the end user. This level of interfaces is reduced to interfaces of entities, which are data structures with standard interfaces for self-visualization, user and program data modification and interaction with script. The second level is a level of the light simulations. For basic types of scene objects (geometry, camera, observer, light sources and optical properties), the minimal interface providing accurate and efficient ray tracing and calculation of direct and indirect luminances was designed. Moreover, for scene objects with a special behavior like scattering micro-geometry or special lenses, the conception optical elements is introduced. The interface of the optical elements joins interfaces of all other scene object types. A photorealistic scene visualization applies bi-directional stochastic ray tracing which provides physically correct light transfer from light sources through scene to camera. The ray tracer and renderer are designed on object-oriented principles too and all interactions of ray tracer and renderer with scene database is restricted with the basic interfaces.
Object-oriented model of the scene database and photorealistic visualization solution based on the bi-directional stochastic ray tracing were implemented in Lumicept software package. As an example, the article shows a result of computer visualization of LCD display of car dashboard under different conditions of interior and exterior illumination. The main specific of the visualization is physically accurate light simulation, which takes into account all details of the LCD construction, including scattering microstructures, polarization filters and TFT matrix.
The developed object-oriented model of photorealistic visualization is based on physically correct scene models including spectral and polarization light ray transformation incorporated to the basic interfaces of the proper object types. The conception of the optical element allows extending this object-oriented scene database with special objects, which interface cannot be expressed in the frames of standard scene object type. As a difference from most of computer solutions, the object-oriented conception was implemented for whole software package that significantly simplifies its extension with new scene and ray tracing models.
Keywords: photorealistic visualization, scene, scene object, optical element, program interface, rendering, stochastic ray tracing, bi-directional ray tracing, physically accurate rendering.
References
[1] Khodulev A.B., Kopylov E.A., Zdanov D.D. Requirements to the Scene Data Base. Proc. 8th International Conference on Computer Graphics and Visualization, Russia, Moscow, September. pp. 7-11, 1998, p. 189-195.
[2] A. G. Voloboi, V. A. Galaktionov, E. A., Ershov S.V., Zhdanov D.D. Opticheskie elementy kak sredstvo rasshireniya funktsionalnosti programm opticheskogo modelirovaniya [Optical elements as a tool of a light simulation software extension[. Proc. 16th International Conference on Computer Graphics and Applications. GraphiCon’06, Russia, Novosibirsk, June 1-5, 2006, pp. 182-191.
[3] Grady Booch, etc. Obektno-orientirovannyy analiz i proektirovanie s primerami prilozheniy [Object-Oriented Analysis and Design with Applications]. 3rd edition. Addison-Wesley Professional publisher, 2007.
[4] Kajiya, J. T. The rendering equation. Siggraph 1986. p. 143.
[5] Henrik Wann Jensen, Per Christensen. High quality rendering using ray tracing and photon mapping. SIGGRAPH '07.
[6] Matt Pharr, Greg Humphreys. Physically Based Rendering - From Theory to Implementation. Morgan Kaufmann, 2004.
[7] Toshiya Hachisuka and Henrik Wann Jensen. Stochastic progressive photon mapping. ACM Trans. Graph., 28 (5):1-8, 2009.
[8] Andrei Alexandrescu. Sovremennoe proektirovanie na C++ [Modern C++ Design]. Addison-Wesley, 2001.
[9] Ingo Wald, Carsten Benthin, and Philipp Slusallek. A Simple and Practical Method for Interactive Ray Tracing of Dynamic Scenes, report, Saarland University, 2002.
[10] Integra. Available at: http://www.integra.jp/en/index.html