За нашими даними Hydra перевершує всі існуючі рендер-системи в швидкості. Протягом семи років ми відбирали і відточували найбільш практичні алгоритми, які роблять Hydra Renderer оптимальної реалізацією найсучасніших підходів обчислення глобального освітлення повністю на GPU! 
Рис 1.Сравнение рендер-систем за відносним індексу продуктивності на різних сценах
Рис 2.Сравненіе рендер-систем за відносним індексу продуктивності (середнє по всіх сцен)
Збіг зображень і методика порівняння
Для кожної системи і кожного сценарію ми розраховували свій еталон, з яким згодом вироблялося порівняння. Такий спосіб дозволяє виключити відмінності реалізації окремих незначних моментів і зосередитися на порівнянні швидкості інтегрування (тобто обчислення GI)
Для всіх систем проводилося порівняння двох типів: спочатку фіксувалася невелика помилка (наскільки це можливо), і вимірювалося час синтезу зображення. Потім фіксувалося час синтезу зображення (зазвичай невелика, в межах 1 хвилини) і вимірювалася помилка. Так порівнювався якість отриманих зображень в умовах фіксованого часу. З двох порівнянь для систем зі зміщеним рішенням в результуючий графік входив середній індекс продуктивності. Такий спосіб дозволяє частково вирішити проблему оптимізації налаштувань для систем зі зміщеним рішенням, оскільки на підсумковий результат впливають обидва типи оптимізацій (орієнтовані на якість і швидкість). Для систем з незміщеної рішенням відношення швидкість / якість для обох типів порівнянь збігається.
Як ми вимірювали швидкість?
Добре відомо, що час обчислення освітленості в трасувальникові шляхів обернено пропорційно квадрату помилки. Тобто, щоб збільшити точність в 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).
>>>>>>>> Дані в порівнянні
>>>>>>>> Сцени
Як ми вимірювали швидкість?