Оптимизация сетки для воксельных кубов

Играя с созданием пейзажей Minecraftish / Lego World в Unity 3D (процедурно генерируемые воксельные ландшафты с кубами), я обнаружил, что сетки, созданные для этих ландшафтов, занимают много памяти. Сетка в настоящее время состоит только из вершин для видимых сторон куба. Использование памяти для сложной местности может занять 6 или 7 сотен мегабайт.

Эти сетки можно оптимизировать, но я изо всех сил пытаюсь найти достойный алгоритм для этого.

Алгоритм должен учитывать, что вы не хотите «объединять» блоки разных типов местности. Я полагаю, что действительно простым началом было бы просто обработать все блоки вдоль одной оси и выполнить дополнительные развертки для двух других осей.

Мне нужно сохранить форму сетки, чтобы не было слияния вершин до такой степени, что меняется пустое или сплошное пространство. Причина в том, что могут быть существа / и т.д., которые все еще должны перемещаться по мешу. Так что я не могу просто создать очень низкую детализацию, искаженную сетку.

Любые мысли / предложения / советы по этому поводу?

3d-meshes optimization voxels

— Джеймс Ливингстон
источник

Почему вы храните вершины для куба известного размера? Делайте это алгоритмически; или используйте общий буфер вершин.

— замедленная

Почему полигональная сетка? Voxel может быть воспроизведен довольно эффективно, как они . Для одного воксельного куба Вам понадобится 3 поплавка (x, y, z), для 1 блока Вам потребуется около 8 * 3 поплавков (8 вершин), и это в случае, если у вас есть неявные ребра и многоугольники. Возможно, Unity не является инструментом для решения этой проблемы с вокселями.

— user712092

Ответы:

Мой вопрос:

Зачем вам нужен сам меш для перемещения существ?

Разве вы не можете рассчитать пути на трехмерной матрице идентификаторов?

Я думаю, что Minecraft использует 3d-матрицу с 4-битным pr-блоком. Это также только симулирует существ определенного радиуса вокруг игрока.

Вы можете хранить свои чанки в структуре oc-дерева, где каждый чанк сжимается.

Если вы храните сжатые данные в оперативной памяти, вы можете распаковать данные довольно быстро, когда это необходимо.

альтернативный текст

— гвоздильщик
источник

Я полагался на наличие сетки для встроенного обнаружения столкновений с Unity, но ничто не мешает мне просто протестировать столкновение / путь на основе пользовательской структуры данных. Однако мне все еще нужно создать видимую сетку для отображения ландшафта, и это то, что мне нужно оптимизировать.

— Джеймс Ливингстон

Еще один момент ... как вы можете видеть на скриншоте ... не так уж много плоского ландшафта. Сетки, как правило, являются шероховатыми поверхностями кубов, но я думаю, что есть место для оптимизации граней / вершин сетки. Кажется, что октре было бы лучше для данных, которые имеют много одинаковых блоков данных, а не "неровных" данных. Или это не правильно?

— Джеймс Ливингстон

@Gatorfrog: Помните, пустое пространство - это тоже данные. если он зазубренный, то, конечно, будет много битов, сигнализирующих о его пустоте. Октри как раз для вас, чтобы выяснить, какие куски вы должны распаковать, прежде чем рендерить их. Пустое пространство будет просто кучкой нулей. Мой рабочий день включает в себя работу с очень сложной библиотекой рендеринга вокселей. Мой следующий пост опишет, что они делают.

— Нейлер

Библиотека, с которой я работаю, делает следующее: Создает куски данных и сохраняет их в базе данных плоских файлов. У каждого куска есть идентификатор. Каждый куб состоит из множества кусков. Для каждого чанка создается определенное количество уровней детализации. Там, где наивысший уровень детализации имеет 100% вокселей, второй наивысший уровень имеет 25% всех вокселей, а затем делит на 4 все для каждого последующего уровня. Куски, которые находятся рядом с вами, можно визуализировать, используя самый высокий уровень детализации.

— Нейлер

все данные отправляются в сжатом виде из ОЗУ в VRAM, где они раздуваются алгоритмами сжатия GPGPU, работающими в CUDA. Это экономит много памяти при использовании. Итак: проверь, где находится игрок, и получи там высокий уровень детализации, самые отдаленные вещи можно легко визуализировать с помощью одного из более низких LOD.

— Нейлер

Как насчет использования октодерева для хранения ландшафта?

Например, air = no node, у всех других типов местности будет узел с типом местности.

При вставке / удалении узлов вы можете проверить, имеют ли все восемь дочерних узлов каждого узла в измененном пути дерева один и тот же тип terain, и объединить их при необходимости. Таким образом, большие блоки из одного материала будут занимать только один узел.

— Exilyth
источник

Вы создаете кубы только для тех частей геометрии, которые видит игрок? Это был бы мой первый шаг. В зависимости от размера вашей местности вам не нужно загружать весь мир / рисовать / видеть / что угодно.

— тетрада
источник

Я создаю сетку только для сторон кубов, у которых есть пустой воздух рядом с ними. Что касается не рисования мешей, которые игрок не может видеть ... Я думал об исключении любых кусков, которые не имели видимых блоков, таких как подземные пещеры или отверстия, которые вели в землю под углом. Однако я определенно не смогу полагаться на свои сетки для столкновения / прохождения пути.

— Джеймс Ливингстон