Збереження вокселів для воксельних двигунів в C ++

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

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

Отже, ще один варіант - просто створити масив розміром 16 * 16 * 16 і мати один фрагмент, і ви заповните його елементами. А частини, де немає жодних елементів, матимуть значення 0 (0 = повітря). Але я боюся, що це втратить багато пам’яті і не буде дуже швидким.

Потім ще один варіант - вектор для кожного шматка, і заповнити його кубиками. І куб утримує своє місце в шматку. Це економить пам'ять (немає повітряних блоків), але робить куб у певному місці набагато повільніше.

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

Але ще одна проблема - надання. Просто читати кожен фрагмент і надсилати його до GPU за допомогою OpenGL - це легко, але дуже повільно. Генерувати одну сітку за шматок було б краще, але це означає, що кожного разу, коли я перериваю один блок, я повинен будувати весь шматок, який може зайняти трохи часу, викликаючи незначну, але помітну гикавку, якої я, очевидно, теж не хочу. Так що було б важче. То як би я видавав кубики? Просто створіть усі кубики в одному вершинному буфері за шматок і зробіть це, а може, спробуйте вкласти це в інший потік, чи є інший спосіб?

Дякую!

Збереження блоків як позицій та значень насправді дуже неефективно. Навіть не маючи накладних витрат, спричинених структурою або об'єктом, який ви використовуєте, вам потрібно зберігати 4 різних значення на блок. Використовувати його було б лише за методом "зберігання блоків у фіксованих масивах" (той, який ви описали раніше), коли лише чверть блоків є твердими, і таким чином ви навіть не використовуєте жодних інших методів оптимізації. рахунок.

Octrees насправді чудово підходить для ігор на основі вокселів, оскільки вони спеціалізуються на зберіганні даних із більшими можливостями (наприклад, патчі одного блоку). Щоб проілюструвати це, я використав квадрат (в основному октриси в 2d):

Це мій стартовий набір, що містить плитки 32х32, що б дорівнювало 1024 значень:

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

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

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

Червоні лінії позначають те, що ми зберігаємо. Кожен квадрат - це лише 1 значення. Це зменшило розмір з 1024 значень до 439, це на 57%.

Але ви знаєте мантру . Пройдемо ще крок далі і згрупуємо їх у комірки:

Це зменшило кількість збережених значень до 367. Це лише 36% від початкового розміру.

Вам, очевидно, потрібно зробити цей поділ, поки кожна 4 сусідня клітина (8 сусідніх блоків у 3d) всередині шматка не зберігається всередині однієї комірки, по суті перетворюючи шматок в одну велику клітинку.

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

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

Той факт, що ваші вокселі однакового розміру, означає лише, що ваша октарія має фіксовану глибину. напр. для шматка 16х16х16 вам потрібно щонайбільше 5 рівнів дерева:

• корінь шматка (16x16x16)
  • октант першого рівня (8x8x8)
    • октант другого рівня (4x4x4)
      • октант третього рівня (2x2x2)
        • один воксель (1x1x1)

Це означає, що у вас є щонайбільше 5 кроків, щоб дізнатися, чи є в певному положенні воксель:

• корінь шматка: чи є цілий шматок однакового значення (наприклад, все повітря)? Якщо так, ми закінчили. Якщо ні...
  • перший рівень: чи все одно значення має октант, який містить цю позицію? Якщо ні...
    • другий рівень ...
      • третій рівень ...
        • тепер ми звертаємось до одного вокселю і можемо повернути його значення.

Набагато коротше, ніж сканувати навіть 1% шляху через масив до 4096 вокселів!

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

Для звернення до дітей шматка, як правило, ми будемо діяти в порядку Мортона , приблизно так:

1. X- Y- Z-
2. X- Y- Z +
3. X- Y + Z-
4. X- Y + Z +
5. X + Y- Z-
6. X + Y- Z +
7. X + Y + Z-
8. X + Y + Z +

Отже, наша навігація по вузлу Octree може виглядати приблизно так:

GetOctreeValue(OctreeNode node, int depth, int3 nodeOrigin, int3 queryPoint) {
    if(node.IsAllOneValue)
        return node.Value;

    int childIndex =  0;
    childIndex += (queryPoint.x > nodeOrigin.x) ? 4 : 0;
    childIndex += (queryPoint.y > nodeOrigin.y) ? 2 : 0;
    childIndex += (queryPoint.z > nodeOrigin.z) ? 1 : 0;

    OctreeNode child = node.GetChild(childIndex);

    return GetOctreeValue(
                child, 
                depth + 1,
                nodeOrigin + childOffset[depth, childIndex],
                queryPoint
    );
}