воскресенье, 15 апреля 2018 г.

smallptgpu lazarus

интересно сделать запуск opencl рендера на Lazarus.
это ж будет потом под все системы!
и сделаю там синхронизацию потоков, как в smallptgpu2, но не барьерами, а стандартными средствами lazarus/delphi

среда, 4 апреля 2018 г.

delphi/lazarus, c++. работа с zip

для c++ и распаковки zip-архивов есть минималистичная библиотека miniz.c
example2 красноречиво рассказывает, как извлекать инфу из архивов.
kuba-- сделал удобную надстройку над miniz, чтоб удобно работать с zip-архивами

для lazarus/delphi есть удобное решение, описанное  в форуме в теме Zip component that works for both FPC and Delphi 7?

ленивое программирование и распределение нагрузки

раз уж так хорошо работает на с++ написанный smallptGPU 2.0, нет смысла делать аналог на delphi/lazarus.
буду передавать в с++ pepelac бинарное описание сцены для быстрого рендера и, возможно, в упакованном виде.

на delphi/lazarus пишу загрузку сцен в форматах общеизвестных и сохранение в бинарный формат проекта

понедельник, 2 апреля 2018 г.

pepelac. new todo

  • octree, frustrum culling. octree только для frustrum culling
  • wasd, стрелки
  • pick, shift-pick, группирование, групповые операции
  • вращение, перемещение, scale для объектов
  • classic grid для ray tracer
  • свой grid
  • загрузка сцен
  • сохранение и загрузка проекта

sparse voxel octree vs мои работы давние

как я писал раннее, можно построить grid без самой структуры. сейчас имею смелость сказать, что и массива центероидов тоже не будет. потому как всё равно доступны будут ограничивающие крайние координаты объектов(bounding box).
и расчитать их - проще простого. ах, одно умножение на каждую координату. но на gpu и с сортировкой... уууу будет интересно.
смотрел сегодня описание sparse voxel octree. и вспомнилось мне, что давным-давно я нашёл эвристику, которая отсекает несозвучные с ходом луча части пространства и ограничивающие крайние координаты объектов.
публиковал где-то 2003м

воскресенье, 1 апреля 2018 г.

борьбу во мне выигрывает c++

ужасающий размер exe файлов, генерируемый lazarus, а это для windows - 2.5мб, для mac - 10мб отпугивает и я склоняюсь к с++, библиотеке imGUI и простому шаманству.
minGW gcc, который у меня в windows, генерирует exe размером 800кб - 1.5мб с окнами и glut.
gcc в linux - примерно такие же размеры файлов.
так зачем же использовать неоптимальное?
c++ я знаю давно и могу с ним совладать

суббота, 24 марта 2018 г.

delphi, opengl, opencl

нашлись мне примеры работы с openCL Delphi. очень хорошие примеры.
а еще я вспомнил про Delphi raytracer с openGL preview и там можно мышью сцену вращать.
поискал, как выбрать объект мышью на Delphi и на ресурсе OpenGL Projects http://www.sulaco.co.za/opengl.htm мне нашелся и загрузчик 3ds, загрузчик obj.
и показывает с текстурами!
потом можно будет переписать под lazarus и собирать везде под любые системы.
Delphi мне проще по созданию интерфейса и с выводом на экран проще и threads отличные.
можно будет запускать на многих гпу свой рендер

с++ и smallptGPU 1.6, smallptGPU 2.0, ocltoys использую как пример. boost и прочие выкрутасы c++ меня утомляют.

pepelac render пишу теперь на Delphi.
быстрее выпущу версию с выбором объектов, сменой свойств материалов

вторник, 13 марта 2018 г.

glsl мой близкий друг

рендер на glsl от Тошийя Хачисуки stochastic progressive photon mapper еще можно улучшать и я вижу как туда дописать материалы полноценные из obj и вращения камерой и другие алгоритмы рендеринга.

