Render.ru

VRay 8/16/32/64/....

Paul_Winex

Знаток
Рейтинг
20
#1
Потестил размеры бакетов с целью выяснить закономерности зразмерности. Результаты:
8х8 - 114 сек.
16х16 - 71 сек.
32х32 - 56 сек.
64х64 - 50 сек.
96х96 - 48 сек. (не стандартный размер)
128х128 - 47 сек.
180х180 - 46 сек. (не стандартный размер)
256х256 - 46 сек.
512х512 - 68 сек.
1000х1000 - 146 сек. (не имеет смысла, так как при картинке 1200х900 слишком много времени считает только одно ядро, ханимая около 70% картинки своим бакетом.)

Далее хотел, чтобы протеститовать бакет 1000х1000 рендерю картинку 3000х3000, дабы задействовать подольше все 4 ядра. Но опять же, картинка не равномерная, каждая область считается отдельно по времени. Хотя бы половина ядер будет стоять на месте и ждать остальных. Я бы мог рендернуть картинку например 5000х5000, но вряд ли рядовому пользователю пригодятся такие данные. Потому надо рсчитывать относительно стандартных рамеров, скажем 1600х1200.
Табличные данные показывают, чем больше рамер бакета, тем быстрей просчет. Но в зависимости от размера картинки определенное увеличение может и задержать просчет, выдавая отдному ядру большую зону прчета. Очевидно что лучше эту зону разделить на несколько ядер. Отсюда и прирост. К тому же по крайней мере на моей машине не обязательно размер бакета ставить каких-то стандартных размеров типа 32 или 64. Зачем соблюдение этих размеров я пока не знаю.
Общий вывод - чем больше размер картинки, тем больша можно ставить бакет. Исходя из текущих размеров можно сказать что размер бакета составляет 1\5. То есть я беру длину стороны (1200) и делю на бакет с лучшим временем (256). То есть разбивка на такие зоны более оптимальной получилась.

Моя система:
Win7x64
Max 2009
Core2Quad 3.4G
8GbRAM
 

Mr.Absent

Moderator
Команда форума
Рейтинг
860
#4
Ясен перес не зацепила, это ж зависит от конкретной сцены. Обьектов, материалов, разрешения и т.д.
 

Paul_Winex

Знаток
Рейтинг
20
#5
Это понятно, но если разделить время зависящее от размера бакета и время зависящее от материала? Допусим делаем сцену с ровномерным заполнением в которой все пиксели требуют одного времени просчета. Ведь всё равно размер бакета меняет время рендера! Так что дело не только в конкретной сцене. Не про то вы подумали. Крайний случай - кода при слишком больших бакетах под конец последний бакет занимает площать, которую могли бы считать 2 бакета, то есть 2 ядра (процесса). Да, крайность, но раница есть. Другая крайность - бакет 1х1 пиксель. Вопрос в другом, стоит ли искать золотую середину или же в усреденных (стандартных) размерах особенно разницы нет? Вопрос может не интересен, но тоже имеет право быть.
 

Paul_Winex

Знаток
Рейтинг
20
#7
Ну хорошо. Допустим выводить какие-то оптимальные значения, делая эксперименты, нужно для конкретно взятой сцены. Но учитывая незначительность разницы во времени при использовании среднестатистических параметров, делать этого никто не будет, да и не выгодно тратить силы. Разве что вы спасёте 20 секунд в то время как рендерить надо 5000 кадров.
А с другой стороны, длячего то же сделана возможность изменения размера бакета. Не просто потому что это получается делать.
Тут нужно ГОРАЗДО больше экспериментов для выводов.
Для чего больше? Уже и на нескольких видна разница. Что даст большое количестко эксперементов? Или вы говорите про различное наполнение сцены?
 
Сверху