Corona Renderer - Оптимизация, Тесты. Рендер анимации

Здравствуйте, уважаемые коллеги!
Представляем вашему внимание работы по исследованию рендер движка Corona, с уклоном на архитектурные анимации.

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

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

*Исходная сцена

Все тесты проводились на одном отдельно стоящем компьютере, через Backburner, в полном покое, без каких-либо посторонних процессов.

1. Базовые настройки для рендеринга анимации:

- Lock sampling pattern off (статичный шум очень тяжело вычищать, он будет висеть на экране как грязь на стекле, лучше уж пусть картинка шумит)

- UHD Cache – Animation (flicker-free) (чтобы GI не создавал артефакты), так же желательно увеличивать Precision, особенно в сценах, где много деталей, светильников. Я использую от 2.0 до 4.0

Предпросчет GI хорошо работает в статичных сценах, но с движущимися объектами в 99% случаев нет смысла с этим возиться и тратить на это свое рабочее время. Очень индивидуально.

2. Результаты тестов:

Max ray depth:

Картинка в интерьере выглядит достаточно хорошо лишь при 6-7 переотражениях, и то, только если там нет стеклянных объектов. Дальше этот параметр практически никак не влияет на время рендеринга. Поэтому сэкономить тут не получится. Даже когда половина экрана заставлена хромированными объектами, разницы между 15 отражениями и 20 практически нет.

GI vs AA:

Для этого теста в сцену был добавлен Motion Blur и DoF, т.к. мы говорим про анимацию, то часто их приходится включать. И именно в таких случаях понижение GI vs AA помогает быстрее избавляться от артефактов. Крайне не рекомендуется ставить 0-2, они дают сильный шум. Хорошо себя показывают значения в районе 6. Разницу в количестве «светлячков» видно невооруженным взглядом.

*В случаях, когда у нас нет ни размытия движения, ни глубины резкости, можно оставлять по умолчанию.

Light Samples Multiplier:

*Первый тест проводился с довольно сильной глубиной резкости.

При значениях 0 картинка очень сильно шумит. А вот понижение этого значения до 0,2-0,5 часто дает довольно хороший результат, больше пассов и ниже шум.

*Второй тест проводился без глубины резкости.

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

Max Sample Intensity:

*Первый тест проводился с довольно сильной глубиной резкости на всей стене.

Чем выше значение, тем время рендеринга и значение шума тоже выше. Тут важно найти свою золотую середину, т.к. идеальные значения зависят от силы источников света в сцене. Например, в этом случае самые сильные источники света имели мощность 50 единиц при экспозиции в -0.5. То есть, лучше стремиться уменьшить Light Samples Multiplier так, чтобы общее освещение и сила бликов не изменились слишком заметно. Тогда мы можем срезать 5-10% времени с кадра, что довольно ощутимо.

*Второй тест проводился без глубины резкости.

На сценах БЕЗ глубины резкости (или размытия движения) этот эффект ощутимо слабее, но общий тренд такой же.

Displacement:

Для начала необходимо сказать, что в анимации крайне не рекомендуется использовать Screen size (px) Displacement, в первую очередь потому, что он будет порождать артефакты и фликеринг на границах кадра (т.к. объект будет изменяться по мере вхождения/выхождения в кадр). А также необходимо помнить, что для отражений Corona создает упрощенную модель, и когда эта упрощенная модель начинает отражаться в других объектах, а тем более во время анимации, то она так же порождает артефакты.

*Ближняя часть объекта видна и в сцене и в зеркале. Дальняя часть объекта видна только в зеркале

Безопаснее использовать World size (units), предварительно сделав несколько тестовых рендеров для самых ближних ракурсов, которые у нас планируются. В случае интерьера значения могу быть от 2.0cm до 0.01cm.

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

Был проведен тест на влияние количества полигонов в исходном объекте. В результате не было замечено сильного влияния на скорость рендеринга.
Поэтому нет смысла беспокоиться об этом, до тех пор пока нам хватает оперативной памяти. Но, однако, точно не нужно добавлять дополнительных полигонов на объект, если этого не требуется.

Caustics Solver:

Разумеется, рендер каустики в анимации очень дорого обходится по времени, и лучше его избегать или делать фейк. На качество и скорость каустики очень сильно влияет количество пассов, поэтому низкие значения GI vs AA помогают получить лучший результат. Значения 6-8 дадут много пассов и не испортят картинку. Именно для качества каустики еще более низкие значения дают еще более чистый результат, но там уже сильно страдает качество других отражений и общий уровень шума.

