обзор nox render

nox renderer - render от evermotion.com, ныне - opensource. исходный код можно загрузить с сайта. из интересного для меня:

• path tracing, bidirectional path tracing
  
  
• прогрессивное обновление изображения
• render passes, здесь называемые LAYERS
  
• разные алгоритмы заполнения изображения семплами
• аккуратное управление камерой - фокусное расстояние, пресеты обьективов
  
  
• очень хороший редактор материалов
  
• присутствуют пост-эффекты bloom, glare, fog
  
• коррекция изображения с помощью кривых
  
• настройки антиалиазинга и пресеты фотоплёнок
  
• хорошие настройки солнца, неба, атмосферы
  
• оптимизация геометрии при загрузке - находятся дубли вершин и сохраняются только неповторяющиеся. экономит память
• удобный интерфейс

внимательный читатель заметит, что я обошел стороной вкладку FAKE DOF. я там ничего не понял и слово fake меня отогнало

в комплекте с исходниками идёт и nox bench

загружается и рендерится достаточно увесистая сцена с помощью nox render
сцену можно загрузить в nox render

из минусов
странно на этапе загрузки сцены видеть, что вычисляются uv-координаты и дисплейсмент
я бы рассчитал потом, когда это действительно понадобится
процесс загрузки сцены

о 3х-проходном методе рендеринга. продолжение

в прошлой заметке я показывал вот такую схему проходов рендеринга

если внимательно посчитать и подумать, то:
1й проход это 1/16
2й проход это 4/16
3й проход это 16/16 - 4/16 - 1/16 = 11/16

многовато на 3й проход... подумалось мне и придумал я другую схему

в новом варианте на 2м проходе немного странноватая схема - не 2х2 блок, а 2 на 3 строки
итого:
1й проход 1/16
2й проход 6/16
3й проход 16/16 - 1/16 - 6/16 = 9/16
так вроде бы лучше ;-)

хотел заметить, что фотонов выпускать нужно 1/16, 6/16 и 9/16. размер изображения 1/4, 1/2, 1/1

manifoldis next event estimate

в ближайшее время возьму реализацию PTMNEE из nanogi.cpp и внедрю в свой PEPELAC RENDERING BANDURA отдельным рендером на основе pathtracer.hxx, в работе которого и всего комплекса основного рендеринга я насилу разобрался

а это мой пепелац, который скоро уже выйдет в люди. готовлю первую версию публичную версию

render dev roadmap

хорошее дело - дорожная карта. не даёт сбиваться с пути разработки и расфокусироваться на задачи оптимизаций и наворотов фич небывалых отовсюду, отнимая кучу времени на пустые тесты.
расфокусироваться очень легко - много сейчас интересных исходников и пдфок с отчетами и идеями!
итак, моя дорожная карта на ближайшее время:

• запоминать render passes, в том числе по технологиям, как в UPBP
• variance adaptive importance sampling for cam paths, как в akari
• AdaptiveDistributedRenderScene() готово
• далее - воплотить 3х-ступенчатый метод рендеринга готово
• добавить texture mapping, bump mapping, displacement, процедурные текстуры
• добавить tinyexr для чтения и записи exr
• добавить assimp кучи форматов 3d-сцен и обьектов, оптимизировать assimp в плане поиска в строках и любимую мной буферизацию добавить
• на основе примера из fox toolkit сделать загрузчик и просмотрщик всех форматов 3d, поддерживаемых assimp
• добавить загрузчики и сохранение изображений из stb_image, lodepng для png, jpeg compressor для jpg
• добавить uniform grid scene accelerator - для вокселизации всей сцены и сделать мою реализацию, без хранения большого массива массивов с обьектами. линейный массив и бинарные поиски!
• добавить qbvh из akari. создавать qbvh в каждой ячейке grid, к которой происходит обращение. можно кешировать и выбрасывать из кэша, если память нужнее
• попробовать переписать vector.push_back на emplace_back и проверить насколько мой arr_list быстр и уместен
• hdri освещение с importance sampling из akari
• сохранение hdr с rle-упаковкой из akari, код записи которого я недавно ускорил с 17 секунд на файл до 0,6 секунд. это всё чудеса буферизации и выбрасывать нужно по-тупому используемые функции, которые дико там не к месту. код не лучше, чем у меня, и потому внедрять его не стану
  

akari MinGW build !!!

minGW port of akari
я наконец-то собрал akari с помощью MinGW компилятора gcc.
теперь заживу!
меня останавливало от продолжения работы над рендером отсутствие вменяемого примера, когда qbvh собирается с MinGW без ошибок


преимуществом факта сборки с помощью MinGW akari стало то, что можно будет собирать мой рендер на любой платформе без потери скорости

мне радость!!!!!!!!!!
потому что из akari можно взять работу с апертурой-изображением, variance-based importance sampling path tracing, importance sampled IBL, qbvh и еще парочку штук

vcm в 3 прохода с импортансами в придачу

