6 мая 2012 в 23:24

Опенсорс-фотореализм на GPU: Cycles Render

С развитием технологии GPGPU, на рынке появилось немало рендеров на GPU, среди них iRay, V-ray RT, Octane, Arion. Но, сообщество opensource не дремлет, и появились по-крайней мере два известных мне свободных рендера на GPU: SmallLuxGPU и Cycles Render. Хочу поделиться впечатлениями о последнем.

Cycles Render — unbiased рендер, с возможностью рендеринга на GPU (CUDA и OpenCL для ATI). Лежит в коробке с Blender, который работает на Windows, Linux, OSX.


Cycles Render, авто с процедурной текстурой, FullHD готовилось 2 мин на GTX580.

Блендер меня мало интересовал, даже не смотря на некоторые известные мне достоинства: открытость, легкость инсталлятора, скорость работы. Пересесть консерватору с 3д макс на Блендер крайне сложно: другое управление, «все не так!». Но, будучи повернутым на теме анбиас рендеров, тем более на GPU, решил таки опробовать Cycles, за одно и Блендер подучить (на момент опубликования статьи версия 2.63).

Небольшой ролик об интерактивности, и о том, как оно все работает:

Режим рендеринга с помощью Cycles можно сделать прямо в активном вьюпорте (это не новшество, просто удобство), либо следить с камеры за изменениями в сцене в реальном времени.

CPU vs GPU
Ядра процессоров архитектуры x86-64 имеют очень громоздкий набор команд, требующий большой площади кристалла. Из-за этого сложно расположить много ядер на CPU, но в однопоточных приложениях x86 показывает себя с лучшей стороны.
Но рендеринг — дело многопоточное до безобразия. Главное здесь — большая скорость операций с плавающей точкой, и оперируя большим количеством данных требуется хорошая пропускная способность памяти. GPU подходит для этих целей намного лучше.
Но GPU, как платформа, изначально заточенная под аппаратную растеризацию (OpenGL, DirectX) достаточно тяжело адаптировать под задачи GPGPU. Многие программные решения, которые с легкостью решаются на CPU требуют немалых плясок с бубном на GPU через фреймворки типа CUDA и OpenCL. Зачастую из-за сложности реализации алгоритмов, слабой оптимизации фреймворков (например OpenCL) от программирования на GPU отказываются.
Для математических операций (рендеринг, расчет физики) нужна новая архитектура процессора с небольшим набором инструкций, большим числом ядер и набором аппаратных решений для быстрых сложений и умножений чисел с плавающей точкой. Либо ждать, пока GPU аппаратно и программно лучше адаптируют под нужды не-графических вычислений.
Но в виду отсутствия таковой архитектуры и не желания ждать, пока все «станет круто», разработчики по всему миру уже вовсю осваивают GPU. Конечно же, рендеринг на GPU увеличивает скорость рендеринга в несколько раз.

Есть небольшой бенчмарк, где вы можете попробовать свое железо.
Мое время рендера (core i5 2500 vs GTX580).
Windows 7 64bit: CPU 5:39:64 CUDA 0:42:54. В 8.07 раз.
Ubuntu 12.04 64bit: CPU 3:48:77, CUDA 0:39:03. В 5.84 раза.

Было бы интересно разузнать о скорости рендеринга на последних топовых Радеонах.

Интересен тот факт, что Юниксы превосходят Windows в скорости рендеринга на CPU. Чтобы вы не думали, что моей винде плохо живется я накопал доказательства: раз (4-е сообщение) и два (на англ). С чем это связано — не хочу гадать, не знаю.
UPD: уже знаю, спасибо Lockal за комментарий.

Отрыв GPU так же зависит от железа, и сложности процедурных текстур. В сложных процедурных текстурах отрыв GPU немного сокращается. Кстати, о них.

Процедурные текстуры
Чтобы создать желаемый материал необходимо обладать навыками построения шейдеров с помощью нод графа. Как оно работает попробую объяснить на примере:

