пятница, 21 апреля 2017 г.

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

четверг, 20 апреля 2017 г.

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.
большое спасибо авторам указанных рендеров!!!!!!!!!!!!!!!!

среда, 12 апреля 2017 г.

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!

воскресенье, 9 апреля 2017 г.

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 - там где каустика и отражения

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

пятница, 7 апреля 2017 г.

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

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

четверг, 6 апреля 2017 г.

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...

среда, 5 апреля 2017 г.

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

akari + mcmc ups

собрал akari под MinGW 64-битным компилятором. собирается и под linux тоже теперь.
markov chain monte carlo ups/vcm(mcmcups) встрою в akari как один из рендеров
очень пригодится akari aaa, придумал как использовать с mcmcups

среда, 29 марта 2017 г.

отличия от 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

понедельник, 6 марта 2017 г.

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 !!!

пятница, 3 марта 2017 г.

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

вторник, 21 февраля 2017 г.

bidirectional path tracing и потоки

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

суббота, 18 февраля 2017 г.

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


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

пятница, 17 февраля 2017 г.

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 и луча из камеры, давая новые эффекты

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

среда, 15 февраля 2017 г.

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 наглядно



вторник, 14 февраля 2017 г.

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

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

воскресенье, 12 февраля 2017 г.

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 для методов рендеринга

понедельник, 9 января 2017 г.

воплотил подобие 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) - для центрального.

    пятница, 6 января 2017 г.

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

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

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

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