пока в виде идеи, но на днях воплощу такое:
отрываю фотошо и рисую простую картинку с линиями и циферками, которую рисовал в блокноте сегодня

1. первый проход
   
   • выпускается 1/4 лучей из ламп от размера изображения
   • просчитывается картинка 1/4 от размера кадра
   • если итерация алгоритма первая, то зарисовать все остальные пикселы полученным цветом. маленькие цифры покажут что я зарисую тем же цветом пиксела
   • шаг к следующей комбинации 4
   • ^{у меня исполняется за часть секунды (0.1 - 0.3), у людей компы посильнее и будет очень быстро}
2. второй проход
   
   • выпускается 1/2 лучей из ламп от размера кадра
     *просчитануя на предыдущем проходе хэшмап фотонов можно использовать в качестве импортонов - для улучшенного попадания лучей в действительно важные области изображения
   • просчитывается картинка с на размер изображения 1/2 от размера изображения с учетом variance от картинки с прошлого шага. адаптивный самплинг тут сделаю
   • если итерация алгоритма первая, то зарисовать все пикселы справа и снизу квадратами 2х2
   • шаг к следующей комбинации 2
   • ^{у меня исполняется за 3 секунды}
3. третий проход
   
   • всё также, как и в 2м
     
   • ^{у меня исполняется за 3 секунды}

итерация - это один полный цикл трейсинга для получения полного кадра
проход - в каждой итерации 3 прохода
комбинация - это цикл прохода по пикселам изображения - сначала обработаются все 1, затем все 2, затем все 3

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

1/4 размера кадра у меня исполняется за часть секунды (0.1 - 0.3), у людей компы посильнее и будет очень быстро
1/2 размера кадра - за 3.5 секунды
полный кадр просчитывается за 17 секунд

Volumetric Vertex connection and merging и другие новшества из проекта UPBP

при внимательном изучении кода UPBP обнаружил:
upbp_bpt это vbpt(volumetric bidirectional path tracing)
upbp_surf - vertex merging фотоны на поверхности
upbp_vcm = upbp_bpt + upbp_surf, volumetric vcm
upbp_pp3d - point to point merging - соединяет фотоны volume - дымы, туманы и прочее такое, немного совсем замедляет рендеринг
upbp_pb2d - point to beam - связывает фотоны с photon beam(световые трубы), замедляет ощутимо, до 2х раз время рендеринга
upbp_bb1d - beam to beam - связывает световые трубы, капец как сильно замедляет рендеринг

upbp_bpt, upbp_surf, upbp_pp3d работают с фотонами-точками,
upbp_pb2d, upbp_bb1d - с photon beams - световые трубы, снопы света

*помимо упомянутых здесь photon beams, облегчающих задачу визуализации volumetric-эффектов есть еще Progressive Expectation–Maximization for Hierarchical Volumetric Photon Mapping, который ускоряет рендеринг по сравнению с photon beams.
изображение из pdf


все эти алгоритмы нашёл как пустить через importance sampling дабы избежать долгого рендеринга.
спасибо авторам UPBP за внятный код и реализованные там алгоритмы сохранения DebugImages - сохраняются изображения покрытия семплами для каждого алгоритма и даже по проходам картинки сохраняются

на State of the Art in Photon Density Estimation SIGGRAPH 2012 Course также есть интересная техника Photon Relaxation

из исходников вытер всякое упоминание методов рендеринга, которые дублируются в upbp.hxx - exe уменьшился на 100 кб. небольшое, но всё ж уменьшение ;-)

что такое Vertex Merging в алгоритме Vertex Connection and Merging (vcm)

читая исходный код UPBP, наткнулся на неплохую реализацию Volumetric Bidirectioanl Path Tracing.
и многое мне напоминало код vcm.
сравнил код VolBidirPT.hxx и VertexCM.hxx увидел, что отличие, кроме volumetric-кода, в коде Vertex Merging.
в vcm, upbp он есть, а в vbpt - нет.

bpt		vcm
33s		56s
39s		73s
37s		71s
29s		44s

в обоих случаях - 5 проходов

между Generate light paths и Generate camera paths
вписан следующий код

создаётся на основе запомненных попадений луча в обьекты и цвета этих "фотонов" хэш-таблица для progressive photon mapping, который дописывается после vertex connection, который в свою очередь собирает лучи из камеры для каждого пиксела


vertex merging - очень хороший пример path reuse, использования уже просчитаной информации еще одним путём для нахождения дополнительной информации об освещении сцены.
и пофиг, что vcm в 1.5-2 раза медленнее bpt. у многих современных рендеров и такое редкость, не говоря о качестве изображения.

Volumetric Bidirectional Path Tracing мне приглянулся больше, чем UPBP-технологии - быстрее, не уступает в качестве - более равномерное покрытие семплами изображения

восторг при чтении кода

эвристика для ускорения поиска фотонов, попадающих в радиус

фотоны, которые попадают в квадрат, автоматически попадают в нужную мне окружность и не надо считать расстояние до фотона

smallUPBP - сцена 27