Где (мне показалось, что задом наперед будет понятнее):
1. Выход. Material Output необходим для вывода функции на поверхность.
2. Шейдер смешивает составляющую краски (4) и глянца (5) в соответствии с параметром (3).
3. Коэфициент отражения глянцевой поверхности (коэфициент отражения зависит от угла падения, чем перпендикуярно поверхности отражается меньше, чем по касательной)
4. Шейдер смешивает шейдеры 6 и 7 в равных пропорциях (Fac=0.5).
5. Зеркальное отражение (лакированная поверхность).
6, 7. Диффузная и глянцевая (шероховатостью 0.35) составляющие краски.
8. Преобразователь цвета. На входе Hue параметр fac текстуры (9) от 0 до 1. На выходе — смещение света относительно красного.
9. Генератор ячеек случайного цвета (r,g,b), где fac — интенсивность (от 0 до 1).

Освоив принцип работы, можно немного поиграться:

Можно комбинировать любые текстуры и типы поверхностей. Имеется FullHD.

Можно создавать источники света отрицательной светимости.

Свет, антисвет.

Процедурными можно сделать не только поверхности, но и окружение: небо, тучи и т.п. А с помощью нодов можно также настроить постобработку изображения.

Непонятности
Ну сначала для меня этот вопрос был непонятностью, но затем я понял, что к чему. Тут, как я понимаю, вопрос стоит между производительностью и удобством, и это относится ко всем анбиасам на GPU (не грешит этой особенностью Arion Render и все анбиасы на СPU).
В них существует glossy material для зеркальных и глянцевых отражений, и diffuse — для рассеянных.
Дело вот в чем. Если рассеивание отсутствует, то величина случайного отклонения в точки падения луча равна 0, и луч отражается зеркально. Если 1 (максимально) — то луч может отразиться в любом направлении в полусфере отражения. То есть если мы возьмем зеркало и дадим ему максимальную шероховатость — то получится белая бумага. По крайней мере я к этому привык, пользуясь Максвеллом.

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

Тоже самое касается translucent шейдера. Translucent переводится как непрозрачная среда, однако в рендеринге имеется в виду диффузное преломление. То бишь Translucent, это матовое стекло (Glass шейдер с матовой шероховатостью).

По этим картинкам можно сказать что Translucent выглядит нормально.

Ясно то, что при шероховатости Glossy и Glass близкой к 1 (визуально, больше чем 0.7) лучше использовать Diffuse и Translucent.

Подробная информация по свойствам шейдеров есть тут.

Эти вопросы не принципиальны для получения реалистичной картинки, но все же, хотелось бы добавить какую-нибудь более обобщающую и правдоподобную модель отражения для тех, кто к таким привык.
Например: задавать шероховатость поверхности каким-либо одним параметром, как это сделано в Maxwell, Fry, Indigo, Lux а особенности распределения отражения — дополнительными ползунками и галочками. А для самых суровых — управлять распределением отражения с помощью кривых Безье. Пусть, в ущерб производительности.

Кроме того, Cycles render грешит еще такой особенностью. Если мы в сцене имеем несколько источников света (допустим, 2), то вероятность того, что выпущенный с камеры луч отразится на большой источник света будет больше, чем на маленький, при чем не зависимо от интенсивности источников света. Когда в сцене комбинируется мягкий и жесткий свет, это может выглядеть так (слева), и ждать, пока пройдет шум, прийдется долго.

На картинке слева видно, что «шумит» именно передний источник света, в то время как задний чувствует себя прекрасно.

Первое, что может прийти в голову — это совместить 2 рендера в постобработке.
Однако, чтобы люди сильно не мучались, в Cycles есть такая функция: «Sample as lamp», которая включена по умолчанию. Если снять с нее галочку, то часть выпущенных с камеры лучей, будут отражаться от объектов в случайном направлении, а не в направлении источника света (чистый path tracing). В этом случае выиграет маленький источник света, и немного проиграет большой. Думаю, это временное решение, и рано или поздно программа будет допилена и возьмет на себя решение этой проблемы.

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

Апельсины vs помидоры
Может так некоторые подумают о сравнении Cycles с Maxwell. Но новенькому опенсорс рендеру надо расти и равняться на старших товарищей.
Итак, разрешение 400х300, время 10 сек:

Maxwell выглядит намного живее, как ни крути.

В Maxwell не настраивались никакие параметры поверхностей вроде sample as lamp, алгоритм все распределения нагрузок берет на себя.
Сильный шум от каустики в Cycles (а каустику, при желании, можно отключить) объясняется тем, что в нем отсутствует Metropolis Sampling (алгоритм оптимизации лучевых пучков, который есть в Maxwell Render).

Надо заметить, при использовании света от окружения или одного большого источника света, изображение в Cycles заметно чище, чем в Maxwell.

