Судя по этой статье, 2048^3 можно хранить в 70Mb. (dataset=hash+offset=dataset)
А вот ещё один фокус (правда оффтопик): 3D в 2D в 3D(поиск оптимального «скальпеля» и выворачивание mesh в bmp) Здесь инфа по Volume (voxel) Ray-Casting'у
Чтобы ответить на этот вопрос, надо прикинуть, а что сейчас мешает делать всё это в runtime?
Мне кажется, что данная технология позиционируется именно для static mesh, так как можно грузить данные, которые были просчитаны заранее.
Хммм… а что если для статик меша подсчитать не 15-20 уровней детализации, а первые 5-10 и в последние кубы вложить информацию о полигонах… и при необходимости, как раз в runtime, просчитывать локальный octree. Такой подход уменьшит кол-во мегабайт pre-computed octree…
Вроде данный подход имеет место быть…
А при грамотной детализации ты никогда не поймешь, где воксели, тк куб для рендера соизмерим с пикселем у тебя на экране. + камеру поворачивали в «нужную» сторону.
Знаешь, у меня тут идейка появилась… мне кажется, что ребята из Unlimited Detail, для ускорения процесса сделали небольшой хак.
Что лучше всего использовать для рендера?!.. Правильно!!! СФЕРЫ.
ИМХО: Они используют Octree для поиска и сферы описаные вокруг куба для рендера. Отсюда и software-mode с ~10-30fps. Может и ошибаюсь.
Этот кубик мы найдем только после декомпрессии очередного слоя детализации, в котором мы имеем по 9 байт на кубик… итого если у нас у родителя байт children = 01000100, то в дочернем слое мы имеем два кубика по 9 байт… а зная последовательность в байте children, я знаю, какая именно «девятка» мне нужна.
Вот теор инфа (olick слайд 170):
Data Storage Size
• 1.15 bits of positional data per voxel
•Cost savings improves as triangle size decreases.
•160 bits per triangle in traditional format
–x,z,y,s,tall 32-bits
-2.2:1 ratio
•80 bits per triangle in compressed format
–x,y,z,s,tall 16-bits
-1.1:1 ratio
•72 bits equivalent per triangle in oct-tree
–(for next generation)
По поводу объемов:
Как я уже сказал, каждый воксел(куб) в дереве содержит 9 байт информации. (1-children + 4-color + 3-normal + 1-specuar)
Если мы имеем пространство 2048 x 2048 x 2048, то у нас максимум информации ~72Gb.
Допустим, после избавления от «пустых» данных, мы получим ~32Gb. Но ведь это не сжатые данные. и никто не говорит, что нам необходимо их все разом грузить в память.
В презентации Olick'а с SIGGRAPH2008 предложен следующий вариант сжатия:
а. Разделить все данные по слоям детализации.
б. Сжать информацию о детях в данном слое путём RLE-like преобразований.
в. Преобразовать информацию о цвете в дельту к родительскому слою (слайд 167/168 Olick'а) и сжать с помощью RLE
В результате имеем структуру, которую можно stream-ить по мере необходимости. Причём, оффсеты для данных и декомпрессия необходимых значений происходит на лету.
В документе ещё идёт речь о кешировании, но я не вдавался в детали.
c) с помощью occlusion culling алгоритмов отбросить ненужные полигоны
d) оставшиеся полигоны (полигон — часть плоскости, с бесконечным количеством точек внутри себя) преобразовать в конечное число пикселей на экране (рендер)
e)post-processing
А что если, пойти обратным путём:
a) для каждой точки экрана сразу определим цвет, глубину, нормаль...
b) просчитаем освещение и тени
c) выведем данную точку на экран
Это достигается путём:
a) деление mesh'а алгоритмом octtree на конечное количество кубов.
Количество кубов зависит от сложности модели и необходимой детализации. Для статичных моделей производится заранее и требует много места на диске.
Каждый куб содержит информацию о «детях» (1-byte), цвете(4), нормали(3) и specular power(1)
b) (Multi-Core)Определить куб для данного пикселя экрана путём Ray-Casting'а по Octtree дереву. Также получаем доп. параметр — глубина
c) Расчитать освещённость и тени
d) Post-processing
Те. мы работаем не с Mesh'ем, а с его Octtree представлнием.
Дерево можно сильно сжать с помощью RLE-like преобразований.
А вот ещё один фокус (правда оффтопик): 3D в 2D в 3D(поиск оптимального «скальпеля» и выворачивание mesh в bmp)
Здесь инфа по Volume (voxel) Ray-Casting'у
Мне кажется, что данная технология позиционируется именно для static mesh, так как можно грузить данные, которые были просчитаны заранее.
Хммм… а что если для статик меша подсчитать не 15-20 уровней детализации, а первые 5-10 и в последние кубы вложить информацию о полигонах… и при необходимости, как раз в runtime, просчитывать локальный octree. Такой подход уменьшит кол-во мегабайт pre-computed octree…
Вроде данный подход имеет место быть…
Что лучше всего использовать для рендера?!.. Правильно!!! СФЕРЫ.
ИМХО: Они используют Octree для поиска и сферы описаные вокруг куба для рендера. Отсюда и software-mode с ~10-30fps. Может и ошибаюсь.
Вся прелесть всего этого SVO безобразия в скорости Ray Tracing'а
Data Storage Size
• 1.15 bits of positional data per voxel
•Cost savings improves as triangle size decreases.
•160 bits per triangle in traditional format
–x,z,y,s,tall 32-bits
-2.2:1 ratio
•80 bits per triangle in compressed format
–x,y,z,s,tall 16-bits
-1.1:1 ratio
•72 bits equivalent per triangle in oct-tree
–(for next generation)
+ драгоценные циклы пойдут на прорисовку динамических объектов
Как я уже сказал, каждый воксел(куб) в дереве содержит 9 байт информации. (1-children + 4-color + 3-normal + 1-specuar)
Если мы имеем пространство 2048 x 2048 x 2048, то у нас максимум информации ~72Gb.
Допустим, после избавления от «пустых» данных, мы получим ~32Gb. Но ведь это не сжатые данные. и никто не говорит, что нам необходимо их все разом грузить в память.
В презентации Olick'а с SIGGRAPH2008 предложен следующий вариант сжатия:
а. Разделить все данные по слоям детализации.
б. Сжать информацию о детях в данном слое путём RLE-like преобразований.
в. Преобразовать информацию о цвете в дельту к родительскому слою (слайд 167/168 Olick'а) и сжать с помощью RLE
В результате имеем структуру, которую можно stream-ить по мере необходимости. Причём, оффсеты для данных и декомпрессия необходимых значений происходит на лету.
В документе ещё идёт речь о кешировании, но я не вдавался в детали.
По теме:
Текущий pseudo-подход к рендеру mesh-ей:
А что если, пойти обратным путём:
Это достигается путём:
Количество кубов зависит от сложности модели и необходимой детализации. Для статичных моделей производится заранее и требует много места на диске.
Каждый куб содержит информацию о «детях» (1-byte), цвете(4), нормали(3) и specular power(1)
Те. мы работаем не с Mesh'ем, а с его Octtree представлнием.
Дерево можно сильно сжать с помощью RLE-like преобразований.
Ссылки:
Сайт с документацией от сотрудника NVidia Research...
Инфа по движку GigaVoxels
Видео по GigaVoxels
Сайт VoxLOD'а
Видео по VoxLOD
Спасибо за внимание.
P.S. Первый коммент. Чувствую, что где-то сильно накосячил.