7 проблем GPU рендеринга
GPU рендеринг в Octane, Redshift и других рендерерах, использующих ресурсы видеокарты, а не процессора, поначалу вызывает настоящий восторг. Время рендера по сравнению, например, с V-ray уменьшилось в разы, можно в реальном времени оценить результат изменений в сцене, можно быстро посмотреть как все будет выглядить на финальных рендерах и многое другое будет говорить, казалось бы, о несомненном доминировании рендера на видеокарте.
Однако не все так просто! Давайте оставим за рамками вопросы подходит ли GPU рендер под требования производства отдельных видов графики, отсутствие полноценного продакшен GPU рендера и все такое. Представим, что у вас небольшая банда из 3 визуализаторов, вы делаете преимущественно рекламные ролики и вот вы перешли на GPU рендеринг. Давайте посмотрим на 7 проблем, которые вас подстерегают:
Большинство специализированных GPU решений предполагают, что добавление видеокарт дешевле покупки полного компьютера, но только при покупке специальных серверных шкафов и систем для работы большого количества видеокарт. Сами такие решения недешевы и требуют определенных навыков. Но представим, что мы пошли по пути покупки стандартных компьютеров и установки в них 2-3-4 видеокарт. Сравните стоимость в дальнейшем апгрейда процессора и апгрейда этих 2-3-4 GPU.
2. Маленькое влияние крутых видеокарт на всю систему
В отличие от апгрейда CPU, который окажет влияние на работу всех приложений, видеокарты окажут влияние только на сокращение времени рендера. Их присутствие никак не повлияет на работу ОС и любых 3d приложений для работы с графикой. За исключением, разве что, игр. Но вы же не играете на своем рабочем компьютере, правда? )
Проще говоря, когда вы тратите деньги на GPU в целях работы, это дает вам весьма узкие и специфичные преимущества.
3. Постоянный шум и тепловыделение
Охлаждение практически любой видеокарты гораздо шумнее работы охлаждения CPU. Еще важнее, что постоянная работа 2-3 видеокарт быстро создает в помещении невыносимую температуру.
4. Вопросы масштабирования
Если у вас несколько GPU машин, рано или поздно встает вопрос покупки дополнительных лицензий и возможны проблемы совместимости видеокарт различных производителей и разных моделей. По мере обновления парка столкновение поколений видеокарт неизбежно. А вы же помните что, если в одной системе стоит, например, видеокарта с 8гб памяти и 12гб, то память будет ограничена меньшим значением.
5. Капризы видеокарт и драйверов
Обычное обновление драйвера может обрушить все. Видеокарты в любой системе — основной источник зависаний и сбоев. Любая проблема с обновлением драйверов, их совместимостью, багами и прочими прелестями однозначно ведет к тому, что и в рендере будут проблемы! Нужно ли говорить, что при рендере на CPU этих проблем нет.
6. Ограниченная память
В настоящее время в GTX 1080Ti всего 12 Гб памяти, которые не увеличить вставив планку памяти как в обычных компьютерах. И она не суммируется при установке нескольких карт. Если, например, установить таких 3 карты, то под сцены будет доступно так же 12 Гб. При превышении доступного объема памяти на рендере, все просто крашится. Вариантов как на CPU с использованием файла подкачки, который хоть и замедляет рендер, но все же делает его возможным — нет.
7. Ограниченный круг ПО
Рендер на GPU поддерживает ограниченное количество графических приложений и рендеров, что накладывает свои ограничения.
В завершении, отмечу. что несмотря на недостатки GPU рендеринг имеет и безусловные достоинства, которые значительно перевешивают и существующие недостатки.
3D рендеринг: как работает GPU
Всем привет. Меня зовут Глеб Булгаков, я — программист. Вместе с тех. артистом Романом Лещенко мы работаем в компании Fractured Byte и хотим поделиться нашими знаниями и опытом в деле оптимизации реалтаймового контент пайплайна.
Работая вместе в компании BWF, мы успели приложить руку ко множеству разных по жанру, целевой платформе и сложности проектов. Среди них было и портирование всемирно известных проектов на мобильные платформы (Life Is Strange, Brothers: A Tale of Two Sons), разработка собственных проектов на разные платформы (In Fear I Trust, Renoir), и даже прототипирование и R’n’D для VR игр. У нас 9 лет опыта работы с движком Unreal Engine, начинали с UE3. Мы успели поработать с такими компаниями как Square Enix, Disney, 505 Games, Framestore, Chillingo и т.д. Таким образом, мы почти никогда не сталкивались с одними и теми же задачами и нам всегда приходилось изыскивать возможности отрисовать много контента на экране за минимальное количество миллисекунд. Так что, можно сказать, что мы съели на этом пару собак 🙂
В этой статье мы разберем принцип работы и отрисовки простейшей сцены на GPU, а также познакомимся с базовыми понятиями, на которые будем впоследствии ссылаться. Надеемся, эта статья будет интересна как техническим специалистам, так и артистам, желающим понять, почему “злые программисты” говорят им уменьшать разрешение текстур.
Обзор
Перед тем как погрузиться с головой в оптимизацию, нужно разобраться в том, как работает GPU и процессах, которые происходят в движке.
В упрощенном виде конвейер рендера (именно конвейер, потому что многие последующие процессы зависят от результатов завершения предыдущих) работает по такому принципу:
Как вы могли заметить, основная “магия” происходит в четвертом пункте. Что это за сложные вычисления, как они влияют на производительность и как научится их контролировать? Этим мы сегодня и займемся, а начнём с того, какие объекты можно создавать и какие операции можно делать над ними, а потом плавно перейдем к отрисовке сцены.
Также перед тем, как начать, стоит сказать, что эта статья не описывает какой-то конкретный конвейер рендера в конкретном движке (хотя мы и будем приводить много примеров из UE4), а старается обобщить наши знания таким образом, чтобы вы могли понять откуда “растут ноги” у современных контент-пайплайнов и графических фич, а также поняли, почему количество полигонов в модели уже давно не является адекватным мерилом производительности.
Мы также хотим уточнить, что эта статья не затрагивает моменты оптимизации самого рендера, мы хотим научить локализовывать проблемные места в игре, показать способы их обхода, а также показать как бороться с ограничениями платформы — иногда это означает разработку нового пайплайна для создания или оптимизации контента, иногда замену эквивалентными решениями, а иногда — отказ от данной фичи.
Какие ресурсы можно создать на GPU?
Текстуры
Самый известный и самый объемный ресурс — это, наверное, текстура. Чисто для примера мы будем использовать простую текстуру 8х8 пикселей с призраком из игры Pac-man:
Текстура обладает рядом характеристик: размером, форматом, наличием мип мап. Это самые основные настройки текстуры, на которые стоит обращать внимание, поскольку они определяют объем памяти, занимаемый этим ресурсом, определяют — хранится ли текстура со сжатием и т. д. Стоит также разобраться в типах текстур — на удивление, их достаточно много. Итак, поехали:
Двумерные (в терминологии DirectX 11 — Texture2D).
Тут и рассказывать особо нечего — это самый распространенный тип текстур, который с большой вероятностью будет делать
90% картинки в вашем проекте. Текстуры объектов, интерфейса, служебные LUT, карты высот — как правило, это все Texture2D.
Трехмерные (в терминологии DirectX 11 — Texture3D).
Такие текстуры можно представить как массив или слои двумерных текстур. В редакторе создавать их как ассеты можно, но для этого их нужно включить ( r.AllowVolumeTextureAssetCreation 1 ). В основном, 3D текстуры используются самим движком для работы с Vector Fields, Distance Fields, Volumetric Lightmaps и т.д. То есть там, где необходимо пространственное представление данных.
Каждая текстура может обладать уменьшенными копиями самой себя — это так называемые мип-мапы (mip maps). Дело в том, что когда мы рисуем объект, он может находится как близко, так и далеко от игрока и соответственно иметь разный размер на экране. В результате, если объект имеет текстуру большего разрешения, чем его фактический размер на экране в этот момент — невозможно стабильно получить один и тот же цвет пикселя на экране с течением времени. В результате возникает эффект, известный под названием Муар (от фр. Moire).
Чтобы избежать этого, придумали мипмапы, которые по сути являются уменьшенными копиями оригинальной текстуры, из которых значительно проще получить стабильный цвет пикселя на удалении. GPU сам определяет, какую мипмапу ему лучше использовать для каждого пикселя в зависимости от расстояния до пикселя. Генерация мипмап поддерживается аппаратно и нам не нужно заботиться об их создании вручную.
8 Мб
Константные буферы
Следующий ресурс — константный буфер. Это просто участок памяти, который используется для хранения информации, например, для геометрии модели или же для параметров материалов.
Рассмотрим простейшую модель — куб. Как вам, возможно, известно — треугольник является наименьшим элементом, из которого состоят все 3D-модели. И чтобы описать модель способом, который будет понятен GPU, нам нужно 2 буфера — вершинный и индексный. Вершинный описывает, как ни странно, вершины модели: их позицию, нормали, текстурные координаты и т. д. Индексный буфер содержит индексы вершин, порядок соединения этих вершин, необходимый для построения на экране отдельного треугольника.
Шейдера и стейты
Вместе с ресурсами на GPU можно создавать дополнительные объекты: стейты и шейдера. Первые из них являются объектами, которые описывают правила взаимодействия с конкретным ресурсом, вторые же —отдельные программы для GPU.
SamplerState — стейт, который определяет, как GPU делает выборку с текстуры: фильтрацию, адресацию. Это, наверно, единственный стейт в UE4, на который мы явно можем влиять, когда устанавливаем текстуру в материале или в настройках самой текстуры. При описании текстур я избегал слова “сэмплить” (sample), под сэмплингом подразумевается вычисление цвета, именно вычисление, а не простая загрузка из памяти. Каждый раз, когда мы сэмплим из текстуры, GPU делает много вычислений, чтобы определить, с какой мипмапы брать цвет, возможен даже блендинг между мипмапами; для определенных типов фильтрации, таких как Anisotropic, в учет берется и положение треугольника в пространстве. Сэмплинг — достаточно сложная операция, и чем меньше текстур используется при рендеринге объекта, тем лучше.
А что будет, если мы попытаемся взять пиксель за пределами текстуры (напомним, что текстура находится в пределах 0. 1)? Для этого и была придумана адресация.
Хоть большую часть стейтов мы и не можем контролировать напрямую, понимание того, как они работают, может помочь нам при профайлинге кадра.
Шейдер — это программа, которая выполняется на GPU. Есть разные виды шейдеров, но мы остановимся только на двух основных: Vertex Shader (вершинный) и Pixel Shader (пиксельный). Основной задачей вершинного шейдера является трансформация объекта в пространстве (перемещение, поворот и масштабирование) и проецирование на экран. После того, как GPU спроецировала примитив на экран, вступает в работу пиксельный шейдер, который и вычисляет цвет пикселя.
В UE4 шейдеры создаются путём визуального программирования в Material Editor. Каждый материал имеет в себе предопределенные входы (инпуты) (Base Color, Metallic, Roughness, Emissive и т.д.), и мы, создавая ноды и соединяя их в определенной последовательности, генерируем код шейдера. Этот код является только частью шейдера и определяет основные параметры материала. В свою очередь, материал генерирует не один шейдер, а целое множество шейдеров для разных проходов материала.
Операции на GPU
На GPU есть особая текстура — Swapchain, которая представляет собой область экрана, где рисуется наша сцена. Swapchain состоит из нескольких буферов: front buffer — содержит то, что сейчас мы видим на экране, и back buffer — текстура, в которую мы рисуем следующий кадр. Когда наша сцена отрисована и находится в back buffer, мы вызываем команду Present — она меняет front buffer и back buffer местами. И отрисовка следующего кадра начинается снова.
Спасибо за внимание, надеемся, вы почерпнули новых знаний и лучше поняли возможности GPU и для чего они используются. Во второй части статьи мы рассмотрим на практическом примере процесс отрисовки сцены. До встречи на UE4 Daily!
Переезжаем на GPU Rendering, первый опыт(VrayRT 3.5 GPU).
После просмотра демо ролика мне буквально не сиделось на месте и я начал собирать информацию о ГПУ рендере везде где только мог, выяснилось что Bulgarov уже давно переехал на ГПУ:
и собрал какого-то нереального монстра с водяным охлаждением, а так же небезызсвестный DabartiCGI тоже перешел на ГПУ и во всю пропагандирует вегетарианство и сыроедство его.
У него система уже попроще, но всё равно довольно дорогая. Основные тезицы которые я почерпнул исследовав интернет такие:
1. Видеокарты могут быть разными(но просчет только Nvidia)
2. Количество памяти может быть разным. Оно не суммируется и используется наименьший объем памяти из всех доступных у видеокарт
3. Можно сочетать Ati/AMD(для отображения изображения с мониторов) и Nvidia для рассчетов
4. Sli режим не нужен, достаточно просто выбрать нужное количество видеокарт для просчетов
5. Основная проблема это охлаждение и питание.
Немудурствуя лукаво я зашел на интернет магазин и купил 7 видеокарт Nvidia 1070GTX 8Gb(25-35 тыс руб штука) которые были в наличии разных производителей и цены, чтобы проверить все тезисы выше, а так же 2 БП 1200 и 1000Ватт(8-10тр штука) чтобы точно хватило(заявленное потребление у видеокарт 150 ватт штука).
Первым делом выяснилось, что просто так вставить 7 видеокарт в одну материнскую плату невозможно, даже если в ней есть 7 PCI-express-x16, они попросту туда не влезут, поэтому покупать специальную материнскую плату не надо. Достаточно любой «Gaming» с 4хPCIexpress-x16(это стандартные длинные пазы для видеокарт) и 3xPCIexpress-x1(урезанные, обведены красным)
К сожалению моя настольная материнка была с тремя большими ГПУ слотами и совсем не подходила даже для простой ГПУ станции, поэтому я пошел на балкон:
Попутно выяснилось что Fedex,DHL и все скоростные доставщики больше физлицам в РФ не отправляют ничего, продавец прискорбно сообщил об этом и добавил мне к заказу ещё 2 удлинителя(к 20 которым я купил) и отправил всё Почтой россии/EMS, я превратился в ждуна и собрал 4хГПУ систему:
До этого у меня была 980GTX 4 GB и я решил оставить её для тестов рендера с разной памятью. Zotac был самый дорогой, в металлическом корпусе, с диодной подсветкой и т п + ещё одна самая дешевая 1070gtx от нвидии из пластика и с всего 8 пинами питания вместо 16 как у остальных.
Проблемы при сборке:
1. Видеокарты очень длинные (возможно кому то придется вырезать мешающиеся запчасти)
3. Видеокарты лучше втыкать по одной, почему то на двух материнках изначально заработало только во втором слоте ГПУ с одной видеокартой(в биосе стоит по умолчанию первый PCIe)
4. Биос стартует гораздо дольше!
5. Windows может после старта висеть с черными экранами 2-5 минут каждый запуск(проверено на 7ке и 10ке). Просто ждите 🙂
Ну и вот так это всё примерно выглядит.
Я перешел на 4к рендеринг видео, поэтому мощностей всегда не хватает. Например этот 21 секундный ролик в Corona рендерился почти неделю, это конечно не приемлиемо:
Даже с использованием Vray один кадр с 4к честным дофом или моушен блюром рендерится около 2х часов на моем 44ядерном Xeon, что то типа такого:
Первый тест ГПУ я провел на сцене изначально сделанной под ЦПУ :
Превью рендеринг анимации 480*320 с честным дофом занял 3 часа, пока я ездил в магазин за едой на одном компьютере! Это очень круто.(сетка немного глючит изза неверного подбора ФПС, именно за этим такие тесты и прогоняются 🙂
Опенсорс-фотореализм на 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, но я про них не знаю.
Субъективное мнение
На сегодняшний день, Cycles уже достаточно хорош для визуализации.
Мне кажется, было бы неплохо его использовать для предметной визуализации: на базе Cycles можно создать свой собственный Bunkspeed Shot, Hypershot, Keyshot, Autodesk Showcase. Чтобы человек, не посвященный в премудрости 3д редакторов мог скачать модель и полюбоваться ею со всех сторон в красивом рендере.
Энтузиазм разработчиков не может не радовать, как и активность opensource сообщества в целом.
Жду дальнейшего развития проекта.
