mmlt-s in action

отличия от upbp

• importance sampling lights
• 3-pass preview
• adaptive antialiasing
• mmlt
• чтение и запись большего количества форматов сцен и изображений
  29 mar 17
  
  • png - lodepng
  • hdr, tga, bmp - stb_image_write
• AquireImage - autoexposure из WinOsi
  29 mar 17
• path regularization

smallmmlt в elementary os

elementary os

установил elementary os без проблем.
программа скомпилировалась без ошибок.
размер исполняемого файла 1,3 мб.
запустился без проблем и создал файлы с рендереным.
я доволен, что пепелац легко собирается и на linux

deepin linux

установил сиё чудо просто и без проблем. интернет, музыка и видео - из коробки.
скопировал свои исходники и make... не знает что такое g++, gcc говорит cc1 чего-то там не хватает.
synaptic, gcc, lazarus не известны магазину приложений тамошнему.
установил synaptic через консоль и всё остальное.
корявые шрифты и много мороки.
поставлю Elementary os. с ним не было проблем

как сделать компактные исполняемые файлы в c++, lazarus, delphi

C++, компилятор MinGW

• лучше printf, чем std::cout
• лучше массивы, выделяемые с помощью malloc, чем std::vector
• char * строки лучше std::string
• c-аналоги std:: - функций и классов лучше

в моём exe на 307kb также есть работа с std::vector и push_back и сопутствующее

Free Pascal/Delphi, компилятор Lazarus
основному оконному и runtime-набору есть чудесная замена — https://github.com/FChrisF/LLCL
c  помощью этой диво-библиотеки exe получаются 100kb
со всем функционалом!
в описании LLCL написано, что собирает программы только под Windows.

Delphi и LVCL
попробую аналогичную библиотеку LVCL для Delphi 7.
аналогичный пример занимает 58kb
буду программировать оконную часть на Delphi !!!

bathroom - upbp. спустя многие проходы

bathroom - upbp_vcm + point-to-point

bathroom - upbp vcm + point-to-point + beams

Path Space Regularization for Holistic and Robust Light Transport

Path Space Regularization for Holistic and Robust Light Transport, описание
посмотрел pdf прилагаемые к этой работе и в дополнительных материалах нашел простую реализацию этого метода на основе explicit direct light path tracing

Path tracer with Regularization 16 spp		Explicit direct light path tracing 16 spp
Path tracer with Regularization 2048 spp		Explicit direct light path tracing 2048 spp

код и примеры доступны на github https://github.com/tigrazone/ptreg
картинки кликабельные

в сравнении можно посмотреть на moo.ho.ua/ptreg/ptreg.html

volumetric vcm + point-to-point vs volumetric vcm + point-to-point + point-to-beam and beam-to-beam merging

time of renders are same

эксперименты с multiplexed metropolis light transport

bidirectional path tracing и потоки

настроил я наконец-то многопоточность.
теперь потоки друг друга не перебивают и не делают дикую мешанину из семплов

bidirectional path tracing, DOF и темнота

эти 2 сцены сложны по освещенности для рендера
посмотрим как справится с ими vertex connection and merging и path traced manifoldis next event estimate

vertex connection and merging. обьяснение и связь с bidirectional path tracing

типичный bidirectional path tracing выглядит так:
для каждого пиксела:

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

vertex connection and merging

двухпроходный: 1й проход - light tracing, сохраняет куда какой луч попал и что полезного обнаружил, 2й проход - лучи из камеры пересекаются с сохранными light-путями(как в bidirectional path tracing), а также луч находит световые эффекты, которые просчитываются по алгоритму  progressive photon mapping на основе той же сохраненной информации о вершинах из light tracing-прохода.

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

и это - не обман и не приблизительное

Spectral Rendering with POV-Ray

Spectral Rendering with POV-Ray

интересная работа по быстрому семплингу - Fast Random Sampling of Triangular Meshes

Fast Random Sampling of Triangular Meshes. M. Šik and J. Krivánek 2013

