По нашим данным Hydra превосходит все существующие рендер-системы в скорости. В течение семи лет мы отбирали и оттачивали наиболее практичные алгоритмы, которые делают Hydra Renderer оптимальной реализацией самых современных подходов вычисления глобального освещения полностью на GPU!
Рис 1.Сравнение рендер-систем по относительному индексу производительности на различных сценах
Рис 2.Сравнение рендер-систем по относительному индексу производительности (среднее по всем сценам)
Для каждой системы и каждого сценария мы рассчитывали свой эталон, с которым впоследствии производилось сравнение. Такой способ позволяет исключить различия реализации отдельных незначительных моментов и сосредоточиться на сравнении скорости интегрирования (т.е. вычисление GI)
Для всех систем производилось сравнение двух типов: сначала фиксировалась небольшая ошибка (насколько это возможно), и измерялось время синтеза изображения. Затем фиксировалось время синтеза изображения (обычно небольшое, в пределах 1 минуты) и измерялась ошибка. Так сравнивалось качество полученных изображений в условиях фиксированного времени. Из двух сравнений для систем со смещенным решением в результирующий график входил средний индекс производительности. Такой способ позволяет частично решить проблему оптимизации настроек для систем со смещенным решением, поскольку на итоговый результат влияют оба типа оптимизаций (ориентированные на качество и скорость). Для систем с несмещенным решением отношение скорость/качество для обоих типов сравнений совпадает.
Рис 3. Изображение сцен, на которых проводились сравнения ('Cornell Box' отсутствует). Была достигнута высокая степень совпадения для рендер-систем
Хорошо известно, что время вычисления освещенности в трассировщиках путей обратно пропорционально квадрату ошибки. То есть, чтобы увеличить точность в 2 раза, вам придется рендерить в 4 раза дольше.
Для того, чтобы оценить производительность рендер-систем на различных сценах и сопоставить их друг с другом, введем абсолютный индекс производительности
Абсолютный индекс производимости
Где MSE - квадратичная ошибка, вычисляемая при помощи программы 'The compressonator', а t - время в секундах. Если сцена, условия освещения и оборудование фиксированы, отношение индексов производительности для 2 систем будет адекватно отражать отношение производительности этих систем.
Однако, зависимость сравнения от сцены, оборудования и абсолютные значения индекса снижают наглядность сравнения.
По этой причине введем относительный индекс производительности
Относительный индекс производимости
Относительный индекс производительности будет равен 100 баллам для системы, которая является на данной сцене самой быстрой. Остальные системы получат баллы пропорционально тому, на сколько они медленнее. Таким образом, относительный индекс производительности не зависит от сложности сцены, и его можно усреднить по всем тестовым сценам, оценив, как система проявила себя в комплексе.
Сценарий номер 1. VRay (4 минуты, MSE = 5.8), Corona (VCM, 1.5 минуты, MSE = 3.9), Hydra (1.5 минуты, MSE = 3.4)
'Cornell Box' с зеркальным чайником. Несмотря на свою простоту, в данном сценарии присутствуют практически все основные эффекты трехмерной компьютерной графики: шумное первичное освещение и мягкие тени, зеркальные блики от источника освещения, отраженные каустики. Являясь геометрически простой, сцена в некоторой степени амортизирует стандартные потери производительности GPU трассировщиков лучей на ветвлениях, а CPU трассировщиков лучей на кэш промахах.
Сценарий номер 2. VRayRT (1 минута, MSE = 1.7), Corona (1 минута, MSE = 2.3), Hydra (1 минута, MSE = 2.0)
Уличная (outdoor) сцена. Данная сцена, являясь геометрически сложной (из-за травы), тем не менее, с точки зрения освещения достаточно проста - однородная панорама и один относительно неяркий источник освещения. Время синтеза изображения на такой сцене должно в основном быть обусловлено скоростью трассировки лучей.
Сценарий номер 3. VRay (1 минута, MSE = 7.3), Corona (1 минута, MSE = 12.6), Hydra (ML Filter, 1 минута, MSE = 3.8)
Верхний коридор Crytek Sponza. В данном сценарии практически все видимое освещение вторичное. Здесь силен вклад от второго и третьего диффузных переотражений, поэтому финальный сбор должен давать значительное ускорение. Такой сценарий наиболее точно отражает скорость расчета вторичного освещения.
Сценарий номер 4. VRay (2 минуты, MSE = 8.5), Corona (2 минуты, MSE = 15.1), Hydra (Кэш освещенности, 2 минуты, MSE = 4.5)
Зал конференций. Сложность расчета освещения в данной сцене заключается в большом числе источников освещения. Под потолком находится 20 источников прожекторного типа. Тем не менее, каждый из источников светит на относительно небольшой участок сцены, поэтому, если в рендер-системе реализована эффективная схема сэмплирования источников, в каждой конкретной точке сцены большинство источников должны быть эффективно отброшены или учитываться относительно нечасто.
Сценарий номер 5. VRay (3 минуты, MSE = 7.3), Corona (2 минуты, MSE = 4.0), Hydra (ML Filter, 2 минуты, MSE = 3.0?)
Освещение 'Небесными Порталами'. Данная сцена демонстрирует достаточно типичный сценарий расчета дневного освещения в помещении. При таком сценарии напротив окон ставятся источники света, имитирующие свет от внешнего окружения, проникающий через окно. Такой источник называется "Небесным Порталом" (Sky Portal). При правильной реализации "Небесный Портал" является полностью корректным решением. Такой источник света является средством расчета освещения от окружения при помощи явной стратегии (стратегии сэмплирования источников света). Иными словами, "Небесный Портал" является не самостоятельным источник света, а всего лишь подсказкой для Монте-Карло трассировки лучей, позволяющей вычислять освещение от окружения более эффективно в тех случаях, когда изнутри помещения видима относительно небольшая часть окружения. Тем не менее, при использовании небесных порталов расчет первичного освещения в определенной степени осложняется по 2 причинам. Во-первых, небесные порталы могут иметь значительные размеры, в результате чего замедляется расчет мягких теней. Во-вторых, число источников этого типа может быть достаточно большим (5-10), что еще более осложняет вычисление первичного освещения. На данной сцене были использованы различные комбинации методов для различных систем, наилучшим образом показавшие себя.
Сценарий номер 6. VRay (20 минут, MSE = 5.5), Corona (10 мин, MSE = 5.0), Hydra (ML Filter, 10 мин, MSE = 5.0 ?)
Тест на MLT (Metropolis Light Transport). В данном сценарии небольшой участок сцены освещается исключительно ярким направленным источником света, имитирующим солнце. Вторичное освещение, вызванное таким освещением, является трудным для расчета (hard sampling). Фотонные карты, в сочетании с финальным сбором (как и карты светимости), амортизируют увеличение времени расчета только за счет ускорения вычисления компоненты от третьего и более переотражений. Однако, вычисление компоненты от второго переотражения света данным методом не ускоряется. С другой стороны, алгоритм переноса света Метрополиса (MLT) и аналогичные алгоритмы, при условии корректной реализации их в той или иной системе, должны давать на данной сцене значительное ускорение по сравнению с традиционным методом Монте-Карло и финальным сбором.
Сценарий номер 7. VRay (2 минуты, MSE = 7.8), Corona (1 мин, MSE = 10.5), Hydra (1 мин, MSE = 5.6)
Водные каустики. В данной сцене присутствуют отраженные каустики и подводные каустики SDS типа (Specular Diffuse Specular), являющиеся сложными для расчета. IRay и VRayRT не были способны корректно расчитать данный тип каустиков за приемлимое время, хотя система IRay способна эффективно считать каустики видимые напрямую (ESDL).
>>>>>>>> Данные по сравнению <<<<<<<<
© Ray Tracing Systems. 2014-2021. Все права защищены.