Оптимізація сітки для ландшафтів куб вокселів

Граючи навколо, створюючи ландшафти світу Minecraftish / Lego в Unity 3D (процедурно генеровані воксельні пейзажі з кубиками), я знаходжу, що сітки, створені для цих пейзажів, займають багато пам’яті. Наразі сітка складається лише з вершин для видимих сторін куба. Використання пам'яті для складної місцевості може зайняти 6 або 7 сотень мегів.

Ці сітки можна оптимізувати, але я намагаюся знайти гідний алгоритм для цього.

Алгоритм повинен враховувати, що ви не хочете "зливати" блоки, що мають різні типи місцевості. Я думаю, що дійсно простим початком може бути просто обробити всі блоки вздовж однієї осі, і зробити додаткові зачистки для двох інших осей.

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

Будь-які думки / пропозиції / поради щодо цього?

3d-meshes optimization voxels

— Джеймс Лівінгстон
джерело

Чому ви зберігаєте вершини для куба відомого розміру? Робіть це алгоритмічно; або використовувати загальний буфер вершин.

— deceleratedcaviar

Чому багатокутна сітка? Воксель можна виводити досить ефективно, як і вони . Для одного куба вокселя вам потрібно 3 поплавця (x, y, z), для 1 поля вам потрібно близько 8 * 3 поплавків (8 вершин), і якщо у вас є неявні ребра та багатокутники. Можливо, Unity не є інструментом для цієї проблеми з вокселями.

— користувач712092

Відповіді:

Моє запитання:

Навіщо тобі потрібна сама сітка для руху істот?

Ви не можете зробити обчислення шляху на 3d-матриці ідентифікаторів?

Я думаю, що Minecraft використовує 3d-матрицю з 4-бітним блоком PR. Він також лише імітує істот певного радіусу навколо гравця.

Ви можете зберігати ваші шматки в структурі дерева дерев, де кожен шматок стискається.

Якщо ви зберігаєте стислі дані в оперативній пам’яті, ви можете декомпресувати дані досить швидко, коли це потрібно.

alt текст

— Найлер
джерело

Я покладався на те, що у мене є сітка для вбудованого виявлення зіткнень з Unity, але ніщо не заважає мені просто тестувати зіткнення / контур проти користувацької структури даних. Однак мені ще потрібно створити видиму сітку для відображення місцевості, і це те, що мені потрібно для оптимізації.

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

Ще один момент ... як ви можете бачити на скріншоті ... Є не вся ця територія, яка рівна. Сітки - це як правило шорсткі поверхні кубів, але я думаю, що є місце для оптимізації граней / вершин сітки. Здається, що октрис буде найкращим для даних, які мають багато подібних блоків даних, а не "тужливих" даних. Або це не правильно?

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

@Gatorfrog: Пам'ятайте, що порожній простір теж є даними. якщо він нерівний, то впевнений, буде багато бітів, що сигналізують про його порожнє. Октрис саме для вас, щоб зрозуміти, які шматки слід розпакувати, перш ніж їх робити. Порожній простір буде просто купою нулів. Моя щоденна робота передбачає роботу з дуже складною бібліотекою візуалізації вокселів. У моєму наступному дописі буде описано, чим вони займаються.

— Nailer

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

— Nailer

всі дані надсилаються у стислому вигляді з оперативної пам'яті до VRAM, де вони завищені алгоритмами стиснення GPGPU, що працюють у CUDA. Це економить багато пам’яті пропускної здатності. Отже: Перевірте, де знаходиться гравець, і отримайте там високий рівень деталізації, речі, що знаходяться на відстані, можна легко візуалізувати за допомогою одного з нижніх LOD.

— Nailer

Як щодо використання octree для зберігання місцевості?

Наприклад повітря = немає вузла, усі інші типи місцевості мали б вузол із типом місцевості.

Вставляючи / видаляючи вузли, ви можете перевірити, чи всі вісім дітей кожного вузла на модифікованому траєкторії дерева мають однаковий тип тераїну та об'єднати їх у разі потреби. Таким чином, великі блоки з одного матеріалу займуть лише один вузол.

— Екзиліт
джерело

Ви створюєте лише кубики для частин геометрії, яку може бачити гравець? Це був би мій перший крок. Залежно від розміру вашої місцевості вам не доведеться завантажувати весь світ / малювати / видно / будь-що.

— Тетрад
джерело

Я створюю сітку лише для сторін кубів, які мають порожнє повітря поруч. Що стосується того, щоб не малювати сітки, які гравець не може бачити ... Я думав про виключення будь-яких шматочків, у яких не було видимих блоків, таких як підземні печери або отвори, які вели під кутом землю. Я, безумовно, не міг би покластися на свої сітки для зіткнення / проходження в той момент.

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