Unbiased DirectX Рендеринг на GPU, CPU и в облаке

    Как создать рендерер, который бы работал даже на компьютере вашей бабушки? Изначально перед нами стояла немного другая задача — создать unbiased рендер для всех моделей GPU: NVidia, ATI, Intel.
    Хотя идея такого рендера для всех видеокарт витала в воздухе давно, до качественной реализации, тем более на Direct3D, дело не доходило. В своей работе мы пришли к весьма дикой связке и дальше расскажем, что нас к ней привело и как она работает.

    renderbro resource combined


    О том, что такое unbiased rendering, или рендеринг без допущений, очень хорошо изложил Marchevsky в серии статей
    «Трассировка пути на GPU» часть 1, часть 2 и "Unbiased rendering (рендеринг без допущений)".
    Вкратце: это рендеринг, который не вносит систематические ошибки в расчет и воспроизводит физически точные эффекты

    • глобальное освещение
    • мягкие тени, реалистичные переотражения
    • глубину резкости и motion blur
    • подповерхностное рассеивание и многое другое


    glass ball, 2 minutes on HD 5770

    Ввиду физической достоверности и качества картинки, такой подход заведомо является очень ресурсоёмким. Решить проблему можно путем переноса расчётов на GPU, так как такой подход даёт увеличение скорости расчета до 50‒и раз на каждое GPU устройство.

    mech octopus, 9 minutes on HD 6870
    1200x600 (кликабельно), AMD Radeon HD 6870, render time: 9 min

    Почему Direct3D


    Существует множество GPGPU платформ (OpenCL, CUDA, FireStream, DirectCompute, C++ AMP, Shaders и др.), но споры об оптимальном выборе идут до сих пор, и однозначного ответа на то, что лучше использовать, нет. Рассмотрим основные аргументы в пользу Direct3D, которые склонили нас к выбору именного этого API:

    • Работает на всем спектре видеокарт, эмулируется на всех моделях процессоров: один и тот же шейдер работает везде
    • Именно спецификации Direct3D задают направление развития потребительского железа
    • Всегда первым получает самые свежие и стабльные драйверы
    • Остальные кросс‒вендорные технологии не стабильны, либо слабо поддерживаются

    Из OpenCL и Direct3D мы выбрали то зло, которое, по крайней мере, имеет стабильные драйвера, отточенные десятилетиями игровой индустрии, и имеет лучшую производительность в ряде бенчмарков. Также, исходя из задачи, была отброшена CUDA, несмотря на все инструменты, обильное количество примеров и сильное сообщество разработчиков. C++ AMP в то время еще не был анонсирован, но т.к. его реализация построена поверх DirectX, перенести рендер на него не составит особых проблем.
    Связка OpenGL/GLSL также рассматривалась, но быстро была отброшена ввиду ограничений, которые в DirectX решаются с помощью DirectCompute (задачи двунаправленной трассировки пути и пр.).

    Так же, отметим ситуацию с GPGPU драйверами потребительского железа, которые выходят с запозданием и долго доводятся до стабильности. Так, при выходе линейки NVIDIA Kepler 600, геймеры сразу получили качественные Direct3D драйверы и более производительные машины для игр, но большая часть GPGPU приложений потеряла свою совместимость или стала менее производительной. Например, Octane Render и Arion Render, построенные на CUDA, начали поддерживать линейку Kepler буквально на днях. К тому же, профессиональное GPGPU железо не всегда оказывается намного лучше в ряде задач, о чем рассказано в статье “NVidia для профессиональных 3D приложений”. Это дает повод собрать рабочую станцию именно на потребительском игровом железе.

    Почему не Direct3D


    Во всех анонсах DirectX 10‒11 пишут о том, что новые модели шейдеров идеально подходят для трассировки лучей и многих других GPGPU задач. Но на деле никто особо не использовал эту возможность. Почему?

    • Не было инструментов и поддержки
    • Исследования сдвинуты в сторону NVIDIA CUDA ввиду сильного маркетинга
    • Привязка к одной платформе

    Вернемся на год назад. Последнее обновление DX SDK было в июле 2010. Интеграции с VisualStudio нет, сообщества разработчиков GPGPU и качественных примеров нормальных вычислительных задач практически нет. Да что уж там, подсветки синтаксиса шейдеров нет! Вменяемых инструментов дебага тоже нет. PIX не способен выдержать несколько вложенных циклов или шейдер в 400+ строк кода. D3DCompiler мог падать через раз и компилировать сложные шейдеры десятки минут. Ад.

    С другой стороны — слабое внедрение технологии. Большинство научных статей и публикаций были написаны, используя CUDA, и заточены под железо NVIDIA. Команда NVIDIA OptiX тоже не особо заинтересована в исследованиях для других вендоров. Немецкая компания mentalimages, которая десятилетиями накапливала опыт и патенты в этой области, теперь так же принадлежит NVIDIA. Все это создает нездоровый перекос в сторону одного вендора, но рынок есть рынок. Для нас это все означало, что все новые GPGPU техники трассировки и рендеринга надо исследовать заново, но только на DirectX и на железе ATI и Intel, что часто приводило к совершенно другим результатам, например на архитектуре VLIW5.

    Реализация


    Устраняем проблемы
    Перед описанием реализации приведу несколько полезных советов, которые помогли нам в разработке:
    • По возможности, переходите на VisualStudio2012. Долгожданная интеграция с DirectX, встроенный debug шейдеров, и, о чудо, подсветка синтаксиса HLSL сэкономят вам кучу времени.
    • Если VS2012 — не варинат, можно использовать инструменты типа NVidia Parallel Nsight, но опять возникает привязка к одному типу GPU.
    • Используйте Windows 8.0 SDK, это ваш бро. Даже если разрабатываете на Windows Vista / 7 и старых версиях VisualStudio, в вашем распоряжении будут последние D3D библиотеки, включая свежий D3DCompiler, который сокращает время компиляции шейдеров в 2‒4 раза и стабильно работает. Для настройки DirectX из Windows 8.0 SDK имеется подробный мануал.
    • Если вы все еще используете D3DX, задумайтесь о том, чтобы отказаться от него, это не бро. В Windows 8.0 SDK прекратили его поддержку по весьма понятным причинам.


    Растеризация vs трассировка
    Не смотря на то, что используется DirectX, о растеризации речи не идет. Стандартный Pipeline вершинных, Hull, Domain, геометрических и пиксельных шейдеров не используется. Речь идет о трассировке путей света средствами пиксельных и Compute шейдеров. Идея комбинирования растеризации + трассировки, конечно же, возникала, но оказалась очень сложной в реализации. Первое пересечение лучей можно заменить растеризацией, но после этого сгенерировать второстепенные лучи очень непросто. Зачастую оказывалось так, что лучи находились под поверхностью, и результат оказывался неверным. К такому же заключению пришли ребята из Sony Pictures Imageworks, разрабатывающие Arnold Renderer.

    Rendering
    Существуют два основных подхода организации рендеринга:

    1. Все вычисления происходят в мега-ядре программы GPU, которая ответственна как за трассировку, так и за шейдинг. Это самый быстрый способ рендеринга. Но если сцена не помещается в память GPU, то произойдет либо свопинг сцены, либо приложение сломается.
    2. Out Of Core Rendering: в GPU передается только геометрия сцены либо ее часть, вместе с буфером лучей для трассировки, и производится многопроходная трассировка лучей. Шейдинг производится либо на CPU, либо еще одним проходом на GPU. Такие подходы не славятся потрясающей производительностью, зато позволяют рендерить сцены продакшн‒размера.




    Мы остановились на первом варианте с использованием шейдеров для GPGPU, но перед тем как что‒либо рендерить, нужно подготовить геометрию и данные о сцене, правильно разместив их в памяти GPU.
    Данные о сцене включают в себя:

    • геометрию (вершины, треугольники, нормали, текстурные координаты)
    • ускоряющую структуру (узлы Kd‒дерева или BVH)
    • материалы поверхностей (тип, цвета, указатели на текстуры, отражательные экспоненты и многое другое)
    • текстуры материалов, карты нормалей и пр.
    • источники освещения (сингулярные и протяженные)
    • положение и параметры камеры, такие как DOF, FOV и пр.

    Никаких вершинных и индексных буферов при рендере не используется. В Direct3D11 данные унифицированы, все хранится в одинаковом формате, но можно сказать устройству, как на них смотреть: как на Buffer, Texture1D/2D/3D/Array/CUBE, RenderTarget и т.д. Данные, к которым производится более‒менее линейный доступ, лучше хранить в виде Buffer'ов. Данные с хаотичным доступом, например, ускоряющие структуры сцены, лучше хранить в текстуре, т.к. при частых обращениях часть данных закешируется.
    Быстроменяющиеся и небольшие куски данных разумно хранить в константных буферах, это параметры камеры, источники освещения и материалы, если их не много и они умещаются в буфер, размером 4096 x float4. При интерактивном рендеринге изменение положения камеры, настройка материалов и света — самая частая операция. Изменение геометрии происходит несколько реже, но константной памяти все равно не хватит, чтобы разместить ее.

    Т.к. памяти в GPU относительно мало, нужно использовать умные подходы к ее организации и стараться запаковать все, что только можно запаковать и использовать сжатие данных. Текстуры материалов мы размещаем в многослойном текстурном атласе, т.к. количество текстурных слотов GPU ограничено. Также, в GPU имеются встроенные форматы сжатия текстур – DXT, которые используются для текстурных атласов и могут уменьшить размер текстур до 8‒и раз.

    Упаковка текстур в атлас:


    В итоге, расположение данных в памяти выглядит так:


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



    Переходим к рендерингу: в вершинном шейдере рисуем квад, размером с экран, и используем технику маппинга текселей в пикселы, чтобы при растеризации каждый пиксел пиксельного шейдера имел правильные текстурные координаты, а следовательно, правильные значения x и y на экране.

    Далее, для каждого пиксела в шейдере производится рассчет алгоритма трассировки пути лучей. Этим способом производятся GPGPU вычисления на пиксельных шейдерах. Такой подход может показаться не самым оптимальным, и более разумно было бы использовать DirectCompute, для которого никаких вершинных шейдеров и скрин‒квада создавать не надо. Но многочисленные тесты показали, что DirectCompute оказывается на 10‒15% медленнее. В задаче трассировки пути все преимущества от использования SharedMemory или использоания пакетов лучей быстро сходят на нет из-за случайно природы алгоритма.

    Для рендеринга используются две техники: интерактивный просмотр работает на модифицированной однонаправленной трассировке пути (Path Tracing), а для конечного рендеринга может быть использована двунаправленная трассировка пути (Bidirectional Path Tracing), т.к. ее фреймрейт весьма не интерактивен на сложных сценах. Семплирование методом Metropolis Light Transport пока не используется, т.к. его эффективность еще не оправдалась, о чем говорит один из разработчиков V-Ray на закрытом форуме ChaosGroup:

    vlado posted:
    “...I came to the conclusion that MLT is way overrated. It can be very useful in some special situations, but for most everyday scenarios, it performs (much) worse than a well-implemented path tracer. This is because MLT cannot take advantage of any sort of sample ordering (e.g. quasi-Monte Carlo sampling, or the Schlick sequence that we use, or N-rooks sampling etc). A MLT renderer must fall back to pure random numbers which greatly increases the noise for many simple scenes (like an open skylight scene).”


    Multi‒Core. Multi‒Device. Cloud.


    Отметим, чем очень хорош unbiased‒рендеринг — он основан на методе Монте‒Карло, а это значит, что в общем случае каждая итерация рендеринга не зависит от предыдущей. Именно это делает данный алгоритм привлекательным для вычислений на GPU, многоядерных системах и кластерах.

    Чтобы поддержать железо классов DX10 и DX11 и не переписывать все заново под каждую версию, стоит использовать DirectX11, который с небольшими ограничениями работает на DX10 Железe. Имея поддержку широкого класса железа и предрасположенность алгоритма к распределению, мы сделали Multi‒Device рендеринг, принцип работы которого очень прост: в каждый GPU нужно поместить одинаковые данные, шейдеры и просто собирать результат с каждого GPU по мере его готовности, перезапуская рендеринг при изменениях в сцене. Алгоритм позволяет распределить рендеринг на очень большое количество устройств. Эта концепция замечательно подходит для вычислений в облаках. Но, облачных GPU‒провайдеров не так много, и компьют‒тайм стоит тоже не очень дешево.

    С появление DirectX11 на помощь пришла замечательная технология — WARP (Windows Advanced Rasterization Platform). WARP Device транслирует Ваш GPU код в SSE‒оптимизированный многопоточный код, позволяя производить GPU вычисления на всех ядрах CPU. Причем абсолютно любых CPU: x86, x64 и даже ARM! С точки зрения программирования, такое устройство ничем не отличается от GPU устройства. Именно на основе WARP в C++ AMP реализованы гетерогенные вычисления. WARP Device — тоже ваш бро, используйте WARP Device.


    Благодаря этой технологии мы смогли запустить GPU рендеринг в CPU облаке. Немного бесплатного доступа к Windows Azure мы получили через программу BizSpark. Для хранения данных был использован Azure Storage, данные с геометрией сцены и текстурами хранились в “блобах” (Blobs), данные о заданиях рендеринга, закачке и скачке сцен находятся в очередях (Queues). Для обеспечения стабильной работы использовалось три процесса: распределитель задач (Work Scheduler), наблюдатель за процессами (Process Monitor) и процесс, скачивающий отрендеренные изображения (Image Downloader). Work Scheduler ответственен за загрузку данных в блобы и постановку задач. Process Monitor отвечает за поддержание всех воркеров (Worker – вычислительный узел Azure) в рабочем состоянии. Если один из воркеров перестает отвечать, то происходит инициализация нового экземпляра, таким образом, обеспечивается максимальная работоспособность системы. Image Downloader собирает отрисованные куски картинки со всех воркеров и передает готовое или промежуточное изображение клиенту. Как только задача рендеринга выполнилась, Process Monitor ликвидирует образы воркеров, чтобы не было простаивающих ресурсов, за работу которых пришлось бы платить.


    Эта схема неплохо работает, и за этим, как нам кажется, будущее рендеринга – Pixar уже осуществляет рендеринг в облаке. Обычно облачная тарификация идет только за скачанный траффик, который состоит из отрендеренных картинок размером не больше нескольких мегабайт. Единственное узкое место такого подхода – канал пользователя. Если вам нужно редерить анимацию с размером асетов в несколько десятков или сотен GB, то у вас проблемы.

    Результат


    Результатом всей этой работы стал плагин RenderBro для Autodesk 3DS Max, который, как и задумывалось, должен рендерить даже на бабушкином компьютере и может использовать любые вычислительные ресурсы.



    Сейчас он находится на стадии закрытого альфа тестирования. Если Вы GPU‒энтузист, 3D‒художник, задумали построить ATI/NVIDIA кластер, у Вас куча разных GPU и CPU или любая другая интересная конфигурация, дайте знать, будет интересно вместе поработать. Очень хотелось бы проверить рендер на чем-нибудь вроде этого:


    Так же, впереди C++ AMP версия рендера, более серьезные облачные тесты и разработка плагинов для других редакторов. Присоединяйтесь!
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 55

      +1
      Шикарно! ждем под другие редакторы. Молодцы!
        0
        Лого люкса детектед
          +2
          все верно :)
          своего bro-шара для тестовых рендеров пока нет
          0
          очень круто!
            0
            Молодчага. Бетатестером возьмёте?) И у меня еще есть желающие
              0
              Мощный проект! Позволит ли это использовать реалтайм Unbiased рендеринг высочайшего качества для игр, собирая «домашние облака»?
                0
                У последних поколений видеокарт NVIDIA и AMD есть фича, которая позволяет одному GPU перекидывать память в другой минуя системную память. Если собрать ящик из 6-8 таких GPU, то фреймрейты будут что надо, и картинка будет хорошей. Вопрос только зачем это? Для студии анимации это имеет смысл, чтобы сократить время на настройку сцен. Для игр — не понять. Установка слишком дорога, чтобы найти масс-маркет.
                  0
                  ну 2-3 видюхи народ ставит для игр. Вобщем не жуть как дорого получается
                    0
                    Да вот пример 2xGT580 www.youtube.com/watch?v=gZlCWLbwC-0
                      0
                      да, это движок Brigade. Подразумевается, что он будет игровым. Наша разработка тоже в эту сторону движется, но лишь как очень-очень ранний прототип. До игр еще далеко.
                      0
                      для игр multi-GPU используют через SLI или Cross-Fire, когда устройства логически объединяются в одно. Чтобы делать рендеринг на нескольких картах, надо значительно перерабатывать игровой движок и тратить много сил на коммуникацию между GPU. На старых поколениях это был гемор. На новых намного легче, но мало кто это будет делать в ближайшее время, рынка нет для этого.
                  +2
                  Еще б не под 3д макс, вобще б хорошо было
                    0
                    в смысле, я за standalone версию с привязками к разным пакетам. О кроссплатформенности речи не идет пока, как я понимаю?
                      0
                      Я б тоже пощупал консольно-автономную версию.
                      Эх, была б под Linux — я б на нашей GPU-ферме накатил 8(
                        –1
                        Пока будет на Direct3D, то это, конечно, только Windows. С++ AMP поправит положение дел, но еще нужно убедиться, что на нем рендер будет так же быстр.
                          0
                          Ну на самом деле интересна скорее именно standalone версия, операционная система дело десятое
                        0
                        Есть наработки для Google SketchUp, он на очереди после 3ds Max.
                          +1
                          А для Blender ожидается?
                            0
                            Думаю, нет. Создание плагина под редактор – огромная работа. Над этим проектом всего 2.5 человека работает :) Если есть желание им заняться, присоединяйтесь!
                        +1
                        Волшебно.
                        Одно только интересно — а насколько реальны перспективы облачного рантайм рендеринга?
                          0
                          Поясните пожалуйста, что такое рантайм? Работать в 3ds Max'е, и получать моментальный отклик рендера, который рассчитывается в облаке? Не совсем понял.
                            0
                            Я имел в виду интерактивные миры и игры, разумеется.
                              +1
                              Тут возникает несколько проблем:
                              1) Precompute. Создание качественного BVH или Kd-дерева для сцены с большим количеством полигонов – не быстрый процесс. У нас на создание BVH для сцены с 2млн полигонов уходит 300-600 ms. А что если сцена намного больше и меняется каждый фрейм, что и происходит в играх? Тут с фреймрейтом все плохо. А ведь мы еще и до рендеринга не добрались. Мы сейчас работаем над распределением построения BVH на все ядра CPU. Это должно ускорить процесс, но не так значительно, как хочется.
                              2) Rendering. Можно очень быстро отрендерить несколько самплов и получить шумную картинку. Если хочется лучшего качества, нужно увеличивать количество самплов рендеринга. Это линейно увеличивает время. Тут можно применять умные техники фильтрации, которые, к слову, тоже не самые быстрые.

                              Если грамотно распределить эти задачи между устройствами, то можно добиться хороших результатов. Тут важно, чтобы устройства в облаке были очень близко или имели быстрый доступ друг к другу. Но передача изображения по узкому каналу пользователя сведет на нет работу даже очень близко расположенных сильных устройств. В этом можно убедиться на примере сервиса OnLive.
                                0
                                >У нас на создание BVH для сцены с 2млн полигонов уходит 300-600 ms. А что если сцена намного больше и меняется каждый фрейм, что и происходит в играх?
                                в играх сцена между фреймами меняется далеко не полностью, поэтому BVH не нужно строить с нуля каждый раз, достаточно обновлять
                                  0
                                  Всю сцену – да. У многих объектов анимация, их надо перестраивать, а остальную сцену обновлять. Это, конечно, намного быстрее.
                          0
                          А где можно достать модель Mech Octopus'а?

                          При долгом вычислении на GPU «Timeout Detection and Recovery» не приходит?

                          Как по качеству/скорости сравнимо с Octane/Cycles?

                          Не боитесь, что черемерное употребление «bro» на сайте отпугнет англоязычных пользователей?
                            0
                            Если карта слабая или сцена очень тяжела, то Watchdog ругается и сбрасывает рендер. В таком случае Timeout Detection and Recovery можно отключить. При установке плагина сделаем опцию отключения. Но вообще не рекомендуют это делать. Хотя ничего страшного в этом нет, карта не сгорит :)
                            По факту, финальный рендер лучше осуществлять без интерактивного отображения в окно. Для этого можно отключить timeout и поставить карту работать. Проверено, что рендер в таком случае может быть до 2-2.5х раз быстрее.
                            0
                            Есть ли сейчас возможность запустить распределенный рендер на нескольких машинах? Есть зоо-парк из почти 100 машин Core i7+GTX 570 и свободное время по ночам. Уже запускали рендер на 20 в течении недели, не очень удобно в установке и настройке, но быстрее на порядок.
                              0
                              Ого) 100 Core i7 + GTX 570 звучит… дорого :)
                              Очень интересная возможность, но на разных машинах пока проблематично. Мы только проверили концепт, что так можно сделать, но до хорошего автоматизированного решения руки еще не дошли. Можно запустить рендер на всех машинах машинах, но результат пока придется собирать руками. Вот если у вас много GPU+CPU в одной машине, то тут без проблем.
                                0
                                Это рабочие станции, пробовали делать обычный SLI, но он просто не поддерживается большинством программ. Несколько CPU (2 Xeon W5580) есть только на одном компьютере, но там только одна GPU (Quadro 5800). Когда посчитали время рендера получилось около месяца, собственно для этого и развернули распределенный вариант.
                              0
                              >> Работает на всем спектре видеокарт, эмулируется на всех моделях процессоров:

                              А также эмулируется на армах и мипсах, да? Не заметил что-то.

                              >> один и тот же шейдер работает везде
                              >> Именно спецификации Direct3D задают направление развития потребительского железа

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

                              >> Всегда первым получает самые свежие и стабльные драйверы
                              >> Остальные кросс‒вендорные технологии не стабильны, либо слабо поддерживаются

                              А чем поддержка OpenGL и OpenGL ES хуже то? Для целого спектра девайсов это единственное доступное API.

                              Я пока вижу в основном такой довод, что взяли то, что лучше всего умели и знали, остальное так сверху дописали чтобы убедительнее было.
                                +1
                                Не дай нам боже рендерить на мобилах для продакшена
                                  0
                                  А Linux фермы, linux суперкомпьютеры? ARM и MIPS это весьма дешевые процессоры и из них можно весьма дешево насобирать очень мощный кластер, куда с D3D дороги никакой нет!
                                    +2
                                    А что уже есть нормальные дешевые ARM платформы, пригодные для сборки ферм?
                                  0
                                  На ARM без проблем, про мирсы речи не было. Так C++ AMP работает, берет GPU код и транслирует его на каждую поддерживаемую платформу (x86, x64, ARM). Эта фича WARP, заложенная в DirectX 11.

                                  OpenGL, в том числе ES, можно использовать только для простых алгоритмов рендеринга. Они просто не были созданы для такой производительности, которая требуется для unbiased рендеринга.
                                    0
                                    >> Они просто не были созданы для такой производительности, которая требуется для unbiased рендеринга.
                                    О какой производительности идёт речь? Отрисовать 1 треугольник?
                                  +2
                                  >плагин RenderBro для Autodesk 3DS Max, который, как и задумывалось, должен рендерить даже на бабушкином компьютере

                                  и ниже комп с десятком вставленных Тесл в качестве примера :)
                                    +2
                                    бабушек не выбирают ;)
                                    0
                                    А анимацию не пробовали им рендерить? Было бы интересно посмотреть
                                      +2
                                      Анимацию пока нет. У нас со статикой-то проблемы возникают. Код Autodesk — такой кусок говна. 3ds Max SDK и создание плагина вызвало у нас больше проблем, чем создание самого рендера.
                                        +1
                                        Да там еще с времен, когда макс принадлежал discreet, народ матерился на писание плагинов к нему )))
                                      0
                                      Отличная статья!
                                        0
                                        Но гибридные рендеры более перспективны. furryball.aaa-studio.eu/
                                          –1
                                          Гибриды бесконечно гибкие, чистые GPU о таком и не мечтают. Но у них разные задачи.
                                            0
                                            Под «гибридными» имел ввиду не unbiased. Почему выбор пал на unbiased? Из-за простоты реализации? Какие конечные цели проекта?
                                            Насчет физкорректности: можно осветить синим цветом оранжевый шарик? :)
                                              0
                                              Промахнулся с ответом. См. ниже.
                                        0
                                        Недопонял Вас значит. Под гибридом я подразумевал метод трассировки, а не сам рендер (когда GPU лишь помогают найти пересечения лучей, но не отвечают за шейдинг). Unbiased хорошо подходит для архитектуры GPU. Простота – довольно спорный момент. Качественная реализация Bi-Directional Path Tracing или Metropolis Light Transport на GPU не так проста.
                                        Конечная цель – рендер, наилучшим образом работающий на широком классе GPU.
                                        >Насчет физкорректности: можно осветить синим цветом оранжевый шарик? :)
                                        Можно. Взять например голубоватое небо с теплотой цвета 7000 Кельвинов и выше.
                                          0
                                          Не хотел нисколько принизить сложность реализации вашей работы, с вопросом про гибридность, просто думал это промежуточный этап. По ссылке что я привел — рендер с предварительными фильтрациями и трэйсингом. Он позволяет достичь очень высокой скорости на широком спектре аппаратных устройств.
                                          Формулировка конечной цели все равно ускальзывает от меня — какова область применения? Архитектура, анимация или прокачка своих скилов?
                                          >Можно. Взять например голубоватое небо с теплотой цвета 7000 Кельвинов и выше.
                                          Тут вопрос с подвохом был. если взять источник синего цвета (0,0,1) и оранжевый шарик (1, 1, 0) то при при просчете диффуза он станет черным, т.к. в подавляющем большинстве даже «физкорректно» названные рендеры работают с RGB пространством покомпонентно. т.е. (0*1, 0*1, 1*0) что дает 0.
                                          Но вообще вы молодцы что взялись за такое — буду наблюдать с интересом.
                                            0
                                            Про черноту первый раз слышу, не знал, что анбиасы таким болеют. Для теста: куб цвета (1, 1, 0), освещение цвета (0, 0, 1).
                                            image
                                              0
                                              Нужен дифуз колор, который реагирует на лайт. Я не знаю как в максе — по виду на скриншоте это констант — которые не зависят от освещения.
                                                0
                                                это проблема не анбиаса, а RGB пространства.
                                            0
                                            Друзья раз пока вопрос не стоит о коммерческой выгоде, может зарелизите публично альфу? так и фидбеков будет больше :)
                                              0
                                              Пока нет. На данный момент у нас уже очень много заявок на альфа тест, который будет проходить закрыто.
                                              0
                                              О, дык Бро это еще и наши придумали! Молодцы!
                                              На днях как раз оставлял вам заявку на тест.
                                                0
                                                заявку отправил а ответа нет(
                                                когда релиз?

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

                                                Самое читаемое