progressive photon mapping: progressive approach vs smallvcm/smallupbp

сравнивал исходные тексты tatsy_pppm и meta-inf/raytr с smallupbp и обнаружил, что в последнем реализовано более продумано, поэтому ничего в этом месте менять не стану.

попробую теперь реализовать в smallUPBP Skeleton based Vertex Connection Resampling for Bidirectional Path Tracing вместо реализованного

TODO. probabilistic progressive photon mapping + photon planes, etc.........

probabilistic progressive photon mapping отлично и наглядно реализован в tatsy-pppm https://github.com/tatsy/tatsy-pppm
photon planes - более продвинутая, чем photon beams, технология рендеринга объемов. реализована в tungsten renderer https://github.com/tunabrain/tungsten/commit/a3233951d948cda1141f4aa305982feae70d427d
а потом

• реализовать mcmcups в probabilistic progressive photon mapping, который выбрать основным
• реализовать  Skeleton based Vertex Connection Resampling for Bidirectional Path Tracing https://github.com/Celeborn2BeAlive/pg2015-code вместо простого bidirectional path tracer
• всё собрать воедино и перенести в glslppm-based рендер

glsl sppm github

выложил свои ускорения и оптимизации glslppm на github https://github.com/tigrazone/glslppm.
приятно было увидеть, что уже делают форки

glsl sppm

#glsl #3d #render #sppm #gpu #demo
славься, великий Тошийя Хачисука!
изобретатель алгоритма stochastic progressive photon mapping участвовал в Tokyo Demo Fest в 2015 и, что немаловажно, выложил исходные тексты.
рендер работает на glsl, а еще
* строит bvh на cpu и находит пересечения на gpu
* читает obj
ясное дело, адаптировать надо будет, но я СМОГ ЕГО СОБРАТЬ и могу менять как угодно. на толстых файлах аж трещит и падает, ничего не показав, но это я исправлю

glsl. читая исходники gpusppm2

gpusppm2 был выпущен в конце 2009 - начале 2010 года.
я его себе тогда сохранил, но изучить не хватало ума и понимания связи path tracing, bidirectional path tracing и photon mapping, не говоря про новомодные ныне progressive photon mapping, multiplexed metropolis light transport и его модификации, vertex connection and merging.
вчера прочёл вдумчиво исходники великого ТОШИЯ ХАЧИСУКА(Toshiya Hachisuka), затем на еще одной его странице - со ссылками на исходники и pdf нашёл описание parthenon render выпуска 2002 года, который я запускал, но не понимал ничего - ни какой метод используется, ни как работает вообще. запускал, удивлялся и не понимал.
также там есть описание stochastic progressive photon mapping с построением bvh на cpu и поиск пересечений на gpu, загрузка моделей из obj файлов. с исходными текстами и pdf с развёрнутым описанием.
Тошия использовал эти исходники на Tokyo Demo Fest 2015. программа идёт со свободной лицензией, при условии что упомяну Тошия как автора и используй как вздумается.

выводы от чтения исходников и оптимизаций

• замена деления умножением очень нравится gpu и здорово ускоряет расчёты
• замена умножения на 2 простым сложением - ускоряет
• вынос расчета констант из цикла дело благое и обязательное
• использование констант вместо расчетов это ваще силища
• расписывать детально расчет onb было полезно для cpu-версии рендеров, для gpu рендера всё же быстрее встроенные cross, normalize, количество которых я постарался уменьшить

наглядное сравнение оригинальной и моей, оптимизированной версии gpusppm2

было

стало

возросла скорость!!!
13%

openCL. памятка себе

на openCL целесообразно писать рендер даже по той причине, что можно один и тот же код запускать и на gpu и на cpu

nanosg улучшил, tinyobjloader выйдет с моими новшествами

для nanosg исправил 2 неудобства и ощибки

1. не читался obj без материалов или если нету файла материалов.
   теперь читается
2. при загрузке объектов с текстурами-изображениями nanosg честно грузил с нуля каждый файл.
   я сделал кэширование. каждый файл читается теперь 1 раз, сам obj загружается из-за этого быстрее и памяти намного меньше тратится
   
   было
   
   стало
   

еще хочу сделать Frustrum Culling, чтоб выводить только попадающие в камеру треугольники - для ускорения отображения превью моделей.
я лентяй и поискал реализацию в гугле, но единственно внятное нашел - "попадают ли кубы в frustrum?"
можно адаптировать, сформировав такие кубы по минимумам-максимумам вершин треугольника

