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

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

2009-04-20

Добротно.

2009-04-20

Спасибо, многие вещи стали яснее

2009-04-20

[quote]В любом случае, теперь вы знаете, как заставить эту заразу работать быстрее.[/quote] Эта "зараза" местным работягам деньги на жизнь обеспечивает. А вообще ладненький такой урок (4/5)

2009-04-20

Спасибо, очень познавательно. 5/5 Приятно понимать что ты настраиваешь и делаешь)

2009-04-20

Приятно видеть в авторах урока девушку )) по уроку в целом- нравяться все действия ведущии к экономии ресурсов ( наверное это неприязнь к гигантомании микрософта) на счет бинарного дерева : насколько я понял по уроку стремимся приблизиться чтобы листьев было не сильно больше 4 ? не слишком ли маленькое значение? если количество полигонов велико то дерево сильно вырастет и просто времени на проверки по ветвлениям будет уходить гораздо больше чем на перебор конечного числа листьев.

2009-04-21

Вопрос заставил поскрипеть мозгами :) Хорошо. Как Вы быстрее найдете нужное Вам слово? В словаре, в котором все слова сортированы по буквам, но внутри подраздела слова расположены как угодно, или в словаре, в котором все слова не только сортированны в группы по первой букве, но и внутри подраздела идет четкая сортировка по 2, 3, 4, n-ной букве. В официальной документации разработчики упоминают некую "критическую точку" после которой дальнейшее уменьшение Face/level coef. не дает прироста в скорости. После последней операции деления Vray ищет искомый полигон пребором треугольников, чем меньше ему приходится перебирать "втупую" "попал, не попал", тем меньше уходит времени на просчет луча. Мало того, в дальнейшем, когда мы добавим антиалиасинг, глосси-эффекты, множество источников света, количество полигонов не увеличится, но для каждого луча мы будем каждый раз проходить и проходить переборы, что совсем не оптимально... В тестах мне удалось понять, что оптимальное число для быстрого нахождения искомого треугольника - это число близкое к 4 ( не всегда это число целое, кстати), но я обязательно проведу несколько тестов, чтобы наглядно подтвердить свои слова, тем более, что сейчас как раз веду работу над классическим домом, где полигонаж зашкаливает за 5-7 миллионов на комнату.

2009-04-21

За старания Спасибо... Но тема до конца не раскрыта... - твикинг действильно крупных сцен где настройка дерева может помочь отрендерить или сократить время рендера... PS еще автор как-то пропустил момент что при уменьшении face level coef - total frame time вырос до 13 сек - или это не в счет O_o ? PSS вообще складывается впечатление что хотелось что-то важное сказать но не получилось )))

2009-04-21

впринципе неплохо видеть такие уроки от девушки,молодец 5\5

2009-04-21

[quote=A_T] PS еще автор как-то пропустил момент что при уменьшении face level coef - total frame time вырос до 13 сек - или это не в счет O_o ? [/quote] Это происходит из-за того, что бинарное деверо строится около 12 секунд. Да, предрасчет вырос, тотальное время увеличилось. Но время, затраченое на построение девера так и останется в пределах 12 секунд. Когда добавятся расчеты GI, антиалиасинга, и прочия и прочия, затратить *всего* 12 секунд для того, чтобы лавина лучей отсчитывалась максимально оптимально - тогда и будет видна вся экономия. Конечно, когда весь рендер укладывается в 15 секунд, построение дерева в 12 сказывается на total frame time. Последняя картинка отсчиталась за 7m24,9s - это вполне достояйная скорость рендера. Даже если мы и подождем 12 секунд, прежде чем начнется рендер. Разумеется, тема до конца не раскрыта, так как целью было показать только то, что режимы имеют разный принцип работы, и зная, как они работают, можно сократить время рендера без потери качества. Секунды складываются в минуты, минуты в часы, а это не только деньги, но и бессоные ночи и нервы, которые мы тратим, ожидая картинки. Конечно, у меня полный подход к настройкам сцены, и я буду писать сделующие статьи, которые, надеюсь, будут менее сумбурны. Всё-таки это первая моя попытка что-то сказать вслух.

2009-04-21

Спасибо! Очень интересно.

2009-04-21

