пятница, 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-освещения, неба, других параметров)

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

EDXRay to pepelac render TODO добавка

в догонку к EDXRay to pepelac render TODO
  • openEXR - file read, tinyexr - file save
  • сохранение картинки во всех доступных форматах изображения
  • tone mapping
  • DebugImages - они же light passes, нужно будет для MultiLight, для сохранения нормалей, глубин, прозрачности и т.д.

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

EDXRay. материалы. удивительные открытия в коде

как оказалось, Glass материал поддерживает Fresnel.
как оказалось при рассмотрении кода с учетом Френеля из других рендеров и обьяснения к рендеру Hydra Render

Fresnel:  (френелевские отражения)

Опция Fresnel используется для симуляции материалов c покрытиями и работает полностью аналогично френелю в таких рендерах как VRay, Corona и mental.


Заметка
Френель в редакторе материалов таких рендеров, как VRay, Corona, Mental и Hydra - это удобный способ симуляции двуслойных материалов. Изначально формулы Френеля были разработаны для стекла. При попадании луча света на стекло, часть энергии отражается, а часть проходит внутрь и преломляется. То, какая часть света проходит внутрь, а какая отражается, зависит от угла падения и определяется формулами Френеля. Однако позже формулы Френеля начали использовать для симуляции материала, состоящего из 2 слоёв (как минимум). Первый слой - стекловидная плёнка, которая и создаёт эффект Френеля. Второй слой, как правило, диффузный.
Интересно отметить, что используемые в современных рендерах формулы Френеля - это формулы для диэлектриков, то есть стёкол. Для металлов, то есть проводников, существуют другие формулы точно описывающие их поведение. Однако, так совпало, что при задании больших значений IOR в формуле френеля для диэлектриков, они начинают вести себя похожим образом на формулы Френеля и для проводников. Задание IOR = 50 или 20 далеко от физического смысла, но даёт похожий результат на формулы Френеля для проводников, то есть “случайно получается” металл. В Hydra Renderer мы не стали нарушать эту старую добрую традицию, и поддержали ставший “де факто” трюк с большими значениями fresnel IOR.
Моделирование материала с покрытием с использования формул френеля. Первый слой представляет собой полностью прозрачное стекло (или любой другой диэлектрик) с определённым IOR френеля. При увеличении fresnel IOR данный двухслойный материал становится всё более металлическим.
Диффузный цвет шара чёрный. Вверху френелевские отражения включены. Внизу выключены, что делает маетриал похожим на зеркало.

Fresnel IOR:  (френелевские отражения)


Френелевские отражения с различными значениями Fresnel IOR. Диффузный цвет шара - жёлтый, цвет отражений - также желтый.

среда, 28 июня 2017 г.

EDXRay. волшебная сила Ctrl

в openGL виде нажать Ctrl и мышкой тыцнуть обьект - он станет выделен и покажется редактор материалов!
типа материала и свойства можно менять

EDXRay to pepelac render TODO

todo на ближайшее время по рендеру:
  • кнопка загрузки объектов, сцен, проектов(сцена+рендеренное)
  • сохранение сцен, проектов
  • средняя кнопка мыши зажатая и движ мыши с текущим объектом - переместить объект
  • вращение средней кнопкой мыши - увеличение/уменьшение
  • доделать обработку клавиатуры
  • все свойства материала из obj/mtl - ADVANCED mat
  • все мои антиалиазинги
  • vcm
  • все мои оптимизации(vm_hybridance, path_reuse)
  • удаление выделенных объектов
  • interactive preview(magic sampling)
будет как в keyshot, но по-новому и без progressive photon mapping

    суббота, 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
    ошибка на картинке -
    статуе присвоен материал с
    Kd 1.000000 0.800000 0.800000
    Ks 0.2 0.2 0.2
    но используется только зеркальная(Ks - specular) составляющая.

    стеклянная сфера тоже передана не совсем верно
    newmtl Reflective
    Ns 96.078431
    Ka 0.000000 0.000000 0.000000
    Kd 0.0 0.0 0.0
    Ks 0.9 0.9 1.0
    Kt 0.9 0.9 1.0
    Ni 1.5
    d 1.000000
    illum 2
    а в рендере использовано только преломление(Kt - Transmission)

    пятница, 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 чёрный.