Уроки: 3ds Max

Vray - дело тонкое

Добрый день. Меня зовут Евгения Казакова. Работаю в интерьерной визуализации около трех лет. В работе пытаюсь воссоздать какое-то настроение, показать не только мебель и детали интерьера, но и наполнить картинку жизнью.

Стараюсь сделать хорошо, лучше и ещё лучше, надеюсь, мои наблюдения и вам помогут что-то улучшить в своих работах.

Постоянно натыкаюсь в форумах на советы выставляться в свитке 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 отбирать больше памяти для быстрейшего рендера, разумеется, придется платить большей нестабильностью работы. Возможные падения из-за неправильного и слишком большого отжора оперативки могут испортить не только настроение.

В любом случае, теперь вы знаете, как заставить эту заразу работать быстрее.

169470 Автор:
Актуальность: 676
Качество: 657
Суммарный балл: 1333
Выбор Публики
Голосов: 208 оценки

Отзывы посетителей:

2 3 4 | След.
аватар
 
Joe Romersa 2 0
подскажите пожалуйста, где можно бесплатно скачать Vray для 3ds max 2010
аватар
 
Андрей Годарев 1 0
здравствуйте, не подскажете с чего начать если из макса только моделинг знаю ? по книгам изучил вполне нормально, Есть какие либо уроки в ВэРэе или надо на курсы идти ? http://vkontakte.ru/id9692281 если удобней скинуть то вот из контакта ссылка , заранее благодарю =)
аватар
 
Андрей Годарев 1 0
Здравствуйте , не подскажете с чего начать если из макса только моделинг знаю ? по книгам изучил вполне нормально, Есть какие либо уроки в ВэРэе или надо на курсы идти ? http://vkontakte.ru/id9692281 если удобней скинуть то вот из контакта ссылка , заранее благодарю =)
аватар
 
Rajah 22 0
to ..::Klimber Quellecairion Didenkoff::..

Чтобы получить количество raycasts равное числу пикселей нужно
1. удалить все ИС из сцены ( или выключить их ) IES это так же касается.
2. Выкючить все материалы.
3. Выставить антиалиасинг в fixed
4. Выключить GI

Если у Вас при выполнении всех этих действий всё равно нет равенства, то, возможно, стоит "отресетить" Vray на дефолтные настройки. Сделать это можно выбрав в Assign Renderer другой рендер, после этого снова выбрать Vray и уже тогда выполнить вышеперечисленные пункты.

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

"Если мы исключили все лишнее, то минимум лучей, которые будут выпушены из нашей картинки будет соответствовать количеству пикселей этой картинки, так как каждый пиксель-это луч.

Картинка разрешением 714х800. При умножении 714*800=571200"

А как Вы так настроили что у вас при таком разрешении такое количество лучей получилось? Я кручу эти настройки и у меня ничего не получается.
аватар
 
xavi moreno 27 0
Я не знаю все равно я не понял , так какой режим надо включать....Придется тестить и самому делать выводы.....и тратить время....
аватар
 
Шмель 2 0
Уважаемые!!! Пожалуйста подскажите с чего начать по вирею?? я понимю тут вы обсуждаете про "Деревья" но а если дерево читает это? ;) Буду Весьма БЛАГОДАРЕН!
аватар
 
kodo 1 0
спасибо! Извлек для себя полезные толики информации;)
Продолжайте в том же духе!
аватар
 
Rajah 22 0
To Константин Суханаев
Посмеялась.
Спасибо, за доставленные минуты удовольствия. Редко встречаю человека с таким прекрасным чувством юмора.
аватар
 
Константин Федоров 121 0
а мне че то результат не очень нравиться, можно было и по интересней сделать в плане виза... не в обиду!
аватар
 
Rajah 22 0
TO Tigranik
Когда Вы включите у Omni VrayShadows, тогда количество raycasts будет меняться.
Пока Вы не включили механизм просчета теней, количество OMNI не будет влиять на количество raycasts.
Речь идет именно об Omni, так как нам требовалось контролировать количество raycasts, и исключить на начальном этапе просчет raycasts к источнику света.

