понедельник, 24 октября 2016 г.

two-stage mlt

рассматривал mitsuba render в действии и заметил, что есть в kalemen-style mlt(в mitsuba этот метод называется primary sample space mlt) галочка two-stage mlt.
все попытки понять что это такое отсылали меня к чтению документации.
оказывается, сначала генерируется картинка 1/16 размера и высчитывается variance начальных путей для mlt, далее с использованием variance выбирается путь, что даёт более точную картинку.
direct samples не делает картинку лучше. поэтому они и не нужны



на что обратить внимание

воскресенье, 23 октября 2016 г.

обзор nox render

nox renderer - render от evermotion.com, ныне - opensource. исходный код можно загрузить с сайта. из интересного для меня:
  • path tracing, bidirectional path tracing

  • прогрессивное обновление изображения
  • render passes, здесь называемые LAYERS
  • разные алгоритмы заполнения изображения семплами
  • аккуратное управление камерой - фокусное расстояние, пресеты обьективов

  • очень хороший редактор материалов
  • присутствуют пост-эффекты bloom, glare, fog
  • коррекция изображения с помощью кривых
  • настройки антиалиазинга и пресеты фотоплёнок
  • хорошие настройки солнца, неба, атмосферы
  • оптимизация геометрии при загрузке - находятся дубли вершин и сохраняются только неповторяющиеся. экономит память
  • удобный интерфейс
внимательный читатель заметит, что я обошел стороной вкладку FAKE DOF. я там ничего не понял и слово fake меня отогнало

в комплекте с исходниками идёт и nox bench

загружается и рендерится достаточно увесистая сцена с помощью nox render
сцену можно загрузить в nox render

из минусов
странно на этапе загрузки сцены видеть, что вычисляются uv-координаты и дисплейсмент
я бы рассчитал потом, когда это действительно понадобится
процесс загрузки сцены

суббота, 22 октября 2016 г.

о 3х-проходном методе рендеринга. продолжение

в прошлой заметке я показывал вот такую схему проходов рендеринга

если внимательно посчитать и подумать, то:
1й проход это 1/16
2й проход это 4/16
3й проход это 16/16 - 4/16 - 1/16 = 11/16

многовато на 3й проход... подумалось мне и придумал я другую схему

в новом варианте на 2м проходе немного странноватая схема - не 2х2 блок, а 2 на 3 строки
итого:
1й проход 1/16
2й проход 6/16
3й проход 16/16 - 1/16 - 6/16 = 9/16
так вроде бы лучше ;-)

хотел заметить, что фотонов выпускать нужно 1/16, 6/16 и 9/16. размер изображения 1/4, 1/2, 1/1

понедельник, 17 октября 2016 г.

manifoldis next event estimate

в ближайшее время возьму реализацию PTMNEE из nanogi.cpp и внедрю в свой PEPELAC RENDERING BANDURA отдельным рендером на основе pathtracer.hxx, в работе которого и всего комплекса основного рендеринга я насилу разобрался

а это мой пепелац, который скоро уже выйдет в люди. готовлю первую версию публичную версию

суббота, 15 октября 2016 г.

render dev roadmap

хорошее дело - дорожная карта. не даёт сбиваться с пути разработки и расфокусироваться на задачи оптимизаций и наворотов фич небывалых отовсюду, отнимая кучу времени на пустые тесты.
расфокусироваться очень легко - много сейчас интересных исходников и пдфок с отчетами и идеями!
итак, моя дорожная карта на ближайшее время:
  • запоминать render passes, в том числе по технологиям, как в UPBP
  • variance adaptive importance sampling for cam paths, как в akari
  • AdaptiveDistributedRenderScene() готово
  • далее - воплотить 3х-ступенчатый метод рендеринга готово
  • добавить texture mapping, bump mapping, displacement, процедурные текстуры
  • добавить tinyexr для чтения и записи exr
  • добавить assimp кучи форматов 3d-сцен и обьектов, оптимизировать assimp в плане поиска в строках и любимую мной буферизацию добавить
  • на основе примера из fox toolkit сделать загрузчик и просмотрщик всех форматов 3d, поддерживаемых assimp
  • добавить загрузчики и сохранение изображений из stb_image, lodepng для png, jpeg compressor для jpg
  • добавить uniform grid scene accelerator - для вокселизации всей сцены и сделать мою реализацию, без хранения большого массива массивов с обьектами. линейный массив и бинарные поиски!
  • добавить qbvh из akari. создавать qbvh в каждой ячейке grid, к которой происходит обращение. можно кешировать и выбрасывать из кэша, если память нужнее
  • попробовать переписать vector.push_back на emplace_back и проверить насколько мой arr_list быстр и уместен
  • hdri освещение с importance sampling из akari
  • сохранение hdr с rle-упаковкой из akari, код записи которого я недавно ускорил с 17 секунд на файл до 0,6 секунд. это всё чудеса буферизации и выбрасывать нужно по-тупому используемые функции, которые дико там не к месту. код не лучше, чем у меня, и потому внедрять его не стану

пятница, 14 октября 2016 г.

akari MinGW build !!!

minGW port of akari
я наконец-то собрал akari с помощью MinGW компилятора gcc.
теперь заживу!
меня останавливало от продолжения работы над рендером отсутствие вменяемого примера, когда qbvh собирается с MinGW без ошибок


