Торрент-рендер (3ds max) torrender.net, идея, концепция и реализация Опции

[Coon]

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

А если ещё и CUDA...

[1асс]

Вот что надумал насчет распределения задачи по пирам и анализа готового.

Берем случай для анимации, когда нужно отрендерить 100 кадров, каждый рендерится 10 минут, сцена с текстурами весит 100 мегов. Понятно, что сто пиров не канает, ибо нерационально качать сто мегов, чтобы отрендерить один кадр, поэтому берем например 5 пиров, каждому по 20 кадров (вообще оптимальное число пиров может задать автор сцены, либо скрипт посчитает это число основываясь на размере сцены, времени рендера и еще каких-нибудь параметрах). Скрипт генерирует текстовый файл со следующими 5-ю строками и выкладывает в папку на ftp:
scene_1-20
scene_21-40
scene_41-60
scene_61-80
scene_81-100

5 файлов с такими же названиями присутствуют тут же рядышком. Торрент-клиент первого пира читает этот текстовый файл, берет себе один из 5 файлов и перемещает с ftp пиру на комп и запускает рендер (настройки рендера хранятся в перемещенном файле). Торрент-клиент второго пира тоже читает этот текстовый файл, смотрит, какие из 5 файлов остались, перемещает доступный файл и тоже запускает рендер. И так далее, т.е. если файла нет - значит и рендера нет. Так мы разруливаем проблему дублирующихся рендеров. Далее, если пир отменил рендер, то торрент-клиент возвращает файл обратно на фтпшник и его может подцепить другой пир. А если рендер прошел успешно, то клиент просто заливает картинку на итоговый фтпшник (вообще изначально клиенты сканят итоговую папку и смотрят какие картинки там уже есть, чтобы их не перерендеривать).

Вот как-то так, дешево и просто. Клиенты знают названия итоговых файлов, поэтому рендерить или не рендерить - определяется просто наличием или отсутствием такового файла в выходной папке.

[AnTonG]

Вот как-то так, дешево и просто.

трафик ты прикинул вообще то?

[bdancer]

1асс, ну я так понимаю все же есть какой-то lock-файл запрещающий чтение ибо проблему одновременного чтения файла это не решает (скачка файла и удаление тоже ведь время занимает).

AnTonG, а дорого щас трафик стоит?

Сообщение отредактировал bdancer - 01/12/2010, 21:46

[1асс]

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

Сообщение отредактировал 1асс - 01/12/2010, 22:27

[Exactamente]

в тред призываются системные администраторы, программисты графики и сетевые программисты о_О

Как рендер-фермы работают? По сути, надо сделать это же, с добавляющимися-отпадающими машинами и автоматическим распределением прав между ними. Вообще, сомневаюсь, что это будет продуктивно при средних и малых рендерах. Я только немножко читал об этом, но в дата-центрах и всяких рендер-фермах широчайшие каналы между серверами. Если гигабитный канал покромсать до пары мегабит, то только за счет времени на передачу общее время вырастет на порядок (ну тут надо считать подробнее, на самом деле).

С файлами на фтп совсем несерьёзно. Скачать, удалить, потом закачать, если передумал А если я просто кабель выдерну - как вы себе этот файл вернёте?

А как раздавать "рейтинг"? За нарендеренные пиксели или количество кадров (разная сложность)? За время рендера (разные производительности)? За что (разные вопросы))?
Почему-то вы забываете про "рендер-треккер". Раздавать задания должен он, а не какие-то файлы на фтп))


Лучче всего дождаться гугло-ОС, и когда они будут продавать виртуальные серверные мощности клиентам ОС: "аналог и7 40 баксов/мес, аналог п4 2 бакса/мес" - к тому времени и интернеты расширятся, и никто не будет знать проблем

Сообщение отредактировал Exactamente - 01/12/2010, 22:41

[bdancer]

1асс, ну тут фишка в том что два и более клиентов могут одновременно считать файл описаний (фтп ведь обеспечивает многопользовательский доступ); до этого другой клиент может начать перемещать файл с фтп на сторону клиента (но файл то еще на сервере будет) - соответственно у этих двух будет неправильное состояние да и еще они начнут перемещать тот же самый файл. Короче будет косяг Поэтому надо либо блокировать чтение (по-простому lock-файл - просто файл: клиен начав чтение создает его, по завершению удаляет, соотв. пока он есть чтение для остальных запрещено) либо как-то хитрее организовывать доступ.

Так что трафик только на скачку сцены

+ трафик если надо вернуть сцену.

[AnTonG]

скорее авто удаление.

[KuvicK]

всё равно на выходе "42" получится

[Exactamente]

http://en.wikipedia.org/wiki/Render_farm
http://en.wikipedia.org/wiki/Parallel_rendering


с плагинаме надуманная проблема
В профиле юзер-визер ставит галочки: что у него есть - то ему и посылается для виза.
Рендеринг надо делить глубже, на уровне самого процесса рендера, а не файлов. Почитайте про хромиум, например: http://chromium.sourceforge.net/doc/index.html

Без людей, занимающихся этим несколько лет, децки сат получается, а не разговор

Сообщение отредактировал Exactamente - 01/12/2010, 22:51

[1асс]