время просчета - 4 минуты 28 секунд. 10 проходов
алгоритм upbp_vcm
о волюметриках и алгоритмах группы upbp_ могу сказать, что память жрёт очень и очень

smallUPBP

Сделал еще попытку собрать upbp и обнаружил, что программа падает при попытке исполнить sse4 - инструкции. Кое-где заменил на обычный алгебраический подход, без sse.
В тестовых сценах много источников света и им очень-преочень нужно умное importance-based семплирование, коим я сейчас и занимаюсь.
На upbp еще навешаю importance sampling везде где только можно - hdri-освещение, как в предыдущем посте - для direct light и importons для глобального освещения и прочих каустиков


10 проходов. каждые 2 прохода сохранял изображение. 261 секунда(4 минуты 20 секунд)

как видно, семплинг галимейший. ибо столько шума и ярких точек спустя столько времени просчета...

importance light sampling. tungsten

взято из Tungsten. со слов Handling multiple lights

идея для быстрого и экономного акселлератора пересечений луча с обьектами сцены grid. обновлено - пересечение

данный алгоритм писался с учетом особенностей GLSL и программирования GPU-рендера - простота и быстродействие выбраных технологий

1. по формуле из SunFlow расчитать количества ячеек в grid на основе ограничивающего бокса сцены и количества обьектов
2. пройтись по сцене и вместо добавления обьектов увеличивать счетчик необходимых ячеек
3. выделить память под массив
4. расчитать коэфициент ближайшего большего десятка по количеству обьектов
5. хранить одну запись в формате float.
   элемент массива = индекс обьекта*коэфициент + номер ячейки
6. пройтись по сцене и сохранить в массив данные
7. отсортировать сортировкой Шелла массив по номеру ячейки. она на 2-3 месте от quicksort и лучше там, что проста в воплощении и нерекурсивна
8. доступ к элементам в ячейке - быстрый поиск в массиве по номеру ячейки

пересечение. проход ячейки grid.

1. выбираются все обьекты у которых mailbox!=rayID, складываются в массив сортированых ид обьектов. если такой ид уже есть(бинарный поиск мне поможет), то не вставлять. если нет - смотреть и сдвигать элементы массива
2. полученный массив обьектов сортируется по дальности центров BBox относительно ray.org (сортировка шелла, sqrt не вызываю)
   vec3 delta = vec3(bbx.bbmax-bbx.bbmin)*0.5-r.org;
   float dist = dot(delta,delta);
3. отсортированный массив проходится и устанавливается обьектам mailbox=rayID

gpu радует!

вот уж где настоящая многопоточность и многоядерность и скорость!

github open source

Решил какое-то время выкладывать на GetHub свои наработки - path tracer на основе Embree.
Будет выложено:

• ускорение на 5% на сцене с драконом путём оптимизации математических операций sqrt, pow, dot, cross, normalize. местами используются sse-варианты функций и упрощения выражений.
  https://github.com/tigrazone/embree/commit/3ad503d02bb130e876d012032f89de9c386ba8c5
• HDRI-освещение, в том числе importance sampled
• более удобное управление с клавиатуры и мышью
• fast preview, которое я реализовал для предыдущей версии Embree path tracer
• ускорение загрузки файлов с помощью буферизации файлов и хэширования по Флетчеру - упрощенные контрольные суммы Флетчера
• Adaptive Distributed Rendering
• Kalemen-style Metropolis Light Transport
• расширения формата obj
• несколько новых тестовых сцен

The Tungsten Renderer

https://benedikt-bitterli.me/tungsten.html

ОТМЕЧУ ПОДЧЕРКИВАНИЕМ ТО, ЧТО ХОЧУ ПОЗАИМСТВОВАТЬ

Feature list

Below is an incomplete list of the features implemented in the renderer. If you're really interested, there is also the detailed (boring, outdated) project report from summer 2014.

Supported integrators

• Bidirectional Path Tracing
• Primary Sample Space Metropolis Light Transport
• Progressive Photon Mapping
• Light Tracing
• Photon Mapping
• Path Tracing

Material models

• Hair
• Smooth coat (varnish on top of configurable material)
• Microfacet dielectric (GGX, Beckmann or Phong)
• Microfacet conductor (GGX, Beckmann or Phong)
• Diffuse Fibers
• Thin-sheet dielectric
• Rough Conductor Wires
• Oren-Nayar
• Plastic
• Smooth dielectric
• Smooth conductor
• Alpha mapped surfaces
• Bump mapped surfaces
• Mixed (blend between two materials)
• Lambert
• Phong

In many instances, material parameters can also be specified via texture.

Shapes

• Triangle meshes
• Bspline curves (ribbons, cylinders, half-cylinders, camera-facing flats)
• Spheres
• Quads
• Disks
• Infinite spheres (for environment maps)
• Infinite spherical caps (for sun-like emitters)

Camera model

• Depth of field
• Shaped Bokeh (configurable via texture)
• Cateye effect
• Chromatic aberration
• Tone mapping (Filmic, Reinhard, Gamma)

