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

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

Более точный анализ производительности для нескольких систем под Autodesk 3ds Max на семи различных упрощенных сценариях был предложен в [1]. Чтобы решить проблему отличающихся эталонов, для каждой системы предлагалось использовать свой собственный эталон, получаемый именно этой системой за достаточно большое время и не содержащий шума. При этом считается, что изображения эталонов визуально совпадают — системы рендеринга отличаются лишь в «реализации отдельных незначительных моментов». Общий уровень яркости, геометрическая форма объектов на изображениях и характер освещения должны совпадать. Таким образом, в [1] фактически измеряется то, насколько быстро алгоритм и его реализация в системе рендеринга сходятся к своему собственному эталону.

Несмотря на то что сцен при таком подходе было значительно больше, чем в проводимых ранее сравнениях, данный набор вряд ли можно считать объективным. Кроме того, не были задействованы популярные в научном сообществе сцены, например L1.4, L1.5, L1.6, L2.2 (рис. 1), применяемые для выполнения хоть какого-либо сравнения. Все это делает такое сравнение неинформативным, не позволяющим даже приблизительно сопоставить существующие реализации систем рендеринга.

Рис. 1. Некоторые сцены из набора ORB

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

Первая проблема — отсутствие стандарта, согласно которому интерпретируются параметры моделей и ведутся вычисления внутри физически корректных систем рендеринга. Например, в некоторых из них могут быть реализованы математические модели материалов или источники света, отсутствующие в других. Более того, даже имея идентичный набор моделей и параметров, можно получить отличающиеся изображения, поскольку разные системы могут по-разному интерпретировать данные и параметры моделей. Простейший пример — степень «матовости» отражения, записанная в текстуре. Этот параметр, задаваемый в текстуре от 0 до 1, должен отобразиться на интервал от 1 до бесконечности, что соответствует идеальному зеркалу, а коммерческие системы не описывают, какое же именно отображение используется.

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

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

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

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

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

1. Cornell Box с несколькими вариациями. Геометрически простые сцены, содержащие почти все основные эффекты: шумное первичное освещение и мягкие тени, зеркальные блики от источника освещения и пр.

1.1. Базовый вариант, содержащий поровну все эффекты.

1.2. Базовый вариант + зеркало.

1.3. Вариант, ориентированный на многократные глянцевые отражения.

1.4. Оригинальный Cornell Box Эрика Вича, используемый им для демонстрации Metropolis Light Transport. Ярко выраженные трудновычислимые феномены освещенности.

2. Сильное вторичное диффузное освещение и геометрия средней тяжести.

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

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

2.3. San Miguel — тяжелая геометрическая сцена с растительностью, пропускающей свет. Яркое солнце и сильное вторичное освещение.

2.4. Ночной вариант сцены San Miguel. Несколько источников света, более сложное первичное освещение.

3. Сцены на сложную геометрию и простые по освещению.

4. Тестирование освещения для простой геометрии и при сильно неравномерном первичном освещении.

5. Тест на небесные порталы — источники света в окнах, имитирующие рассеянный свет с улицы.

6. Тесты на вторичное освещение от солнца, образованное относительно узкой, но яркой полоской света.

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

8. Трудновычислимые феномены освещенности, видимые через зеркало или стекло, например бассейн с водой.

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

10. Трудновычислимые феномены освещенности, оригинальная сцена Эрика Вича с приоткрытой дверью и ее вариация с глянцевыми отражениями.

11. Сцена с самосветящимися поверхностями.

12. Тест на большое количество источников света.

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

С учетом данных рекомендаций был создан специальный набор сцен (бенчмарк) Open Rendering Benchmark (ORB), позволяющий оценить производительность рендеринга в различных ситуациях и выбрать систему, максимально пригодную для решения конкретной задачи. Данный бенчмарк обладает максимальным покрытием при минимуме сцен, способных вызвать затруднение при визуализации у какой-либо из более двух сотен существующих систем рендеринга.

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

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

Для оценки ошибки и последующего вычисления баллов используется метрика MSE (Mean Squared Error, квадрат ошибки — среднеквадратичное отклонение определяемой величины от ее математического ожидания)*.

На некоторых из созданных сцен (рис. 1) было проведено пилотное сравнение четырех популярных продуктов: V-Ray (www.chaosgroup.com/vray/3ds-max), Corona (corona-renderer.com), Octane (home.otoy.com/render/octane-render) и Hydra Renderer [2].

В России особенно популярны Corona и V-Ray, работающие на универсальных центральных процессорах (CPU) и использующие для ускорения алгоритмы со смещенным решением, в которых нет акцента на точности и которые не обладают способностью достигать правильного решения в пределе. С другой стороны, для типичного пользователя системы рендеринга важна не столько правильность решения, сколько реалистичность изображения, однако смещенные алгоритмы часто дают неприемлемые артефакты.

