Войти как пользователь
Вы можете войти на сайт, если вы зарегистрированы на одном из этих сервисов:
< >
1 2 3 4 5

Hydra Renderer: найшвидший рендер

  1. Збіг зображень і методика порівняння
  2. Як ми вимірювали швидкість?
  3. тестові сценарії

За нашими даними Hydra перевершує всі існуючі рендер-системи в швидкості. Протягом семи років ми відбирали і відточували найбільш практичні алгоритми, які роблять Hydra Renderer оптимальної реалізацією найсучасніших підходів обчислення глобального освітлення повністю на GPU! За нашими даними Hydra перевершує всі існуючі рендер-системи в швидкості

Рис 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).

>>>>>>>> Дані в порівнянні

>>>>>>>> Сцени

Як ми вимірювали швидкість?