tinyobjloader я начинил скоростью и некоторыми перспективными алгоритмами. скоро выйдет в мир 

приёмчики из realtime raytracing еще сгодятся и в realtime gpu path tracer

читал свой твиттер, в который прилетает много инфы по новинкам в программировании global illumination и там один человек в коментах к реализации своего трейсера пишет, First Bounce Caching это очень хорошо!

мне вспомнилась статья от lycium, которая вышла в августе 2001.
я сохранил страницу из русского издания
http://moo.ho.ua/lyrtrt.htm

можно легко использовать first hit optimisation, shadow cache, запоминать последний ударенный лучом объект. часто он тот же самый для соседних пикселов(First Bounce Caching)

цитаты оттуда

Теневые буферы

Если вы трассируете экран горизонтальными полосами слева направо, сверху вниз (организация большинства фрейм-буферов), и необходимо выполнить проверку теней для каждого пересечения, вы заметите, что если одна точка затенена, то почти гарантировано, что в тени будет и следующая. Так что для выполнения последовательной проверки на затенение для каждого объекта (согласно закону Мерфи, объект, преграждающий свет, будет последним в списке :) храните указатель на последний преграждающий свет объект. 

Оптимизация в первом приближении

Если любая из величин, которые вы рассчитываете в течение всего хода рендеринга зависит от источника луча и некоторых других величин, которые остаются постоянными для каждого кадра (радиус сферы, позиции объектов и т.д.), вы можете заранее просчитать эти значения и сохранить их в защищенных (private) полях данных структуры объекта, а потом просто использовать их, как только вам потребуется просчет для первичных лучей (лучи исходящие из камеры или глаза). Данный метод работает только для первичных лучей, так как отраженные или преломленные лучи, очевидно, не зависят от позиции камеры. Это означает необходимость написания специализированной процедуры определения пересечения для первичных лучей (или как вы узнаете позже, лучей с фиксированным источником).

Это абсолютно необходимая вещь для любого realtime-трассировщика, так как первичные лучи составляют большую часть (относительно, в сравнении с "нормальной" трассировкой лучей) общего числа выпущенных лучей, так как полнота и сложность сцены в нашем случае намного ниже.

Оптимизация проверки на затенение

Проверки на затенение являются очень прожорливыми, когда вы имеете множество объектов в сцене (n объектов - n проверок на затенение на ОДНО ПЕРЕСЕЧЕНИЕ). Но так как все эти теневые лучи исходят из фиксированного источника (точки пересечения), вы можете заранее сосчитать некоторые значения как это было описано выше. Это должно сохранить вам гигантское количество времени.

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

годные расширения для path tracer

• mvnee - Multiple Vertex Next Event Estimation
  https://github.com/pasiwe/MVNEE-Paper
  
• mnee - manifold next event estimation
  https://github.com/lighttransport/nanogi
  

потом расширить можно с учетом этих методов до bidirectional path tracer
и сразу на GPU

ocltoys. sss и fog scenes

Дописать по алгоритму MVNEE, адаптировать к bidirectional path tracing, mmlt,
bvh из tinsel render, другие объекты - не только сферы

NANOSG. my todo

• загружать также файлы без материалов или с отсутствующими текстурами/файлом материала
  ГОТОВО 6 ДЕК 17
• в opengl просмотре сцены делать frustrum culling для ускорения отображения больших сцен, может какой-то bvh
• пробел можно использовать не так, как сейчас - вернуть камеру в позицию дефолтную, а вместо Tab - zoom. Tab как-то противоестественно использовать с мышью
• сделать texture cache, чтоб не грузить одну и ту же картинку кучу раз, расходуя при загрузке время и сжирая память
  ГОТОВО 6 ДЕК 17

NANOSG. сцены rungholt и house

NANOSG

#3d #render #interface #nanort #obj_loader
NANOSG - просмотрщик и студия для редактирования загруженых obj-файлов. всё сделано максимально просто с использованием библиотек nanort, imgui, tinyobjloader, stb_image.
вот таким полуфабрикатом можно пользоваться!
в окошке есть render. рендерит пересек ли луч что и насколько далеко(даже не ray tracer, а ray caster, если вы понимаете о чем я), а также нормали и еще несколько режимов.
понацеплю туда своего. будет как FIRE в maxwell render.
nanosg умеет вращать, увеличивать-уменьшать и перемещать объекты. также на скриншоте видно, что есть список всех объектов загруженной сцены.
написал автор nanort