А вот касаемо второй части вопроса, почему Vray показывает на один источник света больше, чем есть на самом деле - до сих пор мне разобраться не удалось. Но вопрос интересный. Если Вам удасться разобраться в этом вопросе, буду очень рада услышать ответ!
аватар
 
Tigranik 107 0
Автору спасибо за урок! Но кое-что мне заводит в заблуждение...

Цитирую:...то есть, если у нас источников много, то луч после соударения будет делиться и направляться ко всем имеющимся в сцене источникам, мы делаем минимальное возможное количество лучей.


Дело в том, что на самом первом этапе когда я решил добавить еще один Omni, но количество raycasts осталось прежнем 480 000! сцена разрешением 800*600. Может я что то недопонял?
И почему когда в сцене 1 реальный источник света, V-Ray Massages пишет: 2 render light(s) (O_o)

аватар
 
cbapog 2 0
Цитирую vianar:
я хочу сказать благодарность не автору а cbapog


всегда пожалуйста)))

Вот работаю над очень комплексной сценой экстерьера турбазы, много поликов (огромный ковёр 3д травы)
Сравниваю разные настройки ирмапы,
результаты по времени тут http://s48.radikal.ru/i120/0905/30/e62844e4bbfc.png

А4 150дпи:
с ГИ - http://s41.radikal.ru/i091/0905/65/d3b1a0ea7410.jpg
без ГИ - http://i040.radikal.ru/0905/ad/1d4a6d649f3e.jpg

аватар
 
LevaLeva 112 0
Полезно для лентяев, вроде меня :)
аватар
 
vianar 2 0
урок не всем но полезный....
но я хочу сказать благодарность не автору а cbapog +за наглядные тесты по буферу..)))
аватар
 
cbapog 2 0
В общем уважаемый Салюто всё верно подвёл. Памяти больше на борту - проблем меньше. Сам сижу на 8гб, но последнее время приходиться считать картинки в 15000х7500 и выше (до 30000х15000) и память расходуется очень быстро (даже с выкл. врейфреймбуфером). Подумываю о переходе на х58 платформу и 16гб ддр3 (самой дешёвой)
аватар
 
And2003 1 0
Спасибо!!! Реально хороший урок. Тем более, что дизайнеры, как правило, таким вещами как память, ее распределение и т.п не уделяют внимание. В свое время я обнаружил только, то что при включении галки dynamic скорость падала в разы, но исчезали постоянные падения. После этого урока мне стало понятным почему макс падал и как этого избежать не роставшись с быстрым просчетом.
аватар
 
SALuto 148 0
Теоретическая информация в любом случае дело нужное и полезное. Спасибо большое.
Как практик скажу, что поиск оптимального соотношения этих параметров занимает зачастую больше времени чем выигранная в итоге разница. :) Да и разработчики Vray тоже не рекомендуют менять эти значения.
Что касается режимов авто-статик-динамик, то при использовании 64-битных систем смысла менять статик на что-то еще практически нет, а использовать 32-бита для 3D, в настоящее время просто мазохизм. И при нынешних ценах на оперативную память, иметь ее меньше чем 6-8Gb (оптимально по цене) тоже не очень правильно.
Всем удачных рендеров!
аватар
 
zhuzhy 1 0
Тоже не удержался от тестирования. На примере простой сценки выяснилось, что при Default geometry static понижение Face/level coef. до 0,3 дает незначительное уменьшение времени рендера, а дальнейшее понижение этого коэффициента, наоборот, дает некоторый прирост, как и у cbapoq. Ну да, где-то в районе 4-х Average face/leaf - дальше опускать не имеет смысла. Default geometry dinamic дал прирост по времени примерно 23%.
Евгении - спасибо, а также Фаине за наглядное разъяснение бинарного дерева.
2 3 4 | След.
Зарегистрируйтесь, чтобы добавить комментарий.
Эту страницу просмотрели: 393 уникальных посетителей