четверг, 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++ я знаю давно и могу с ним совладать