[quote=Rajah] Вопрос заставил поскрипеть мозгами :) [/quote] На самом деле если Вы проводили тесты, то я полностью доверяю вашим утверждениям, тем более что в Ви_рее могут быть свои особенности ( хотя BSP это сейчас универсальный алгоритм трассировки, даже для игровых движков) Но на примере Приведенного словаря. Если на каждую букву ( и далее на вторую и третью...) примерно одинаковое количество слов, то картина стандартная и легче сводить к минимуму листьев. А если количество слов разное. может получиться что надо построить 100 проверок чтобы потом выбрать2 ( на распространеную букву) слова. а можно сделать 50 проверок но выбрать из 8 слов. в первом случае 102 телодвижения ( но при этом для буквы Э будет всего 6-8 телодвижений), во втором 58 ( но для буквы Э будет 16 -20). Это я все к тому что рецепт оптимального дерева сильно зависит от наполнения сцены. Кстати в Ви_рее нет теста графического представления дерева? когда видиш наглядно по цветовой гамме легко сделать поправки

2009-04-21

To Alex Kras Мы можем контролировать число операций деления. У меня ни разу не превышало 100. Честно сказать, до дефолтного 80 не доходило даже. Буквально позавчера я проводила любопытные тесты. Есть сцена с 1 миллионом треугольников, которые равномерно заполняют объем сцены. И есть то же самое количество треугольников, но которые сжаты в три раза, относительно своего первоначального объема. Удивительно, но дерево было разным, хотя полигоны не менялись. И сцена считалась совершенно по-разному. Так что ребята из хаос групп сваяли какой-то весьма интересный алгоритм :) Сейчас занимаюсь поиском объяснения этого наблюдения. По поводу графического представления дерева - увы, такой штуки нет, только несколько чисел в окне Vray messager.

2009-04-21

To Alex Kras. Дело в том, Вы задаете вопрос, связанный не сколько с построением бинарного дерева, сколько с поиском пересечения искомого луча. Это настолько сложный процесс, что объяснить этот алгоритм здесь, в комментариях, мне не представляется возможным, и объяснение этого процесса будет настолько специфическим, что, как мне кажется, совсем не будет актуалено для работы основной массы визуализаторов. Но лично мне очень интересен этот вопрос. Возможно, напишу статью об алгоритме поиска raycasts во Vray, но, как мне кажется, данная тема выходит за тематические границы этого портала. На Ваш вопрос можно сказать следующее. Даже при очень больших массах треугольников, деление сцены на два до критической массы в 4-5 треугольников и последующее хождение по уровням бинарного дерева, всё равно будет более оптимальным, чем перебирание и сравнение большего числа треугольников, чем вышеобозначеная "critical point". Однако, хочу заметить, что теоритически возможна сцена, при которой построение бинарного дерева будет абсолютно бессмысленно, так как raycasts будет искаться перебиранием всех треугольников в сцене. К счастью, это только гипотетический случай, который не встречается на практике.

2009-04-21

Alex Kras Ну и вдогонку для моего примера со словарем. Если у нас для буквы А - 1024 слова, а для буквы Э - 64 слова, то: мы будем делить слова на букву "А" 10 раз рекурсивно, а слова на букву "Э" - 6 раз рекурсивно, до получения искомого одного слова. То есть, мы не просто взяли и разделили 1024 слов на 10, а 1024\2\2\2\2\2\2\2\2\2\2 и получили 1 слово. В случае, если мы разделим меньшее количество раз, например, на 8 и 4 соответственно, то получаем 8 операции деления на два + перебор по 4-м словам = 12 операций поиска нужного слова для буквы "А", против 10 операций в первом примере 4 операции деления на два + перебор по 4-м словам = 8 операций для поиска искомого слова для буквы "Э", против 6 операций в первом примере

2009-04-21