Изменение Light Samples Multiplier в меньшую сторону так же дает небольшой прирост скорости. Значения в районе 0.5-1.0 не портят картинку и дают заметную экономию скорости.

Exposure:

Если вдруг, кого-то интересует, различается ли скорость рендеринга при высоких значениях экспозиции и слабом свете от скорости при низких значениях экспозиции и сильном свете. Ответ: нет, не отличаются. Можно делать очень темные сцены и поднимать экспозицию, а можно наоборот.

*три теста с различными уровнями экспозиции и силой источников света

Multi/Sub-Object Material:

Сверху вниз:
1) Рендер с одной большой текстурой 1 Гб, потребовал 3 Гб ОЗУ
2) Рендер с 10 большими текстурами 1 ГБ, потребовал 21 Гб ОЗУ
3) Рендер с 10 большими текстурами 1 ГБ, но, в сцене назначен только один ID, для первой текстуры, остальные текстуры вообще никак не участвуют в сцене. Т.е. по идее, остальные 9 текстур не должны грузиться, но они грузятся. Снова 21 Гб ОЗУ.

Вычистить эти лишние гигабайты можно только удалив лишние ID материалы и перезагрузив 3ds Max. Еще одна веская причина
не собирать все материалы в один большой Multi/Sub-Object Material.

* три теста с разным количеством загруженных текстур

Corona Light vs Corona Light Material vs Self-Illumination:

Можно смело утверждать, что нативный источник света Corona Light и специальный материал Corona Light Material условно идентичны по своей скорости работы. В тесте видна разница между ними, да. Источник света справился медленнее и дал меньше шума. Но дело в том, что по умолчанию Light Samples Multiplier стоит на 2.0. При коэффициенте 1.0 результат практически идентичен.
Использовать Self-Illumination в качестве сильных источников света не рекомендуется даже в официальной документации.

При этом, если взять 250 источников света и 250 объектов с Corona Light Material, то источники света выигрывают и уровню шума при равном количестве затраченного времени. Т.е. если источников света много, то Corona Light все же предпочтительнее, особенно с учетом того, что мы можем уменьшать Light Samples Multiplier ниже 1, что даст хороший прирост в сценах с сильно глубиной резкости и размытием движения.

Edit Mesh vs Edit Poly:

Для Corona Render нет разницы, какой объект рендерить, Mesh или Poly. Но вот для самого 3ds max разница есть!

*сам рендер забрал по 9.5 Гб ОЗУ в обоих случаях

Так, например, 50 миллионов полигонов в Edit Poly во время рендера занимают 31.5 Гб ОЗУ. А вот те же 50 миллионов сконвертированные в Edit Mesh
займут 25.7 Гб ОЗУ. Поэтому очень полезно конвертировать свои модели в Mesh (именно базовую геометрию, до модификаторов сглаживания), если это ничего не ломает в вашей сцене.

NURMS vs MeshSmooth vs TurboSmooth vs OpenSabdiv:

Похожая ситуация и с модификаторами сглаживания. Для самого рендер движка разницы принципиальной нет. А вот для 3ds Max целиком разница есть, т.к. для каждого метода нужно разное количество оперативной памяти.

NURMS - 9800 Mb
MeshSmooth - 11920 Mb
TurboSmooth - 7960 Mb
EditMesh + TurboSmooth Hidden - 7388 Mb
OpenSabdiv - 10837 Mb

Т.е. для экономии памяти идеально использовать Turbo в режиме «Off in Viewport». Если, конечно, вам не нужен другой особым образом настроенный алгоритм (что в 99% случаев не так).

Denoise:

На финальный рендер все-таки стоит включать Denoising «Corona Hight Quality». В большинстве случаев хорошо работает Amount 0.5 – 0.75 c Radius 1.0.

3. Выводы:

Если есть возможность не рендерить честную глубину резкости и размытие движения, то лучше сделать их на пост-обработке. Так же на пост-обработке можно победить различные виды «светлячков», не всегда есть смысл стараться избавиться от них честным способом. Обычно это очень долго и дорого.

Еще больше времени сэкономит смена рендер-движка, например на FStorm

Спасибо за внимание, быстрых и чистых вам рендеров!