Input formats

• Curves: HAIR, FIBER
• Meshes: OBJ, WO3
• Textures: HDR, JPG, PNG, TGA, BMP, GIF
• File save: HDR, PNG, TGA, BMP

AdaptiveDistributedRenderScene()

void adaptive_distributed_render_scene(
   double HalfWidth,double HalfHeight,
   int   nx,int ny,int nxSub,int nySub,
   double Variance,
   char *PicFileName)
{
   double x,y;                // sample point
   ray   ray;                 // pixel ray
   double hx = 2.0   * HalfWidth / nx;   // pixel width
   double hy = 2.0   * HalfHeight / ny;     // pixel height
   double hxSub = hx /  nxSub;
   double hySub = hy /  nySub;
   double Disp;               // dispersion squared
   int   i,j;
   Vector Color;
   Vector Sum;
   Vector Mean;
   int   Count;

   // make  next in  some higher-level module as: RenderOutFile = new Targa...
   targa_image *tga = new targa_image(PicFileName, nx, ny);
   rgb   c;

   for(i = 0, y = HalfHeight; i < ny; i++, y -= hy)
   {
      for(j = 0, x = -HalfWidth; j < nx; j++, x += hx)
      {
         double x1 = x - 0.5 * hx;
         double y1 = y - 0.5 * hy;
         double d;

         Sum   = 0;
         Disp  = 0;
         Count = 0;

         TotalPixels++;

         do {
            for(int  iSub = 0; iSub < nxSub; iSub++)
               for(int  jSub = 0; jSub < nySub; jSub++)
               {
                  camera(x1+hxSub*(iSub+rnd()),y1+hySub*(jSub+rnd()),ray);
                  Color =  trace( air, 1.0, ray );
                  Sum   += Color;
                  Disp +=  Color &  Color;
                  Count++;
               }
            Mean = Sum / Count;
            d =   (Disp /  Count -  (Mean &  Mean)) * Count / (Count - 1);
         } while(d / Count >= Variance && Count < 99);

         clip( Mean );
         c.r   = Mean.x * 255;
         c.g   = Mean.y * 255;
         c.b   = Mean.z * 255;

         tga->put_pixel(   c );
      }
   }

   delete tga;
}

https://github.com/berkus/grayzer/blob/master/src/render/ADRender.cpp
и пример использования https://github.com/berkus/grayzer/blob/master/examples/exampleA/exampleA.cpp

заклинание!

massive progressive adaptive importance!

какие лучше и почему они

• path tracing(pt), в том числе progressive - тормозной алгоритм, который выявляет нужные полезные пути долго и с трудом. стал популярен из-за обилия GPU-числодробилок, которым всё равно что молотить. надоел уже в чистом виде и в нечистом надоел тоже
• metropolis light transport(mlt) намного больше вызывает доверия, даже в чистом виде. ибо хорош, особенно в связке с photon mapping и bidirectional path tracing. строит начальный путь и модифицирует его с помощью всевозможных мутаций. так быстро просчитывается каустика и сложные световые эффекты
• progressive photon mapping интересен, больше даже в модификации stochastic
• bidirectional path tracing(bidir pt) - хорош весьма, в отличии от pt соединяет пути из камеры и из ламп-эмиттеров, пользуясь хитрыми коэффициентами MIS - multiple importance sampling
• минус всех вышеупомянутых - не обращает внимания на распределение света по лампам и потому часто стреляет лучами лампы мимо кассы, тратя на это драгоценное время. importance-техники, next event estimation и explicit light sampling (проверка видимости ламп) - помогают для более быстрого и качественного изображения
• vertex connection and merging(vcm) - гибрид bidirectional path tracing и stochastic progressive photon mapping. выпускает фотоны строго с MIS - multiple importance sampling, но беда всё та же, что и у bidir pt - стреляет фотонами куда попало
• моя модификация vcm, в которой будет на этапе light tracing Metropolis light transport Kalemen-style c учетом importance ламп и потому - дополнительные разбросы лучей буду делать как в psychopath

приятные пустяки

   возился с vcm и нашёл, как переписать std::sqrt на sse-вариант. ускорение вышло незначительное, но есть. и скорее всего, intel c++ версия скомпилированного кода даст одинаковый или не медленнее варианта MinGW. можно теперь добавить в pathtracer из Embree замену на sse-sqrt, sincos воплотить тоже sse-вариант.
   интересно выходит. правлю в одном testbed, затем воплощаю наработки в основном проекте. akari2 не на первом месте. еще можно в vcm QBVH-акселератор

мой новый obj

в дополнении к описанному еще:

• Ni, которое описывает index of refraction, может содержать формулу с переменной w - текущая длина волны. в WinOsi, где подобный подход реализован, встречаются формулы
  ior = 1.400 + 250.0 / (w - 230.0)            ! index of refraction dependent from wavelength
  
  
  
• cuboid, noisesurface - для подобных сцен
  
  

P.S. WinOsi ваще крутейший:

все примеры рендеринга WinOsi взяты из галереи его сайта http://winosi.onlinehome.de/Gallery.htm

идея для GPU-рендеринга

есть у меня gpusppm2.rar от Toshiya Hachisuka - воплощенное шейдерами для OpenGL stochastic progressive photon mapping - близкий родственник алгоритма vertex connection and merging. но одна беда - не работает на моём железе - некрутая у меня gpu-карта. услышал недавно, что DirectX поддерживает шейдеры даже если OpenGL версии этих прог не работают. скачал примеры с шейдерами - работает! нужно переписать gpusppm2.rar под DirectX - может это и будет прогрессивное моё направление для создания GPU-рендера

+ и - path tracer из примера Embree 2.10.0 в сравнении с example renderer из Embree 2.0.0

+ есть corona loader - можно будет загружать xml из corona render

- не читает и не поддерживает такие команды входного файла ecs:

• -hdrilight - освещение с помощью HDRI-карт. и нет файлов для hdri-освещения
• -radius - радиус для камеры
• -gamma - велечина для гамма-коррекции изображения
• -angle для camera FOV
• -renderer - настройки для рендера

- неудобное управление клавиатурой и мышью
- нет быстрых preview-режимов, которые я дописал к embree example render
- sincosf в windows-версии Embree сделан тупейше. заменю на sse-версию

эти все минусы устраню, перенеся готовый код и адаптируя. далее - оптимизирую код для более быстрого просчета. также пересмотреть загрузку obj, xml в плане ускорения. после воплощения HDRI-освещения допишу importance sampling HDRI-карты для скорости и качества

как собрать Embree под Windows - build Embree on Windows

читал инфу с сайта Embree как же собрать с помощью Visual Studio его и примеры, пробовал - ошибки, чего-то не хватает. потратив почти целый день, собрал!
вот алгоритм построения Embree и примеров:

1. выключил принудительно tbb в файле CMakeLists.txt. потом можно будет собрать с tbb
2. cmake -G "Visual Studio 10 2010"
3. у меня установлен MinGW(под ним не собиралось никак - ошибки) и в файлах проекта прописалось местами c:\dev\mingw\include - я эти строчки просто удалил, т.к. все include стандартные пробовал тягать оттуда и было море ошибок. после удаления этого пути - собирает.
4. с помощью Visual Studio 2013 открываем и собираем embree2.sln

далее я собирал с Intel Compiler. exe и dll получились больше, но path tracer генерировал кадр быстрее в среднем на 5-6%. после упаковки с помощью upx размеры рендера с dll стала 2.5 мб - вполне приемлимо. столько обычно занимают файлы после компилятора Lazarus. удобств и о том чтоб как-то перенести в Lazarus Embree и речи быть не может пока что. можно доручить работу со сценой и пересечениями Embree и заняться чем-то более творческим вроде воплощения и тестирования новшеств

скачать Embree pathtracer с моделью дракона [103mb]
после распаковки в отдельную папку запустить dragon.bat

новый Embree и неожиданные находки

Вышел новый Embree!
В bin-сборке обнаружились

• user_geometry.exe - для работы не только с треугольниками, о чем я ошибался. В версии 2.0.0 2013 года, откуда я взял демо-рендер, не было еще этого удобства. раньше нужно было возиться с исходниками Embree. посмотрел историю версий и появилось в версии 2.1.0. сейчас - брать за основу pathtracer из примера, оптимизировать и добавлять своё
  
• pathtracer.exe - для построения минимального path tracer. example path tracer отличается настроенным управлением с клавиатуры и поддержкой разных материалов.
• lazy_geometry.exe нужно еще почитать о чем это. название привлекает новизной
  *оказалось, что можно заказывать чтоб геометрия строилась и предрасчитывалась перед проверкой на пересечение с обьектом. как раз я такое люблю! буду оттуда себе брать!
• hair_geometry.exe - долго возился, но белый экран. позже оказалось что сгенерированное что-то волосатое было вне фокуса камеры. покрутил камерой и оно нашлось и вывелось на экран
• displacement_geometry.exe - как настраивать displacement geometry в Embree
• curve_geometry.exe - что-то о кривых. выглядит как цветная загогулина
• viewer.exe - просмотр моделей в bin-формате Embree и настроек камеры ecs
• viewer_streamed.exe - то же что и предыдущее, но алгоритм отображения ambient occlusion и почему-то streamed. почитаю внимательнее

когда сохранял новый embree в папке, там обнаружился архив с asian_dragon. открыл его и увидел несколько файлов в уже известных мне по модели короны форматах. открыл этот файл и обнаружил там на 7 миллионов полигонов красного дракона.

отрендерил и вот он:

Стоит обратить работу над рендером снова к Embree, потому что за его скоростью самописными методами не угнаться. Собрать новый Embree было непросто - не обошлось от доработок и выключения TBB. Посмотрим как соберётся...

как разлагается свет в спектр

 

резонно переключать рендер в режим просчета спектрального освещения при преломлении с материалом с зависящим от длины волны