эммм... последние отзывы определённо запутали меня. у меня есть 2 вопроса к автору: 1. повлияет ли изменение "Face\level coef" на продолжительность рендера? 2. и как это работает в сцене, где преимущественно используется vray-proxy? может конечно я чего-то не дочитал здесь... но я запутался по полной =(

2009-04-21

To subfeel А вы не обращайте внимание на мой диалог с Alex Kras, мы говорим, в основном, о теории. Перечитайте статью ещё раз, со слов "Теперь более тонко настроим то, как VRay будет раскладывать геометрию." Тут подробно объясняется, как Face\level coef влияет на скорость рендера. Что же касается VrayProxy - то все эти объекты будут рассчитываться динамически, вне зависимости от того, какой режим Вы поставите, Static, Auto или Dynamic

2009-04-21

Я к пирмеру 90% использую Dynamic, т.к. в режимах Static и Dynamic после просчета LC, при DR рендеринге, слейвы на ирмапе тупят. Главаня машина уже во всю считает, а остальные тупят, при том что в логе пишется что они подцеплены и после просчета ирмапы, на финал стартуют на ура. Вот такие чудеса. А ещё момент, если отсчитать лайт кэш в файл и потом подгрузить, то все ок. Я на хаос писал, но они мне этоже самое и посоветовали. Но тут скорее частный случай, может прелести сети или ещё чего.

2009-04-21

To MpaKo6ec Что бы ответить на этот вопрос, уточните. 1. Геометрия (сцена) лежит на отдельном file server или она записана на HDD каждой машине renderfarm? 2. Есть ли разница между конфигурацией Master и Slave машинами? 3. Пропускная способность сетки. 4. Приведите пример сцены: а. Размер проекта целиком б. Размер MAX File, размер Proxy - файлов, количество полигонов в сцене без прокси объектов.

2009-04-21

Да это прелести жизни визуализатора. Файлы кидал и на разные серверы и на мастере, и с прокси и без. Сцена не тяжелая, студийный виз объекта, все машины коннектятся без проблем, все файлы (текстуры, прокси и т.д,) подтягиваются без проблем. тут просто такой тупняк получается, если считать сходу ЛК и затем Ирмапу, то тупят. Если ЛК сохранить и поздгурзить все ок. Слейвы тупят в том смысле что просто во фрейм буфере видно только как масте считает, о слейвы не то чтобы стоят - и просто нет :) т.е. они подцеплены и сцену подгрузили и получили все что надо, но вот просто стоят и ждут чегото, бывают стартуют уже к концу расчета ирмапы, когда мастер уже проскакал все. Скорее просто мастер не успевает им Лк раздать, хотя сомнительно, т.к. при днамике успевает. А сейчас для теста лишил макс одного ядра, считали 3 из 4x, и слейвы стартанули на ирмапе)) правда к концу расчета уже, но это потмоу как сцена очень простая, интерьерка без мелочи всяких деталей.

2009-04-21

Очень интересно! Спасибо!!! Самое приятное, что такая мега-заумность от девушки)) Это редкость... Видимо, действительно, грядет революция!) Урок очень практичный! Я уже успел поэкспериментировать - результат порадовал! На маленькой сцене прирост скорости 6%. Ерунда, конечно, НО ведь все таки ПРИРОСТ! Еще раз спасибо! И целую ручку;) 5/5

2009-04-21

[quote=Oleg A.] Самое приятное, что такая мега-заумность от девушки)) Это редкость... Видимо, действительно, грядет революция!) [/quote] Присоединяюсь к высказыванию :)

2009-04-21

To MpaKo6ec Наверное, Вы в курсе, что лайткеш каждая машина считает самостоятельно? А ирду - все вместе. Я не случайно задавала вопросы, так как причина может быть в чем угодно. Если железо разное, то мастер уже остчитал лайткеш и начал считать ирду, а хосты до сих про просчитывают. Если файло лежит на файл-сервере, то в момент рассчета лайткеша происходит гоняние пакетов туда-сюда, посмотрите, если Ваша сеть загружена на 100%, то процессоры на хостах могут не быть загружены максимально. Кроме того, если при прямом соединение двух машин можно добиться заявленой скорости Вашей сетки, то при 100% загрузке сетки несколькими машинами, скорость передачи данных будет меньше, чем заявленую скорость делить на количество машин. Нодело не может быть в режиме Static или Dynamic, так как построение дерева идет ДО построения лайткеша. Или оно не строится вовсе, а строится на лету. И единственный выход в Вашей ситуации - да, считать LC в файл и подгружать его. Или переходить на другие методы многопроцессорного рендеринга. Рекомендую изучить Deadline. Хороша, чертовка! Удачи.

2009-04-21

Спасибо всем за интересные высказывания и тёплые слова. :)

2009-04-21