go gpu

изучил несколько исходников с path tracer на opengl glsl шейдерах. заработали очень немногие. полноценно работающего я не нашел.
из openCL - path tracer вызывает интерес smallptGPU 1.6 и построенный на его основе ocltoys - volumetric path tracer

так как я основываю свой рендер на nanosg, мне нужно соединить запуск openCL path tracer с текущей сценой и выводов результата в окно

back to bones. akari

достал запылившийся akari.
ясное дело, qbvh оттуда спокойно можно отложить на склад истории и воплотить интеграцию с модным nanort.
потом подружу его c imgui, tinyobjloader, bidir_path_tracer из набора nanort/examples, значительно мною переработанным(разделение на модули, упрощение арифметики, оптимизация кода, magicSampling, сохранение в кучу форматов изображений).
научил akari аккуратненько складывать результаты работы в отдельную папку.
хороший akari. умеет много всего.
и так милы сердцу комментарии на чистейшем японском языке
// 次のサンプルマップを計算
puts("calculate variance_map");
или
// importance_mapをぼかす

пока вот и все новости

новая реализация MLT

моя первая книга по рейтрейсингу

первой моей книгой по рейтрейсингу была книга Борескова и Шикина "Компьютерная графика. Динамика, реалистические изображения", выпущенная в 1996 году.


я шёл по переходу в киеве и тут она! я зачитался и офигел. не встречал нигде более подробного описания рейтрейсера в примерах.
купить я её не успел. потом появилась более урезаная версия этой книги, но там очень многого не было. я её купил. но первую книгу читал и конспектировал в библиотеке КПИ.
на основе описаного в книге рендера некто berkus выложил grayzer

ох как приятна реализация текстур и кирпичей процедурных и мрамора и всякого такого с помощью простого obj->findTexture(p, txt);

Embree renderer. восстановлю из пепла

в 2013 году Intel выпустила Embree Renderer.
во многом он устарел уже. нет поддержки формата hdr, в obj не поддерживается эмиссия.
пишет в стандартные растровые файлы в основном с помощью image magick. сейчас в ходу универсальный stb_image_write.h
читает только obj, описание сцены хранит в xml и своём формате ecs.
path tracer с множеством материалов, который считает очень даже неплохо.
под новый Embree я его не переделывал и не собирал

изображение можно нажать, чтоб увидеть большое

P.S.

воплотил в рендер мой быстрый превью, в свойства материала добавил Kt/Tf - коэффициент трансмиссии и Ke - коэффициент эмиссии.
поставил сцену из obj-файла на загрузку. пишет, что загружает материалы и присваивает.
результат - всё белым залито и некоторых обьектов вообще не видно. перекрашивал окружающий цвет на красный - не видать всё равно.

как не крути, но tinsel пока лучший.
tinsel пока присваивает всей загруженной модели один материал. научить его для каждого треугольника назначать свой материал из obj/mtl и соответственно, поддерживать материал с такими свойствами.

в Embree Renderer интересна идея со списком brdf.
в nox render свои слоёные материалы

tinsel render my favorite

tinsel render очень мне нравится тем, что можно не только из заданной камеры создавать изображение, но и вертеть камеру мышью и клавиатурой как вздумается.
можно увидеть сцену с неожиданной стороны
сцена с моделью ajax содержит также сферу-осветитель и плоскость, на которой размещена модель.
плоскость и сфера - параметрические, плоскость - по-настоящему бесконечная


смущает еще много чего:
* рендер единственный - path tracer. воплощу upbp с учетом эмиссии на основе исходника bidirectional path tracer от tatsy из комплекта nanort/examples
* bvh быстр, но nanort быстрее. прицеплю nanort. на днях как раз разбирался с обновлением nanort в интеграции с демо-рендером
* недописанный disney материал. допишу на основе кода из EDXRay

4 миллиона треугольников и tinsel render

во время работы над рендером собрал в одну сцену несколько моделей для сильной нагрузки
вышло забавно
◐

EDXRay. update

как оказалось, падение рендера вызывали sse-инструкции от самодельного bvh, который всюду по рендеру кроме AreaLight заменен на Embree.
заменю и в AreaLight.
позже надо будет попробовать вариант с заменой на nanort

ошибки поиска пересечения

