1: Я не можу зрозуміти, в який момент вниз по трубопроводу Chunked LOD сітка розбивається на шматки. Це під час початкової генерації сітки, чи існує окремий алгоритм, який це робить.
Це не має значення. Наприклад, ви можете інтегрувати фрагменти в алгоритм генерації сітки. Ви можете навіть робити це динамічно, щоб нижчі рівні динамічно додавалися (наприклад, у міру наближення гравця) за допомогою плазмового алгоритму уточнення. Ви також можете генерувати сітку з високою роздільною здатністю з даних вимірювання введення виконавця або висоти та об’єднувати їх у всі фрагменти LOD під час завершення активу. Або ви можете змішувати і відповідати. Це дійсно залежить від вашої заявки.
2: Я розумію, що структура даних Quadtree використовується для зберігання даних Chunked LOD, я думаю, що мені трохи не вистачає точки, але чи є квадратне збереження даних вершин та трикутників для кожного рівня підрозділу?
Не обов'язково. Дерево просто зберігає інформацію про геометрію та способи її надання. Це може означати наявність списку вершин / облич у кожному вузлі дерева. Більш реально в цей день і вік ви зберігаєте ручки сіток / екземплярів у пам'яті GPU.
3а: Як зазвичай обчислюється відстань до камери Читаючи про квадрати, багато згаданих обмежувальних коробок по осі. У цьому випадку кожен шматок має коробку, що обмежує зіткнення, щоб виявити камеру чи програвач поблизу? чи є кращий спосіб зробити це? (Можливо, радіація?)
Дуже дешевим і простим варіантом є використання відстані до центральної точки шматка, а потім виправлення. Ви знаєте, що ця відстань - це завжди недооцінка: якщо центральна точка знаходиться на відстані Z, це означає, що половина шматка знаходиться ближче до цього. Що ми не знаємо, але це орієнтація. Якщо ми переглянемо шматок ширини, який знаходиться на wмежі ширини , найближчий шматочок буде знаходитися на відстані Z-w. Однак, якщо ми спочатку переглянемо кут, куди буде найближчий біт Z-sqrt(2)*w. Якщо ви можете жити з цією невизначеністю (ви майже завжди можете), ви закінчите. Зауважте, що ви також могли скоригувати кут огляду за допомогою основної тригонометрії.
Я вважаю за краще обчислити абсолютну мінімальну відстань від камери до шматка, щоб мінімізувати артефакти. На практиці це означає зробити тест на відстань у точці-квадраті . Це трохи більше роботи, ніж обчислення відстаней до центральних точок, але це не так, як ви будете робити мільйон з кожного кадру.
Якщо ви можете скористатися вашим фізичним двигуном, щоб це зробити, то всіма силами зробіть це, але ви дійсно хочете думати про це більше з точки зору "запиту на відстань", ніж "зіткнення".
3b: Чи шматки самі обчислюють відстань камери?
Це дійсно залежить від конструкції вашого двигуна. Я б рекомендував зберігати листя відносно невеликою вагою. Залежно від вашої платформи, лише накладні витрати на виклик з кількох тисяч ландшафтів місцевості виконують власне оновлення, кожен кадр може серйозно вплинути на продуктивність.
4: Чи має кожен шматок однакову "роздільну здатність". наприклад, на верхньому рівні сітка буде 32x32, чи буде кожний підрозділений вузол також 32x32.
Вони не повинні, але зручно, якщо всі шматки займають однакову кількість місця. Тоді ви можете виконувати управління (GPU) пам’яттю в одиницях «шматок». Так само простіше зняти / приховати шви між двома шматками різного розміру, якщо одна роздільна здатність кратна іншій, оскільки вони мають більше вершин. (наприклад: 32x32 та 64x64 простіше керувати, ніж 32x32 та 57x57) (спасибі Guiber!). Якщо у вас є вагомі підстави змінити розмір геометрії шматка, будь-ласка, займіться цим.
