Що для рендерингу вокселів, що ефективніше: попередньо виготовлений VBO або шейдер для геометрії?

Враховуючи досить статичний масив вокселів, що є більш ефективним: використання процесора для попереднього генерування VBO для візуалізації облич вокселя (ігнорування на сьогодні більш досконалих форм візуалізації, як маршируючих кубів) або використання шейдера геометрії на графічному процесорі для створення обличчя на льоту?

Я не так переживаю за оновлення зміни вокселів, але, звичайно, це є перевагою версії GPU, оскільки вам не доведеться перебудовувати VBO. Крім того, підхід GS відчуває себе трохи сучаснішим :)

З іншого боку, я не розглядав деталі того, як GS насправді працює з конвеєром растерізації в сучасних графічних процесорах. Чи виводить вершини в якийсь кеш-потік або вершини записуються в звичайну пам'ять GPU? Якщо це останнє, то на ходу генерування може зменшити доступну пропускну здатність і потужність обробки від решти завдань GPU, я думаю, і тоді було б вигідніше це робити на процесорі ..

Я думаю про сцену типу Minecraft, де під вокселем ви маєте на увазі світ блоків, які насправді відображаються за допомогою полігонів:

Якщо ви використовуєте шейдер для геометрії, буде важко уникнути наявності рівно трьох граней (або будь-яких) на воксель.

Якщо у вас є багато сусідніх блоків, що мають однакову текстуру, тоді ви можете використовувати плитку текстур, щоб у вашій (виродженій) смужці було набагато менше трикутників у підході VBO. Я маю на увазі, якщо є хороша велика плоска 6x6 трав'яних вокселів, ви можете намалювати всю вершину всього в 2 трикутники, а не в 64.

Із підходом GS ви не можете здійснити тривіальне відсікання облич, заткнутих суміжними вокселями, що дуже прямо і при підході VBO.

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

Я використав окремі VBO для кожної з 6 граней - вам потрібно коли-небудь намалювати максимум 3 з них, очевидно. Це добре поєднується з різними текстурами, які зазвичай використовуються у верхній частині вокселів у стилі minecraft. Тому що для кожного набору нормальне і таке тоді є рівномірним.

Використовуючи вертикально викладені пікселі в атласі з GL_REPEATгоризонтальною віссю та маючи повернені на 90 градусів версії пікселів у тому ж атласі, я виявив, що я можу намалювати величезну кількість очевидно різних блоків, використовуючи один і той же VBO в одному дзвінку. У прикладі трави 6х6 я розділив би її на 12 трикутників, оскільки я повторюю лише один вимір у своєму атласі.

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

Що з третім варіантом, використовуючи вбудовані масиви? В основному ви малюєте безліч полів (виготовлених з простого 8-вершинного куба) за допомогою одного виклику малювання, пошуку позицій (та інших даних) як атрибутів на примірник з VBO-даних Voxel (використовуючи glVertexAttribDivisorOpenGL, я впевнений У DX теж є). Це може бути швидше, ніж підхід до геодезичного шейдера, хоча код програми (не шейдер) повинен бути досить схожим, оскільки я пам’ятаю, що шейдери з геометрії мають репутацію повільності, хоча я не маю досвіду роботи з ними (або з інстанцією), оскільки я все ще сиджу на обладнання 2.1.

Але в будь-якому випадку, або шейдери геометрії, або вбудовані масиви повинні більше підходити, ніж вбудована процесором геометрія вокселів, особливо коли дані вокселів можуть змінюватися. У поєднанні з зворотним зв'язком трансформації (вихідний потік у DX?) Ви можете встановити добру техніку відсікання на основі GPU.

Версія шейдера з геометрії для мене звучить набагато краще. Ви можете мати лише точку vbo та сконструювати поле на льоту (точка введення, вихідний трикутник потоку). Це буде швидко (навіть швидше, якщо ви будете використовувати блок tessellation в шейдері моделі 5 екв. DX11) і зменшите пропускну здатність надзвичайно, це буде приємним і чистим рішенням.

Про ГС. Він розміщується між вершинним шейдером та піксельним шейдером та модифікує потік вершини (примітивів). Хоча вершина шейдера працює лише на вершинах, шейдер геометрії працює на цілих примітивах. Вихід цього потоку спрямовується лише на піксельний шейдер (і він растеризується до цього поза курсом :)), і немає можливості його зберегти. (Можливо, за допомогою божевільного відтворення текстури, а потім її розбору ... але реальної простої можливості немає)

Примітка щодо продуктивності: Ви повинні мати можливість у всьому шадері геометрії та пропускати (просто передавати дані) вершинні шейдери. Але це не найкращий спосіб. Краще (швидше) - зробити більшість можливих перетворень на вершинній шейдері та спробувати мінімізувати програму шейдерів геометрії. Не бійтеся використовувати для циклу, якщо він вам знадобиться (наприклад, для створення коробки). Компілятор розкрутить його за вас.