направления и отвлечения

yocto-gl - отличный проект, его хочется развивать и дорабатывать, но потрачу много времени и займусь своим рендером спустя много времени.
временами написан замысловато. например, мне тяжело было посчитать количество треугольников в загружаемой модели.
можно использовать как тестовую площадку для алгоритмов рендеринга, например, mnee - как расширение volume path tracer + mis.

tinsel - очень хорош и недавно вышло к нему обновление.

лучше не впадать в подобные проекты надолго, а брать из них полезное.
и продолжить работать над решением на основе nanosg, nanort.
nanort яснее и в моей версии nanosg/nanort:

• magic sampling, для быстрого preview
• load/save готовое bvh из файла/в файл, добавить упаковку и автосохранение и будет проект грузиться быстро
• bidirectional path tracer/cpu добавлю

todo отовсюду

• jacco bikker's grid - для https://github.com/tigrazone/smallpt
• glass, png save, scenes read - vulkan renderer. и попробовать простые сцены из opencl рендера
• Practical Path Guiding for Efficient Light-Transport Simulation https://www.disneyresearch.com/publication/practical-path-guiding-for-efficient-light-transport-simulation
• mnee
• pixel cache light tracing

технологии

только написал на c++, отладил, ускорил, появляется opencl.
переписал под него, но для cpu оптимизировал, а на gpu запускать - медленно. нашел еще пару подводных камней.
появился vulkan api на моём горизонте. снова переписать на этот диалект и фреймворк.
доколе? после переписывания на vulkan api, пока буду на нем

опять todo. хотелось бы

всё это относится к рендеру на vulkan

• png save output
• --prefix for file name
  done 24 sep 18
• -t, -p, -ep, -et  fixed time, fixed passes, save every passes, save every n seconds
  done 24 sep 18
• emission mat
• glass mat
• volume - mat, env volume
• save vertices
• load scenes from files
• mvnee
• mnee
• bdpt
• rjmlt
• meshes

vulkan path tracer. а шо, низя?

заинтересовался, что за вулкан такой новомодный.
нашёл рендер https://github.com/mwalczyk/flow и не удержался от желания ускорять и ускорять. и выложил изменения в коде шейдера и скомпилированный вариант рендера
https://github.com/tigrazone/flow
скачай, попробуй силищу вулкана!

todo. pppm, vcm, amcmcppm

• probabilistic progressive photon mapping
  меняется расчет радиуса и он глобальный для всех фотонов
• adaptive markov chain monte carlo progressive photon mapping
• adaptive markov chain monte carlo probablilstic progressive photon mapping
• vcm, очень похоже на probabilistic progressive photon mapping

probabilistic progressive photon mapping vs progressive photon mapping

todo: pppm, pclt

• probabilistic progressive photon mapping
  + чётче каусика, больше просчитывается путей и сглаживание лучше
• pixel cache light tracing
  + четче детали, отсутствие размытия

probabilistic progressive photon mapping. meta-inf/raytr

запустил и смотрю на результаты probabilistic progressive photon mapping в исполнении https://github.com/meta-inf/raytr
и можно сравнивать с progressive photon mapping. нашел следующие отличия:

• probabilistic progressive photon mapping быстрее находит caustic-пути
• probabilistic progressive photon mapping делает чуть более размытую картинку на фоне, где меньше фотонов. но общая картинка у probabilistic progressive photon mapping лучше
  

probabilistic progressive photon mapping лучше и в сравнении с progressive photon mapping, даже с большим количеством проходов

glsl pepelac roadmap

• -t, -p как параметры для ограничения по времени и по количеству проходов
• probabilistic photon mapping
• manifold next event estimate
• amcmcppm
• уменьшение количества вершин
• предрасчеты
• передача более компактных описаний модели
• связь с studio

glslppm. не сегодня. снова opencl

как бы ни хотелось, но пока не буду связываться с glslppm. потому как понять эти исходники мне долговато будет. и не уверен, что справлюсь, чтоб добавить своё.
уж лучше продолжу opencl рендер и добавлю сразу probabilistic photon mapping. сразу будет решен вопрос с пятнистостью progressive photon mapping, vcm.
и сделаю позже еще и path reuse. уж очень хорошая и недорогая технология. а качество сразу выше и быстрее!

powerplant.obj - 12 миллионов треугольников и всякие bvh