такое встречалось и в рендерах smallUPBP(старый embree), и NanoRay, и akari с самодельными bvh.
в oreoren посмотрел построение самодельного bvh и взял оттуда константу
#ifdef USE_FLOAT
const float EPSILON = 4e-3f;
#else
const double EPSILON = 2e-4;
#endif
и подставил её в akari
результат стал лучше, но ошибки не ушли.
в верхнем правом углу - результат bvh nanort, у которого всё в порядке с поиском пересечений.
буду использовать его

обрадовали tinsel, nanoRay, embree path tracer

автор tinsel render создал и nanoRay.
поддерживает:
* MatteMaterial(Lambert), PlasticMaterial(Blinn)
* объекты Sphere, Mesh, Plane, Disc, Cone, DistanceField(можно задавать функцию, но что это такое - я не понял; нужно проверить на примере)
* текстуры MixTexture, PerlinTexture, CheckerboardTexture
* небо, солнце. но мне однозначно не нравится воплощенная Perez's model for sky luminance
* так же, как и tinsel render, загружает сцены из obj и ply

материалы хорошие есть еще в embree path tracer. до сих пор я поражон примером с короной. я его обязательно отрендерю своим рендером.
изучение кода EDXRay и эксперименты с материалами здорово меня взбодрило на развитие рендера!

в tinsel есть, но в NanoRay нет:
* dinsey brdf, хоть и неполная реализация. лучше брать из EDXRay
* g_options.filter = Filter(eFilterGaussian, 1.1f, 1.0f);, остальные фильтры можно взять из EDXRay
* nlm denoise, сравнить с другими более новыми денойзерами

EDXRay. прощание

намаявшись с дописыванием полной версии smallVCM с сохранением light paths, решил проверить, насколько хорошо можно отрендерить subsurface с помощью path tarcer, который единственный умеет волюметрику.
рендер падает. APPCRASH.

во время работы с исходным кодом EDXRay много раз удивлялся, зачем автор сделал самодельные и диковатые воплощения стандартных Array, Map и прочих.
возможно, для энтузиастов и студентов это нормально - создать самостоятельно.

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

а еще! КОМПИЛИРОВАЛИСЬ SmallUPBP и EDXRay только Visual Studio и соответственно, только под Windows.
захотел скомпилировать и поэкспериментировать с некоторыми идеями на ноуте и был ПОРАЖОН - Visual Studio инсталлятор 22гб. у меня и флешки такой нет ;-)
к тому же, Visual Studio генерирует далеко не самый быстрый КОД!

minGW можно запускать и с флешки. генерирует программы намного быстрее, чем Visual Studio Compiler и Intel compiler. и компилятор обновляется до самых современных версий.
код, который компилируется в minGW обычно потом отлично собирается в linux

будет теперь

на основе ImGui внешний вид рендера. под minGW отлично собрался демо-пример для opengl2.
из akari1 многое возьму.
там очень много полезного воплощено:
* path tracer
* HDRI light с importance sampling
* qbvh sse. быстрое
* aperture image
* DOF
* adaptive antialiasing
* tone_curve
* vignetting
* depth-based blur

VCM воплощу, пользуясь своими наработками и собранным из последних commit людей, сделавших fork оригинального smallVCM.
NanoRay - очень привлекателен. буду и из него брать наработки

ближайшие планы

• Bidirectional path tracer. сохранять light paths - только для path reuse
• Bidirectional path tracer. сделать path reuse
• Вместо vcm сразу воплощать UPBP - vcm extended c volumetrics(дым, туман, абсорбция, разброс - scattering)

хороший интерфейс на основе ImGui

EDXRay. создание arealight из эмиссивных треугольников

после загрузки файла с моделью, пройтись по всем треугольникам модели и, если у материала установлена эмиссия, то создать AreaLight с этим треугольником.
для всех треугольников строится структура BVH2 и по ней проход и пересечения с треугольником. не будет большого вреда, если это будет создаваться для одного треугольника. можно будет сделать отдельную обработку этого случая и взять пересечение с треугольником из akari qbvh, если не заработает решение

sun & sky в EDXRay и в документации по Mitsuba render

заметки о рендерах pbrt и EDXRay

• EDXRay: Multiplexed MLT во многом повторяет mlt.cpp из pbrt
• pbrt: PLY поддерживается с помощью rply
• pbrt: New samplers: a much-improved Halton sampler, and an all-new Sobol’ sampler are both quite effective for path tracing and bidirectional path tracing
  EDXRay: воплощен только sobol
