Добрый день. Меня зовут Евгения Казакова. Работаю в интерьерной визуализации около трех лет. В работе пытаюсь воссоздать какое-то настроение, показать не только мебель и детали интерьера, но и наполнить картинку жизнью.
Стараюсь сделать хорошо, лучше и ещё лучше, надеюсь, мои наблюдения и вам помогут что-то улучшить в своих работах.
Постоянно натыкаюсь в форумах на советы выставляться в свитке System Default geometry в режим Auto или Dynamic.
[Вы должны быть зарегистрированы и подключены, чтобы видеть это изображение]
Очень хочу объяснить, что же это такое, и почему не все режимы одинаково полезны.
Начну немного издалека.
Этот пресловутый список делает настройку одного raycast.
Что такое raycast? Raycast - это столкновение наблюдаемого луча о полигон в нашей сцене. Из нашего изображения, из камеры, выпускается луч, он стукается о препятствие, размножается, ещё раз отражается, претерпевает кучу приключений и так до тех пор, пока не попадет в источник света.
Это называется обратная трассировка. Её стали применять, чтобы избежать лавину расчетов тех лучей, которые выходят из источника света, но уходят за пределы картинки.
Итак.
Мы должны настроить просчет одного raycast максимально оптимально.
Поэтому приведу некоторые соображения, которые могут отличать подход к работе от того, что вы привыкли делать раньше, но этот порядок работы поможет настроить рендер на максимальную скорость.
1.Сцена должна быть законченной. То есть, со всеми материалами и самое главное - со всеми объектами.
Если мы настраиваем рендер на пустой комнате, то с внесением в нее новых тысяч полигонов рендериться она будет все медленнее и медленнее. Это правильно. Но, так как мы настроили свиток на одно количество полигонов, а в сцене другое, оптимальным просчетом это уже не назовешь.
Поэтому повторюсь, сцена должна быть закончена.
2. Так как raycasts плодятся из-за источника света, то есть, если у нас источников много, то луч после соударения будет делиться и направляться ко всем имеющимся в сцене источникам, мы делаем минимальное возможное количество лучей. Для простоты и наглядности, мы выключаем все источники и вешаем один Omni в центр комнаты. У него выключаем тени.
3. Так как луч при соударении с полигоном при просчете GI будет вести себя совершенно иначе, чем без GI, мы убираем глобальное освещение из просчета. Просто вырубаем галочку.
4. Антиалиасинг тоже добавляет ненужных вычислений, посему - ставим режим Fixed - 1.
5. Всю сцену переводим в серый материал без каких-либо отражений и преломлений.
6. В свитке DMC Sampler, Adaptive amaunt выставляем в 1.
7. Никаких гамм 2.2 и Frame Buffer на этом этапе.
8. У физической враевской камеры отжимаем галочку exposure - это приведет камеру к режиму работы как обычная максовская камера.
Рендерим.
[Вы должны быть зарегистрированы и подключены, чтобы видеть это изображение]
Вот это окошко для нас сейчас несет очень важную информацию.
[Вы должны быть зарегистрированы и подключены, чтобы видеть это изображение]
А именно - Number of raycasts: 571200
Если мы исключили все лишнее, то минимум лучей, которые будут выпушены из нашей картинки будет соответствовать количеству пикселей этой картинки, так как каждый пиксель-это луч.
Картинка разрешением 714х800. При умножении 714*800=571200
Значит, мы все делаем правильно, теперь будут наглядны все те пассы, что будем проводить.
Для начала включаем у источника тени.
[Вы должны быть зарегистрированы и подключены, чтобы видеть это изображение]
Number of raycasts увеличился - 1098475.
[Вы должны быть зарегистрированы и подключены, чтобы видеть это изображение]
Еще одно замечание. Для сравнения времени следует смотреть на не Total frame time, а на Region rendering, потому что в Total включают общее время от "нажали кнопку" до полного конца рендеринга. В Region rendering сообщают время только рендера, безо всяких вспомогательных расчетов.
Пока время рендера не отличается особо, но количество raycasts выросло.
Теперь идем в System и выставляем Default geometry из Auto в Dynamic. Больше ничего не трогаем.
[Вы должны быть зарегистрированы и подключены, чтобы видеть это изображение]
При одинаковых картинках время выросло с 2,4 сек. до 26,7 сек. Количество raycasts же неизменно.
Время выросло почти в 10 раз!
[Вы должны быть зарегистрированы и подключены, чтобы видеть это изображение]
А теперь немного физики и анализа.
Для того, чтобы следить за путешествием луча, Vray должен знать, об какой полигон произойдет столкновение. В режиме Static, Vray начинает строить так называемое бинарное дерево из геометрии, что есть в сцене. Если объяснить упрощенно, то это выглядит примерно так - сцену делим пополам, если нужного полигона нет в одной половине, то её отбрасываем, снова пополам, снова отбрасываем и так до тех пор, пока у нас в идеале не останется два полигона, один из которых будет искомый, об который стукается наш луч.
Это дерево строится один раз перед началом самого процесса рендера, вся геометрия расскладывается "по полочкам" и пишется в некую таблицу, параметрами таблицы можно управлять как раз из свитка Raycaster params.
[Вы должны быть зарегистрированы и подключены, чтобы видеть это изображение]
Когда геометрия вся разложена в такое дерево, очень просто найти об какой полигон стукнулся наш луч, пробежать по готовой таблице и оп, нашли нужный.
Теперь более тонко настроим то, как VRay будет раскладывать геометрию.
Обращаем внимание на соотношение между подчеркнутыми красным величинами.
[Вы должны быть зарегистрированы и подключены, чтобы видеть это изображение]
Меняем Face/level coef. с 1 до 0,5. Рендерим. Смотрим.
[Вы должны быть зарегистрированы и подключены, чтобы видеть это изображение]
При уменьшении Face/level coef. уменьшается число Average Face leaf. Это и есть число полигонов (треугольников) в конечном звене бинарного дерева, так называемом "листике". Сейчас Vray в конце ищет нужный полигон среди 18.2 треугольников.
При этом, возросло количество памяти, занятое под наше дерево с 50,05 Мб до 61,35 Мб.
Ещё уменьшим число в Face/level coef. Рассчет бинарного дерева в предпроцессах ощутимо вырос, но это ерунда.
[Вы должны быть зарегистрированы и подключены, чтобы видеть это изображение]
Average Face leaf. уменьшилось до 3,14, используемая память возрасла до 236,23 Мб.
То, что у нас не меняется время на Region Rendering при этих манипуляциях, только оттого, что быстрее некуда. В дальнейшем, когда количество raycasts лавинообразно будет расти, когда появятся рассчеты GI и множество источников света, к которым миллионы лучей нужно будет отследить, эта разница ещё как прочувствуется.
Есть только одно замечание, основанное на личном опыте, но ничем не подтвержденное документально.
По логике, искать среди 2 полигонов гораздо проще, чем среди 4-х. Но, почему-то, у Vray нет никакой разницы между Average Face leaf. около 2-х и Average Face leaf. около 4-х. Но память при этом честно отъедается и дерево строится по-разному. Но прироста по времени нет ни на мгновение. К тому же, появляются странные вылеты, никак не связанные в отсутствием оперативки. Так что мой совет - стараться приблизиться к числу 4 в Average Face leaf. Меньшее не имеет смысла.
О других параметрах этого свитка не имеет смысл расписывать многое.
Max. tree depth - есть количество делений на два, так называемые "узлы дерева" Или уровни бинарного дерева. Этот параметр практически всегда можно оставить по дефолтному значению, число же реального количества деления можно узнать из V-ray message. Если видно, что Average Face leaf остается на высоком значении, а количество произведенных делений в списке приближается к дефолтному значению, имеет смысл увеличить максимально разрешенное количество операций деления.
[Вы должны быть зарегистрированы и подключены, чтобы видеть это изображение]
Min. leaf size - по умолчанию стоит 0. В этом случае Vray делит всю геометрию вне зависимости от величины полигонов и размера сцены. Если же выставить отличное от нуля значение, Vray будет прекращать деление геометрии при достижении заданного размера "массы полигонов". Имеется смысл этим пользоваться, если сцена перегружена микроскопическими треугольниками, или при избыточной детальности. Но о какой оптимальности тогда может идти речь?
И немного о самом спорном. О Dynamic memory limit.
Разработчик говорит следующее - Dynamic memory limit это количество оперативной памяти, занятой под динамическое отслеживаение лучей, то есть, да, этот параметр начинает работать только тогда, когда у нас стоит режим Dynamic. Однако, продолжаю цитировать официальный документ, следует отметить, что этот кусок памяти может быть разделен между разными процессами рендера.
Да. Выходит, что в режиме Static этот параметр не влияет на рендер как таковой.
Но. Есть одно наблюдение, как говорится, из жизни.
При просчете Light Cache оперативная память съедается Vray именно по этому указаному лимиту. То есть, если у вас мало оперативки, часть мы съели на бинарное дерево, часть у нас съедено операционой системой, имеет смысл понизить это число. Эта операция спасет нас от очень распространенных падений макса как раз в момент расчета Light Cache.
Теперь кратко о других режимах.
В режиме Dynamic бинарное дерево строится каждый раз "на лету". По словам разработчиков, размер раскладываемой геометрии соответствует части, которая в данный момент рендерится. Видимо, имеется в виду размер bucket-а, регулируемого в соседнем свитке Render Region Division. Одно явно и ясно точно - бинарное дерево, построеное в самом начале на всю геометрию позволяет оптимально быстро рассчитывать raycasts, в чем мы убедились, поменяв один режим на другой.
Режим Auto появился сравнительно недавно. В этом режиме часть геометрии раскладывается в таблицу, а часть "на лету". Решение о том, какая часть как будет отрабатываться, Vray принимает самостоятельно, основываясь на количестве треугольников в объекте и количестве Instance этого объекта.
Когда этот режим только появился, я провела несколько тестов. Старый добрый Static отрабатывал быстрее, поэтому этот режим так же не пользуется у меня популярностью.
Для чего нужен Dynamic и почему он все-же есть.
Бинарное дерево при построении загружает всю геометрию в оперативную память. Соответственно, если памяти мало и/или геометрии очень много, то может не хватить. Вылет Max - гарантирован. В этом случае приходится переходить в режим Dynamic, ограничивать использование оперативки, плясать с бубнами и всячески переживать.
Так же режим Dynamic хорошо отрабывает, к примеру, когда в сцене имеется большое количество Vray Proxy, VrayFur и\или VrayDisplace. Инструмент Vray Proxy позволяет значительно разгрузить сцену от избыточной геометрии, но при просчете Vray распаковывает все прокси в момент просчета и в этот момент можно наблюдать строчку Load\Unloade geometry. Другими словами, если в сцене есть Vray Proxy, бинарное дерево будет построено для имеющейся геометрии, а все Vray Proxy будут отсчитываться в режиме Dynamic. Это и хорошо и плохо. Хорошо, если у нас много оперативки, тогда раз столкнувшись с Proxy, Vray распакует этот кусок в память и в дальнейшем уже не будет раскладывать геометрию, попав снова на этот объект. Плохо, если памяти мало. Потому, что мы не получим всей ожидаемой выгоды от оптимизированного режима Static. Ключевое слово - всей.
Так как имея даже приличное количество Vray Proxy в сцене, в режиме Static, как правило, общее время просчета будет в разы быстрее, чем в других режимах.
И есть ещё одно наблюдение. При заставлении Vray отбирать больше памяти для быстрейшего рендера, разумеется, придется платить большей нестабильностью работы. Возможные падения из-за неправильного и слишком большого отжора оперативки могут испортить не только настроение.
В любом случае, теперь вы знаете, как заставить эту заразу работать быстрее.
[Вы должны быть зарегистрированы и подключены, чтобы видеть это изображение]]