суббота, 24 июня 2017 г.

EDXRay. чтение материалов из obj/mtl

не читались и не учитывались параметры материла:
Ke - emissive color(r, g, b)
Ni - IOR материала
Ns - phong exponent
Kt - transmissive color.

сейчас все эти параметры запоминаются в свойствах материала и Ni, Kt учитываются при рендеринге:


пока еще сложно даются рендеру материалы, у которых поровну Specular и Diffuse или Specular и Transmissive

пятница, 23 июня 2017 г.

EDXRay. hairball.obj и hdri освещение

нашёлся мне EDXRay - bidirectional path tracer, path tracer, multiplexed mlt с поддержкой disney brdf(по этой фразе его и нашёл), загружает obj, можно загрузить и повращать hdr.

после чтения исходников удивительной находкой оказалось, что используется код smallVCM, на основе которого я писал свой рендер.
в рендере также есть:
  • фильтры изображения MitchellNetravali, gaussian, box(без фильтрации)
  • adaptive sampling - галочка есть, а самого адаптив семплинга в коде нет
  • загрузка environment map(картинка для hdri освещения) интерактивно, в самой программе - в форматах JPEG, PNG, TGA, PSD, GIF, BMP, HDR, PIC, PNM, PPM, PGM. допишу еще pfm
  • сохраняет только в самописный BMP
  • RandomSampler, SobolSampler, Metropolis(фактически его нет, вызывается RandomSampler, сделано наверное для Multiplexed MLT - metropolis там единственный семплер)
  • StochasticPPM - не реализован - вызывается BidirPathTracingIntegrator😹
  • Camera Models

    • Thin Lens Model
    • Fisheye Camera
    • Realistic Camera Parameters
    • Arbitrarily Shaped Bokeh
    • Vignette and Cateye effect
  • Light Source

    • Point Light
    • Directional Light
    • Polygonal Area Light
    • Procedural Sky Light with Hosek Model
    • HDR Probe
  • Integrators

    • Volumetric Path Tracing - как его вызвать, я не понял. надо читать исходник Media/Homogeneous.cpp - похоже используется в phaseFunction HenyeyGreenstein
    • Bidirectional Path Tracing with Multiple Importance Sampling
    • Multiplexed Metroplis Light Transport
  • Materials

    • Lambertion Diffuse
    • Smooth Conductor
    • Smooth Dielectric
    • Rough Conductor
    • Rough Dielectric
    • Disney BRDF
      • Layered Material with Up to 2 Specular Coats
      • Cloth
    • Subsurface Scattering
      • BSSRDF based on Normalized Diffusion
      • Participating Media
    • Normal Map
    • Roughness Map
    • Alpha Test
отлично сделан рендер. я автору написал "thanks for HUGE rework of smallVCM code"
я писал свои модификации к оригинальному smallVCM, но в некоторых моментах я замечал, что сложно добавлять новые штуки. остановил разработку, смотрел как бы мне сделать более универсальный каркас. и перепробовал много исходников и оказывается, что автор EDXRay уже порезал и замиксовал на новый лад исходники smallVCM. сам алгоритм vcm в рендере не реализован. я допишу🐼
также я планирую:
  • загрузку obj с помощью tinyobjloader
  • nanort для пересечения с треугольниками, сферами, curves, cones. сейчас поддерживается Embree для пересечения с треугольниками. сферы превращаются в треугольники
  • загрузка сцен в форматах ini, xml, rib, всех форматах, поддерживаемых assimp
  • реализовать материалы из obj, mtl, поддержка disney brdf из mtl

суббота, 17 июня 2017 г.

tinsel renderer and my speedup modifications

tinsel renderer and my speedup modifications:
  • cpu only version. gpu version hardcoded off
  • openMP is added. on my 2-core cpu speedup to 160%(before openMP 4.7s per frame for ajax scene, after 2.9s) - more cores = faster
  • little bit speedup for disneyBRDF pdf calculation
TODO:
- nanoRT scene accelelerator
- tinyobjloader with my speedups
- lodePNG for save png
- openCL version

Features
  • Unbiased uni-directional path tracer
  • Disney's principled BRDF with importance sampling of diffuse and specular lobes
  • CPU or GPU tracing and shading with a persistent CUDA threads model
  • Interactive OpenGL progressive mode
  • Explicit area light sampling
  • Affine and deformable motion blur
  • Gaussian reconstruction filter
  • Instanced triangle mesh primitives with affine transformations
  • AABB tree with SAH and splitting
  • Simple scene description format
  • Windows / macOS / Linux support

    P.S. зачеркнутое - заявленное, но в коде нет этого




available on github https://github.com/tigrazone/tinsel

воскресенье, 11 июня 2017 г.

embree и openexr. пустые страхи

почему-то было у меня отторжение openEXR и Embree, особенно напрягался про то, что фиг соберёшь под linux и macOSx, но, почитав руководства по установке, становится понятно, что как раз windows-версия сложнее для установки и обновления под Visual Studio. под minGW можно наверное собрать из исходников openEXR и Embree.
SmallUPBP очень уж неплохо работает.
tinyexr можно оставить для записи файлов. неплохо сохраняет и файлы получаются меньше, чем сохраненные openEXR. буду его использовать чтоб не искать в настройках openEXR. может и openEXR у меня старый, только толстые файлы сохраняет.
может я и лось и что-то недонастроил что с tinyexr, но но при загрузке exr для IBL - не видно результата, будто б exr чёрный.

пятница, 9 июня 2017 г.

pepelac. ibl from akari1

после попыток прицепить IBL от upbp и неясного падения проги от этого, решил брать независимый исходник от akari1.
к тому ж там есть importance sampled ibl для direct paths

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

четверг, 8 июня 2017 г.

density control for photon maps

документ Density control for photon maps опубликован в 2000 году
с 2001 года реализован в RenderPark
подобное предлагали в 2014 году Jiří Vorba, Ondřej Karlík, Martin Šik, Tobias Ritschel, Jaroslav Křivánek в работе On-line Learning of Parametric Mixture Models for Light Transport Simulation
да и в mental ray были importons
и я сделаю
если кратко - выпускаются сначала фотоны для оценки, куда их надо больше - небольшое количество и потом - по построенной карте - более грамотно запускаются фотоны для полноценного просчета

понедельник, 5 июня 2017 г.

akari2 vs gemspt

gemspt подкупает тем, что поддерживает раздельно материалы diffuse, specular, glass и они содержат одинаковые методы, это упрощает и унифицирует подход к материалам.
в akari2 только 2 материала - diffuse, specular/glossy.
была идея перенести в gemspt хорошие решения из akari2, но я, просмотрев исходные тексты nanort/examples/path_tracer/, понял что лучше добавить более стандартную работу с материалами, разделив на компоненты

https://github.com/githole/gemspt
https://github.com/tigrazone/akari2

пятница, 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

GEMSPT https://github.com/githole/gemspt
интересен тем, что четко прописаны Diffuse, Specular, Glass материалы.
после внедрения obj достаточно просто переключать между этими 3мя материалами.
хорошо расширяется

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