Рендерилось 5 секунд.


И чуть посерьезнее (core i5, 1 мин).

BVH
Bounding Volume Hierarchy — переводится как иерархия ограничивающих объёмов (спасибо don за просветление в этой части).
Честно говоря в разных рендерах процесс «предрендерной подготовки» называют по разному, compiling mesh в Octane, Voxelisation — в Maxwell. Я, как и многие работающие с Максвеллом, привык называть это дело вокселизацией, но вышеуказанный товарищ говорит, что это не одно и то же. Прошу простить сию неточность.
Это дело было придумано, чтобы не проверять каждый луч на пересечение со всеми треугольниками в сцене. А если их миллионы? Их всех нужно будет проверить на пересечение. В таком случае, мы вряд-ли увидим скорость больше пары семплов в секунду. И с каждым новым треугольником задача будет все больше усложняться.
Минус в том, что построение BVH выполняется в Cycles всегда на CPU. Может когда-нибудь появится, вокселизация на GPU, но пока этого нет, из чего вытекают свои ограничения. Например, у вас в сцене 10 млн треугольников, и 8 топовых видеокарт. Отрендерят картинку они в считанные секунды, в то время как время вокселизации объекта может перевалить за минуту даже на крутом Core i7. Если же вы используете только core i7, то на вокселизацию у вас уйдет около минуты, а на рендер — минут 20-30. В этом случае время вокселизации не принципиально.
Вокселизация вышеотрендеренного автомобиля (400k треугольников) занимает 14 секунд.

При интерактивной визуализации (preview) вокселизация выполняется только перед началом рендеринга, и при изменениях в геометрии объектов (положение вершин, применение модификаторов). А так же, при нажатии Ctrl+Z (даже, если я ничего подобного не делал, наверно недоделали еще). В построении BVH нет необходимости при навигации, масштабировании, изменении расположения и поворота объектов.

При рендеринге (то бишь, при финальном, нажатием кнопки F12) вокселизация выполняется всегда. При анимации можно избежать постоянном перепостроении BVH статичных объектов нажатием галочки Cache BVH.
Будем надеяться, что в скором времени этот вопрос будет как-то решен в пользу ускорения процесса вокселизации, может и на GPU эту задачку можно будет перенести.

OpenCL
Огорчил OpenCL под мою Nvidia, скорость уступает CUDA раза в два. Под Ubuntu Блендер с OpenCL просто вылетает. Под Win7 рендерит с помощью OpenCL но рендер выглядит у меня неправильно, если материал состоит из нескольких слоев, то из них показывается только один, например глянец или матовая составляющая. А баги во вьюпорте просто неподражаемы.
На Radeon, вроде бы, подобных багов нету, может коментарии покажут.

Тормоза интерфейса
Если во время рендеринга на CPU заниматься веб серфингом не сложно, то при полной нагрузке GPU удобно только читать, Хабр, например. При чем, желательно стараться свести листания страниц к минимуму, чтобы не напрягаться от тормозов.
Может есть какие-то способы изменять приоритет задач на GPU, но я про них не знаю.

Если сильно заинтриговал
Можете запустить его прямо сейчас. Для этого нужно скачать Blender и запустить Cycles у себя. Для выбора GPU: File -> User Preferences, выбрать вверху вкладку System, и слева внизу можете выбрать платформу для рендеринга (стоит CPU по умолчанию).

Субъективное мнение
На сегодняшний день, Cycles уже достаточно хорош для визуализации.
Мне кажется, было бы неплохо его использовать для предметной визуализации: на базе Cycles можно создать свой собственный Bunkspeed Shot, Hypershot, Keyshot, Autodesk Showcase. Чтобы человек, не посвященный в премудрости 3д редакторов мог скачать модель и полюбоваться ею со всех сторон в красивом рендере.
Энтузиазм разработчиков не может не радовать, как и активность opensource сообщества в целом.
Жду дальнейшего развития проекта.
Станислав Марчевский @Marchevsky
карма
39,0
рейтинг 0,0
Пользователь, дизайнер
Самое читаемое Дизайн