преимуществом факта сборки с помощью MinGW akari стало то, что можно будет собирать мой рендер на любой платформе без потери скорости

мне радость!!!!!!!!!!
потому что из akari можно взять работу с апертурой-изображением, variance-based importance sampling path tracing, importance sampled IBL, qbvh и еще парочку штук

среда, 12 октября 2016 г.

vcm в 3 прохода с импортансами в придачу

пока в виде идеи, но на днях воплощу такое:
отрываю фотошо и рисую простую картинку с линиями и циферками, которую рисовал в блокноте сегодня


  1. первый проход
    • выпускается 1/4 лучей из ламп от размера изображения
    • просчитывается картинка 1/4 от размера кадра
    • если итерация алгоритма первая, то зарисовать все остальные пикселы полученным цветом. маленькие цифры покажут что я зарисую тем же цветом пиксела
    • шаг к следующей комбинации 4
    • у меня исполняется за часть секунды (0.1 - 0.3), у людей компы посильнее и будет очень быстро
  2. второй проход
    • выпускается 1/2 лучей из ламп от размера кадра
      *просчитануя на предыдущем проходе хэшмап фотонов можно использовать в качестве импортонов - для улучшенного попадания лучей в действительно важные области изображения
    • просчитывается картинка с на размер изображения 1/2 от размера изображения с учетом variance от картинки с прошлого шага. адаптивный самплинг тут сделаю
    • если итерация алгоритма первая, то зарисовать все пикселы справа и снизу квадратами 2х2
    • шаг к следующей комбинации 2
    • у меня исполняется за 3 секунды
  3. третий проход
    • всё также, как и в 2м
    • у меня исполняется за 3 секунды

итерация - это один полный цикл трейсинга для получения полного кадра
проход - в каждой итерации 3 прохода
комбинация - это цикл прохода по пикселам изображения - сначала обработаются все 1, затем все 2, затем все 3

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

1/4 размера кадра у меня исполняется за часть секунды (0.1 - 0.3), у людей компы посильнее и будет очень быстро
1/2 размера кадра - за 3.5 секунды
полный кадр просчитывается за 17 секунд

воскресенье, 9 октября 2016 г.

Volumetric Vertex connection and merging и другие новшества из проекта UPBP

при внимательном изучении кода UPBP обнаружил:
upbp_bpt это vbpt(volumetric bidirectional path tracing)
upbp_surf - vertex merging фотоны на поверхности
upbp_vcm = upbp_bpt + upbp_surf, volumetric vcm
upbp_pp3d - point to point merging - соединяет фотоны volume - дымы, туманы и прочее такое, немного совсем замедляет рендеринг
upbp_pb2d - point to beam - связывает фотоны с photon beam(световые трубы), замедляет ощутимо, до 2х раз время рендеринга
upbp_bb1d - beam to beam - связывает световые трубы, капец как сильно замедляет рендеринг

upbp_bpt, upbp_surf, upbp_pp3d работают с фотонами-точками,
upbp_pb2d, upbp_bb1d - с photon beams - световые трубы, снопы света

*помимо упомянутых здесь photon beams, облегчающих задачу визуализации volumetric-эффектов есть еще Progressive Expectation–Maximization for Hierarchical Volumetric Photon Mapping, который ускоряет рендеринг по сравнению с photon beams.
изображение из pdf


все эти алгоритмы нашёл как пустить через importance sampling дабы избежать долгого рендеринга.
спасибо авторам UPBP за внятный код и реализованные там алгоритмы сохранения DebugImages - сохраняются изображения покрытия семплами для каждого алгоритма и даже по проходам картинки сохраняются

на State of the Art in Photon Density Estimation SIGGRAPH 2012 Course также есть интересная техника Photon Relaxation

из исходников вытер всякое упоминание методов рендеринга, которые дублируются в upbp.hxx - exe уменьшился на 100 кб. небольшое, но всё ж уменьшение ;-)

среда, 5 октября 2016 г.

что такое Vertex Merging в алгоритме Vertex Connection and Merging (vcm)

читая исходный код UPBP, наткнулся на неплохую реализацию Volumetric Bidirectioanl Path Tracing.
и многое мне напоминало код vcm.
сравнил код VolBidirPT.hxx и VertexCM.hxx увидел, что отличие, кроме volumetric-кода, в коде Vertex Merging.
в vcm, upbp он есть, а в vbpt - нет.

bpt vcm

33s
 
56s
 

39s
 
 
73s
 

37s
 
 
71s
 

29s
 
 
44s
 
в обоих случаях - 5 проходов

между Generate light paths и Generate camera paths
вписан следующий код

создаётся на основе запомненных попадений луча в обьекты и цвета этих "фотонов" хэш-таблица для progressive photon mapping, который дописывается после vertex connection, который в свою очередь собирает лучи из камеры для каждого пиксела


vertex merging - очень хороший пример path reuse, использования уже просчитаной информации еще одним путём для нахождения дополнительной информации об освещении сцены.
и пофиг, что vcm в 1.5-2 раза медленнее bpt. у многих современных рендеров и такое редкость, не говоря о качестве изображения.

Volumetric Bidirectional Path Tracing мне приглянулся больше, чем UPBP-технологии - быстрее, не уступает в качестве - более равномерное покрытие семплами изображения