c--

• много времени потратил чтобы изменить переменные класса в методе описаном как const. хотел сделать предкалькуляцию по ходу исполнения проги. сократить, ускорить. наивный. сделал иначе и всё равно вышло быстрее, чем было
• временами на непонятных наборах данных программа валится. APPCRASH. надо будет внимательно порассматривать под отдадчиком. оказалось что это sse-команды из кода qbvh. убрал и заработало нормально. компилировал и visual c++ и gcc 4.5 из MinGW - результат один - APPCRASH. после убирания sse-команд в обоих вариантах всё заработало без сбоев

почему не Delphi

• OpenMP делает много работы по потокам. В Delphi придется написать самостоятельно управление кучей потоков
• Форматы файлов многие уже воплощены
• Много опубликовано c, c++ кода и проще компоновать
• stl хорош. например для массива не надо ничо писать. бери vector и радуйся. для парсинга и прочей замены map использую самодельное, но во всем другом - инструментария хватает
• профайлер Very Sleepy не понимает fpc-таблиц символов и не понятно что ж работает дольше и можно ускорять. в c++ с этим прозрачнее. и видно что вот кто у нас тут тупит 
• оптимизации кода. Delphi-варианты одного path tracerа в 2 раза медленнее скомпилированного Lazarus. Lazarus делает могучие exe от 2мб. мне такое не годится
• дикая временами ситуация с теми же методами мгновенной перерисовки. тысячи их и для нормальной эффективности приходится подключать библиотеки или читать о ScanLine, RawImage и подобном. в с++ лёгкая библиотека fltk на любой системе соберётся и шустро будет работать и не жрать тонны места на диске и в памяти

идея ускорения tinyobjloader

искал в google tinyobjloader faster чтоб увидеть, что мой блог по этому запросу второй, а первым в списке стоит Mike Acton's Data-Oriented Design Workshop (2015). поискав по странице tinyobjloader и вчитавшись, понял, что 2 студента получили задание ускорить tinyobjloader. они засунули тестовую программу в профилировщик Very Sleepy и обнаружили, что тормозит зараза std::map. предложенное ими решение мне не очень подходит. я поискал упоминание std::map в файле и понимаю что могу заменить на более шустрый свой хэш. заменю и проверю, хорош ли прирост производительности. кода наверняка станет яснее и без std::map еще и, надеюсь, exe станет меньше

интересное расширение obj

в http://www.kixor.net/dev/objloader/ предложили расширение формата obj для raytracing

Sphere (non-standard):
Spheres are defined with a position vertex and two normals: one for the up normal and one for the equator normal. The length of either normal can be chosen for the sphere radius.

v 10 10 10
vn 1 0 0
vn 1 0 0
sp 1 1 2

Plane (non-standard):
Planes are defined with a position vertex and two normals: one for the rotation normal and one for the plane normal.

v 0 0 -10
vn 0 0 1
vn 1 0 0
pl 1 1 2

Light, point (non-standard):
A simple point light source. Use a material definition to set the output values.

v 10 50 0
lp 1

Light, quad (non-standard):
A 4 cornered area light.

v 0 50 0
v 10 50 0
v 10 50 10
v 0 50 10
lq 1 2 3 4

Light, disc (non-standard):
A disc-shaped arealight source. The normal specifies the direction and size of the disc.

v 0 50 0
vn 0 -1 0
ld 1 1

Camera (non-standard):
Used to define a simple camera. The 2 vertices define the camera position and the point the camera is focusing on. The normal defines the up vector.

v 0 0 -20
v 0 5 5
vn 0 1 0
c 1 2 1

принцип такой - описываются вершины, нормали, а потом выясняется что это описывали камеру и вершины изымаются из общего буфера вершин и нормалей и превращаются в описываемый обьект

также есть расширение mtl

r 0.5            # reflection amount (non-standard)

воплощу в своём рендере

я ускорил tinyobjloader!

до 25% ускорения в чтении/парсинге файлов obj и mtl, убрал медленный и устаревший код.

детально можно почитать на https://github.com/tigrazone/tinyobjloader/commit/9393eda99baae77cd6df471a41025467983a76c3
new tinyobjloader - faster

как я провёл выходные

   закопался в исходник smallppm, затем попутно вспомнил реализацию bpt и 2 варианта pt на предмет, к какому из хороших реализаций-примеров добавить эксперименты с guidiing pt, с которыми не было времени разобраться и вникнуть.
   edubpt оказался на редкость интересной реализацией bpt и pt там неплохие. ускорил там всё по максимуму. еще  всмотрелся в gemspt - в нём хорошо реализован pt с реализацией материалов. возрадовался чудесам простых оптимизаций.
   пробовал запустить mmlt - гибрид keleman mlt и pssmlt с учетом importance. предрасчеты долгие вела программа, то, что посчитала, было шумное и я не понял, чем этот метод хорош. отложил пока подальше.
   читал akari2, oreoreon renderer и примерял реализации qbvh к своему vcm. понял, что основывать свой qbvh буду на akari2. внёс оптимизации в vcm. решил снова возиться с vcm как с основным.
   в oreoreon renderer qbvh строится без учета sah, он интересен тем, как реализовано пересечение и храниение треугольников и других примитивов.
   в vcm сделал заготовку для qbvh. выбросил неиспользуемый код. добавил реализацию sincos с sse из mitsuba. с удивлением обнаружил, что в vcm есть уже savePFM. не ожидал, что так популярен неизвестный мне раньше hdri-формат.

