Редагувати: Це лише для мого власного досвіду навчання, я не задаю це питання.
Це стосується місцевого двигуна, подібного до Minecraft. Я зберігаю блоки в шматках (16x256x16 блоків в шматку). Коли я генерую шматок, я використовую кілька процедурних прийомів для встановлення місцевості та розміщення предметів. Під час генерації я зберігаю один 1D масив для повного блоку (суцільного чи ні) та окремого 1D масиву суцільних блоків.
Після покоління я повторюю суцільні блоки, перевіряючи своїх сусідів, тому генерую лише обличчя блоків, у яких немає суцільних сусідів. Я зберігаю, які обличчя потрібно генерувати у своєму власному списку (це 6 списків, один на можливе обличчя / нормальний). Під час візуалізації фрагменту я рендую всі списки в поточному відрізку камери та лише списки, спрямовані до камери, у всіх інших фрагментах. Я роблю це, зберігаючи всі 6 списків в одному буфері, після чого я просто змінюю діапазони, які малюю.
Використовуючи 2D атлас з цим маленьким шейдерним трюком, який запропонував Ендрю Рассел, я хочу повністю об'єднати подібні обличчя разом. Тобто, якщо вони знаходяться в одному списку (однаковий звичайний), примикають один до одного, мають однаковий рівень освітлення і т. Д. Я знаю, що все одно закінчусь прямокутниками, але це може легко зменшити кількість вершин на 50% або краще, якщо мої оцінки правильні.
Моє припущення полягає в тому, щоб кожен з 6 списків був відсортований за віссю, на якій вони опираються, а потім за іншими двома осями (список у верхній частині блоку буде відсортований за значенням Y, потім X, Z).
Тільки за допомогою цього я міг би досить легко об'єднати смужки обличчя, але я прагну об'єднати більше, ніж просто смужки разом, коли це можливо. Я читав цей жадібний алгоритм обміну повідомленнями, але у мене виникають багато проблем з його розумінням.
Отже, моє запитання: виконувати злиття граней, як описано (ігноруючи, чи це погана ідея для динамічного рельєфу / освітлення), чи є, можливо, алгоритм, який простіше реалізувати? Я б також із задоволенням прийняв відповідь, яка розглядає мене через жадібний алгоритм набагато простішим способом (посилання чи пояснення).
Я не проти незначного зниження продуктивності, якщо це легше здійснити або навіть якщо це лише трохи краще, ніж просто робити смужки. Я хвилююся, що більшість алгоритмів зосереджуються на трикутниках, а не на квадратиках та використовують 2D атлас таким, яким я є, я не знаю, що я міг би реалізувати щось трикутник на основі моїх нинішніх навичок.
PS: Я вже збиваю зріст за шматок, і як описано, я також зрізую обличчя між суцільними блоками. Я ще не оклюзію, і ніколи.
* Редагувати: Я реалізував свою власну маленьку техніку, яка, ймовірно, має назву, але я просто проходжу свої 6 списків, відсортованих за осями, на яких вони опираються, за типом блоку, а потім за рівнем освітлення. Я повторюю їх, створюючи нові прямокутники, коли я йду, і вирощую їх одночасно (з великим ухилом до певної осі). Це, безумовно, не є оптимальним, але він дуже швидкий, і це знижує кількість вершин у середньому на 50%. Коментар Byte56 - це шафа, яку я вважаю справжньою відповіддю, але я не можу вибрати її для відповіді / щедрості.
Ось мій швидкий і спрощений спосіб вирішення цієї проблеми ПІСЛЯ генерування повного початкового рельєфу без особливої оптимізації. Якщо припустити, що всі задані квадрати - це одне і те ж зображення, рівень освітлення, нормальний тощо. Кожен колір - це інший квадратик, який я б представляв. З моїми списками, відсортованими таким чином, як вони є, це дуже простий / швидкий підхід.
