Трассировка пути на GPU, часть 2

    Первая часть обнаружена тут.

    Чтож, рассмотрим:
    Видеокарта: Nvidia GeForce GTX580 (надо учитывать, что не каждый захочет ради еще не развитой технологии GPU рендеринга покупать топовую видеокарту), Частота шейдеров 800 MHz, 512 ядер CUDA.
    Тестовая сцена: хоровод стендфордских высокополигональных дракончиков, танцующих вокруг светящейся шестиугольной призмы, висящей в воздухе.

    image
    Вот эти ребята.

    Чего хотим добиться: минимального шума при минимальных вычислительных затратах.
    Сложности:
    1. Большинство испытаных рендеров не поддерживают SSS.
    2. Демоверсии Octane Render и Arion Render имеют ограничение по разрешению, а сцены типа «шар на поверхности при дневном свете» очищаются от шума быстро даже на CPU рендерах, тем более при столь небольшом разрешении.
    3. Сложностью для всех видов рендеринга является рендеринг непрямого освещения, в частности интерьеров, а особенно каустика, на которой мы и остановимся.


    Octane Render
    OctaneRender_DEMO_1024_beta246b_win_x64
    Порадовала скорость при прямом освещении. Картинка в разрешении 1000х600 почти полностью очищается. за 3-5 секунд.
    image

    Теперь займемся каустикой.

    image
    И где? А как же Physically Based? И зачем я брал такую видяху?
    Целых 15 секунд ждал, пока хоть что-то просветит, не просветило и спустя несколько минут. Перекрутил все настройки. Значит её либо нет, либо она урезана в демо версии (тогда как можно в демонстрационной версии урезать такие важные вещи?).
    Негодую.

    Минусы:
    1. Не работает каустика!
    2. Отсутствует SSS (походу, только в демоверсии)
    3. Неудобный редактор материалов, примитивные шейдеры.
    Очень хочется видеть редактор материалов как в Maxwell или Fry, где каждый материал состоит из нескольких слоев, на мой взгляд очень удобен.

    Iray
    В коробке с 3ds Max 2012.
    В отличии от Octane, iRay рендерит каустику:
    image
    iRay на 15-й секунде, да будет каустика!

    Минусы:
    1. Отсутствует интерактивная визуализация (картинку нельзя покрутить в реальном времени), однако при использовании 2-х видеокарт iRay рендерит интерактивно (не знаю, как на счет geforce, но при использовании quadro + tesla работает точно).
    2. Немного примитивные шейдеры, подобные Octane.

    Arion
    RandomControl ARION (64-bit) — v2011.08.19 — v1.5.02 Beta DEMO
    Арион — очень своеобразная программа. Интерфейсом он мне напомнил Maxwell (он и Fry напоминает), достаточно удобен, хороший редактор материалов.
    Однако, существую разные баги, например есть функция вращения объекта, но точка, относительно которой он вращает объект находится где-то очень далеко за пределами экрана, поэтому вместо того, чтобы посмотреть объект с разных сторон — мы частенько «улетаем» в неизвестном направлении. Заметил, что лечится созданием новой камеры, которая сразу знает относительно какой точки вращаться.
    Еще один интересный баг повлиял на все тестовые сцены. Оказывается, если убрать свет неба — не будут светить источники света. Почему? Может источники света работают на солнечных батареях, расположенных где-то неподалеку? Заметил, что такое никак не лечится, кроме как «сделаем во всех рендерах серое небо», ради справедливости тестов.
    Кроме того, Arion спокойно рендерит и на CPU. Правда очень спокойно (в моем случае, core i5 2500 уступал в скорости рендеринга раза в 4-5).
    image
    Минусы:
    1. Не работает автофокус.
    2. SSS присутствует, но не работает.
    3. Сильно много шума от каустики.
    4. Множество багов и недоработок.

    Cycles
    Найден в коробке с Блендером 2.60
    На удивление, ОЧЕНЬ неплохой opensource (встроенный в специальную сборку Блендера) рендер.
    Поддерживает OpenCL, CUDA, также может рендерить и на CPU. Есть возможность лицезреть результат прямо во вьюпорте Блендера. Можно двигать (!) геометрию там же (правда, тяжко будет, если геометрия сложная).
    Хотелось бы:
    1. Встроить его в 3д Макс, Синьку, Рино и другие пакеты.
    2. Добавить SSS.
    3. Добавить физ. небо.
    4. Включить оптимизацию ERPT или MLT, дабы сократить время снижения шума от каустики.
    5. Добавить фото-tonemapping для естественной цветопередачи.
    image
    Минусы:
    1. Кто не любит/не знает блендер — не сможет пользоваться им.
    2. Примитивные шейдеры.
    3. Нету физически корректного процедурного неба.

    Indigo, Lux рендеры не тестировались, т.к. не являются 100% GPU рендерами. Они с помощью видеокарт ускоряют вычислительный процесс, но скорость их существенно ниже true GPU рендеров.

    GPU unbiased рендеры еще не вышли «в массы», имеют множество недостатков, но их судьба предопределена. Технология вычисления на графических ускорителях значительно увеличивает скорость рендеринга.

    Делайте выводы, господа!
    Поделиться публикацией

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

      0
      Интересно.
      А вот на такой вопрос сможете ответить: в openGL 4 есть трассировка каустики?
        +1
        Ну, встроенной, наверно нет, но каустику можно нарисовать и средствами более ранних opengl.
          +1
          Действительно, даже старые версии позволяли это:
          http.developer.nvidia.com/GPUGems/gpugems_ch02.html
          www.gamedev.ru/code/articles/caustic

          А возможности взаимодействия openGL4 с вычислениями на GPU без необходимости гонять данные в оперативку компьютера, а потом обратно в буфер оперативки видеокарты, наверняка позволят сделать довольно сложные отображения в реальном времени.

          Вот, кстати отличная иллюстрация построения простой каустики в реальном времени (обычный webGL, каустика, к сожалению, работает лишь в хроме):
          madebyevan.com/webgl-water/
            0
            evan вообще жжот на webgl :)
        0
        А кто-нибудь может мне объяснить, доросли ли современные мощности видеокарт для отрисовки в реальном времени освещения методом трассировки лучей? Или все же там применяются какие-то упрощения и ухищрения?
          0
          Всё от сцены зависит
          0
          В Octane точно есть каустика (пр. www.octanerender.com/forum/viewtopic.php?f=6&t=9448 ), но сам с ним не разбирался, так как осх-версии до сих пор нет. Вообще все анбиасы для большинства действительно скорее поиграться, я не знаю ниодного фрилансера, например, который бы на анбиасах считал 3д. В то же время знаю студию, которая мультики в Максвелле рендерит. Интересно, что дальше будет.

          ps А Keyshot почему забыли?
            0
            Keyshot и Shot используют iRay. Кстати, ускорение от видяшки чувствуется, и вращать вьюпорт в реальном времени тоже возможно. Хорошая программка.
            0
            1. Отсутствует интерактивная визуализация (картинку нельзя покрутить в реальном времени), однако при использовании 2-х видеокарт iRay рендерит интерактивно (не знаю, как на счет geforce, но при использовании quadro + tesla работает точно).

            Если про ActiveShade — то оно есть, но в Subscription Advanced Pack.
            Тук
              0
              Пардон, парсер убрал ссылку:
              usa.autodesk.com/adsk/servlet/pc/item?siteID=123112&id=15451618
                +4
                Cycles после одной минуты на GPU:


                Ролик для желающих посмотреть, как работает в реальном времени:
                vimeo.com/27409184

                Ещё много видеоуроков по Cycles: cgcookie.com/blender/category/tutorials/cycles-tutorials/

                Про небо, а что вы понимаете под физ. небом? В Cycles можно организовать освещение по hdr-окружению (пример) или сгенерировать текстуру неба с помощью ноды «Sky texture».

                «Cycles: Добавить SSS» — можно сымитировать с помощью разных материалов. Да, это не настоящий SSS, но если никому не говорить, никто не догадается =)

                Indigo, Lux рендеры не тестировались, т.к. не являются 100% GPU рендерами.
                А вот это зря. 100%-го GPU-рендеринга в природе не существует, это изобретение маркетологов. Всякие расчёты замкнутых пространств, сортировки и процедурные генерации нетривиальных текстур всегда будут на CPU, ибо векторизовать там практически нечего. А вот пустить тысячи лучей во всех направлениях — это как раз задача GPU во всех движках, где GPU используется.

                Что касается LuxRender, он вообще стоит на отдельном пьедестале: пока люди разбираются с отключённой каустикой в Octane, LuxRender по умолчанию работает в полном спектре (а не RGB), в воздухе при температуре 25 градусов и имитирует существующие модели камер при цветокоррекции.
                  0
                  Забыл сказать, что моя видеокарта GeForce GTX 275 достаточно старая и современные видеокарты могут выдают картинку выше в разы быстрее.
                    0
                    Physically based sky присутствует почти во всех пакетах, обычно позволяет задавать географические координаты и дату/время, исходя из этого строит освещение: ставит солнце и красит небо. Ести нода Sky texture позволяет это делать, то это и есть физ. небо
                      0
                      как-нибудь потестю :)

                      Очень жаль, что отсутствуют универсальные стандарты в рендерах.
                      Вот есть шейдеры для OpenGL, которые можно вставить в любой движок, и материал будет вести себя как надо.
                      А вот с трассировщиками пути так просто дело не стоит. Созданные в Максвелле материалы — в iRay никак. Каждая организация «гнет свою линию».
                        0
                        А где скачать саму сцену?
                          0
                            0
                            а можно в блендоровском формате, а то импортирую в блендер и пусто, я хотел скорость протестировать у меня видеокарта radeon 4870, но слабый проц и оперативки 2гб
                        0
                        Без каустики и SSS (но со всякими там scene-space ambient occlusion), сценеры уже лет пять-шесть как умеют делать такое не только в реалтайме, но и запихивать в 4-килобайтные exe'шники. Например (утуб).
                        0
                        Люди, кто-то видел smallluxgpu под винду?
                          0
                          И еще вопрос программистам.
                          Вот существует madebyevan.com/webgl-path-tracing/ трассировщик пути на web-gl. Выходит, для рендеров вовсе не нужды во всяких там CUDA, OpenCL, достаточно просто писать программу на шейдерах. Я слышал (не могу найти ссылку), что на шейдерах и физику можно писать.
                          Если язык шейдеров, использует вычислительные ядра GPU, и отлично работает с float, почему существуют CUDA, Firestream, PhysiX и прочие?
                            0
                            Насколько я могу догадываться (а я довольно нуб в теме CUDA-и-пацаны), причины примерно две:
                            1. CUDA появилась раньше, чем GL/D3D-биндинги к шейдерам дали возможность делать аналогичное, а железо уже умело
                            2. GL/D3D всё же рассчитаногвоздями забито на расчет и вывод графики пользователю в глаза, поэтому там свой собственный конвейер, другие требования к точности и прочая, прочая
                              0
                              Традиционное объяснение — разные технологии с разными возможностями. Например, OpenCL умеет выполнять вычисления одновременно и на CPU и на GPU. Но результатом является крайне сложный для понимания код (на мой взгляд). CUDA имеет красивый си-подобный синтаксис и специальные оптимизации в компиляторе. Все эти технологии в чём-то особенны и удобнее других.

                              А вот что выходит на практике:
                              1. Microsoft-у выгоден DirectX+ HLSL для игр и AMP для вычислений, поскольку привязка приложений к нему означает привязку к продуктам Microsoft
                              2. Mac OS, Linux и прочим осям выгодны OpenGL и GLSL, поскольку разрабатываются независимой компанией, которая не станет требовать отчислений
                              3. CUDA железно выгоден только NVIDIA
                              4. FireStream железно выгоден только AMD
                              5. OpenCL не выгоден никому, поскольку разрабатывает его независимая организация, а реализация общедоступного стандарта не даёт возможности производителям привязать программы к своему оборудованию. На практике это выражается в медленном переходе на новые версии стандарта OpenCL по сравнению со скоростью перехода на новые версии CUDA и FireStream.
                                0
                                кстати, да!
                                Надо сказать, что GLSL возможен практически на любых видеокартах и при любых осях.
                                Но почему, тогда все кинулись делать трассировщики пути на CUDA, а никак не на шейдерах, которые появились значительно раньше CUDA.
                                  0
                                  Забавно, что я, например, наоборот о трассировщиках на CUDA не слышал совсем ничего, а на шейдерах — уймищу всего. Да и по ссылкам, которые я привел выше, как раз такие шейдерные трассировщики и есть.
                                  На самом деле для трассировки лучей от шейдеров нужны как минимум две вещи: (а) честная поддержка ветвлений и циклов (они появились, емнип, в GLSL 1.20), (б) довольно большой допустимый размер программы. Все это стало массово доступно где-то в районе 2005 года, хотя, например, мой ноутбук 2007 года напрочь не умеет ветвиться, и инструкций во фрагментном шейдере у него может быть всего 64 штуки — каши особой не сваришь.
                                    0
                                    ноутбук случайно не с Intel GMA? :)
                                      0
                                      Не, там что-то вроде ATI rs485, который на самом деле модификация r300.
                                  0
                                  Предположу обратное: OpenCL более выгоден разработчикам ПО, т.к. не привязывается к конкретному производителю железа. Разработчик ПО на CUDA рискует пострадать, например, от внезапного повышения цен на карты NVIDIA. И спрос на его ПО упадет из-за того, что оно не универсально и не работает на картах других производителей. ИМХО.
                                    0
                                    Короче, я так думаю, что кардинально этот вопрос может решить открытое аппаратное обеспечение, чтобы производители ПО могли модифицировать железо под свои нужды.
                                    +1
                                    OpenCL спонсируется Apple и впервые как полноценной реализация появился именно в Mac OS X 10.6.

                                    На текущий момент (да и самого начала) openCL был на маке из коробки причем и для gpu и cpu сразу.

                                    Шейдеры напрямую очень редко используются в мак программах, любая программа может использовать openCL причем без ограничений в стиле невозможен больше запуск граф программ и тд.

                                    Я думаю что openCL это будущее, при должной степени старания вендоров
                                  0
                                  Немного промазал с ответом (см. выше)
                                  –1
                                  Обнаружил исходники Октана… это кому надо было их выкладывать?
                                  thepiratebay.org/torrent/6735365/Octane_Render_Source_Code

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

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