В системах Octane и Hydra не используются алгоритмы со смещением (приближенные методы), но обе работают с графическими процессорами (GPU). Открытая система Hydra базируется на OpenCL, использует алгоритм Multiplexed MLT [3] и позиционируется как ПО, соединяющее промышленность с научными разработками в области рендеринга и параллельных вычислений на GPU. В одной из самых дорогих коммерческих систем в мире, Octane, применяется алгоритм PMC/ERPT [4] и CUDA.

Результаты численного сравнения в единицах метрики MSE (Hydra — 34; Octane — 32; Corona — 27; V-Ray — 29) могут показаться недостаточно наглядными для 3D-художников, поэтому для иллюстрации возможностей ORB было проведено еще и экспертное сравнение, в котором приняли участие десять профессиональных 3D-художников.

Выбор системы рендеринга: Open Rendering Benchmark
Рис. 2. Пример сопоставления систем рендеринга и их алгоритмов на сцене ORB L4.1

Результаты сравнения (рис. 2) оказались достаточно неожиданными. С одной стороны, по метрике MSE победили системы, работающие на GPU (Hydra и Octane), что, в принципе, ожидаемо. С другой стороны, система V-Ray победила в экспертном сравнении (в среднем VRay выдает более четкую картинку, особенно на начальных, простых сценах). Однако разница между победителем и проигравшим в экспертном сравнении была весьма незначительной (1,5 балла), а по метрике MSE — 7 баллов. Измерения MSE — более чувствительный способ сравнения и более объективный, позволяющий непосредственно измерить ошибку. Кроме того, эксперты не заметили разницы в производительности систем рендеринга — благодаря применению разных подходов, алгоритмов и вычислителей (CPU и GPU) все продукты, за исключением отдельных сцен, достигают паритета. Из этого можно сделать как минимум два вывода.

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

Второй: скорость расчета без допущений («в лоб») на GPU почти сравнялась со скоростью «приближенных» методов на CPU. Это означает, что за исключением небольшого количества случаев (вроде искусственного примера L1.5, рис. 1) «приближенные» методы в фотореалистичном рендеринге теряют свою актуальность. К тому же методы расчета без допущений, как правило, универсальней и проще в поддержке (добавление новых материалов, источников и т. д.). Расчет без допущений делает осмысленным усложнение моделей взаимодействия света с веществом для все большего погружения систем рендеринга в физику явлений и углубления моделирования.

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

Сравнивая Octane и Hydra, можно косвенно сравнить технологии CUDA и OpenCL. На сцене с тяжелой геометрией и простым освещением (сцена L2.2, рис. 1) ощутимой разницы в производительности трассировки лучей нет. Следовательно, закрытым коммерческим решениям, использующим аппаратные особенности конкретных GPU, без ущерба производительности вполне можно предпочесть открытую и аппаратно-независимую технологию OpenCL.

***

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

Литература

1. В. А. Фролов, В. А. Галактионов, М. А. Трофимов. Сравнение индустриальных систем расчета освещения (по состоянию на 2014 год) // Приволжский научный журнал.— 2014 — № 4. — С. 79–85.

2. Ray Tracing Systems. Hydra Renderer. Отечественная рендер-система на GPU с открытыми исходными кодами, создаваемая при поддержке Института прикладной математики имени М. В. Келдыша РАН и лаборатории компьютерной графики и мультимедиа ВМК МГУ. URL: http://www.raytracing.ru (дата обращения 30.05.2019).

3. Toshiya Hachisuka, Anton S. Kaplanyan, Carsten Dachsbacher. 2014. Multiplexed metropolis light transport // ACM Trans. Graph. — 2014. — Vol. 33, N. 4, Article 100. — 10 p. DOI: https://doi.org/10.1145/2601097.2601138.

4. Yu-Chi Lai, Shao Hua Fan, Stephen Chenney, Charcle Dyer. Photorealistic image rendering with population monte carlo energy redistribution // Proceedings of the 18th Eurographics conference on Rendering Techniques (EGSR'07, 2007). — Eurographics Association: Aire-la-Ville, Switzerland. — P. 287–295. DOI: http://dx.doi.org/10.2312/EGWR/EGSR07/287-295.

Владимир Фролов (vova@frolov.pp.ru), Владимир Галактионов (vlgal@gin.keldysh.ru) — сотрудники, ИПМ им. М. В. Келдыша РАН, ВМК МГУ им. М. В. Ломоносова (Москва); Денис Павлов (denis.pavlov@graphics.cs.msu.ru) — аспирант, ВМК МГУ им. М. В. Ломоносова (Москва); Максим Трофимов (max.trofimov@graphics.cs.msu.ru), Павел Казбеев (silentprayercg@gmail.com) — 3D-художники, ВМК МГУ им. М. В. Ломоносова (Москва).

* Подробное объяснение метрики MSE приведено в полной версии статьи http://www.raytracing.ru/papers/comparison_paper.pdf.