LC вобще-то на сколько я помню при DR только мастер считает, соответственно в этот момент все слейвы сидят и ждут (были разговоры по поводу что было бы неплохо распараллелить расчет LC но в релизе я ещё этого не видел). Как мастер заканчивает LC, то тут все начинают считать ирмапу. Вот тут то чудеса и происходят :) Deadline, RoyalRender и т.д. мне не особо необходимы, т.к. я сиквенсы не рендерю, у меня статика и юзаю DR. DR мне удобнее и быстрее пререндеры фигачить. Через Deadline есть смысл тот же NUKE на ферму зарядить, просто необходимости в этом нет.

2009-04-22

Респект

2009-04-22

MpaKo6ec Боюсь, Вы ошибаетесь. Light Cache просчитывается каждой машиной самостоятельно. В официальной документации нет четкого подтверждения этого факта. Эта причина является одной из самых распространенных задержках просчета при Irradiance Map при DR. Я могу посоветовать Вам пройти регистрацию в официальном форуме разработчиков Vray, где несколько раз эта тема обсуждалась и объяснялась самим Vlado. Форум тут http://www.vray.com/support/

2009-04-22

Да, так и есть. Сейчас глянул, все на 100% при расчете ЛК загружены.. только какой в этом смысл вобще не понятно. Странный подход. Ну все ясно, странно что раньше не замечал, почему-то был уверен что они не считают, просто я в этом смысла не вижу в том как сейчас это реализовано.

2009-04-22

MpaKo6ec Корни этого лежат в том, что Light Cache рассчитывается в несколько пассов и после все пассы суммируются. В меньшем количестве пассов будет меньше шума. Но сама технология распределения построения LC была сделана для того, чтобы можно было оптимально загрузить мультипроцовые CPU - несколько CORE - несколько пассов. Чтобы не было отличия между картинками, просчитанными на разных конфигурациях, в DR и сделали, что на каждой машине LC строится самостоятельно. Советую просчитывать LC на головной машине и грузить из файла. Ну, и потестить Ваши сцены и рендерферму в режиме Static

2009-04-22

[quote=Rajah] Чтобы не было отличия между картинками, просчитанными на разных конфигурациях, в DR и сделали, что на каждой машине LC строится самостоятельно. [/quote] Как-то странно мысль звучит. Т.е. рендерфарм из 20 разных машин и каждая считает свой лк чтобы не было отличия?.. это как? Если учесть что когда лк считает одна машина, сейвит в файл и потом все остальные машины используют эту карту для дальнейших расчетов ГИ без проблем, то зачем её считать всем машинам, я вот этого понять не могу. Мне не понятно как 20 просчитанных отдельных разных карт ЛК положительно повлияют на рендер. Я бы ещё понял если процесс был распараллелен, чтбы каждая нода фермы считала свою часть ЛК и потом сливала в одну карту и считале дальше, но ведь все не так. Единственная причина этому, которую я сейчас могу себе представить это только некий плюс в скорости от того что каждая машина держит свой ЛК и использует его, т.е. нет необходимости пересылать карту по сети с мастера на слейвы.

2009-04-22

Ушам своим не верю. Сеньёрита, вы великолепны.

2009-04-22

Не, такого не бывает. Я [s]влюби[/s] очарован. Первая девушка, которая интересуется механикой рендерера, да еще и повествует складно. Я таких никогда не видел. 5/5

2009-04-23

Мало того, что повествует складно, да еще и такими вещами оперирует и понятиями, что у меня мозг после третьей строчки начинает распухать!!! Это при том, что математические науки мне весьма не чужды!))) Молодец, в общем!

2009-04-23

Очень понравился урок!

2009-04-23

Урок супер! Конечно я ничего не понял, надо попробовать на практике. И от куда только столько знаний берётся! Автору респект и увожение.

2009-04-23

Иногда девушка это еще и "супер"-слов нет! В правительстве одна такая есть...

2009-04-24

Rajah, огромнейшее спасибо! Отличный урок)) 5/5 ^_^

2009-04-24

Rajah, огромнейшее спасибо! Отличный урок)) 5/5 ^_^

2009-04-24

