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

как ускорить free pascal/lazarus программу в 2 раза

в free pascal/lazarus есть удивительная опция. называется она целевая платформа.
если выбрать ту платформу, под которой будет работать программа, или достаточно выбрать x86_64 и скомпилировать, то программа заработает в 2 раза быстрее.
в исходном коде не нужно для этого ничего менять
а вот 2 скриншота, показывающие результат

small mlt на free pascal

пришла мне идея проверить скорость работы free pascal compiler по сравнению с gcc на с++.
напишу pascal-версию small mlt для проверки на скорость.
для проверки раньше использовал другие рендеры на lazarus/free pascal и включение одной опции компилятора добавило 690 кб к размеру exe и невиданую доселе скорость работы получившейся программы - всего на 20% медленнее c++ версии алгоритма.
алгоритм был реализован неаккуратно и с точностью тех тестов согласиться не могу.
поэтому напишу своё. может пригодиться впоследствии.
заодно проверю перезагрузку операторов

hash maps

оказывается, ассоциативные массивы с ключом-строкой могут быть быстрее unordered_map <std::string, int>

unordered_map <std:string, int> map1;
 
    printf("std hash func... ");
 
    clock_t t0=clock();
 
    for(i=0;i < n;i++)
        str = ltoa(i);
        map1[str]=i;
    } 

если хранить индекс, как int со значением из хэш-функции, то можно достигать до 4х-кратного повышения скорости работы

unordered_map <uint32_t, int> map3_3;
 
    printf("X31_hash_string hash func... ");
 
    clock_t t20_3=clock();
 
    for(i=0;i < n ; i++)
        str = ltoa(i);
        map3_3[X31_hash_string((char*)str.c_str())]=i;
    }

и функция расчета хэша, которую я взял из проекта khash.h, выглядит просто и работает быстро и создаёт мало коллизий:

typedef uint32_t khint_t;
 
uint32_t X31_hash_string(const char *s)
{
 
    khint_t h = *s;
    if (h) for (++s ; *s; ++s) h = (h << 5) - h + *s;
    return h;
} 

xxhash оказался не очень быстрым, хоть и качественный, почти как и другие сравниваемые алгоритмы хеширования
sz означает количество элементов
если их меньше 5000000 - количество добавляемых элементов - то коллизии-наложения и ошибки
fletcher32 оказался не очень быстрым и к тому же создаёт много коллизий. не нужен!
X31_hash_string оказалась и быстрее, и хороша - мало коллизий(0)

скачать source code of tests on c++

сначала связать, затем оптимизировать

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

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

новый todo

• сделать akari variance based с blur и т.д. adaptive antialiasing
• IBL - tinyexr, hdr чтение оптимизировать из akari
• из akari взять целиком загрузчик vvv и интеграция с qbvh
• добавить загрузку изображений
• добавить texture mapping во всех видах
• добавить assimp, допилить его по максимуму
• добавить сцены

adaptive antialiasing + 3-pass preview

воплотил обе методики и заметил, что частое использование 3х-ступенчатого метода превью создаёт мерзкую квадратную структуру на изображении. отключаю эту методику для создания превью с 2й итерации. картинка получается быстрой и точной. раньше можно было получить первое изображение на тестовой сцене через 19-25 секунд.
сейчас же первая картинка - 4 секунды

SOIL - Simple OpenGL Image Library

хорошая библиотека, ремикс stb_image.
добавлен формат tga,
есть функции для загрузки текстур и отображения их с помощью OpenGL
https://github.com/kbranigan/Simple-OpenGL-Image-Library

курс держать учусь я снова

увлёкся отвлёкся привлёкся lazarus и библиотеками чтения, отображения 3d-форматов. автор искушает еще path tracer, с хорошей связью с читалкой файлов.
не смущало сильно и то, что тормозные достаточно читалки и дописывать тьму и то, что path tracer вникнуть, переписать, довнедрить из с++ версии...

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

отложил lazarus в сторону. ибо можно воплотить хорошо и быстро работающий вариант рендера, а переписывать, дописывать, шлифовать(а надо ли?) можно будет потом

важнее всего - быстро выпустить бету без потерь качества

не соблазняться и не отвлекаться
и фигачить!

переход снова к pascal/delphi -> lazarus

lazarus всё ж ближе. на крестах суетно писать бывает. и про то чтоб собрать везде спокойно не уверен что выйдет. сам намучился с присоединением к fox toolkit, fltk.

проще всего связать рендер с fox toolkit, дописав в проекте visual c++ вместо примера по fox toolkit вызов своего кода и компилировать intel c++.

с помощью MinGW новой версии с 64-битным компилятором не смог собрать fltk и выбросил всё из исходника, касающегося gui. получился консольный вариант. можно оказывается разделить варианты программы.  

lazarus радует наличием библиотек и компонентов для загрузки и отображения 3d-форматов.
glscene и Castle Game Engine - достойные библиотеки. возьму одну из них и допишу из другой, недостающее возьму из assimp.

Castle Game Engine порадовали наличием поддержки hdr, но exr сделан через экспорт из imagemagick. надо код связи с imagemagick изгнать и сделать на основе tinyexr, stb_image

AdaptiveDistributedRenderScene, vcm и разные семплинги

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

smallVCM sampling		шумный семплинг из других рендеров
path_noisyness 0.15		path_noisyness 0.075

все рендеры - 10 минут +-10 секунд

интересная работа - Глобальное освещение с помощью октантных текстур

Глобальное освещение с помощью октантных текстур

two-stage mlt

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



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