• pbrt: текстуры, в том числе процедурные и ptex(ptex.cpp)

EDXRay. sss и disney brdf subsufrace. path tracing vs bidirectional path tracing

EDXRay. текстуры

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

enum class TextureFilter
{
  Nearest = 0,
  Linear = 1,
  TriLinear = 2,
  Anisotropic4x = 3,
  Anisotropic8x = 4,
  Anisotropic16x = 5
 };

enum class TextureWrapMode
 {
  Clamp, Repeat, Mirror
 };

EDXRay. MultiplexedMLT, my MultiplexedMLT, Bidirectional path tracing

EDXRay. MultiplexedMLT. эксперименты

обнаружил, что дополнительный просчет Direct Illumination на этапе предрасчета и раз в 3 прохода дополнительный подсчет Direct Illumination и учёт его для metropolis sampling очень благотворно сказывается и на specular, и на diffuse составляющих изображения.
вот такой вышел результат после экспериментов:

вследствии моих экспериментов Environment map темнее, зато проработанней материалы на обьектах. возможно, нужно иначе делить изображение с учетом сработавших семплов.
следующее в развитии MultiplexedMLT - семплинг лучей камеры по порядку, а не по metropolis, как сейчас.

для сравнения:
до моих экспериментов, оригинальный MultiplexedMLT из EDXRay


и он же за время, как у моего варианта

EDXRay. пре-альфа

единственно необходимый шаг для выпуска альфа-версии EDXRay - загрузка файлов.
можно из командной строки, можно кнопкой
следующий шаг - сохранение сцены/проекта - изменений, сделанных в рендере-студии(передвижение камеры, обьектов, смена материалов, смена параметров hdri-освещения, неба, других параметров)

EDXRay to pepelac render TODO добавка

в догонку к EDXRay to pepelac render TODO

• openEXR - file read, tinyexr - file save
• сохранение картинки во всех доступных форматах изображения
• tone mapping
• DebugImages - они же light passes, нужно будет для MultiLight, для сохранения нормалей, глубин, прозрачности и т.д.

EDXRay. материалы Rough Conductor и Rough Dielectric

EDXRay. материалы. удивительные открытия в коде

как оказалось, Glass материал поддерживает Fresnel.
как оказалось при рассмотрении кода с учетом Френеля из других рендеров и обьяснения к рендеру Hydra Render

Fresnel:  (френелевские отражения)

Опция Fresnel используется для симуляции материалов c покрытиями и работает полностью аналогично френелю в таких рендерах как VRay, Corona и mental.

Заметка

Френель в редакторе материалов таких рендеров, как VRay, Corona, Mental и Hydra - это удобный способ симуляции двуслойных материалов. Изначально формулы Френеля были разработаны для стекла. При попадании луча света на стекло, часть энергии отражается, а часть проходит внутрь и преломляется. То, какая часть света проходит внутрь, а какая отражается, зависит от угла падения и определяется формулами Френеля. Однако позже формулы Френеля начали использовать для симуляции материала, состоящего из 2 слоёв (как минимум). Первый слой - стекловидная плёнка, которая и создаёт эффект Френеля. Второй слой, как правило, диффузный. Интересно отметить, что используемые в современных рендерах формулы Френеля - это формулы для диэлектриков, то есть стёкол. Для металлов, то есть проводников, существуют другие формулы точно описывающие их поведение. Однако, так совпало, что при задании больших значений IOR в формуле френеля для диэлектриков, они начинают вести себя похожим образом на формулы Френеля и для проводников. Задание IOR = 50 или 20 далеко от физического смысла, но даёт похожий результат на формулы Френеля для проводников, то есть “случайно получается” металл. В Hydra Renderer мы не стали нарушать эту старую добрую традицию, и поддержали ставший “де факто” трюк с большими значениями fresnel IOR.

Моделирование материала с покрытием с использования формул френеля. Первый слой представляет собой полностью прозрачное стекло (или любой другой диэлектрик) с определённым IOR френеля. При увеличении fresnel IOR данный двухслойный материал становится всё более металлическим.

Диффузный цвет шара чёрный. Вверху френелевские отражения включены. Внизу выключены, что делает маетриал похожим на зеркало.

Fresnel IOR:  (френелевские отражения)

Френелевские отражения с различными значениями Fresnel IOR. Диффузный цвет шара - жёлтый, цвет отражений - также желтый.

