Воксельные миры (7 стр)

Aslan
> Уже из анотации видно, что твоя статья не по теме
то есть дальше аннотации ты читать не пробовал? гуляние по octree без стека и без рекурсии реализуется одинаково хоть для плотных, хоть для разреженных, хоть на CPU, хоть для GPU, хоть в screenspace, хоть в worldspace. вся суть — в арифметике определения соседних узлов, ближайших родителей, итп — она везде одинаковая.

> Лишь бы ляпнуть
🤨 ты не попутал ничего, родной? я вообще-то не из теоретических соображений рассуждаю, все мои октри растеризаторы (из недавних) на этой технике основаны

Suslik
> то есть дальше аннотации ты читать не пробовал?
Проглядел бегло. Вижу что там PointCloud, Z-buffer в несколько слоев и репроекция
Так что твое "всё это уже придумали, и это реализуется умнее и быстрее, чем ты описал" - это да, лишь бы ляпнуть
> ты не попутал ничего, родной
Маори тебе родной, ахах

Репроекция - наше все

Зачем спорить, может устроим тест?

Salamandr
Жгите!

Suslik
> все мои октри растеризаторы (из недавних) на этой технике основаны
посмотрел видео (без негатива)

> Should the static storage be populated before the render? Or it can be generated on the fly?

> can be generated on the fly, it does not matter. however, the generation takes quite some time (this dataset took half an hour), so it would quickly become the bottleneck without optimization

в контексте Воксельные миры - как я понял, в случае с техникой Suslik предполагается "читерить" - и рендерить Lod-ы того что пока загружается при повороте камеры, и сам рендеринг "дерева вокселей" делать отложенным используя столько мощностей чтоб не выпадать из за минимум кадров(30фпс как пример)...

звучит как очень большая голованая боль с распределением всего этого, "по фану" яб такое не стал делать так как займет может и год(или больше), придется ведь весь рендер писать со всей логикой отрисовки и менеджмингом ресурсов

П.С.
> vulkan allows you to implement a very robust and reliable data transfer from CPU to GPU while using it during the same frame. the idea is that you store a small host coherent staging buffer that's always mapped, you write into it any data that you need transferred and then copy from this buffer into your gpu-local buffer

я тоже подумал что там может быть сильная нагрузка на память и требуется передавать очень много памяти за кадр, но это решаемо можно делать потихоньку чтоб не жрать 90% времени кадра маскируя куски Лодами как выше сказал... очевидная идея...

Подниму-ка тему

Все вы знаете о привлекательности вокселей для 3d графики, Wiki пишет, что Кармак в Id tech 6 планировал использовать воксели
Есть идея, как растеризовать трегольники непосредственно в SVO на этапе построения
Также есть идея, как эффективно растеризовать SVO без overdraw, SVO отлично подходит для culling.
Также SVO можно текстурировать затайленными 3d текстурами, так информация цвета не займет много места.

Но есть 2 проблемы:
1) как хранить нормали для расчета освещения, в каждом вокселе - слишком расточительно
2) занимаемый обьем
SVO можно ужать до ~ 2 bit/voxel, хранятся по сути, только поверхности тел, но всеже:
Квадрат 100х100 м при размере voxel 10 мм (куда уж больше) - уже 100 млн voxel, а в игровом уровне и размеры больше и много поверхностей различных обьектов, этак нехватит никакой памяти, ни video, ни RAM, это и сдерживает развитие воксельных движков.

С другой стороны, воксели получаются на этапе построения уровня из исходных полигональных или nurbs моделей, рендерингом в SVO, т.е. плоская стена превращается в миллионы вокселей, пустым копированием информации, там где достаточно одного уравнения плоскости.
Если на некоторой глубине oct-tree в узел попадает лишь один полигон, то какой смысл дальше его бить, надо с этим полигоном дальше и работать, в узле хранить его индекс, так растеризатор заодно сможет получить значение нормали в вокселе для расчет освещения.
Разумеется, остаются воксели, где сходятся 2 или более граней. Тут решением будет - или рандомно выбирать в качестве плоскости одну из граней или срезать углы, делать фаску, создавать вместо ребра или пересечения ребер  новую грань с усредненной нормалью. Оба этих варианта применимы, если воксель достаточно мал (1мм или сколько допустимая погрешность разрешения графики), но такие воксели уже будут только лишь вдоль ребер, а не граней, сократили размерность с 2D до 1D и кол-во вокселей, где раньше нужно было 1 млн, теперь 1 тыс!