volumetric vcm + point-to-point connections + beans

photon beams, point-to-beam connections, beam-to-beam connections из оригинального SmallUPBP

собирал очередную сборку своего рендера на основе SmallUPBP b в одном из тестов обнаружил, что сломал логику и сами части рендера слишком увлекшись упрощениями.
вернулся к мастер-версии с https://github.com/PetrVevoda/smallupbp/zipball/master, собрал с единственными изменениями - отключив все sse4-инструкции.
добавлю в мастер-версию только изменения, которые гарантированно полезны - ускоряют, меньше памяти и не ломают работу рендера.
затем проверил, работают ли photon beams - 2 метода - работают!
и решил сравнить в чем между ними отличия


по времени - с photon beams картинки считались в 2-2,5 раза дольше

volumetric vcm наглядно

bidirectional path tracing эксперимент с многопоточностью

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

edubpt: 1 to 512 samples per pixel

nanort - не только минималистическая замена embree, но и хороший исходник bidirectional path tracer

NanoRT, single header only modern ray tracing kernel https://github.com/lighttransport/nanort

в примерах использования идёт bidir_path_tracer

1000 spp, max 8 bounces

возможности этого мини-рендера:

• загрузка obj-файлов с материалами - tiny_obj_loader
• обработка материалов из obj-файла.  прозрачность, источник света излучающий - из материалов
• построение и использование nanort, который ловко справляется с такими моделями - 362k треугольников
• выбор ламп для light tracing происходит не случайно, а по статистической таблице, что делает картинку точнее, меньше артефактов-ярких точек
• сохранение exr - результат работы рендера, необработанные float
• сохранение png - простой clamping tonemap и сохранение с помощью stb_image_write

я приложил руку к исходникам рендера и теперь:

• сохраняет hdr - необработанный float, stb_image_write
• сохраняет png - теперь с помощью lodepng - файл получается меньше. stb_image_write-вариант сохранения png отключил. обратил на lodepng внимание после тестов
• сохраняет bmp, tga, используя код из stb_image_write 

так начиналась моя реализация Manifoldis next event estimation

https://github.com/lighttransport/nanogi/blob/master/src/nanogi.cpp

edubpt+nanort

edubpt уважаю уже давно http://thrlite.blogspot.com/search?q=edubpt
а чтение исходников nanort наталкивает на интересные размышления
очень хорош edubpt и как testbed для методов рендеринга

bidirectional path tracing vs path tracing

bidirectional path tracing


path tracing



на создание обоих картинок ушло по 480 секунд - 8 минут

работаю над новым методом антиалиазинга - contour_map

сцена 8. 8 часов 50 минут

рендер местами далёк от совершенства...

воплотил подобие path reuse, как было описано еще в документе 2002 года

Accelerating Path Tracing by Re-Using Paths
Philippe Bekaert, Mateu Sbert, and John H. Halton. Accelerating path tracing by re-using paths. In Rendering Techniques, pages 125–134, 2002