• akari2 qbvh simd-оптимизированный. crash на этапе построения дерева. жаль. так быстро строил до 4 миллионов.
• oreoren qbvh simd, sisd -   crash на этапе построения дерева. жаль. 8 миллионов нормально строил
• nanosg - nanort построил дерево за 30 секунд. 2гб. и рендер происходит! там надо frustrum culling
• glslppm bvh не буду и пробовать. долго и много памяти тратит 
• tinsel собрать - надо установить побольше из Visual Studio. 4 миллиона из 3х obj открывает и строит bvh за 6 сек. грузит obj долго. надо будет проверить на 12 powerplant.obj
  UPDATE. подставил вместо Sankt_Kilian_Sockel_jotero_com.obj powerplant.obj - программа упала при загрузке файла. так ничего и не построив и не показав

glslppm. 420s -> 2764s. progressive photon mapping

progressive photon mapping.
быстро находятся световые эффекты и со временем - улучшаются детали и уходит шум

glslppm. преимущества

• obj load, slowww
• sah bvh build CPU, use gpu. медленно строится. много памяти съедается
• выбор по весу light sources(area). не сортировано. получается, что выбор случайный. или полуслучайный
• diffuse, glossy, specular, glass mats

glslppm. развитие

давно пора добавить следующие возможности в рендер Тошийи Хачисуки, которого я касался последний раз в марте этого года:

• управление с клавиатуры камерой и объектами
• PROBABILISTIC progressive photon mapping
• path reuse
• vcm

из changelog.txt - уже сделанное

до prenext15:
* shift, ctrl, alt - 10х, 1/10, 1/20 от шага - для всех клавиш
* n m для увеличения, уменьшения радиуса
* -t sec - для ограничения по времени, сохранить в файл
* -p pass - для ограничения по количеству проходов, сохранить в файл
* сохранение в файл. имя файла - колич. проходов_количество секунд.РАСШИРЕНИЕ
* смена labels, titles
* volumetric ok
* volumetric Sample() speedup
* vertex save ok
* crunch.html для чистки и оптимизации .cl - файлов

prenext15
3 aug 18
* LightInfo передаётся как 1 массив из oId, weight, order, 0й элемент.oId = lightCount
* mollify on - в 2.1 раза дольше, но деталей чуть больше - в отражениях
* pickLITE() работает на 0.95-1.2%, max 10% дольше, при отключенном расчете regularization
* pickLITE() выбирает бинарным поиском из сортированному по weight массиву lights
* mollify выключил(do_test_pickLITE_only)
* explicit lightSample 1 с pickLITE(). подсвечивает лампы лучше

рабочие дебри

сделал pickLITE() - выбор из многих ламп бинарным поиском из массива ламп, отсортированного по "весу лампы", "силе лампы".
замедление 1-10% при поиске бинарным поиском.
path regularization замедляет расчеты в 2 раза!
нашёл, как находить лампу для next event estimation.
сгодится для mvnee, mnee

смотря по сторонам

очень хочется уже выпустить рабочую версию рендера, чтоб запустить, пощупать.
для этой цели годится и tinsel render, nanoray - простые и хорошо работают. nanoray хуже считает пересечения, с ошибками.
минусы tinsel - старый и долго строящийся bvh, свой obj reader, png writer - слишком самопальные и устаревшие.
больше для моей цели подходит nanosg и моя версия bidirectional path tracer из примеров к nanort.
большие плюсы делать ренедер на основе nanosg - новый obj loader, nanort дописать gpu-проход дерева и поиск пересечений, работа с объектами сцены(перемещение, вращение, масштаб), можно добавить tinyexr, stb_image для загрузки/записи exr, png,...
и bidirectional path tracer cpu относительно легко добавить к nanosg, затем сделать opencl версию.
и это можно сделать быстро. на основе tinsel возился бы я с переделками дольше.
а еще. nanosg просто компилировать из mingw.
tinsel настроен на visual studio. повозившись, я бы сделал для mingw, но дооолго и не буду.

studio todo

• octree frustrum culling
• colored faces
• textured faces
• pick - traverse octree
• только на этом этапе выбросить nanort

uniform grid от jacco bikker

вспомнил и снова посмотрел реализацию uniform grid от великого просветителя и создателя быстрых экспериментальных решений Jacco Bikker.
он сделал быструю и простую реализацию uniform grid.
даже поиск пересечения оптимизировал. надо будет сделать первым делом его вариант
http://www.flipcode.com/archives/Raytracing_Topics_Techniques-Part_4_Spatial_Subdivisions.shtml