Пару лет назад меня попросили написать ликбез по сетевому рендеру в блендере.
Я слегка увлёкся и получилось то, что представляю вашему вниманию.
Обзор так и не опубликовали до конца на сайте blender3d.org.ua, хотя pdf там можно найти. Прошу сохранить, может быть кому-то будет интересно.
Сетевой рендер в блендере
Это руководство было написано с целью продемонстрировать возможности блендера в этом
сравнительно новом для него амплуа.
В течение вот уже многих лет такие программы как 3Dstudio используются по сети для совместной работы или рендера, в Блендере же эта возможность появилась сравнительно недавно. С выходом в свет короткометражного фильма Sintel авторы продемонстрировали рендер студию, на которой они работали при создании фильма, а также посетовали на то, что для сетевого рендера им пришлось использовать стороннюю разработку вместо встроенного в Блендер 2.5 сетевого рендера, так как к тому времени он был не в состоянии обеспечить студию стабильным и быстрым результатом.
Посмотрим, как дело обстоит сейчас, и заодно сравним внутренний сетевой рендер Блендера
с плaгином LuxBlend, который недавно получил поддержку OpenCL.
Internal netrendering
С появлением Блендера 2.5 необходимость иметь хоть какой-то сетевой рендер внутри программы послужила причиной моментального включения в неё netrender кода, написанного, как и большинство плaгинов, на Питоне Мартэном Пуарье (Martin Poirier).
Идея оказалась неплохая: использовать внутренний рендер Блендера, что должно было гарантировать идентичность картинки, обработанной локально или удаленно; централизацию управления на мастер-сервере; достаточно простое управление серверами и быструю, не сложную установку.
Однако первые тесты показали, что многое еще предстоит, и в настоящий момент плагин хотя и поставляется внутри дистрибутива, активировать его надо в ручную.
Установка
Нетрендер в блендере разделен на три составляющие:
Клиент — Посылающий работу на мастер-сервер
Мастер — Получающий работу от клиентов
Слейв — Зависящий от мастера сервер, обрабатывающий кадры рендера
Клиент
Это может быть любая машина с установленным Блендером; когда сцена готова, настраиваются ip и порт мастера, принимающего запросы, устанавливается количество необходимых кадров на рендер, затем задача отправляется на мастер, который распределит её между остальными серверами.
В интерфейсе клиента присутствуют следующие варианты:
Animation on network — отсылается вся работа целиком, как только готовы первые кадры, они передаются клиенту в формате .exr для отображения в редакторе.
Send job — посылает все выделенные кадры на мастер сервер, после нажатия этой кнопки должно появиться «Job send» в информационном окне, это может занять какое-то время, если ваш .blend и текстуры занимают достаточно места. Еще больше времени это займет, если мастер находится вне локальной сети и канал к нему ограничен.
Может даже показаться, что Блендер завис, проверьте сетевой трафик и убедитесь, что клиент начал передачу данных по сети. Этот вариант сразу освобождает Блендер для сдедующей задачи, так как он не ждёт результата мастера.
Send current frame job — Отсылает только выделенный кадр, при этом имейте в виду, что, как и в остальных случаях, необходимо послать всю информацию (.blend и текстуры), так что времени уйдет на это столько же, как и при пересылке всей работы. Результата не ждёт, моментально освобождая клиент.
После того, как мастер примет работу, начнется передача всего файла и текстур свободному слейву, из этого следует, что лучше располагать их в одной локальной сети, иначе можем получить большой расход трафика и ещё одну точку потенциального таймаута.
То, чего мы пытаемся достичь, — это, нажав на кнопку, продолжить работу, не задумываясь над тем, какой
именно сервер будет заниматься рендером, а также о проблемах, которые при этом могут возникнуть.
Время от времени можно поглядывать на встроенный в мастер web-интерфейс (доступ к нему можно получить, нажав на «Open Master Monitor» или введя в браузере (http://host:ip) и забирать готовые кадры. Мистики в работе слейва нет, это дистрибутив Блендера, которому через параметры передается файл и номера кадров на рендер; как только задача будет готова, он передаст результат в формате .exr на мастер, .log файл и примет следующую порцию кадров.
Мастер, с другой стороны, это гораздо более сложный код, задачей которого, помимо взаимодействия с клиентом, является распределение работ и их кадров между доступными слейвами. Баланс нагрузки пока не отшлифован, и сложно предсказать, кто именно получит следующий кадр, тем не менее в общем со своей задачей он справляется, по крайней мере мне не приходилось видеть простаивающие слейвы при доступной работе.
Забираем результат
Когда несколько кадров готовы, мы можем забрать их с мастера, тут в настоящий момент есть по крайней мере две детали, о которых, на мой взгляд, стоит рассказать.
Во-первых, блендер работает в формате .exr, на деле это означает, что каждый готовый кадр будет сохраняться в открытом формате HDR фотографий, который даёт хорошие возможности для пост-обработки, но далёк от идеала в плане размера. Таким образом, наша фотография, сделанная на одном удаленном сервере, может очень запросто отнять больше
времени на загрузку, обработку и передачу, чем если бы мы делали рендер локально.
Скажем, наш .blend файл занимает 1мб + еще 512кб на текстуры, это 1.5мб только на «подъём» работы на мастер, мастер отдаёт эти 1.5мб слейву (всё равно при одном кадре большее количество задействовать не удастся), слейв делает рендер за 10минут и отдаёт .exr файл на мастер, если было задано FullHD-подобное разрешение, то за исключением случая машины 90х годов или очень хорошего клиент-мастер соединения, кадр мы получим многим позже, чем если бы мы использовали локалный рендер.
На этой ноте позвольте сделать небольшое отступление: дело в том, что, во-первых, сетевой рендер чаще всего используется студиями в локальной сети, при канале не меньше 1гб/с, что сильно меняет дело. Во-вторых, во многих устоявшихся программах для редактирования трёхмерных изображений есть возможность использования нескольких машин при обработке одного кадра, происходит банальное деление картинки на части, равные количеству серверов, либо используются другие методы, которые позволяют уменьшить время, затраченное на рендер пропорционально количеству задействованных серверов.
Так как в блендере этой функции пока нет, очевидно, выгодных результатов можно добиться лишь при анимировании сцен с достаточным количеством кадров, чтобы компенсировать задержки при загрузке и приёме файлов. Кроме того, не стоит также забывать про возможность полностью разгрузить клиент после отдачи материала на рендер, что может оказаться очень кстати, если необходимо продолжить работу над другим проектом.
Инструменты
Для минимальной установки необходим один компьютер-клиент и один мастер/слейв, так как обе функции может реализовывать один компьютер с запущенными мастер и слейв серверами одновременно. Скорость рендера будет напрямую зависеть от скорости слейв машины.
Плюсы
-Простота установки — необходима лишь активация плагина и настройки, так как она производится через интерфейс блендера
-Полная разгрузка клиента сразу после отдачи работы
-Масштабируемость вплоть до количества серверов равного количеству кадров
-Идентичный локальному рендер — нет необходимости что-то настраивать с прицелом на работу по сети
-Теоретическая совместимость между всеми системами. — Вы можете запросто пересесть с windows на linux и отослать работу, в то время как один из слейвов из линукса превратился в макинтош (кстати, это заслуга питона, на котором пишутся плагины для блендера)
-Обещающие коллективные возможности — на один мастер теоретически могут одновременно отправлять работу не ограниченное количество клиентов, мастер сам распределит их между доступными слейвами
-Баланс нагрузки — позволяющий надеяться на то, что при получении небольшой работы мастер отдаст ее одному из слейвов, как только тот закончит порцию кадров (chunk-size), даже если очередь не пуста
-Забираем только нужные нам кадры по мере их готовности из любого браузера или блендера
-Возможность забрать только .jpg кадры, не нагружая канал, оставив тяжёлые .exr файлы на
сервере
Минусы
-Некоторые трудности при работе в интернет — если связь с мастером прерывается, приходится начинать передачу еше раз, удаляя при этом неудачные попытки
-Произвольные тайм-ауты — (в последних версиях их заметно меньше)
-Нет возможности работы нескольких слейв-машин над одним кадром
-Нюансы с внешними файлами – (например, текстурами) при совместной работе на разных операционных системах. Имели место быть досадные ошибки при подключении линукса к Win и макинтошу.
-Некоторые функции пока не работают — (из примеров можно отметить видео вместо текстуры)
-До начала рендера слейв будет некоторое время простаивать, делая препроцессинг (идентично обычному рендеру, это минус лишь при сравнении с люксрендером)
-При остановке мастера — все слейв-сервера моментально отваливаются и поднимать их приходится руками, это тем более странно, если учесть, что при подёме слейва он будет покорно ждать соединения вне зависимости от того, найдет он мастер сразу или нет
-Любое изменение в настройках мастер или слейв серверов влечет за собой предварительную настройку оных в блендере и затем копирование готовых .blend файлов на каждый сервер
-При аварийном завершении процесса мастер сервера мы потеряем последнею работу; необходимо корректно завершить работу мастера для того, чтобы можно было продолжить рендер с того же места или забрать результат без прямого вмешательства в структуру файлов (все готовые кадры в формате .exr скорее всего окажутся на месте).
Lux-рендер
Люксрендер представляет интерес в рамках этого обзора только для сравнения его возможностей с возможностями внутреннего сетевого рендера в блендере, о его преимуществах и недостатках есть где прочитать.
Начиная с версии 0.8 в люксе появилась возможность задействовать мощность современных видеокарт для просчитывания пересечений света посредством OpenCL.
Сетевой рендер в люксе продвигается под слоганом «CPU против GPU? CPU + GPU + сетевой рендер — лучше», в будущем разработчики обещают расширить применение видео карт в рендере, пока же не стоит надеяться на чудо, видео карта вряд ли загрузится больше 30%, хотя определенный прирост производительности наблюдать можно уже сейчас.
В отличие от внутреннего сетевого рендера — Люкс может объединять несколько серверов для работы над одним кадром, мастер-сервер не предусмотрен, его функции частично исполняет клиент. Вся система сводится к одному клиенту и нескольким слейв-серверам, как только после использования люксбленд плагина работа попадает на клиент, вся геометрия сцены передается на слейв, и тот просчитывает несколько сэмплов. Результат будет передан на клиент через некоторый промежуток времени, там он пересечётся с результатом локального рендера, и на выходе мы получим картинку с большим количеством семплов, чем если бы слейв не участвовал в процессе.
Инструменты: Один клиент и один сервер, при этом они работают в паре и дают теоретически линейный прирост производительности.
Плюсы
-Объединение какого угодно количества слейв машин для работы над одним кадром
-Наглядное представление о степени завершенности обшей работы над кадром
-Возможность чередования рендера нескольких кадров для анимации
-Возможность задействовать мощность не только CPU, но и видеокарты каждого слейва при условии поддержки технологии OpenCL и серии выше ATI 4000
-При необходимости можно сохранить результат и продолжить рендер позже
Минусы
-Клиент невозможно разгрузить, как только он будет остановлен, люкс сервер отчистит очередь и перейдет в ожидание нового клиента
-Эгоистичная система коллективной работы «кто первый встал — того и тапки», два клиента на один слейв подключаться не могут
-При большом количестве серверов их добавление в список можно сравнить с работой файла hosts, что как минимум неудобно
-Если, не подождав окончания работы, после нажатия кнопки quit закрыть клиент, особо загруженный слейв может отвалиться, перезапуск необходимо будет реализовать вручную, так как иначе он продолжит ожидание несуществующего клиента.
Установка
В расчёте на то, что будет использоваться сетевой рендер люкса в отдельных случаях, когда необходимо получить картинку с трассировкой лучей, а в остальных внутренний сетевой рендер, можем поставить и то и другое.
Установка Люксрендера
Сначала идём на сайт и скачиваем файл tip.zip, это версия, находящаяся в разработке, если у вас версия блендера новее 2.58, лучше использовать её, а не стабильную сборку.
Далее распаковываем архив в папку плагинов и запускаем блендер, в меню плагинов активируем люкс. Нам будет необходим сам люкс, который можно взять здесь, мне кажется для наших целей лучше подходит не Installer, а Archive, но это по вкусу.
Те, кто уже имел дело с этим рендером, просто настраивают всё под себя, не забывая о том, что поддержка OpenCL доступна только при выборе: “Render:Hybrid (CPU+GPU)”, “Surface integrator: Path” и в “Advanced>Light strategy: one”, иначе выбираем опции по усмотрению и оставляем “Sampler: Traditional CPU”. Далее задаем путь до нашего рендера в “Path to LuXrender installation”, и можно считать, что полдела сделано.
Установка сервера подробно описана на страницах wiki, главное, это открыть соответствующий порт на сервере для доступа извне, в принципе достаточно вот такой команды: luxconsole -s -p 10001
При этом люкс будет слушать на TCP порту 10001 (-p) в режиме сервера (-s), а нам большего и не надо.
Возвращаясь к клиенту, настраиваем LuxRender networking, добавляя в список наш сервер, например так: hostname:10001 или IP:port.
При нажатии F12 должно появиться окно люкса и во вкладке Network мы увидим наш сервер. Во вкладке Log, ошибок, связанных с соединением, быть не должно.
Проверяем загрузку сервера, если видим процессоры под 100%, значит как говорится «пошла вода в хату» и мастер начнет отдавать семплы через промежуток времени, указанный в “Upload interval” опции блендера. Если связь не была установлена, об этом можно будет узнать из логов, скорее всего порт на мастере не открылся, можем проверить, запустив на него telnet и написать что-то в консоли, на сервере вы должны видеть набранный текст.
Вкратце лог содержит записи похожие на:
[192.168.2.3:10001] 00:00:36 — 6T: 3.67 S/p 78.79 kS/s 99% Eff 77.86 kC/s — Using CPU
[сервер: порт] время, в течение которого сервер делает работу — количество ядер: количество Сэмплов на пиксель Количество семплов в секунду (в тысячах) Процент эффективности кадра Усредненное значение между количеством Сэмплов в секунду и эффективностью, последнее означает используется ли на сервере OpenCL для рендера.
Вот еще пример:
[192.168.2.4:10001] 00:06:38 — 4T: 25.92 S/p 51.20 kS/s 99% Eff 50.51 kC/s — Using CPU
Переводим:
После 6:38 минут рендера, сервер 192.168.2.4 на порту 10001 успел получить 22.92 сэмпла на пиксель при скорости в 51.20 тысяч Сэмплов в секунду и 99% эффективности его работа оценивается 50.51 тысячам взносов в секунду при использовании только центрального процессора.
Установка внутреннего сетевого рендера
Всё необходимое для работы входит в состав блендера, активируем плагин netrender в настройках, в соответствующем разделе выбираем netrender и приступаем к настройке.
Сначала легче настроить мастер, выбираем порт, servername оставляем пустым для того, чтобы была возможность также принимать запросы на новых интерфейсах без необходимости настраивать всё заново.
Временной папке в линуксе лучше дать отдельный раздел на жёстком диске, главное не забыть его создать, иначе сервер не запустится. Broadcast оставляем включённым, в случае если мастер будет находиться в локальной сети, тогда клиент сможет найти его сам, однако для этого понадобится открыть ещё один порт UDP (8000). Clear on exit не рекомендую, лучше иметь возможность возобновить работу, а экономить на свободном месте — не наша задача.
Дальше пользователи графики могут смело нажимать «Start service» и продолжать настраивать слейв сервер.
Остальные сохраняют .blend файл с названием master.blend, это конфигурация для нашего окружения, она пригодится нам, если сервер не имеет графического интерфейса и на нем нет возможности провести настройку. Готовый файл отдаем на сервер, также нам понадобится файл startup.blend, в нём сохраняется профиль пользователя, без него блендер просто не
поймет, что ему нужно активировать плагин сетевого рендера, копируем его в директорию пользователя: (.blender/версия блендера/config/startup.blend), затем можем запускать сам сервер из папки блендера:(./blender -b master.blend -а)
Это означает всего-навсего «запустить блендер (./blender), прочитать файл (-b) и делать рендер всех кадров (-a). За последний параметр отвечает сам нетрендер, (-а) пишем только для старта, и это не означает, что будет всегда производиться рендер всех кадров.
После этого должна появиться легенда о том, что сервер ждёт работы, проверяем, зайдя на наш ip: наш порт — это веб интерфейс мастера, через него мы сможем управлять работами и следить за их прогрессом, также он позволит нам быстро забрать готовые .jpg файлы, но об этом позже.
Итак, запускаем блендер, настраиваем его на работу как Client в настройках сетевого рендера, прописываем IP и порт или нажимаем на кнопку с двумя стрелками, если на мастере мы указали Broadcast, как только мы подключимся, можно будет отправлять работу, в окне браузера мы увидим, что ей был назначен номер и что она находится в состоянии Queued —
ждущем режиме, при котором не происходит рендер, так как мастер для этой цели не годится, а слейв мы еще не настроили. Что ж, давайте исправим это упущение.
Настройка слейва
В графическом интерфейсе всё просто, выбираем Slave в опциях нетрендера и находим мастер. Количество потоков (threads) должно быть равно количеству ядер процессора (владельцы intel могут поэкспериментировать). Оставляем Auto-detect за исключением тех случаев, когда за слейвом необходимо делать что-то помимо рендера, так как в этом случае
получим полную загрузку всех ядер. Thumbnails это отдельная тема, дело в том, что если у нас есть несколько слейв-машин, в случае краха удобнее собирать информацию с одного места, а не заходить на каждый сервер, лучше оставить эту опцию выключенной, Clear on exit в этом случае можем активировать, поскольку заполнять жесткий диск на каждом слейве
дубликатами сомнительное занятие.
Если вам нужно запустить слейв на сервере без графического интерфейса, просто сохраните .blend файл и загрузите на сервер, метод запуска идентичен мастеру, легче чтобы не запутаться использовать название скажем slave.blend.
Пробный запуск
После подключения к мастеру наш слейв должен принять у него работу и начать рендер, через количество кадров заданное параметром “chunk-size” в клиенте он отдаст готовую часть работы на мастер и можно будет посмотреть на результат через веб, либо загрузить в блендер кнопкой “get frame”. Существует множество программ, позволяющих загружать
список файлов с сервера, на вскидку flashget под windows или wget под linux, для последнего команда загружающая весь список:
wget http://сервер:порт/thumb_номер работы_{первый кадр..последний кадр}.jpg
например:
wget http://192.168.2.3:10001/thumb_1_{1..20}.jpg
Через flashget: Правая кнопка на иконке>Add new>Add batch download>http://192.168.2.3:10001/thumb_1_(*).jpg, затем ниже устанавливаем условие на загрузку кадров.
Дополнительные настройки
В случае нехватки памяти на слейв сервере, увеличив количество „кусков“ кадра в „Render>Performance>Tiles“ можно добиться освобождения части RAM пожертвовав увеличением простоя при загрузки нити процессора.
Если геометрия на сцене или скорость сервера не позволяют сделать рендер за время меньшее пяти минут, скорее всего произойдёт разъединение мастера и слейв серверов.
Чтобы решить эту проблему, внутри файла „blender-версия-linux-glibc27-x86_64/версия/scripts/addons/netrender/master.py“ находим переменную „self.slave_timeout“ и присваиваем значение равное количеству минут, которые мы рассчитываем займет рендер „chink-size“ кадров у каждого слейва (ориентируемся естественно на слабое звено).
Если нужно посмотреть общую статистику работы, можете воспользоваться этим скриптом (только под *NIX):
blenderartists.org/forum/showthread.php?233628-Netrender-AWK-statistics-script
На этом всё, красивых всем рендеров.
Автор: Wintch
