delphi, opengl, opencl

нашлись мне примеры работы с openCL Delphi. очень хорошие примеры.
а еще я вспомнил про Delphi raytracer с openGL preview и там можно мышью сцену вращать.
поискал, как выбрать объект мышью на Delphi и на ресурсе OpenGL Projects http://www.sulaco.co.za/opengl.htm мне нашелся и загрузчик 3ds, загрузчик obj.
и показывает с текстурами!
потом можно будет переписать под lazarus и собирать везде под любые системы.
Delphi мне проще по созданию интерфейса и с выводом на экран проще и threads отличные.
можно будет запускать на многих гпу свой рендер

с++ и smallptGPU 1.6, smallptGPU 2.0, ocltoys использую как пример. boost и прочие выкрутасы c++ меня утомляют.

pepelac render пишу теперь на Delphi.
быстрее выпущу версию с выбором объектов, сменой свойств материалов

glsl мой близкий друг

рендер на glsl от Тошийя Хачисуки stochastic progressive photon mapper еще можно улучшать и я вижу как туда дописать материалы полноценные из obj и вращения камерой и другие алгоритмы рендеринга.

является немаловажным для меня фактором то, что на моём gpu слабеньком, который не определяет openCL, рендер работает очень быстро и есть исходники, которые можно изменять как хочется.

рендер на openCL рендерит у меня только на cpu и это очень медленно и не хватает сил дождаться результатов.

написал Тошийя достаточно ясно, но есть и замысловатые моменты, которые прояснило общение с им и моё прогресс в понимании алгоритмов рендеринга.

* также переписал расчет onb на revisedONB(http://jcgt.org/published/0006/01/01/)
* по-хулигански закомментировал normalize в шейдерах. скорость увеличилась, а качество не ухудшилось!

можно внедрить еще и другие алгоритмы рендеринга, и volume rendering!

bidirectional path tracing. особенности

• multiple importance sampling, хорошо для связывания вершин 2х путей посчитанного с учетом силы каждой вершины
• eye visibility test, помогает для записи в изображение силы лампы, если она попала в камеру
• можно делать path reuse и достаточно недорого получать больше эффектов освещения

отличный пример со всеми этими штуками - edubpt https://github.com/githole/edubpt

grids, bounding spheres и простые центероиды

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

ускорение просчета сцен без построения bvh и прочих ускоряющих структур

• этап инициализации. делается 1 раз на CPU.
  переделывается для каждого изменения сцены.
  шагов инициализации мало и они выполняются быстро-быстро
  1. для каждого bounding box находится центральная точка(ЦЕНТЕРОИД) и сохраняется
  2. для каждого ЦЕНТЕРОИДА строится массив индексов по x, y, z
  3. отсортировать 3 массива индексов по значениям x, y, z
• этап нахождения пересечения луча с объектами на GPU.
  похоже на прохождение структуры grid, но без построения структуры.
  1. при прохождении ячейки куба найти по большей разнице среди x, y, z приоритетную ось, по которой найти объекты, ЦЕНТЕРОИДы которых в пределах ячейки куба
  2. для каждой ячейки создать второй уровень "виртуальной grid" и проходить детальнее таким же образом, как описано в предыдущем шаге

поиск по сортированному массиву происходит с помощью модификации бинарного поиска и потому происходит очень быстро. мне нужно будет только знать список ЦЕНТЕРОИДОВ и сортированные 3 массива индексов.

path regularization. кривая моя реализация

вышло не очень, по крайней мере, в связке с path tracing.
лучше новые вершины на лампах запоминать и потом просчитывать bidirectional path tracing.
очень хороший bidirectional path tracer, запоминающий только position, normal, pdf и маты - в примерах к nanort.
надо как можно скорее реализовать bidirectional path tracer

path regularization 1-256 samples per pixel

https://github.com/tigrazone/ptreg

path regularization и mvnee. читаю исходники и нахожу параллели

читаю исходники mvnee и сравниваю со своей реализацией path tracer и path regularization и нахожу параллели в том, как изменяют исходники, чтобы добиться ускорений.
в mvnee тоже есть "ох и мне бы так" и читаю pdf по path regularization и, о чудо! там отлично находятся фразы next event и пишут дословно "сделали мы его офигенно и директ считаем, но продуманно, с молификацией". мне этот блок напомнил старые-престарые исходники обычных ray tracers, когда просчитывается вклад каждого источника света - последовательно, не вразброс, как во многих path tracer/photon mapper/mlt и остальные методы, некоторые даже придумывают, как бы выбрать лампы, для которых просчитывать вес силы воздействия и которые СЛУЧАЙНО выбирать из построенной таблицы. можно будет проверить потом и этот волшебный метод выбора ламп

todo новенькое

• воплотить идеи по работе без bvh с массой объектов на основе "grids без grids"
• manifoldis next event estimation
• multiple vertices next event estimation для volume rendering
• воплотить и проверить skeleton bpt
• связать рендер и студию
• добавить в студию загрузчик fbx
• vcm

и всё это на основе gpusppm/glslppm
P.S. за основу взял openCL-рендер на основе ocltoys

full spectrum improvements

расширил максимально рендеринг спектра по длинам волн.
в имеющихся у меня в наличии исходниках рендерились диапазоны
380..780нм, зачастую из этого диапазона текущая длина волны выбирается случайно, что даёт много шума.
так как gpu-рендер очень быстрый даже на моём ati radeon hd 2600xt , я решил просчитывать диапазон 360..830нм, который увидел в одном дотошном и оттого физически точном рендере. там также предлагалась идея просчитать все длины волн с шагом 5нм, что даёт 95 длин волн.
я сначала считаю 95 длин волн последовательно(у меня все 95 посчитались за 2-3 секунды, перелившись всеми цветами радуги), затем случайно выбирается длина волны из диапазона. к этому хитрому алгоритму я дописал случайный выбор, но не менее 10% чтоб просчитывалось, выбирая длину волны из набора 95. остальные 90% - выбираются случайно
на тесте видно, что эта стратегия тщательнее просчитывает дисперсию и прочие спектральные эффекты
1й скриншот - диапазон 380..780нм случайно
2й - диапазон 360..830нм, мой алгоритм

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