Процессор и Max

Задался следующим вопросом. Включаю рендер, запускаю диспетчер задач, смотрю загрузку процессора. Все ядра задействованы. К концу когда регионов становиться меньше чем ядер они исчезают из фрейм буфера. Смотрю в диспетчер задач и вижу, что освободившиеся ядра тоже перестали ренедерить. Т.е. макс не распределяет весь рендеринг на весь процессор, ну может только в самом начале, а в конце уже просто ядра выходят из процесса. Может это как то регулируется?

selfautopsy
никак

https://www.youtube.com/watch?v=ZlDjd_ySC0c 

Можно ещё поменять направление движения бакетов, например, не снизу вверх, а справа налево. Смотря как равномерней будет.

Yehat хоть слева на право, хоть сверху вниз, хоть "каком к верху".... если один бакет завис на тяжёлом участке то ни чего не сделаешь. Будет висеть, покуда не отрендерит. Как по мне, то размер бакета нужно регулировать исходя из разрешения картинки на выходе. Лично я использую для 1200х900 бакет 32х24 и Region Sequence - Spiral

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

Хотя само наличие таких мест, в которых один бакет считается как вся картинка по времени, это повод понастраивать там материал.

От замены мест слагаемых сумма не меняется, что-то в таком духе было в начальных класса.
От размеров бакета, например 16 или 100, разница в выигрыше будет пара процентов, которые на самом финише вылезут.

Да и пофигу, что сумма слагаемых не меняется.
За то время, пока бакет торчит на трудном месте, другие бакеты работают, а не ждут. Вот что меняется.
В этом и был вопрос топикстартера.

Можно просто мышкой в начале рендера натравить их на заведомо трудный участок и идти курить.
К концу просчёта ни одно ядро не будет простаивать.

selfautopsy

Вот я об этом давно тут писал и рисовал картинкуhttp://www.3ddd.ru/modules/phpBB2/viewtopic_p_181222.html#181222  

Нет, процент может добраться и до 10. Я всегда ставлю максимум 10х10 пикселей, независимо от разрешения, и минимизирую потери производительности. А на анимации 10% это огогого!!

Кстати, чем больше бакет, тем быстрее рендер. На те же несколько процентов.

Видимо у тебя сцена - равномерно черный цвет.
Сейчас ради прикола потестил сцену:
бакет 10х10 пикселей - 51,2 секунда (разрешение 800х600)
бакет 100х100 пикселей - 67,2 секунды (разумеется та-же картинка)

а теперь возми и посчитай проценты.

И чем обусловлено такое громкое заявление?

По теме:

Нельзя делать размер бакета меньше, чем размер сэмпла Irradiance Map, это затормозит процесс при просчете IR


PPS Еще я лично убежден в том, что любой параметр, который можно менять разработчики сделали ради каких-то целей (тонких настроек), поэтому в разных ситуациях нужно для увеличения продуктивности и над размером бакета подумать. Все, что не влияет на время в настройках пользовательских скрыто. ИМХО

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

Только отрендери с двумя размерами и выложи статистику, ок? Мне самому интересно. Меня моя теория бакетов не подводила еще

да, я еще попробую одним бакетом отрендрить, размером с готовое изображение ))))

вот на глаз, уже крупные бакеты проигрывают значительно...

НУ а как мы сравнивать рез-ты будем!? )))
А прикинь - 1 бакет размером с фулфрейм - 50% прироста ))) (и рендерить будет 1 ядро)

я в штампе пропишу размеры бакетов ) и время рендра

ииии?
нужно эту же картинку отрендерить с другим размером бакета и проследить тенденцию!

хорошо что я не верил слепо в то что пишут "большой бакет, большая скорость рендра))))"

мне кажется, или крупными бакетами шума меньше?