ну что же... протестировав ваш урок на своей очень тяжёлой сцене при 4,5млн полигонов в сцене получил след. результаты: face\leaf coef 1.0 = avarage faces\leaf = 19,4 dram use 455mb region render time 985sec face\leaf coef 0.15 = avarage faces\leaf = 3,92 dram use 1352mb region render time 950sec экономия 35сек, потери - 900мб оперативки сжираем. [img]http://s55.radikal.ru/i147/0904/5c/1eb6c852c6ee.png[/img]

2009-04-24

cbapog Я начну немного издалека. Представьте, что у нас есть простая комната. 4 стены, пол, потолок, дырка-окошко. А на полу мы поставим жуткополигональный цветок. Миллионов намного. Поставим камеру так, чтобы он не попадал в камеру. Жмем рендер. BSP дерево будет строится на [b]всю[/b] сцену. Разложит все миллионы полигонов во много уровней. НО при поиске пересечения луча не будет бегать по всей глубине построенного дерева, так как луч будет находится быстро, ведь монстроцветка нет в кадре. И как тонко мы не будем настраивать построение дерева, прироста это не даст ни насколько. Пересечение луча находится быстро, на верхних уровнях дерева. Но как только в кадр попадает наша масса полигонов, то сразу же поиск пересечений заходит на глубокие уровни дерева. Кроме того, луч не обязательно пересекается только с одним полигоном. Луч может ( и пересекает!) множество полигонов, которые могут находится абсолютно в разных группах и уровнях BSP дерева. VRay бегает по всему дереву и ищет пересечения луча и вот тогда-то чем правильнее и оптимальнее построено это дерево, тем оптимальнее и быстрее рассчитывается raycast. Пока понятно объясняю? Теперь, что касается Вашего примера. Я не знаю, какая у Вас геометрия, как построена сцена, как настроены материалы, антиалиасинг и какие настройки GI. То, что прирост в скорости столь мал, хотя он и есть, может означать то, что raycasts рассчитываются быстро, на верхних уровнях дерева. Причины этого могут крыться в чем угодно и не видя всей картины я не могу полностью проанализировать Ваше замечание. Потестируйте на других сценах, сделайте общие виды из камер, куда попадет бОльшая часть геометрии. Проверить же оптимальность отрабатывания raycasts легко. На 1 источнике света с выключеными текстурами и выключенным GI, при Fixed 1 и сброшеных настройках Adaptive amaunt в 1, если при этом количество raycasts будет близко к цифре ширина разрешения рендера*высоту разрешения рендера, то следует разделить количество raycasts на время и полученая цивка и есть оптимальный рассчет raycasts в секунду. Если в дальнейшем это число будет менять в пределах разумного, а то и вовсе не будет скакать в сторону увеличения, значит, что raycasts рассчитываются оптимально. В Вашем примере за 1 секунду рассчитывается полмиллиона raycasts. В сцене, на который я писала эту заметку, за 1 секунду отрабатывается примерно столько же raycasts. Что касаемо трассировки одного луча - Ваша сцена в данном конкретном кадре настроена весьма оптимально. Кстати, Вы не могли бы показать, как меняется время рендера, если перевестись в режим Dynamic?

2009-04-24

Уважаемая Евгения! Позволю себе усомниться в справедливости Ваших выводов. Я не разбираюсь в дизайне интерьеров, но я разбираюсь в бинарных деревьях. Собственно, моя работа состоит в том, чтобы обучать студентов специальности "Программирование" в том числе и приёмам работы с бинарными деревьями. Свои рассуждения я проиллюстрирую несколькими рисунками. [img]http://render.ru/forum/images/upload/1225307.jpg[/img] Условно изобразим наше помещение квадратом размером 2 на 2, который для простоты разобьём всего на 4 части (рис. 1). Составим соответствующее такому разбиению бинарное дерево (рис. 2). Вершине R - "корню" дерева - соответствует весь квадрат целиком, вершине A - левая половина квадрата, вершине B - его правая половина, а каждой из концевых вершин - "листьев" - соответствует по маленькому квадратику. Такие квадратики в дальнейшем я буду называть "ячейками". Расположим в нашем "помещении" 5 полигонов (рис. 3). В каждую вершину дерева поместим список тех полигонов, которые попадают в соответствующую этой вершине часть квадрата (рис. 4). Так, например, полигон №2 попал во все списки, т.к. он содержится во всех четырёх ячейках. Дерево готово. VRay, конечно, строит дерево не столь примитивно, но сейчас это не принципиально. В дальнейшем VRay использует его так: он проверяет каждую ячейку из тех, которые пересекаются лучом (на рис. 5 они выделены жёлтым цветом). Спустившись из корня бинарного дерева до листа, соответствующего этой ячейке, VRay считывает из листа список тех полигонов, которые ему надо проверить. Уменьшив параметр Face/level coef, Вы, тем самым, уменьшили размер ячеек, т.е. помещение теперь разбивается на большее число квадратиков. Естественно, что при этом количество полигонов, попадающих в одну ячейку, уменьшилось (в Вашем примере в среднем с 18 до 3). НО!!! Ох, уж это НО! Количество ячеек, которые пересекаются лучом, УВЕЛИЧИЛОСЬ. Так что общее число полигонов, которые вынужден проверить VRay вдоль траектории луча, сократилось незначительно. Мои теоретические рассуждения подтверждает эксперимент, который осуществил уважаемый cbapog. Впрочем, очень может быть, что где-то в своих рассуждениях я допустила ошибку. С удовольствием выслушаю Ваши аргументы.

