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 минут