предстоит также реализовать:

• image samplers - box, bspline, ...
• hdri background light
• tone mappers. раньше делал с помощью gamma и автоэкспозицией
• по-прежнему актуально - чтение 3d-форматов. основных
• текстуры
• sse-ускоренные 1/, sincos

очень благотворно чтение исходников. появляется время подумать и сравнить, сделать по-другому, собрать крупицы в свой продукт. благодарю авторов embree, embree example renderer, oreoreon renderer, akari2, edubpt, gemspt

из понравившегося и планы на 8 марта

• On-line Learning of Parametric Mixture Models for Light Transport Simulation
  предлагается guided path tracing, который на уровне vcm, но без многих шаманств. посмотрел прилагающийся исходник и в очередной раз ужаснулся силе многих overqualified с++-программистов. пример использования техники там привязан к mitsuba, который сам по себе - класс на классе. чую я, что напишу на основе исходника из следующей ссылки simple_guided_pt.cpp
  guided pt состоит в том, что сначала трассируются фотоны и сохраняются в importance map. затем производится честный path tracing с минимальными добавками - перед path tracing дописать photon tracing проход и при умножении переменной, отвечающей за importance при path tracing коэффициент берётся из просчитанной importance photon map
  
  
• smallpm: Global Illumination in 128 lines of C++
  Global illumination via Photon Mapping
  спасибо японскому товарищу за исходник ;-)
  с помощью него написать importance PHOTON MAP будет проще, чем по каракулям из исходника из предыдущей ссылки
  
  
• kd-tree для photon mapping мне не нравится и потому буду использовать hash grid из smallppm.cpp
  к тому ж, smallppm значительно быстрее smallpm
  
  
• у Toshiya Hachisuka нашел "Multiplexed Metropolis Light Transport"   [slides]   [code - mmlt]   [code - pssmlt]
  с исходным кодом!
  

сцена для проверки методов просчёта на каустику

взята из проекта oreoren-rendering и назначено много стекла и треугольник с преломлением.
просчитана с помощью photon mapping.
считалось долго и на потолке освещение вышло отвратительного качества, да и по всей картинке - размытость и нечеткие детали, особенно в каустике.

радует:

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

  [Cuboid] scale = 12 12 12 rotate = 30 30 0 position = 0 0 -100 material = Black repeat = 7 7 7 interval = 1 margin = 0 0 0 randColor = true

  [NoiseSurface] center = 0 -35 0 scale = 150 3 150 rotate = 0 0 0 division = 2000 2000 material = Water noisyHeight = true noisyColor = false

материалы описаны так:

[Material] name = Mirror color = .999 .999 .999 refl = SPEC [Material] name = Glass color = 1 1 1 refl = REFR refrIndex = 1.5 [Material] name = Glass2 color = 0.9 0.9 0.9 refl = REFR refrIndex = 1.5 [Material] name = Black color = 0.1 0.1 0.1 refl = DIFF

[Material] name = CornellRed color = .75 .25 .25 refl = DIFF [Material] name = CornellBlue color = .25 .25 .75 refl = DIFF [Material] name = CornellGray color = .75 .75 .75 refl = DIFF [Material] name = Water refl = REFR color = 0.8 1.0 0.95 refrIndex = 1.333

8 миллионов поли
LightSource - AREA, rectangle(4 вершины)
примитивы - 4 Rectangle, 2 сферы, 1  Cuboid, 1   NoiseSurface, 2 модели из obj-файлов

под катом - вариант сцены с водной гладью - наклон на пару градусов по всем осям и по y больше размер

мелкие достижения

• поправил рендеринг в файл - ppm, pfm, tga
• поправил вывод дебаг-информации в консольном выводе
• поменял Random-генератор на xorshift128
• заметил необходимость переписать сохранение/загрузку файлов кэшированно
• pfm, оказывается, hdri-формат и схож с hdr, но не настолько популярен
• перепишу поиск пересечения луча с треугольником из недр Embree. позор! там Triangle Intersector тормозным методом Moeller Trumbore. добавлю предрасчеты динамические и будет шелестеть!

ускорение metropolis light transport с помощью грамотного распределения нагрузки между потоками

слева - 105 секунд, прошлый вариант
справа - 85 секунд, новый вариант
разница между версиями программы - почти 20 секунд!
это составляет 105 / 85 = 124% ускорения

скачать можно по адресу https://github.com/tigrazone/simple-mlt

изменение курса и новый todo. обновляется