2009-04-24

Ещё раз попробую присоединить картинку: [url=http://render.ru/forum/images/upload/1225307.jpg][img]http://render.ru/forum/images/upload/1225307.jpg[/img][/url]

2009-04-24

Фаина Картинки нет

2009-04-25

доброго времени суток. спасибо за разьяснение, принцип работы и построения дерева BSP мне известен и так. что до практической части я всегда использую static mode, благо оперативной памяти 16гб и рендер 64х битный. тесты я проводил вот на этой сцене http://i036.radikal.ru/0904/5f/573df18ab8bb.jpg сегодня провёл серию тестов используя vrayscatter, посадив на местности 840 деревьев (2 вида прокси) кадр рендера http://i044.radikal.ru/0904/4d/1054a134167f.jpg результаты http://s60.radikal.ru/i168/0904/e9/c20423491fb5.png фаина, присоединяйтесь

2009-04-25

To Фаина Не могли бы Вы мне объяснить, как преподаватель программирования, такую вещь: Зачем в бинарном дереве сохранять больше треугольников, чем их есть в сцене? Пример: Взяли 1 полигон, состоящий их 2 фейсов. Vray, сделав бинарное дерево, поделил его на 1184 куска. Зачем Vray это сделал, и в каком случае ему это может помочь? Здесь лежат три картинки: http://photo.stream24.ru/users/portfolio_kazakova/1004154/

2009-04-25

Ссылка на картинку Фаины поправлена, внимательно читаем [url=http://www.render.ru/show_page.php?page_name=bbcode#0]как правильно добавлять картинки и пользоваться BBCode[/url]

2009-04-25

Дело ясное, что дело темное. Кто прав, кто виноват пока не ясно, но версия Фаины мне нравится больше, да и опыты [b]cbapog[/b] ее подтверждают.

2009-04-25

Уважаемая Евгения! Картинки не грузятся - дома с Интернетом большие проблемы. Может быть, в понедельник на работе смогу посмотреть. Если правильно поняла Ваш вопрос, то это как раз потому, что один полигон может попадать в несколько ячеек (см. рисунок № 3). Соответственно, в каждой из этих ячеек он и будет учтён. Например, у Вас total number of faces stored = 479614 и оно, естественно, не меняется. Далее смотрим: при Face/level coef. = 1 в дереве хранится number of tree faces = 1622458 полигонов, т.е. в среднем один полигон имеет общую площадь с 3 ячейками; при Face/level coef. = 0.5 значение number of tree faces = 2261852 полигонов, т.е. в среднем один полигон имеет общую площадь с 5 ячейками, - и это не удивительно: ведь размеры ячеек уменьшились, а размеры полигонов остались прежними. Во всяком случае, я эту информацию так понимаю. Сами понимаете, я в группе разработчиков VRay'я не состояла. Просто в программировании есть некоторые стандартные приёмы и логично предположить, что именно ими и пользовались при разработке VRay'я.

2009-04-25

Евгения! Я вас люблю! ))))) Коменты читал как дополнение к уроку, всё оч усваемово и ничего лишнего! спс

2009-04-26