Комментарии (75)

  • +1
    Спасибо Стас что освещаешь тему 3D-графики. Хотел бы узнать не попадался ли тебе под руку Bunkspeed? По заявлениям разработчиков, он умеет рендерить на CPU, GPU или Hybrid на выбор пользователя. Хотелось бы услышать обзор или мнение человека который этим вплотную занимается.
    • +1
      Попадался. Чего именно рассказать?
      Таки да, все такое там действительно есть. Скачал модель, выбрал чем хочешь рендерить, выбрал окружение, загрузил модель — и крутишь-вертишь в свое удовольствие. Удобно.
      Правда инсталлятор слишком большой, как-то все сложно устанавливает разные проги в разные директории, не люблю я такое. Хотя функционал программы достаточно прост.
      Ну а так попробуй, вдруг понравится?
      • 0
        Я имел ввиду субьективное мнение как о рендере. а не простоте использования :) Я видел что он простой. Заточен под предметку. Если у тебя есть с чем сравнивать, может оно того и не стоит что бы им заморачиваться и рендерить все Maxwell
        • 0
          Думаю, не стоит. Maxwell действительно дает намного более красивую картинку. Если ты на нем сидишь — лучше не заморачивайся :)
  • 0
    Cycles явно ББ уводит в синюю сторону…
    • 0
      Да я не особо уделил внимание цвету. Меня шум интересовал.
      • 0
        кстати, а шум в рендерах от цвета не зависит?
        • 0
          Ну, не могу прямо ответить.
          Если все кругом светлое — непрямые отражения будут более заметны. Если все кругом темное — непрямой свет быстро в них погасится и никакого шума мы не увидим. Поэтому во многих мануалах к Максвеллу, к примеру, говорят: «не делайте слишком белые стены».
          А от того, синий ли источник света или желтый — уровень шума не зависит.
          • 0
            Кстати шум на белых стенах проще постобработать чем цветные, особенно матовые
          • 0
            ну, если не забуду после выходных 3дшникам на работе подкину тему для размышлений и экспериментов, а вдруг шум таки зависит от цвета)
        • 0
          шум больше из-за света и его силы чем цвета. Да и по логике, шум будет на любой тени и текстуре, вне зависимости от цвета.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Наивный я, думал, режессеры все по честному делают. Эх…
      А вообще, мне нравится этот свет из зада ада.
      • 0
        В фото- и киносъёмке всегда применяются поглотители света наравне с отражателями для создания необходимой световой картины. А отрицательные исочники света в CG — всего навсего более удобный вариант давно известного инструмента.
  • 0
    А откуда информация о слабой оптимизации OpenCL? Вроде бы он полностью построен на вызовах CUDA (имеется ввиду реализация для NVidia, конечно). Я слышал, что он проигрывает не больше 10% приложениям, написанным на CUDA.
    Да и сам стандарт разрабатывался с участием Intel, Nvidia и AMD, вряд ли бы они уделяли время на бесперспективную технологию.
    • +1
      Не думаю, что есть причины считать OpenCL бесперспективным. Но внимания еще уделили маловато, как мне кажется.
      Я лазил по форумам, пытался понять, почему на OpenCL еще не перевели «все на свете». В плане скорости одни говорят, что скорость «существенно ниже», другие — что «то же самое, что и CUDA».
      Вот можно по бенчмарку глянуть: у одних скорость одинаковая, у других разница в полтора раза, у меня — в 2,5 раза. С чем это связано — без понятия.
      Есть видео, показывающее разницу в скорости на разных платформах.
  • 0
    Касательно времени вокселизации: ещё позавчера пробежал коммит:
    Better multithreading for multiple instanced meshes, different threads can now build BVH's for different meshes, rather than all cooperating on the same mesh. Especially noticeable for dynamic BVH building for the viewport, gave about 2x faster build on 8 core in fairly complex scene with many objects.

    Так что можете считать, что там, где раньше была минута на i8, там теперь полминуты :)

    Касательно OpenCL: версия драйвера имеет критическую важность. Если хотите добиться максимальной производительности на nVidia, поставьте драйвер с официального сайта, а не ждите, пока его обновят в репозитариях. Более того: чтобы рендер на GPU с материалами хоть как-то работал на ATI, необходимо поставить самую последнюю версию драйвера: там настолько большое различие функций по версиям, что разработчики cycles намеренно отказались от поддержки старых версий.

    Ну и последнее: к свободным рендерам на GPU с некоторых пор можно отнести LuxRender. В нём много unbiased-алгоритмов, среди них есть несколько вариантов на OpenCL.
    • 0
      Драйвер последний, специально для этих целей обновил — то же самое, может скоро подлатают.
      А LuxRender как-то не приглянулся сразу, а вообще надо будет поглазеть…
  • 0
    Что-то я не пойму, как заставить Cycles Render работать от CUDA? Просчитывает какие-то начальные данные и рендер останавливается, хотя от CPU всё нормально работает.
    • 0
      У меня такой баг на OpenCL бывает.
  • 0
    Исходя из вот этой таблицы на радеоне может оказаться сильно быстрее.
    • 0
      Не теряю надежды, что найдется обладатель крутого радеона, который пожелает похвастаться результатом.
      • 0
        У меня под 32битной виндой не компилится OpenCL ядро, чтобы протестить:( пока гуглил решение(которое пока не нашел) попал на интересный пост
    • 0
      Насколько я знаю, красненькие очень хороши в майнинге потому, что там очень быстро сделана целочисленная арифметика. Вычисления с числами с плавающей точкой же до недавнего времени были уделом зелёненьких. Сейчас АТИ подтягивается и по теселяции и по вычислениями с плавающей точкой вообще, но не более чем подтягивается — там нет никаких чудес. Посмотрите любые тесты со сложными шейдерами, популярный FurMark, например. В них нвидия (сравнимых поколений) обычно заметно обгоняет. Для GPU рендеринга нужна как раз плавающая точка, целые числа там бесполезны.

      Плюс OpenCL, будучи универсальным стандартом под разное железо, по-идее, должна проигрывать CUDA, заточенной исключительно под архитектуру NVIDIA.

      Я не фанат ни тех, ни других, но ждать многократного прироста производительности от ATI так же, как в сравнении производительности майнинга нельзя — это очень специфическая задача, для которой архитектура ATI (случайно?) оказалась очень удачной.

      Кстати, если внимательно посмотреть таблицу производительности железа для майнинга, в конце есть замеры для FPGA. И они оказываются намного эффективнее ATI — если считать вместе с затратами на электричество и само железо. Мне кажется, что рендеринг на этих микросхемах будет делом совсем затруднительным.
      • 0
        Хотя всё это спекуляции. Тот же FurMark на новых видеокартах, говорят, показывает намного меньшую производительность, срабатывает добавленная в новые линейки и красными и зелёными защита по питанию. Никому нельзя доверять, даже себе…
      • 0
        FPGA — вообще очень интересная тема…
        • 0
          Это да. Но и порог вхождения в это дело повыше, чем мигание светодиодами на Ардуине.
  • 0
    Жаль он пока не готов к связке с 2д объектами \ анимироваными плоскостями. Пробовал всякие варианты в 2.62. то там, то тут приходилось костыли подставлять =[.

    Ну а cycles конечно суперский, как починят\добавят адекватную работу с 2д объектами так будет вообще супер)
    • 0
      А с каким продуктом сравниваете?
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      ого, отрывчик…
      • 0
        ееек, известный факт. Стандартная версия под win64 собирается компилятором visual studio, который не силён в векторизации циклов. Так и выходит, что один и тот же код на линуксе и маке на 40%-100% быстрее, чем на windows. Впрочем, если скачать сборку mingw64.zip с builder.blender.org/download/, то будет примерно одинаковая скорость.
        • 0
          Ничего себе, мое время 3:18:18 на mingw64. Это на пол минуты быстрее, чем в linux!
        • 0
          и 35 секунд в Cuda…
          • 0
            Странно, что эта же сборка на CPU под:
            Debian 4:05
            Ubuntu 3:56
            Как так? Mingw всех рубит…
  • +3
    А чтобы почитать такое, чтобы с МАХ на блендер пересесть? А то что ни читаю либо оторванные от среды уроки для тех кто уже в теме, либо разжевывание основ моделирования для совсем новичков.

    А мне бы миграционный материал, мол аналог такой то шняги 3дмакса в блендере это… и так далее.
    • 0
      Ух, сам бы рад. На ощупь щупал, задавал гуглу вопросы, а такой литературы не знаю…
  • 0
    А как обстоят дела у этого Cycles Render с записью результатов в пассы? Есть вообще возможность получать нужные наборы пассов как в MR (mentalRay) или Vray? Акклюзию, тени, пассы на обжект айди, глянец, спегуляр, рефракцию и прочее можно выводить с Cycles в раздельные файлы или поканально в EXR 32-bit?

    Я купил Octane и в нем этого делать нельзя. Потом пробовал использовать Arion, в нем можно выводить RAW-картинку, но все равно не то. С Maxwell все понятно, он может отдать почти любые пассы для композера, а с этим Cycles как? (Я Blender не использую, даже не пробовал.)
    • +3
      Можно делать всё ровно в том объеме, в котором вы хотите:
      • 0
        Спасибо, хорошая иллюстрация.
    • 0
      пассы можно делать. Можно ли свои собственные пассы создавать не знаю
  • 0
    на форуме с бенчмарком по поводу Радеонов:
    «OpenCL acceleration with AMD cards is only available in OS X.»

    мои опыты с моим Радеоном 5830 на Win7/64 это подтверждают, рендер длиться 6:52:76
    и в итоге вот такая хрень:
    image

    а вот CPU Phenom X4 B25 2.7Ghz справляется за 9:35:30
  • –1
    Поискал немного где могли бы применяться в продакшне подобные решения вроде Octane, Arion и вот этого Cycles — не нашел. А есть какие-то примеры применения в жизни тяжелой этого продукта? (Кино, киноанимация, реклама, игровая или научная визуализация? Больше интересует с точки зрения motion, в меньшей — still.)
    • 0
      Нет =) Cycles не поддерживает motion blur на данный момент. Кроме того, анбиаседы и вся их родня пока требуют слишком много времени, чтобы получить картинку для большого экрана.
      Для научной визуализации наверно можно придумать какое-то применение, но там чуваки скорее всего свой софт пишут, если надо физически корректно фотоны считать.
      Единственное, что приходит в голову это заставка Cartoon Network, считанная в максвеле www.youtube.com/watch?v=gXbKFVD-rvo
      • 0
        • –1
          >> beldner
          Фотошоп же.
          • 0
            где?
            • –1
              «beldner 2.65», даже набрать по-человечьи не смогли: www.blender.org/
              • 0
                А вы вообще blender видели?
                На вкладку render/stamp заглядывали?
                • 0
                  Видел и не только. Но в штампе строчкой Note никогда не пользовался. :)
                  • –1
                    Это не повод тупить и инсинуировать.
    • 0
      попробовал. проблему motion blur в cycles можно решить композно. Выгоняем vector pass и в нюке делаем всё нодой VectorBlur. Получется боле-менее неплохо
    • 0
      Вот еще реклама в максвеле www.maxwellrender.com/index.php/gallery/videos
      а про остальные что-то не слышно ничего
      • +1
        Бррр, да я не про это. Maxwell активно используется и в рекламе, и даже в кино порой пробегает. В пайплайнах крупных студий его не найти, но в не очень крупных он иногда проскакивает для вполне конкретных рекламных работ. Опять же, мультик на нем рендерили, потом еще один — в пайплайне он отлично сидит у тех, кому нужно. А вот Arion или Octane, а уже тем более Cycles — я ни у кого не видел из студий в пайплайне этот рендер. Кто вообще мэйджорный потребитель этих рендеров? Энтузиасты?

        Про MB странно. На сколько я помню, даже не самая последняя версия Octane умеет считать Motion Blur сразу в сцену. Вероятно, в Cycles это либо появится позде, либо у него не будет заточки под motion, а будет под still, что тоже хорошо для определенных задач и определенных специалистов. У Maxwell MB отличный, надо признать.

        Композом вообще можно много чего сделать ;-). Даже не будь пассов векторов можно было бы оттречить объект, после чего отротоскопить его (на случай если нет для него маски с альфы) и сделать эту самую карту векторов движения (MotionBlur2D) и потом загнать данные в VectorBlur. Получится неплохо, но все равно далеко от хорошего результата. А если крутить в большую сторону количество сэмплов, то время счета кадров будет сравнимо в рендерингом, что для композа как-то глупо. И когда будет задачка отрендерить в стерео, то такой трюк с Vector Pass может не пройти. (Хотя, для стерео картинки есть другое решение.)
        • 0
          В планах у них значатся MB, волосы, SSS и много чего ещё. Когда сделают — другой вопрос. Cycles намного моложе Maxwell и остальных — wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/ToDo
          • 0
            MB уже сделали, волосы появились в позавчерашнем релизе.
        • 0
        • 0
          Да я просто по привычке все анбиаседы в одну кучу валю =)
          А октан и прочие похоже да, удел энтузиастов.

        • 0
          мне кажется, здесь виновата относительно молодая архитектура GPU для вычислений…
          • 0
            Дело скорее не в возрасте, а в технических ограничениях и определенных требованиях индустрии. На текущий момент GPU-acceleration проникает повсеместно. Джон Ваделтон уже показал частично новый Nuke 7 (предположительно это именно 7-ка, а не 6.3v8), в котором GPU используется в ряде ключевых нод. Например, новый трекер использует GPU-акселерацию, а также zBlur, который HD-картинку без акселерации работает примерно на скорости 1 кадр в секунду, а с акселерацией больше 4 кадров в секунду. Не риалтайм, конечно, но уж лечше чем ничего. Если с дефокусом еще как-то все понятно и его еще можно подождать, то трекинг с акселерацией — это, я вам как композер начинающий скажу, прекрасно.

            На мой вкус будущее в ближайшее время все же ждет больше Hybrid инструментов, нежели чистых GPU. В связке CPU&GPU оно работает прекрасно, а при учете, что всякие там Asus и прочие уже начали продажу решений для довольно недорогого построения 2-процессорных (12-ядерных) машин, на борту которых может быть по три карты Quadro 6000, то это большое будущее. И GPU не смотря на свою молодость отлично уже себя зарекомендовало не только в рендеринге. Взгляните на инструментарий симуляции! Это же революция. Раньше мы ждали простую симуляцию часами, теперь ровно столько же при использовании GPU мы ждем симуляцию огромного знания с модицикацией карты дисплейса для рендера. Это ли не волшебство, если учесть, что мощность процессоров что в GPU, что в CPU за это время (пару лет всего прошло) позросли максимум в пять раз по общему уровню, скорее покрывающему требования рынка, чем реальный прогресс.

            Пока GPU очень скромный по набору инструкций, а фреймворки слабые в силу большого разделения производителей в конкуренции. Лично я не понимаю попытки развивать что-либо не совместимое с CUDA.
            • 0
              Да, это 7й нюк. Выйдет осенью, где-то после IBC. Про GPU в нюке ребята из foundry говорят, что добавлять будут, но это далеко не приоритетное направление.
  • 0
    Вот, что говорят разработчики Максвелла о CUDA и OpenCL:
    Взял отсюда.

    «So is it using CUDA?

    No. While CUDA is a very powerful technology, especially promising in the rendering area, we
    consider that for a renderer like Maxwell Render it is still not good to force customers to spend money
    on dedicated hardware that might be expensive and could be obsolete soon, given the high
    speed of changes in this area. We do not want to tie customers to specific hardware vendors
    when there is no standard in this area yet. OpenCL looks like a very interesting option for the
    future, but the fact is that it still needs time to evolve into any kind of standard used in
    complex development cycles. For simple renderers, GPUs can be extremely fast, but for a state
    of the art raytracer like Maxwell Render that can work with large geometries under any kind of
    complex lighting environment, using multilayered materials, generating several render
    channels, etc. etc. modern CPUs are able to provide similar performance, even better in some
    cases, as shown in the videos of this new engine.»
    • 0
      В интернете есть еще достаточно большой видео обзор от разработчиков Modo, в котором их главный рассказывает и объясняет детально причину, по которой они до сих не разработали хорошего GPU-рендера. Очень технически грамотный у него был язык в разъяснении. («Brad Peebler from Luxology posts some of their research findings on the GPU vs CPU rendering», — так именовался его рассказ, но его что-то везде випилили.) И это, надо отметить, заявление было сделано от лица компании, имеющий очень хороший и быстрый CPU-рендер. Очень быстрый.
  • 0
    то есть по циферкам получается что i7 975 будет уже не так страшно проигрывать 580му GTX как i5 в тестах? :)
  • –1
    > Может есть какие-то способы изменять приоритет задач на GPU, но я про них не знаю.

    На маке я изменял приоритет приложения с помощью renice. Думаю, на убунту примерно так же.

    Например, ставлю на рендер на день, но хочу еще вечером нормально посмотреть фильм в vlc, значит приоритет выше vlc назначаю. Так же для браузера. Чтобы страничку полистать на i5 надо может 1% проца, поэтому скорость рендера особо не падает.
  • 0
    Я первый раз пытаюсь что-то сделать в 3д. Подскажите как избавится от шума. Я решил попробовать что-то отрендерить и у меня все очень зашумленное получается. Как будто снято на хреновый сенсор да еще и ночью… И что я только не крутил, а результат один и тот же.

    Как получить вот такое, а не такое?
    • 0
      Все довольно просто и в первую очередь зависит от количества проходов Samples -> Render с вкладки Render -> Integrator (по умолчанию там стоит число 10, я ставлю от 100 до 500, в зависимости от необходимого качества и сроков исполнения).
      Пример простого прохода по умолчанию.
      Пример настроенного семплирования.
      Просчитанная картинка 1920x1080.
      Пример просчета стандартным рендерингом.

      Особое внимание прошу обратить на время рендеринга каждой из сцен (слева вверху вьюпорта).

      Автору статьи большой респект за то, что подсказал как исправлять шумовые артефакты источников света.
      Кстати, я похожие проблемы исправляю миксом шейдеров, так-как заметил, что шейдер Glossy имеет свойство усиливать шума.
      • 0
        Спасибо, разобрался.
        Мне чтобы избавится от шума потребовалось >500 проходов (10мин на OpenCL HD6800) =\
        • 0
          Кстати, автор поста описывал, что OpenCL еще сырой.
          У меня дома новая видюха NVidia 560 Ti 2Gb RAM, в ней CUDA существенно шустрее OpenCL даже на последних драйверах. Она считает сразу три-четыре семпла за один раз.
          Перед этой картой у меня была ATI HD 3870 512Mb RAM, которая сгорела под нагрузкой современных технологий. Так, что рекомендую иметь хорошее охлаждение и следить за поведением карточки. Если будет уводить комп в синий экран, лучше её сильно не напрягать.
  • 0
    У меня вопрос…

    Я недавно начал осваивать Blender…
    Возможно у нас (у всего отдела дизайна) была одна и та же галлюцинация, но у меня в какой-то версии Blender-а стандартный рендеринг (Blender Render) имел две кнопки CPU и GPU, над кнопками Image и Animation… А потом в один прекрасный день они исчезли…

    Если в курсе, что за версия Blender-а такая, сообщите пожалуйста, а то у меня был прирост производительности тогда примерно в 40 раз (видеокарты NVidia Ti 560, 2Gb RAM и Quadro FX 3800 1Gb RAM)… Там получался просчет одного кадра: CPU — 8 минут 50 секунд, GPU — 2:65 секунды… (42856 Polygonal Multires Cube, Mirror material + Normal Bump texture, AO, Point Light+Area Shadow, 1920x1080). При сравнении обоих вариантов рендеринга, тогда отличий найдено не было.

    Парадокс в том, что я обновлял Blender с оф. сайта и кнопки исчезли. Народ у нас решил подсесть на Blender тогда, после моей рекламы, но из-за вышеуказанного облома все опять вернулись к привычным платным пакетам 3D-графики.
    • 0
      Эта настройка переехала на страницу настроек Блендера, поищите. File->Settings или Preferences, не помню
      • 0
        File->User Preferences->System->Compute Device: None / CUDA / OpenCL

        Это не то, там пишут в подсказке: «Device to use for computation (rendering with Cycles)»
        И я проверял, этот пункт работает только с рендером «Cycles Render» и игнорирует «Blender Render»…

        image

        Если кто нибудь сталкивался, отзовитесь пожалуйста, буду ОЧЕНЬ благодарен.
        • 0
          Могу ошибаться, но старый blender render никогда и не ускорялся на GPU. На GPU ускоренно считает только Cycles, если выбрать CUDA или OpenCL. None — рассчёт будет происходить на CPU. Поэтому я немножко не понимаю, почему нельзя переключаться между CPU и GPU именно этими кнопками.
          • 0
            Пробовал, результат просчета абсолютно идентичен.

            Я же сказал, что там написано в подсказке: «Device to use for computation (rendering with Cycles)».
            Подозреваю, что он где-то настраивается, но где?..

            Как вариант даже опробовал на производительность Acceleration structure на вкладке Performance.
            При стандартном рендеринге изменяя параметры можно значительно ускорить просчет.
            Дефолтное значение «Auto» иногда сильно замедляет просчет.
            При тестировании простой сцены я определил, что для меня самым оптимальным есть значение «SIMD SVBVH». Кстати, изменении параметров Acceleration structure иногда влияет на освещенность, тени, блики, отражения, шума в выходной картинке.
  • 0
    Скажите, а кто придумал node setup материалы? Откуда это чудо появилось?
    Renderman?

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