является немаловажным для меня фактором то, что на моём gpu слабеньком, который не определяет openCL, рендер работает очень быстро и есть исходники, которые можно изменять как хочется.

рендер на openCL рендерит у меня только на cpu и это очень медленно и не хватает сил дождаться результатов.

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

* также переписал расчет onb на revisedONB(http://jcgt.org/published/0006/01/01/)
* по-хулигански закомментировал normalize в шейдерах. скорость увеличилась, а качество не ухудшилось!

можно внедрить еще и другие алгоритмы рендеринга, и volume rendering!

суббота, 24 февраля 2018 г.

bidirectional path tracing. особенности

  • multiple importance sampling, хорошо для связывания вершин 2х путей посчитанного с учетом силы каждой вершины
  • eye visibility test, помогает для записи в изображение силы лампы, если она попала в камеру
  • можно делать path reuse и достаточно недорого получать больше эффектов освещения
отличный пример со всеми этими штуками - edubpt https://github.com/githole/edubpt

четверг, 22 февраля 2018 г.

grids, bounding spheres и простые центероиды

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

пятница, 16 февраля 2018 г.

ускорение просчета сцен без построения bvh и прочих ускоряющих структур

  • этап инициализации. делается 1 раз на CPU.
    переделывается для каждого изменения сцены.
    шагов инициализации мало и они выполняются быстро-быстро
    1. для каждого bounding box находится центральная точка(ЦЕНТЕРОИД) и сохраняется
    2. для каждого ЦЕНТЕРОИДА строится массив индексов по x, y, z
    3. отсортировать 3 массива индексов по значениям x, y, z
  • этап нахождения пересечения луча с объектами на GPU.
    похоже на прохождение структуры grid, но без построения структуры.
    1. при прохождении ячейки куба найти по большей разнице среди x, y, z приоритетную ось, по которой найти объекты, ЦЕНТЕРОИДы которых в пределах ячейки куба
    2. для каждой ячейки создать второй уровень "виртуальной grid" и проходить детальнее таким же образом, как описано в предыдущем шаге
поиск по сортированному массиву происходит с помощью модификации бинарного поиска и потому происходит очень быстро. мне нужно будет только знать список ЦЕНТЕРОИДОВ и сортированные 3 массива индексов.

path regularization. кривая моя реализация

вышло не очень, по крайней мере, в связке с path tracing.
лучше новые вершины на лампах запоминать и потом просчитывать bidirectional path tracing.
очень хороший bidirectional path tracer, запоминающий только position, normal, pdf и маты - в примерах к nanort.
надо как можно скорее реализовать bidirectional path tracer

вторник, 13 февраля 2018 г.

path regularization и mvnee. читаю исходники и нахожу параллели

читаю исходники mvnee и сравниваю со своей реализацией path tracer и path regularization и нахожу параллели в том, как изменяют исходники, чтобы добиться ускорений.
в mvnee тоже есть "ох и мне бы так" и читаю pdf по path regularization и, о чудо! там отлично находятся фразы next event и пишут дословно "сделали мы его офигенно и директ считаем, но продуманно, с молификацией". мне этот блок напомнил старые-престарые исходники обычных ray tracers, когда просчитывается вклад каждого источника света - последовательно, не вразброс, как во многих path tracer/photon mapper/mlt и остальные методы, некоторые даже придумывают, как бы выбрать лампы, для которых просчитывать вес силы воздействия и которые СЛУЧАЙНО выбирать из построенной таблицы. можно будет проверить потом и этот волшебный метод выбора ламп

пятница, 26 января 2018 г.

todo новенькое


  • воплотить идеи по работе без bvh с массой объектов на основе "grids без grids"
  • manifoldis next event estimation
  • multiple vertices next event estimation для volume rendering
  • воплотить и проверить skeleton bpt
  • связать рендер и студию
  • добавить в студию загрузчик fbx
  • vcm
и всё это на основе gpusppm/glslppm
P.S. за основу взял openCL-рендер на основе ocltoys

четверг, 18 января 2018 г.

full spectrum improvements

расширил максимально рендеринг спектра по длинам волн.
в имеющихся у меня в наличии исходниках рендерились диапазоны
380..780нм, зачастую из этого диапазона текущая длина волны выбирается случайно, что даёт много шума.
так как gpu-рендер очень быстрый даже на моём ati radeon hd 2600xt , я решил просчитывать диапазон 360..830нм, который увидел в одном дотошном и оттого физически точном рендере. там также предлагалась идея просчитать все длины волн с шагом 5нм, что даёт 95 длин волн.
я сначала считаю 95 длин волн последовательно(у меня все 95 посчитались за 2-3 секунды, перелившись всеми цветами радуги), затем случайно выбирается длина волны из диапазона. к этому хитрому алгоритму я дописал случайный выбор, но не менее 10% чтоб просчитывалось, выбирая длину волны из набора 95. остальные 90% - выбираются случайно
на тесте видно, что эта стратегия тщательнее просчитывает дисперсию и прочие спектральные эффекты
1й скриншот - диапазон 380..780нм случайно
2й - диапазон 360..830нм, мой алгоритм

воскресенье, 31 декабря 2017 г.

progressive photon mapping: progressive approach vs smallvcm/smallupbp

сравнивал исходные тексты tatsy_pppm и meta-inf/raytr с smallupbp и обнаружил, что в последнем реализовано более продумано, поэтому ничего в этом месте менять не стану.

попробую теперь реализовать в smallUPBP Skeleton based Vertex Connection Resampling for Bidirectional Path Tracing вместо реализованного

суббота, 30 декабря 2017 г.

TODO. probabilistic progressive photon mapping + photon planes, etc.........

probabilistic progressive photon mapping отлично и наглядно реализован в tatsy-pppm https://github.com/tatsy/tatsy-pppm
photon planes - более продвинутая, чем photon beams, технология рендеринга объемов. реализована в tungsten renderer https://github.com/tunabrain/tungsten/commit/a3233951d948cda1141f4aa305982feae70d427d
а потом

воскресенье, 17 декабря 2017 г.

glsl sppm

#glsl #3d #render #sppm #gpu #demo
славься, великий Тошийя Хачисука!
изобретатель алгоритма stochastic progressive photon mapping участвовал в Tokyo Demo Fest в 2015 и, что немаловажно, выложил исходные тексты.
рендер работает на glsl, а еще
* строит bvh на cpu и находит пересечения на gpu
* читает obj
ясное дело, адаптировать надо будет, но я СМОГ ЕГО СОБРАТЬ и могу менять как угодно. на толстых файлах аж трещит и падает, ничего не показав, но это я исправлю

glsl. читая исходники gpusppm2

gpusppm2 был выпущен в конце 2009 - начале 2010 года.
я его себе тогда сохранил, но изучить не хватало ума и понимания связи path tracing, bidirectional path tracing и photon mapping, не говоря про новомодные ныне progressive photon mapping, multiplexed metropolis light transport и его модификации, vertex connection and merging.
вчера прочёл вдумчиво исходники великого ТОШИЯ ХАЧИСУКА(Toshiya Hachisuka), затем на еще одной его странице - со ссылками на исходники и pdf нашёл описание parthenon render выпуска 2002 года, который я запускал, но не понимал ничего - ни какой метод используется, ни как работает вообще. запускал, удивлялся и не понимал.
также там есть описание stochastic progressive photon mapping с построением bvh на cpu и поиск пересечений на gpu, загрузка моделей из obj файлов. с исходными текстами и pdf с развёрнутым описанием.
Тошия использовал эти исходники на Tokyo Demo Fest 2015. программа идёт со свободной лицензией, при условии что упомяну Тошия как автора и используй как вздумается.


выводы от чтения исходников и оптимизаций

  • замена деления умножением очень нравится gpu и здорово ускоряет расчёты
  • замена умножения на 2 простым сложением - ускоряет
  • вынос расчета констант из цикла дело благое и обязательное
  • использование констант вместо расчетов это ваще силища
  • расписывать детально расчет onb было полезно для cpu-версии рендеров, для gpu рендера всё же быстрее встроенные cross, normalize, количество которых я постарался уменьшить
наглядное сравнение оригинальной и моей, оптимизированной версии gpusppm2
было
стало
возросла скорость!!!
13%

суббота, 16 декабря 2017 г.

openCL. памятка себе

на openCL целесообразно писать рендер даже по той причине, что можно один и тот же код запускать и на gpu и на cpu

среда, 13 декабря 2017 г.

nanosg улучшил, tinyobjloader выйдет с моими новшествами

для nanosg исправил 2 неудобства и ощибки
  1. не читался obj без материалов или если нету файла материалов.
    теперь читается
  2. при загрузке объектов с текстурами-изображениями nanosg честно грузил с нуля каждый файл.
    я сделал кэширование. каждый файл читается теперь 1 раз, сам obj загружается из-за этого быстрее и памяти намного меньше тратится
    было
    стало
еще хочу сделать Frustrum Culling, чтоб выводить только попадающие в камеру треугольники - для ускорения отображения превью моделей.
я лентяй и поискал реализацию в гугле, но единственно внятное нашел - "попадают ли кубы в frustrum?"
можно адаптировать, сформировав такие кубы по минимумам-максимумам вершин треугольника

tinyobjloader я начинил скоростью и некоторыми перспективными алгоритмами. скоро выйдет в мир 

четверг, 9 ноября 2017 г.

приёмчики из realtime raytracing еще сгодятся и в realtime gpu path tracer

читал свой твиттер, в который прилетает много инфы по новинкам в программировании global illumination и там один человек в коментах к реализации своего трейсера пишет, First Bounce Caching это очень хорошо!

мне вспомнилась статья от lycium, которая вышла в августе 2001.
я сохранил страницу из русского издания
http://moo.ho.ua/lyrtrt.htm

можно легко использовать first hit optimisation, shadow cache, запоминать последний ударенный лучом объект. часто он тот же самый для соседних пикселов(First Bounce Caching)

цитаты оттуда
Теневые буферы
Если вы трассируете экран горизонтальными полосами слева направо, сверху вниз (организация большинства фрейм-буферов), и необходимо выполнить проверку теней для каждого пересечения, вы заметите, что если одна точка затенена, то почти гарантировано, что в тени будет и следующая. Так что для выполнения последовательной проверки на затенение для каждого объекта (согласно закону Мерфи, объект, преграждающий свет, будет последним в списке :) храните указатель на последний преграждающий свет объект. 

Оптимизация в первом приближении
Если любая из величин, которые вы рассчитываете в течение всего хода рендеринга зависит от источника луча и некоторых других величин, которые остаются постоянными для каждого кадра (радиус сферы, позиции объектов и т.д.), вы можете заранее просчитать эти значения и сохранить их в защищенных (private) полях данных структуры объекта, а потом просто использовать их, как только вам потребуется просчет для первичных лучей (лучи исходящие из камеры или глаза). Данный метод работает только для первичных лучей, так как отраженные или преломленные лучи, очевидно, не зависят от позиции камеры. Это означает необходимость написания специализированной процедуры определения пересечения для первичных лучей (или как вы узнаете позже, лучей с фиксированным источником).
Это абсолютно необходимая вещь для любого realtime-трассировщика, так как первичные лучи составляют большую часть (относительно, в сравнении с "нормальной" трассировкой лучей) общего числа выпущенных лучей, так как полнота и сложность сцены в нашем случае намного ниже.

Оптимизация проверки на затенение
Проверки на затенение являются очень прожорливыми, когда вы имеете множество объектов в сцене (n объектов - n проверок на затенение на ОДНО ПЕРЕСЕЧЕНИЕ). Но так как все эти теневые лучи исходят из фиксированного источника (точки пересечения), вы можете заранее сосчитать некоторые значения как это было описано выше. Это должно сохранить вам гигантское количество времени.
И снова, это крайне необходимая вещь, так как значительно смягчает потери в скорости, которые возникают при добавлении в сцену каждого нового объекта.

годные расширения для path tracer

потом расширить можно с учетом этих методов до bidirectional path tracer
и сразу на GPU

вторник, 31 октября 2017 г.

ocltoys. sss и fog scenes


Дописать по алгоритму MVNEE, адаптировать к bidirectional path tracing, mmlt,
bvh из tinsel render, другие объекты - не только сферы

воскресенье, 17 сентября 2017 г.

NANOSG. my todo

  • загружать также файлы без материалов или с отсутствующими текстурами/файлом материала
    ГОТОВО 6 ДЕК 17
  • в opengl просмотре сцены делать frustrum culling для ускорения отображения больших сцен, может какой-то bvh
  • пробел можно использовать не так, как сейчас - вернуть камеру в позицию дефолтную, а вместо Tab - zoom. Tab как-то противоестественно использовать с мышью
  • сделать texture cache, чтоб не грузить одну и ту же картинку кучу раз, расходуя при загрузке время и сжирая память
    ГОТОВО 6 ДЕК 17

пятница, 25 августа 2017 г.

NANOSG

#3d #render #interface #nanort #obj_loader
NANOSG - просмотрщик и студия для редактирования загруженых obj-файлов. всё сделано максимально просто с использованием библиотек nanort, imgui, tinyobjloader, stb_image.
вот таким полуфабрикатом можно пользоваться!
в окошке есть render. рендерит пересек ли луч что и насколько далеко(даже не ray tracer, а ray caster, если вы понимаете о чем я), а также нормали и еще несколько режимов.
понацеплю туда своего. будет как FIRE в maxwell render.
nanosg умеет вращать, увеличивать-уменьшать и перемещать объекты. также на скриншоте видно, что есть список всех объектов загруженной сцены.
написал автор nanort

go gpu

изучил несколько исходников с path tracer на opengl glsl шейдерах. заработали очень немногие. полноценно работающего я не нашел.
из openCL - path tracer вызывает интерес smallptGPU 1.6 и построенный на его основе ocltoys - volumetric path tracer

так как я основываю свой рендер на nanosg, мне нужно соединить запуск openCL path tracer с текущей сценой и выводов результата в окно

среда, 16 августа 2017 г.

back to bones. akari

достал запылившийся akari.
ясное дело, qbvh оттуда спокойно можно отложить на склад истории и воплотить интеграцию с модным nanort.
потом подружу его c imgui, tinyobjloader, bidir_path_tracer из набора nanort/examples, значительно мною переработанным(разделение на модули, упрощение арифметики, оптимизация кода, magicSampling, сохранение в кучу форматов изображений).
научил akari аккуратненько складывать результаты работы в отдельную папку.
хороший akari. умеет много всего.
и так милы сердцу комментарии на чистейшем японском языке
// 次のサンプルマップを計算
puts("calculate variance_map");
или
// importance_mapをぼかす

пока вот и все новости

воскресенье, 13 августа 2017 г.

моя первая книга по рейтрейсингу

первой моей книгой по рейтрейсингу была книга Борескова и Шикина "Компьютерная графика. Динамика, реалистические изображения", выпущенная в 1996 году.


я шёл по переходу в киеве и тут она! я зачитался и офигел. не встречал нигде более подробного описания рейтрейсера в примерах.
купить я её не успел. потом появилась более урезаная версия этой книги, но там очень многого не было. я её купил. но первую книгу читал и конспектировал в библиотеке КПИ.
на основе описаного в книге рендера некто berkus выложил grayzer

ох как приятна реализация текстур и кирпичей процедурных и мрамора и всякого такого с помощью простого obj->findTexture(p, txt);

Embree renderer. восстановлю из пепла

в 2013 году Intel выпустила Embree Renderer.
во многом он устарел уже. нет поддержки формата hdr, в obj не поддерживается эмиссия.
пишет в стандартные растровые файлы в основном с помощью image magick. сейчас в ходу универсальный stb_image_write.h
читает только obj, описание сцены хранит в xml и своём формате ecs.
path tracer с множеством материалов, который считает очень даже неплохо.
под новый Embree я его не переделывал и не собирал

изображение можно нажать, чтоб увидеть большое

P.S.

воплотил в рендер мой быстрый превью, в свойства материала добавил Kt/Tf - коэффициент трансмиссии и Ke - коэффициент эмиссии.
поставил сцену из obj-файла на загрузку. пишет, что загружает материалы и присваивает.
результат - всё белым залито и некоторых обьектов вообще не видно. перекрашивал окружающий цвет на красный - не видать всё равно.

как не крути, но tinsel пока лучший.
tinsel пока присваивает всей загруженной модели один материал. научить его для каждого треугольника назначать свой материал из obj/mtl и соответственно, поддерживать материал с такими свойствами.

в Embree Renderer интересна идея со списком brdf.
в nox render свои слоёные материалы

суббота, 12 августа 2017 г.

tinsel render my favorite

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


смущает еще много чего:
* рендер единственный - path tracer. воплощу upbp с учетом эмиссии на основе исходника bidirectional path tracer от tatsy из комплекта nanort/examples
* bvh быстр, но nanort быстрее. прицеплю nanort. на днях как раз разбирался с обновлением nanort в интеграции с демо-рендером
* недописанный disney материал. допишу на основе кода из EDXRay

четверг, 10 августа 2017 г.

понедельник, 7 августа 2017 г.

EDXRay. update

как оказалось, падение рендера вызывали sse-инструкции от самодельного bvh, который всюду по рендеру кроме AreaLight заменен на Embree.
заменю и в AreaLight.
позже надо будет попробовать вариант с заменой на nanort

воскресенье, 6 августа 2017 г.

ошибки поиска пересечения

такое встречалось и в рендерах smallUPBP(старый embree), и NanoRay, и akari с самодельными bvh.
в oreoren посмотрел построение самодельного bvh и взял оттуда константу
#ifdef USE_FLOAT
const float EPSILON = 4e-3f;
#else
const double EPSILON = 2e-4;
#endif
и подставил её в akari
результат стал лучше, но ошибки не ушли.
в верхнем правом углу - результат bvh nanort, у которого всё в порядке с поиском пересечений.
буду использовать его

обрадовали tinsel, nanoRay, embree path tracer

автор tinsel render создал и nanoRay.
поддерживает:
* MatteMaterial(Lambert), PlasticMaterial(Blinn)
* объекты Sphere, Mesh, Plane, Disc, Cone, DistanceField(можно задавать функцию, но что это такое - я не понял; нужно проверить на примере)
* текстуры MixTexture, PerlinTexture, CheckerboardTexture
* небо, солнце. но мне однозначно не нравится воплощенная Perez's model for sky luminance
* так же, как и tinsel render, загружает сцены из obj и ply

материалы хорошие есть еще в embree path tracer. до сих пор я поражон примером с короной. я его обязательно отрендерю своим рендером.
изучение кода EDXRay и эксперименты с материалами здорово меня взбодрило на развитие рендера!

в tinsel есть, но в NanoRay нет:
* dinsey brdf, хоть и неполная реализация. лучше брать из EDXRay
* g_options.filter = Filter(eFilterGaussian, 1.1f, 1.0f);, остальные фильтры можно взять из EDXRay
* nlm denoise, сравнить с другими более новыми денойзерами

EDXRay. прощание

намаявшись с дописыванием полной версии smallVCM с сохранением light paths, решил проверить, насколько хорошо можно отрендерить subsurface с помощью path tarcer, который единственный умеет волюметрику.
рендер падает. APPCRASH.

во время работы с исходным кодом EDXRay много раз удивлялся, зачем автор сделал самодельные и диковатые воплощения стандартных Array, Map и прочих.
возможно, для энтузиастов и студентов это нормально - создать самостоятельно.

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

а еще! КОМПИЛИРОВАЛИСЬ SmallUPBP и EDXRay только Visual Studio и соответственно, только под Windows.
захотел скомпилировать и поэкспериментировать с некоторыми идеями на ноуте и был ПОРАЖОН - Visual Studio инсталлятор 22гб. у меня и флешки такой нет ;-)
к тому же, Visual Studio генерирует далеко не самый быстрый КОД!