EDXRay. Rough Dielectric material

выглядит, будто из оптоволокна или стекла

EDXRay. волшебная сила Ctrl

в openGL виде нажать Ctrl и мышкой тыцнуть обьект - он станет выделен и покажется редактор материалов!
типа материала и свойства можно менять

EDXRay to pepelac render TODO

todo на ближайшее время по рендеру:

• кнопка загрузки объектов, сцен, проектов(сцена+рендеренное)
• сохранение сцен, проектов
• средняя кнопка мыши зажатая и движ мыши с текущим объектом - переместить объект
• вращение средней кнопкой мыши - увеличение/уменьшение
• доделать обработку клавиатуры
• все свойства материала из obj/mtl - ADVANCED mat
• все мои антиалиазинги
• vcm
• все мои оптимизации(vm_hybridance, path_reuse)
• удаление выделенных объектов
• interactive preview(magic sampling)

будет как в keyshot, но по-новому и без progressive photon mapping

EDXRay. чтение материалов из obj/mtl

не читались и не учитывались параметры материла:
Ke - emissive color(r, g, b)
Ni - IOR материала
Ns - phong exponent
Kt - transmissive color.

сейчас все эти параметры запоминаются в свойствах материала.
Ni, Kt учитываются при рендеринге:

пока еще сложно даются рендеру материалы, у которых поровну Specular и Diffuse или Specular и Transmissive
ошибка на картинке -
статуе присвоен материал с
Kd 1.000000 0.800000 0.800000
Ks 0.2 0.2 0.2
но используется только зеркальная(Ks - specular) составляющая.

стеклянная сфера тоже передана не совсем верно
newmtl Reflective
Ns 96.078431
Ka 0.000000 0.000000 0.000000
Kd 0.0 0.0 0.0
Ks 0.9 0.9 1.0
Kt 0.9 0.9 1.0
Ni 1.5
d 1.000000
illum 2
а в рендере использовано только преломление(Kt - Transmission)

EDXRay. hairball.obj и hdri освещение

нашёлся мне EDXRay - bidirectional path tracer, path tracer, multiplexed mlt с поддержкой disney brdf(по этой фразе его и нашёл), загружает obj, можно загрузить и повращать hdr.

после чтения исходников удивительной находкой оказалось, что используется код smallVCM, на основе которого я писал свой рендер.
в рендере также есть:

• фильтры изображения MitchellNetravali, gaussian, box(без фильтрации)
• adaptive sampling - галочка есть, а самого адаптив семплинга в коде нет
• загрузка environment map(картинка для hdri освещения) интерактивно, в самой программе - в форматах JPEG, PNG, TGA, PSD, GIF, BMP, HDR, PIC, PNM, PPM, PGM. допишу еще pfm
• сохраняет только в самописный BMP
• RandomSampler, SobolSampler, Metropolis(фактически его нет, вызывается RandomSampler, сделано наверное для Multiplexed MLT - metropolis там единственный семплер)
• StochasticPPM - не реализован - вызывается BidirPathTracingIntegrator😹

• Camera Models

  • Thin Lens Model
  • Fisheye Camera
  • Realistic Camera Parameters
  • Arbitrarily Shaped Bokeh
  • Vignette and Cateye effect

• Light Source

  • Point Light
  • Directional Light
  • Polygonal Area Light
  • Procedural Sky Light with Hosek Model
  • HDR Probe

• Integrators

  • Volumetric Path Tracing - как его вызвать, я не понял. надо читать исходник Media/Homogeneous.cpp - похоже используется в phaseFunction HenyeyGreenstein
  • Bidirectional Path Tracing with Multiple Importance Sampling
  • Multiplexed Metroplis Light Transport

• Materials

  • Lambertion Diffuse
  • Smooth Conductor
  • Smooth Dielectric
  • Rough Conductor
  • Rough Dielectric
  • Disney BRDF
    • Layered Material with Up to 2 Specular Coats
    • Cloth
  • Subsurface Scattering
    • BSSRDF based on Normalized Diffusion
    • Participating Media
  • Normal Map
  • Roughness Map
  • Alpha Test

отлично сделан рендер. я автору написал "thanks for HUGE rework of smallVCM code"
я писал свои модификации к оригинальному smallVCM, но в некоторых моментах я замечал, что сложно добавлять новые штуки. остановил разработку, смотрел как бы мне сделать более универсальный каркас. и перепробовал много исходников и оказывается, что автор EDXRay уже порезал и замиксовал на новый лад исходники smallVCM. сам алгоритм vcm в рендере не реализован. я допишу🐼
также я планирую:

• загрузку obj с помощью tinyobjloader
• nanort для пересечения с треугольниками, сферами, curves, cones. сейчас поддерживается Embree для пересечения с треугольниками. сферы превращаются в треугольники
• загрузка сцен в форматах ini, xml, rib, всех форматах, поддерживаемых assimp
• реализовать материалы из obj, mtl, поддержка disney brdf из mtl

tinsel renderer and my speedup modifications

tinsel renderer and my speedup modifications:

• cpu only version. gpu version hardcoded off
• openMP is added. on my 2-core cpu speedup to 160%(before openMP 4.7s per frame for ajax scene, after 2.9s) - more cores = faster
• little bit speedup for disneyBRDF pdf calculation

TODO:
- nanoRT scene accelelerator
- tinyobjloader with my speedups
- lodePNG for save png
- openCL version

Features

• Unbiased uni-directional path tracer
• Disney's principled BRDF with importance sampling of diffuse and specular lobes
• CPU or GPU tracing and shading with a persistent CUDA threads model
• Interactive OpenGL progressive mode
• Explicit area light sampling
• Affine and deformable motion blur
• Gaussian reconstruction filter
• Instanced triangle mesh primitives with affine transformations
• AABB tree with SAH and splitting
• Simple scene description format
• Windows / macOS / Linux support
  
  P.S. зачеркнутое - заявленное, но в коде нет этого

available on github https://github.com/tigrazone/tinsel

embree и openexr. пустые страхи

почему-то было у меня отторжение openEXR и Embree, особенно напрягался про то, что фиг соберёшь под linux и macOSx, но, почитав руководства по установке, становится понятно, что как раз windows-версия сложнее для установки и обновления под Visual Studio. под minGW можно наверное собрать из исходников openEXR и Embree.
SmallUPBP очень уж неплохо работает.
tinyexr можно оставить для записи файлов. неплохо сохраняет и файлы получаются меньше, чем сохраненные openEXR. буду его использовать чтоб не искать в настройках openEXR. может и openEXR у меня старый, только толстые файлы сохраняет.
может я и лось и что-то недонастроил что с tinyexr, но но при загрузке exr для IBL - не видно результата, будто б exr чёрный.

pepelac. ibl from akari1

после попыток прицепить IBL от upbp и неясного падения проги от этого, решил брать независимый исходник от akari1.
к тому ж там есть importance sampled ibl для direct paths

P.S. причиной падения оказался заход за границу массива. ох уж эти студенты с предустановленными значениями.
заработало ibl-освещение. только новая напасть. освещение будто б черным светом. tinyexr шалит... или я чота сделал не так

density control for photon maps

документ Density control for photon maps опубликован в 2000 году
с 2001 года реализован в RenderPark
подобное предлагали в 2014 году Jiří Vorba, Ondřej Karlík, Martin Šik, Tobias Ritschel, Jaroslav Křivánek в работе On-line Learning of Parametric Mixture Models for Light Transport Simulation
да и в mental ray были importons
и я сделаю
если кратко - выпускаются сначала фотоны для оценки, куда их надо больше - небольшое количество и потом - по построенной карте - более грамотно запускаются фотоны для полноценного просчета

akari2 vs gemspt

gemspt подкупает тем, что поддерживает раздельно материалы diffuse, specular, glass и они содержат одинаковые методы, это упрощает и унифицирует подход к материалам.
в akari2 только 2 материала - diffuse, specular/glossy.
была идея перенести в gemspt хорошие решения из akari2, но я, просмотрев исходные тексты nanort/examples/path_tracer/, понял что лучше добавить более стандартную работу с материалами, разделив на компоненты

https://github.com/githole/gemspt
https://github.com/tigrazone/akari2

github.com/githole/

очень благодарен сетевому создателю многих рендров github.com/githole
с его подачи мне доступны рендеры:
akari3 https://github.com/githole/akari3
akari2 https://github.com/githole/akari2
akari https://github.com/githole/akari
Kelemen style MLT https://github.com/githole/simple-mlt
path tracer https://github.com/githole/cpuex-pt
edubpt https://github.com/githole/edubpt
simple-bidirectional-pathtracer https://github.com/githole/simple-bidirectional-pathtracer