фтп я предложил только как пример, т.к. сам с ним работал. Учитывайте, что скачка сцены занимает приличное время и вероятность того, что пиры скачают ее одновременно и полезут за файлом с описанием рендера (одним из 5) ничтожно мала. Файл этот если пропадет - черт с ним, автор может его перезалить отдельно за секунды потом, либо его можно достать из какой-нить архивной папки там же на фтп или вообще сгенерить на лету. Рейтинг раздавать за адекватность))))))))) Нет ну такие вопросы про рейтинг сейчас это несерьезно, на них ответы будут потом, пока что достаточно того, что учитывать рейтинг вполне возможно. Ессна технических проблем тут невпроворот, потому и обсуждаем пока что только идею и концепцию.

Ежели у кого есть другая концепция - с рендер-трекером, т.е. системой, которая раздает задания и следит как и что - плиз велкам.

Сообщение отредактировал 1асс - 01/12/2010, 22:58

[Exactamente]

Рейтинг - это и есть концепция, идея. Что, а не как. Собственно, рейтинг есть основа всей задумки. Потому что даром не все готовы и для расшифровки генома отдать свои мощности - за высокую и перспективную идею, а не чью-то личную выгоду

Делать это планируете вы лично, или куда? От этого стоит отталкиваться в рассуждениях.

На самом деле, если подойти серьезно, затея тянет на тяжеловесный такой, серьёзный (внимание, модное слово) стартап. А лет через 5 после реализации, а то и раньше, имеет шансы быть купленной автостолом)))


>Ежели у кого есть другая концепция - с рендер-трекером, т.е. системой, которая раздает задания и следит как и что - плиз велкам.
А как же без неё? Клиент подключается к треккеру, делает запрос на рендер или сообщает о готовности к работе, треккер принимает и обрабатывает запрос или даёт задание.
еще проблема с мощностями = "скорость" сидов. Может быть, что кто-то на кулькуляторе примет задание и будет рендерить его полмесяца, тогда как по=хорошему оно считает полсуток.
а, и еще терминология: сиды - те кто рендерят, личи - те кто заказывает рендеры, пиры - все вместе. А то вы всё напутали в первом посте

Сообщение отредактировал Exactamente - 01/12/2010, 23:12

[Evgen]

Как теория - гуд, на практике - бессмысленно.

Имел дело с большими фермами на серъёзном оборудовании неоднократно - даже при условии многотысячных вложений, подобные системы имеют свойство повисать,тормозить и глючить. Ещё ни разу не приходилось видеть ферму из более чем 20-ти машин без глюков.
Кол-во необъяснимых косяков прямо пропорционально количеству задействованных нод.

Технологически построить нормальную работу подобного сервиса на усилиях пользователей - невозможная задача. Если сцену в 600 мегабайт для рендера десятки кадров или больше(дистриб или нет, не важно) начнут с веб-сервера высасывать пару десятков пользователей будет следующее:
1. автор сцены отрендрит у себя картинки быстрее, чем каждый пир скачает себе хотя бы часть его сцены
2. Вы получите весёлое письмо от хостера по-поводу забивания канала и жесточайшего траффика или вам просто втихую зашейпируют канал (в случае если трафф будет бесплатный)
2а - если траф платный то ещё более бесмысленно.
3. Сайт вместе с серверной частью ляжет в результате подобного эксперимента и "быстро отрендрить" уже точно не получится.

Количество битых бакетов,страйпов,кадров которое будет приходить от пиров, будет очень большим. инфа 100%
Серъёзный спец, которому действительно "горит" отрендрить имейдж и уложиться в сроки, стукнется в коммерческую рендерферму где гарантии получить красивую картинку "за быстро" будут значительно выше.

Про хардварную часть раздающего сервера можно не говорить, это должна быть очень серъёзная железяка.
всё это касательно большого хранилища-сервера.

Что касается торрент-системы, то пока автор сцены "отдаст" свою сцену на рендер в сеть, пройдут сутки, потому что тянуть с него те самые 600мб будут сразу несколько человек с низкой скоростью. за сутки можно отрендрить многое "на коленках"
И опять - анимацию рендрят в 32 бита по пассам. в хд это несколько гигов. Эти несколько гигов автор должен слить у клиентов обратно, а если клиент отвалился с большой порцией кадров или бакетов? как проверять такие вещи? постоянными пингами?
На мой взгляд также будет очень проблемно контролировать версии софта на машинах клиентах, и даже одинаковость версий не гарантирует идентичность отрендренных результатов. Вспоминаем моргающие прокси виреевские и пропадающие карты в ментале и вирее то в страйпах, то в бакетах, то в кадрах, эта ситуация характерна даже для одинаковых по конфигурациям машинах в блейд-системах, что уж там говорить о клиентских тазиках.
Как эксперимент - интересно, но в условиях бесконечных глюков даже на локальных фермах с гигабитными скоростями, идея будет сложно-выполнимой.
Опять же, про мотивацию рендер-клиентов тоже нельзя забывать. Если человек хочет рендрить чужие сцены для того чтобы потом иметь возможность отрендрить свои, так он лучше возьмёт и сразу отрендрит свои сцены локально

[windoors]

1асс, идея хорошая, одобрямс, почитайте также про renderfarm.fi и boinc, как у них всё организовано, и с какими проблемами сталкиваются.

Также довольно много времени понадобится на запуск и раскрутку такого проекта.

Evgen, ну с мотивацией всё как раз просто, у меня сегодня, предположим, по ночам простаивает 10 компов. А через полгода мне придётся рендерить большой и длинный ролик. Лучше я его отрендерю за свой "рейтинг" бесплатно, чем отдам 5 килобаксов частной рендер-ферме.

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

Сообщение отредактировал windoors - 01/12/2010, 23:40

[Spear]

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