minGW можно запускать и с флешки. генерирует программы намного быстрее, чем Visual Studio Compiler и Intel compiler. и компилятор обновляется до самых современных версий.
код, который компилируется в minGW обычно потом отлично собирается в linux

будет теперь

на основе ImGui внешний вид рендера. под minGW отлично собрался демо-пример для opengl2.
из akari1 многое возьму.
там очень много полезного воплощено:
* path tracer
* HDRI light с importance sampling
* qbvh sse. быстрое
* aperture image
* DOF
* adaptive antialiasing
* tone_curve
* vignetting
* depth-based blur

VCM воплощу, пользуясь своими наработками и собранным из последних commit людей, сделавших fork оригинального smallVCM.
NanoRay - очень привлекателен. буду и из него брать наработки

вторник, 1 августа 2017 г.

EDXRay. создание arealight из эмиссивных треугольников


после загрузки файла с моделью, пройтись по всем треугольникам модели и, если у материала установлена эмиссия, то создать AreaLight с этим треугольником.
для всех треугольников строится структура BVH2 и по ней проход и пересечения с треугольником. не будет большого вреда, если это будет создаваться для одного треугольника. можно будет сделать отдельную обработку этого случая и взять пересечение с треугольником из akari qbvh, если не заработает решение

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

заметки о рендерах pbrt и EDXRay


  • EDXRay: Multiplexed MLT во многом повторяет mlt.cpp из pbrt
  • pbrt: PLY поддерживается с помощью rply
  • pbrt: New samplers: a much-improved Halton sampler, and an all-new Sobol’ sampler are both quite effective for path tracing and bidirectional path tracing
    EDXRay: воплощен только sobol
  • pbrt: текстуры, в том числе процедурные и ptex(ptex.cpp)