GEMSPT https://github.com/githole/gemspt
интересен тем, что четко прописаны Diffuse, Specular, Glass материалы.
после внедрения obj достаточно просто переключать между этими 3мя материалами.
хорошо расширяется

akari2 optimised path tracer - port to minGW gcc and Linux gcc

сделал оптимизации оригинальному akari2 https://github.com/githole/akari2,
сделал port для gcc и выложил на github https://github.com/tigrazone/akari2

akari2 - path tracer с HDRI освещением и загрузкой сцен из obj, mtl.
mtl тут нестандартный, сделаю стандартным + расширения mtl



по сравнению с akari, тут нет, но допишу:

• importance sampling for IBL
• adaptive antialiasing
• DOF
• vigneting
• aperture
• direct lighting

есть большой плюс - path tracing воплощен так, что легко можно переделать в bidirectional path tracer
в nanort/examples/bidir_path_tracer/ воплощен еще emission и больше материалов поддерживается, чем в akari2.
большое спасибо авторам указанных рендеров!!!!!!!!!!!!!!!!

smallpt pascal lazarus

Очень мало примеров современного и достойного global illumination на pascal в модификации Delphi и Lazarus.
Есть очень неплохой пример на Turbo Pascal 3/Lazarus, написан Dirk de la Hunt http://www.iwasdeportedandalligotwasthislousydomain.co.uk/static.php?page=smallpt_tp

С моими оптимизациями path tracer ускорился на 15%.

Оригинальная версия by Dirk de la Hunt просчитала картинку 1024x768 на 16 spp 4-мя потоками за 68 секунд.
Моя версия - 59 с.

Если выставить в настройках компилятора платформу x86_64, это даст еще прирост скорости!

В сравнении с C++ версией скомпилированной MinGW gcc - 48с - на 15% быстрее моей версии на Lazarus, но в сравнении с скомпилированным Visual Studio Compiler(69c) или Intel C++ compiler результат даже хуже чем Lazarus или похожий.

В настройках всех компиляторов я подбирал самые оптимальные настройки, которые давали скоростной код.

скачать smallpt pascal lazarus path tracer с github

Огромным плюсом я считаю библиотеку FreeImage, которая работает с множеством графических файлов, в том числе поддерживает новейшие изменения в jpeg и работает с HDR, EXR и есть подвязка под Lazarus.

Поэтому на Lazarus буду писать и bidirectional path tracer, и mlt, и vcm!

upbp: path reuse

идея:
соединять eye path не с 1 light path, а с несколькими


eye path соединяется c 1 light path
44 секунды на 1 sample per pixel


eye path соединяется c 5 light path
66 секунд на 1 sample per pixel

как видно из изображений, path reuse помогает найти больше specular path - там где каустика и отражения

для визуального сравнения смотрите страницу

ini как формат сохранения сцены

ini выбираю потому что он проще для редактирования и понимания, чем xml и неструктурированный txt или текстовые описания в своих куче форматов.
для чтения ini нашел библиотеку inih, затем немного её оптимизировал и выложил
идею использовать ini для сохранения сцены подсмотрел у автора рендера oreoren

akarized

akari хорош тем, что там есть свой qbvh очень шустрый - и строит быстро и пересечения находит и не надо подключать большие либы типа embree или nanort.
в akari также есть:
* adaptive IBL
* adaptive antialiasing
* DOF
* vigneting
* aperture
* path tracing with explicit direct lighting
* сохранение hdr, bmp
* чтение hdr

добавил к вышеперечисленному небольшие оптимизации вроде вычисления sincos одной командой, а не 2мя функциями sin и cos, разложение вычисления ONB...

akari2 и оригинальная сцена - 2 миллиона треугольников

картинка кликабельна! | picture is clickable!
HDRI освещение, path tracing, normal mapping
10 минут на amd athlon dual core 4200+, 14 секунд на картинку 1920x1080, 40 проходов

akari2 и hairball.obj - много треугольников!

akari2 отличается от akari наличием obj loader, normal mapping из файла
не очень много я почерпну из него
загрузил hairball.obj на 2.88 миллионов треугольников



картинка кликабельна! | picture is clickable!
HDRI освещение, path tracing, normal mapping
30 минут на amd athlon dual core 4200+, 11 секунд на картинку 1920x1080, 152 прохода

можно скачать архив с akari2 + haiball.obj для windows