Да-а, как говорится без ста грамм не разобраться... А слова ладно складываются

2009-04-27

господа ,а при рендере анимации (не просто пролетов) dynamic и static имеют влияние? кстати есть какой нибудь способ не пересчитывать весь ирмап а пересчитывать его локально. допустим летим над городом а внизу машины, есть ли способ запечь ирмап домов деревьев и земли а пересчитывать только области с движущимися машинами?

2009-04-27

Дааааа 5/5 конечно, но вчитываться долго, попроще бы. [smile=04] Дык объясните, если у меня память 6Гг и в сцене 1 500 000 полигонов, без прокси. Что мне надо выставить, чтобы и память на полную работала и скорость увеличилась? Всегда использую Statik, особо тяжелые сцены которые с вылетом, пускаю на полоски (тоесть через bukbuner). Dinamik в особых случаях. Увеличиваю тока один параметр, max. tree deep до 90. (ну не считая лимит памяти до 6000)

2009-04-28

[b]2 DJ Dimidrol [/b] http://render.ru/books/show_book.php?book_id=634 - урок по композинку как раз на эту тему

2009-04-29

Вечная борьба с VRay за скорость,5 лет назад рендерилось по 20 часов и тогда выкраивали секунды,сейчас мощность компьютеров в разы больше и всё равно борются за секунды.Фраза "...теперь вы знаете, как заставить эту заразу работать быстрее" будет появляться и через 10 лет,когда рендер будет длиться 20-30 секунд.А может в будущем в 3D Max будут моделировать и рендерить не только тумбочки и табуретки.

2009-04-29

полезный урок, читал с удовольствием, ибо Вирееманьяк :) 5/5

2009-04-30

подкину автору новую идейку для исследования (и урока) - использование врей фрейм буфера. его включение при рендере с использованием 32х битных HDRI карт в слоте енвиронмент овердайва, либо в врей дом лайте для расчёта освещения. т.к. буфер хранит в себе множество данных о цвете каждого пикселя (32бита, именно от сюда следует возможность регулировки яркости, уровней и т.п. прямо в буфере) это очень серьёздно нагружает подсистему памяти. при просчёте огромных разрешений (для полиграфий, либо создания качественных сферических либо квадратичных панорам) аппетиты рендера возрастают в геом. прогрессии. и очень быстро мы упираемся в то что памяти не осталось. разница в использовании фрейм буфера и не использовании при финальном рендере столь высока... что это может послужить хорошей темой для исследования. [img]http://s46.radikal.ru/i113/0904/52/d8221037b12a.jpg[/img] [img]http://s51.radikal.ru/i134/0904/dd/e44217193f2c.png[/img] если теги не сработали, то вот линки [url]http://s46.radikal.ru/i113/0904/52/d8221037b12a.jpg[/url] [img]http://s51.radikal.ru/i134/0904/dd/e44217193f2c.png[/img]

2009-05-12

Тоже не удержался от тестирования. На примере простой сценки выяснилось, что при Default geometry [u]static[/u] понижение Face/level coef. до 0,3 дает незначительное уменьшение времени рендера, а дальнейшее понижение этого коэффициента, наоборот, дает некоторый прирост, как и у cbapoq. Ну да, где-то в районе 4-х Average face/leaf - дальше опускать не имеет смысла. Default geometry dinamic дал прирост по времени примерно 23%. Евгении - спасибо, а также Фаине за наглядное разъяснение бинарного дерева.

2009-05-15

Теоретическая информация в любом случае дело нужное и полезное. Спасибо большое. Как практик скажу, что поиск оптимального соотношения этих параметров занимает зачастую больше времени чем выигранная в итоге разница. :) Да и разработчики Vray тоже не рекомендуют менять эти значения. Что касается режимов авто-статик-динамик, то при использовании 64-битных систем смысла менять статик на что-то еще практически нет, а использовать 32-бита для 3D, в настоящее время просто мазохизм. И при нынешних ценах на оперативную память, иметь ее меньше чем 6-8Gb (оптимально по цене) тоже не очень правильно. Всем удачных рендеров!

2009-05-15

Спасибо!!! Реально хороший урок. Тем более, что дизайнеры, как правило, таким вещами как память, ее распределение и т.п не уделяют внимание. В свое время я обнаружил только, то что при включении галки dynamic скорость падала в разы, но исчезали постоянные падения. После этого урока мне стало понятным почему макс падал и как этого избежать не роставшись с быстрым просчетом.

