вторник, 30 октября 2018 г.

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

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

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

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

суббота, 6 октября 2018 г.

технологии

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

пятница, 21 сентября 2018 г.

опять 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

четверг, 20 сентября 2018 г.

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

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

пятница, 7 сентября 2018 г.

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

воскресенье, 2 сентября 2018 г.

todo: pppm, pclt

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

воскресенье, 26 августа 2018 г.

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, даже с большим количеством проходов

пятница, 24 августа 2018 г.

glsl pepelac roadmap

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

пятница, 10 августа 2018 г.

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

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

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

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.
быстро находятся световые эффекты и со временем - улучшаются детали и уходит шум

воскресенье, 5 августа 2018 г.

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

суббота, 4 августа 2018 г.

из 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(). подсвечивает лампы лучше

пятница, 3 августа 2018 г.

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

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

четверг, 17 мая 2018 г.

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

очень хочется уже выпустить рабочую версию рендера, чтоб запустить, пощупать.
для этой цели годится и 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, но дооолго и не буду.

пятница, 4 мая 2018 г.

четверг, 26 апреля 2018 г.

uniform grid от jacco bikker

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

студия на delphi и простое окно glut на с++ ПРОТИВ с++ nanort nanosg

из-за того, что пример студии nanosg - это пример использования, прежде всего, tiny_obj_loader и nanort, оказывается, они завязаны очень друг на друга эти 3 вроде бы независимые библиотеки.
я думал из этой связки выброcить nanort, но на нем завязано "пройти по сцене и сохранить информацию об объектах".
мне еще к nanosg надо было бы добавить отображение цветом треугольников и поменять структуру хранения треугольников на более пригодную для быстрого отображения больших сцен.
на Delphi же есть пример загрузки 3ds-файлов с текстурами и окрашены треугольники цветом материала.
есть выбор объекта и вращение сцены. добавил окошко редактирования материала выбранного объекта.
и это достаточно просто и быстро.
для быстрого отображения множества объектов и быстрого перемещения по сцене возьму реализацию frustrum culling на основе octree на delphi.
затем добавлю скоростное самописное чтение obj, ply, fbx, alembic, collada.
это будет студия под названием ГРАВИЦАПА.
сам рендер будет только принимать сцену и настройки камеры, денойзера и прочих - в своём бинарном формате, рендерить в окно или файл, и быть предельно молчаливым.
на c++ и openCL. очень быстроходный!

embree, nanort, irregular grid

написал я свой grid, да работает он не четко. ошибка какая-то. то ли double, то ли я где-то налажал...
время построения grid мне очень нравится, но bvh, octree, qvht и ТЫСЯЧИ ИХ - всевозможные структуры для определения пересечений луча с геометрией - обычно или дольше во времени построения, или дольше в нахождении пересечения.
embree и nanort хороши, но строят bvh и, зачастую, долго.
посмотрел я пример, как привязать embree к множеству сфер и находить пересечения их с лучом. очень многословно. и сложнота! и дооолго компилировал примеры Visual Studio.
мой любимый minGW чем-то не угодил cmake.
в nanort попроще подобный пример. я решил его проверить.
сам пример простой - создать заданное с клавиатуры количество сфер и просчитать карту нормалей в png.
10 - быстро, 100 - тоже, 10000 - приемлимо, 1млн - уже долго, а 20млн, что будет обычным делом в экстерьерных сценах - очень долго ждал. не подходит мне такое.

попался мне на глаза документ по Irregular Grid и еще построение на gpu и реализация https://github.com/madmann91/hagrid
авторы говорят, что у них умный grid, и место в памяти экономит, пропускает пустое место, и быстрее SBVH - sah bvh.
буду пробовать.
картинка с github https://github.com/madmann91/hagrid

пятница, 20 апреля 2018 г.

grid. bih

сначала реализую grid с бинарным поиском
затем реализую многими позабытый алгоритм, который строит дерево быстро и всего на 20% медленнее, чем kd tree при поиске пересечения.
bih, Bounding Interval Hierarchy, одно время даже существовал в blender. сейчас исходников тех не найти.
есть хорошие исходники - https://github.com/jMonkeyEngine/jmonkeyengine/tree/master/jme3-core/src/main/java/com/jme3/collision/bih
bih из данных хранит 1-2 массива

dacrt planes vs grid

отлично справлялся с 2000 объектов dacrt planes. решил ему подсунуть 50000.
доолго что-то считал. отключил его.
простой grid будет гораздо быстрее и тем более на gpu.
информацию о связи объектов и ячеек grid можно хранить простым массивом отсортированным и передавать в openCL и там находить объекты необходимой ячейки бинарным поиском

четверг, 19 апреля 2018 г.

devide and conquer raytracing and spitting, sorting

смотрел исходники devide and conquer raytracing и во всех реализациях меня поразило, что во внутреннем цикле проверка простым перебором до 48 или больше объектов.
можно отсортировать их вдоль осей пересечения и тогда еще раз разбив список, проверить пересечение, как в одном из примеров smallplane.cpp, где сортируется согласно плоскостей
надо бы проверить
всё это надо бы проверить

воскресенье, 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