суббота, 29 июля 2017 г.

EDXRay. sss и disney brdf subsufrace. path tracing vs bidirectional path tracing

EDXRay. текстуры

при рассмотрении исходников EDXRay заметил, что готова загрузка файлов-текстур и рендерит их нормально.
используются текстурные координаты из модели.
нужно управление из интерфейса при работе с материалами - использовать ли текстурные координаты из модели, использовать ли меппинг по выбору, вращение и масштабирование текстур.
интерполяция текстур уже есть. по умолчанию TriLinear
enum class TextureFilter
{
  Nearest = 0,
  Linear = 1,
  TriLinear = 2,
  Anisotropic4x = 3,
  Anisotropic8x = 4,
  Anisotropic16x = 5
 };

enum class TextureWrapMode
 {
  Clamp, Repeat, Mirror
 };

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

EDXRay. MultiplexedMLT. эксперименты

обнаружил, что дополнительный просчет Direct Illumination на этапе предрасчета и раз в 3 прохода дополнительный подсчет Direct Illumination и учёт его для metropolis sampling очень благотворно сказывается и на specular, и на diffuse составляющих изображения.
вот такой вышел результат после экспериментов:

вследствии моих экспериментов Environment map темнее, зато проработанней материалы на обьектах. возможно, нужно иначе делить изображение с учетом сработавших семплов.
следующее в развитии MultiplexedMLT - семплинг лучей камеры по порядку, а не по metropolis, как сейчас.

для сравнения:
до моих экспериментов, оригинальный MultiplexedMLT из EDXRay


и он же за время, как у моего варианта

четверг, 20 июля 2017 г.

EDXRay. пре-альфа

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