в vertexcm.hxx из SmallVCM
написано:


                // Vertex connection: Connect to light vertices
                if(!bsdf.IsDelta() && mUseVC)
                {
                    // For VC, each light sub-path is assigned to a particular eye
                    // sub-path, as in traditional BPT. It is also possible to
                    // connect to vertices from any light path, but MIS should
                    // be revisited.
                    const Vec2i range(
                        (pathIdx == 0) ? 0 : mPathEnds[pathIdx-1],
                        mPathEnds[pathIdx]);

я же переписал этот момент так:

                // Vertex connection: Connect to light vertices
                if(!bsdf.IsDelta() && mUseVC)
                {
                    // For VC, each light sub-path is assigned to a particular eye
                    // sub-path, as in traditional BPT. It is also possible to
                    // connect to vertices from any light path, but MIS should
                    // be revisited.

pathIdx123 = pathIdx;

// *экспериментально! range - здесь вписать пробную проверку на соседние пикселы
if(pathREUSE)
{
if(screenSample.x<(FLOAT)xx && xx>0)
pathIdx123--;
else
if(screenSample.x>(FLOAT)xx && xx<resx-1)
pathIdx123++;

if(screenSample.y<(FLOAT)yy && yy>0)
pathIdx123-=resX;
else
if(screenSample.y>(FLOAT)yy && yy<resy-1)
pathIdx123+=resX;
}


                    const Vec2i range(
                        (pathIdx123 == 0) ? 0 : mPathEnds[pathIdx123-1],
                        mPathEnds[pathIdx123]);

разница - проверять очередной семпл, к какому пикселу он ближе и использовать не самого пиксела light path, а пикселов, к которым семпл ближе.

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

Metropolis Light Transport - экстремальная версия описываемой техники path reuse

вот несколько результатов для сравнения:
мой небольшой вывод - даёт уменьшение шума и больше деталей. почти без затрат

отличия между изображениями незначительные, но деталей больше в reuse-версиях и они точнее.
надо учитывать и центральный пиксел и соседний пропорционально.
SQRT((screenSample.x-xx)*(screenSample.x-xx)+(screenSample.y-yy)*(screenSample.y-yy)) - коэффициент для соседнего пиксела, (1-SQRT) - для центрального.

сравнение методов антиалиазинга

http://moo.ho.ua/aaa.html
hybrid - это из 5 итераций 3 - distib, 2 - akari

pepelac render. альфа-версия

мой рендер можно СКАЧАТЬ и запустить!

в этой версии:
* несколько заготовленных сцен
* vertex connection and merging
* hybrid adaptive sampling/antialiasing
* многопоточно и прогрессивно показывает рендеренное в окно
* а еще он умеет вот так:

для того чтобы получить рендер этой сцены, запустил bench-8.bat

СКАЧАТЬ альфа-версию pepelac render
после того, как скачаете, запустите один из bench-файлов

полный список команд рендера можно увидеть, запустив pepelac.exe -h в консоли

std::vector и openMP что-то не поделили

переписать некоторые блоки пора начисто и вместо std::vector использовать обычные массивы.
как раньше, vertices *verts = new vertices[numVertices]
да и работает стабильнее.
долой эти дурацкие std::vector!

akari aaa прийде, порядок наведе

min и max семплов - высокое значение, но разбросаное по всему изображению, в среднем даёт 10-11 семплов на пиксель.
это - чудеса антиалиазинга, основанного на размытой черно-белой версии рендеринга с низким количеством семплов.

#my_weird_rendering AGAIN!!!

#my_weird_rendering
на этот раз - ошибка в просчете стекла

FIXED

one more adaptive anti-aliasing

sunflow\src\org\sunflow\core\renderer\BucketRenderer.java
когда akari-based antialias залипает на одинаковом количестве мин и макс семплов, то я включаю антифриз - другой алгоритм антиалиазинга - AdaptiveDistributedRender. можно его дополнить алгоритмом антиалиазинга из sunflow render
или более простым, который сравнивает соседние пикселы и если резкая разница, добавляет количество семплов

HDRI освещение, Image Based Lighting, Environment mapping, UPBP, pbrt и благодарности

Сводка недоступна. Нажмите эту ссылку, чтобы открыть запись.

наследие smallvcm

так как мой рендер на основе smallvcm, то внимательно читая исходники, нахожу нелепости и упрощения.
например, цвет фона - если луч не попал ни в один обьект - почему-то голубой.
может Tomas Davidovic так определял, что дырка в обьекте или Environment map не покрытое место.
как бы там ни было, там нужен чёрный-пречёрный цвет


UPDATE. Как оказалось, тот голубой BackgroundLight освещал сцену 3.


Записал установку такого цвета BackgroundColor при создании сцены - так вернее.
ибо в конструкторе BackgroundLight цвет устанавливать не гоже.

отличие Multiplexed Metropolis Light Transport от Primary Sample Space Metropolis Light Transport

определяются pdf и с их учетом идет рендеринг

vcm + akari variance based adaptive antialias -> 2000 s

#my_weird_rendering