С развитием технологии GPGPU, на рынке появилось немало рендеров на GPU, среди них iRay, V-ray RT, Octane, Arion. Но, сообщество opensource не дремлет, и появились по-крайней мере два известных мне свободных рендера на GPU: SmallLuxGPU и Cycles Render. Хочу поделиться впечатлениями о последнем.
Cycles Render — unbiased рендер, с возможностью рендеринга на GPU (CUDA и OpenCL для ATI). Лежит в коробке с Blender, который работает на Win, Lin, Mac.
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-е сообщение) и два (на англ). С чем это связано — не хочу гадать, не знаю.
Отрыв 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.
Можно (не знаю, правда, зачем), создавать источники света отрицательной светимости.
Свет, антисвет.
Процедурными можно сделать не только поверхности, но и окружение: небо, тучи и т.п. А с помощью нодов можно также настроить постобработку изображения.
При интерактивной визуализации (preview) вокселизация выполняется только перед началом рендеринга, и при изменениях в геометрии объектов (положение вершин, применение модификаторов). А так же, при нажатии Ctrl+Z (даже, если я ничего подобного не делал, наверно недоделали еще). В вокселизации нет необходимости при навигации, масштабировании, изменении расположения и поворота объектов.
При рендеринге (то бишь, при финальном, нажатием кнопки F12) вокселизация выполняется всегда. При анимации можно избежать постоянной перевокселизации статичных объектов нажатием галочки Cache BVH.
Будем надеяться, что в скором времени этот вопрос будет как-то решен в пользу ускорения процесса вокселизации, может и на GPU эту задачку можно будет перенести.
Непонятности
Ну сначала для меня этот вопрос был непонятностью, но затем я понял, что к чему. Тут, как я понимаю, вопрос стоит между производительностью и удобством, и это относится ко всем анбиасам на 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 (бинарной воксельной иерархии).
Объекты и треугольники помещаются в коробку, и прежде, чем проверять пересечение луча с треугольниками, нужно сначала проверить, пересек ли луч воксель, содержащий в себе этот массив треугольников. Если бы этой системы не было — каждый луч проверялся бы на пересечение со всеми треугольниками в сцене. А если их миллионы? Их всех нужно будет проверить на пересечение. В таком случае, мы вряд-ли увидим скорость больше пары семплов в секунду. И с каждым новым треугольником задача будет все больше усложняться.
Минус в том, что вокселизация выполняется в Cycles всегда на CPU. Может когда-нибудь появится, вокселизация на GPU, но пока этого нет, из чего вытекают свои ограничения. Например, у вас в сцене 10 млн треугольников, и 8 топовых видеокарт. Отрендерят картинку они в считанные секунды, в то время как время вокселизации объекта может перевалить за минуту даже на крутом Core i7. Если же вы используете только core i7, то на вокселизацию у вас уйдет около минуты, а на рендер — минут 20-30. В этом случае время вокселизации не принципиально.
Вокселизация вышеотрендеренного автомобиля (400k треугольников) занимает 14 секунд.
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