Итак, обе проблемы решенны.

Что думаете?

Я вот всё хочу сделать minecraft с размером кубика 1 мм. Только есть одна проблема: такое возможность сделать теоретически. Ну вот как доходит дело до практики начинаются всякие трудности.

Начать хотя бы с рендера этих кубиков. Рисовать их по-честному треугольниками не получится и придётся рисовать каким-то другим более сложным способом.

Если посмотреть для примера voxlap. Там для хранения вокселей используется формат похожий на png где только записывается количество пустых пикселей количество полных пикселей и так вертикальными полосочками весь мир это в принципе довольно эффективно.

Можно конечно дерево использовать но в этом случаю кодирование через вертикальные полоски выглядят более эффективным.

Только вот в том же воксельном движке есть проблемы при большом приближении к вокселю у него на краях получаются лесенки довольно видимые шириной в 20 пикселей это явно артефакт рейтрейса.

Возможно ли отмасштабировать Teardown до размеров майнкрафта и при этом иметь возможности онлайн игры?

Представьте огромный мир майна совмещенный с физикой Teardown, игра мечты!

Что стоит на пути реализации такой идеи? Судя по видео тот же voxlap умеет в мультиплеер, наверно будут проблемы с освещением еще

LeonLeonMobo
> Возможно ли отмасштабировать Teardown до размеров майнкрафта и при этом иметь
> возможности онлайн игры?
Конечно, тебе надо всеголишь купить процик за пол ляма!

LeonLeonMobo
> Представьте огромный мир майна совмещенный с физикой Teardown, игра мечты!
1 Фпс игра мечты, мечтаешь о лагах?

LeonLeonMobo
> Судя по видео тот же voxlap умеет в мультиплеер
Только вот физики там нет.

LeonLeonMobo
> Представьте огромный мир майна совмещенный с физикой Teardown, игра мечты!
Представил, майнкрафт лучше.

Это был 1999-й...

samrrr
> Я вот всё хочу сделать minecraft с размером кубика 1 мм
Ну, допустим сделаешь. На стороне куба в 1м уже будет миллион вокселей. И сколько таких кубов потянет твой движок, на 1 комнатушку хватит? А в minecraft хранится не svo, а весь обьем, каждый кубик и поэтому уровень легко разрушаемый, любой кубик можно убрать

> Рисовать их по-честному треугольниками не получится
Рисуй жырнопикселем, спрайтом с размытыми краями, так сгладятся безобразия воксельной лесенки

> Если посмотреть для примера voxlap. Там для хранения вокселей используется формат похожий на png где только записывается количество пустых пикселей количество полных пикселей и так вертикальными полосочками весь мир это в принципе довольно эффективно.
О(N^2) памяти, большой уровень так не закодируешь

LeonLeonMobo
Майкрафт сам неоптимальный и лагучий (и при лагах видно, как отрисовываются подземелья за км от игрока), так что там есть куда оптимизировать и улучшать
Ну и вот же выкладывали видео
https://gamedev.ru/code/forum/?id=252811&page=6&m=5345271#m76
Уже есть движки намного круче, с водой и кровищей, разрушаемые до последней песчинки

Aslan
> Майкрафт сам неоптимальный и лагучий (и при лагах видно, как отрисовываются
> подземелья за км от игрока), так что там есть куда оптимизировать и улучшать
Всем пофиг, тот же бедрок, переписанный на плюсах куда как оптимальнее, но народ играет в Java edition.