Ввиду крутости реализации Embree, замораживаю работу по Delphi-версии рендера и концентрируюсь на рендере на основе Embree в связке c++, FLTK. Приятной особенностью есть готовность Embree к работе на Linux, Mac, Windows.
Поддерживаются форматы файлов с изображениями ppm, pfm, exr, с подключением ImageMagik - tga, gif, jpg, png, bmp, tif
Итак, новый список задач:

• адаптировать к FLTK
• быстрая загрузка obj, xml
  переписать, убрав зависимость от с++-потоков, хэширование, буферизация
  
  7.2.2016 поправил баг в чтении obj, в чтение mtl внёс специфичные для akari атрибуты - для тестирования сцены, которая шла в примере с akari2
  
  7.2.2016 добавил хэширование, буферизация не сработала. перепишу с fread
  
  9.2.2016 частично переписал долгие сравнения строк на хэширование. надо переписать по всему проекту
  
  оптимизировал и выложил на github свою версию tinyobjloader
  18.03.2016
• metropolis light transport(Keleman style)
• path tracing. быстрая перерисовка при перемещении камеры
  1/8 кадра, 1/4, 1/2 и полный кадр
  10.02.2016
• russian roulette для path tracing
  20.02.2016
• Vertex connection and merging
• Manifoldis Next Event Estimate pdf, slides, avi. Реализовано в NANOGI
• загрузка fbx, других форматов сцен
• прицепить на кнопку сохранение сцены - текущее положение камеры и размеры окна
• прицепить на кнопку сохранение отрендеренной сцены в файл
• загрузка/сохранение файлов с изображениями
  добавить hdr
  - сохранение готово
  26.02.2016
  добавить exr(tinyexr)
  ppm, pfm, добавить tga без ImageMagik
  23.02.2106
  
• добавить png, jpg, tif без ImageMagik

hairball + hdri light in my render

hairball.obj 230mb model - 2.88millions faces

адаптирую simplemlt в новый свой рендер на основе Embree Example Render

Embree крутейший!

Наконец-то собрал и запустил у себя на компьютере Embree. Раньше он собирался, но при запуске вылетал с ошибкой. Оказалось, что мой amd не поддерживает sse4. Отключил использование sse4 и с инструкциями sse3 стал отлично работать рендер - демо-программа из пакета с Embree. На основе этой программы построю свой рендер с отличными от path tracing методами просчета и семплерами и тон-мапперами. Базис демо-рендера очень хорош и расширять его легко и можно повысить эффективность в разы.

Скачать сборку для sse3 и sse4. Запускать crown.bat или cb1.bat и смотрите результат и скорость!

Описание на сайте Embree http://embree.github.io/renderer.html

Управление:

• левая кнопка мыши - вращение(rotate)
• средняя кнопка мыши - панорамировать(pan)
• правая кнопка мыши - приближение/удаление камеры(dolly)
• Ctrl+левая кнопка мыши - установить центр, относительно которого будет действовать приближение/удаление/вращение
• Ctrl+Shift+левая кнопка мыши - изменение фокусного расстояния камеры(fov)
• Alt+левая кнопка мыши - вращение камеры относительно поля видимости
• L - уменьшить радиус линз на 1 единицу в пределах координат сцены
• Shift+L - увеличить радиус линз на 1 единицу в пределах координат сцены

adaptive antialias pt. 1

without adaptive antialias


adaptive antialias 3x3 box filter

любимые Инструменты

программы-инструменты, которыми я пользуюсь большую часть дня:
Notepad++
Denwer
Яндекс.браузер(из него и пишу)
Delphi 2006 lite
Visual C++ 2010
Intel C++ compiler

и реже, без сортировки по какому-то критерию:
Open Server
Firefox
Chrome
Opera 12.16
Open Office
Corel_DRAW_X4 + photoshop 7 (portable editions)
PhotoshopPortable-cs6
Adobe.Illustrator.Portable.CS6-PortableApps.com
Fireworks MX
Delphi 6
Visual C++ 6(для компиляции старых, но неплохих исходников типа vaahtokarkit и WinOsi)
Visual C++ 2013
MinGW/Msys/gcc 4.8.1
Keyshot 5
Maxwell Renderer
3ds max 2016 student
cinema4d
blender
vray
cycles
corona

new todo

1. lazarus opengl window
   
   • create
   • draw
   • frustrum culling
2. lazarus mouse и клавиатура как в играх - управление сценой
3. obj load
   
   • fast load
     24 nov 15
   • hashing добработать имеющуюся реализацию с adler32
   • parse
   • store in mem
   • mats
     
   оптимизировал и выложил на github свою версию tinyobjloader
   18.03.2016
   
4. MNEE
5. qbvh scene, tris
6. hdr, ibl

листая старые уроки, листинги

• blob primitive
• procedural textures
• normal mapping
• skybox(6 изображений на каждой поверхности куба)

http://www.massal.net/article/raytrace/page4.html

akari2 - before speedup - tri and bbx sse

61 sec