2009-05-15

В общем уважаемый Салюто всё верно подвёл. Памяти больше на борту - проблем меньше. Сам сижу на 8гб, но последнее время приходиться считать картинки в 15000х7500 и выше (до 30000х15000) и память расходуется очень быстро (даже с выкл. врейфреймбуфером). Подумываю о переходе на х58 платформу и 16гб ддр3 (самой дешёвой)

2009-05-16

урок не всем но полезный.... но я хочу сказать благодарность не автору а cbapog +за наглядные тесты по буферу..)))

2009-05-18

Полезно для лентяев, вроде меня :)

2009-05-18

[quote=vianar] я хочу сказать благодарность не автору а cbapog [/quote] всегда пожалуйста))) Вот работаю над очень комплексной сценой экстерьера турбазы, много поликов (огромный ковёр 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

2009-07-26

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

2009-07-27

TO Tigranik Когда Вы включите у Omni VrayShadows, тогда количество raycasts будет меняться. Пока Вы не включили механизм просчета теней, количество OMNI не будет влиять на количество raycasts. Речь идет именно об Omni, так как нам требовалось контролировать количество raycasts, и исключить на начальном этапе просчет raycasts к источнику света. А вот касаемо второй части вопроса, почему Vray показывает на один источник света больше, чем есть на самом деле - до сих пор мне разобраться не удалось. Но вопрос интересный. Если Вам удасться разобраться в этом вопросе, буду очень рада услышать ответ!

2009-08-15

а мне че то результат не очень нравиться, можно было и по интересней сделать в плане виза... не в обиду!

2009-08-15

To Константин Суханаев Посмеялась. Спасибо, за доставленные минуты удовольствия. Редко встречаю человека с таким прекрасным чувством юмора.

2009-08-17

спасибо! Извлек для себя полезные толики информации;) Продолжайте в том же духе!

2009-09-24

Уважаемые!!! Пожалуйста подскажите с чего начать по вирею?? я понимю тут вы обсуждаете про "Деревья" но а если дерево читает это? ;) Буду Весьма БЛАГОДАРЕН!

2009-12-04

Я не знаю все равно я не понял , так какой режим надо включать....Придется тестить и самому делать выводы.....и тратить время....

2010-04-23

Извините я ниче не понял! "Если мы исключили все лишнее, то минимум лучей, которые будут выпушены из нашей картинки будет соответствовать количеству пикселей этой картинки, так как каждый пиксель-это луч. Картинка разрешением 714х800. При умножении 714*800=571200" А как Вы так настроили что у вас при таком разрешении такое количество лучей получилось? Я кручу эти настройки и у меня ничего не получается.

2010-04-23

to ..::Klimber Quellecairion Didenkoff::.. Чтобы получить количество raycasts равное числу пикселей нужно 1. удалить все ИС из сцены ( или выключить их ) IES это так же касается. 2. Выкючить все материалы. 3. Выставить антиалиасинг в fixed 4. Выключить GI Если у Вас при выполнении всех этих действий всё равно нет равенства, то, возможно, стоит "отресетить" Vray на дефолтные настройки. Сделать это можно выбрав в Assign Renderer другой рендер, после этого снова выбрать Vray и уже тогда выполнить вышеперечисленные пункты. Если это ничего не даст, напишите мне личку, я Вам подскажу мой е-мейл и мы дальше будем говорить уже на конкретной сцене.

2010-07-21

Здравствуйте , не подскажете с чего начать если из макса только моделинг знаю ? по книгам изучил вполне нормально, Есть какие либо уроки в ВэРэе или надо на курсы идти ? http://vkontakte.ru/id9692281 если удобней скинуть то вот из контакта ссылка , заранее благодарю =)

2010-07-21

здравствуйте, не подскажете с чего начать если из макса только моделинг знаю ? по книгам изучил вполне нормально, Есть какие либо уроки в ВэРэе или надо на курсы идти ? http://vkontakte.ru/id9692281 если удобней скинуть то вот из контакта ссылка , заранее благодарю =)

2011-09-30

подскажите пожалуйста, где можно бесплатно скачать Vray для 3ds max 2010