Який найкращий метод LOD для візуалізації планети?

Зараз я працюю над своєю дисертацією, це двигун для надання рельєфу планетарного розміру.

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

Я знаю про геомістмапинг, геометричні кліппи (GPU) та лондонний LOD від Ульріха, які добре працюють на великих місцевостях і можуть бути використані для надання 6 граней куба, а потім "сферифікації" куба цим методом, і я розумію, як реалізувати всі ці методи на графічному процесорі з використанням C ++ / OpenGL / GLSL (використання таких методів, як ROAM або будь-який інший метод, який не використовує куб, недоступний, оскільки текстурування - це біль). Також нещодавно я потрапив у підручник з рендерингу місцевості, використовуючи тут шейдери для теселяції

Отже, я не маю часу впроваджувати ВСІ методи та бачити, який із них найкращий і підходящий для планетарного масштабу, і я прошу тут, щоб перевірити, чи хтось зробив подібне порівняння, і допомогти мені вирішити, який метод я повинен реалізовувати та використовувати (мій репетитор є божевільним і хоче, щоб я зробив щось із ікосаедра, але я не можу зрозуміти цей метод, якщо не використовувати ROAM)

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

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

В даний час я читаю про деякі перетворення матриці для вирішення точності поплавця, проблем боротьби з z, боротьби з відхиленням фрустуму з динамічними z-значеннями та подання даних для фрагментів (використовуючи пробіл патча з поплавками та його положення у світових координатах як подвійне), так Я думаю, що я можу легко вирішити проблему точності. Мені все ж потрібне порівняння методів LOD з вашими думками та пропозиціями, щоб вирішити, що краще для цього проекту. Враховуйте складність реалізації та якість візуалу проти продуктивності, я хочу найкращого.

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

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

Залежно від сітки ви нарешті будете використовувати:

• Сферифікований куб: будь-який метод LOD з реалізацією квадратури буде добре працювати, вам потрібно подбати про особливі випадки, такі як межі між обличчями; у такому випадку ваш квадратур повинен мати вказівник на сусіда на сусідньому обличчі на кожному рівні.
• Будь-який інший: я думаю, що ROAM (новіша версія 2.0 або будь-яке інше розширення, як BDAM, CABTT або RUSTIC) буде добре, проте ці алгоритми важко працювати, вимагають більше пам’яті та трохи повільніше, ніж інші підходи з кубами.

Існує багато методів LOD, які добре підходять, але мої особисті топ-5:

1. Безперервний LOD-залежний від відстані (CDLOD)
2. Геометичні кліпи на основі GPU (GPUGCM)
3. Чудовий ЛОД
4. Візуалізація місцевостей із тесселяцією GPU OpenGL (Книга: OpenGL Insight, Розділ 10)
5. Геометричне MipMapping

Кожен пропонує унікальний спосіб візуалізації рельєфу, наприклад, CDLOD має дуже просту реалізацію за допомогою шейдерів (GLSL або HLSL), але також може бути реалізований на процесорі (для застарілого обладнання), однак мета Планетного рендерінгу - вибухнути найкращий на сучасних графічних процесорах, тому GPUGCM - найкращий, коли ви хочете стиснути свій GPU. Вони обидва дуже добре працюють з даними, процедурними або змішаними (місцевість, заснована на фіксованих даних або мапах висот і деталей, доданих при процедурній роботі), надання великих територій.

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

З іншого боку, LODked LOD ідеально підходить для застарілого обладнання, для роботи не потрібні обчислення на стороні GPU, він ідеально підходить для великих наборів даних, але не може обробляти процедурні дані в режимі реального часу (можливо, з деякими модифікаціями, це може бути)

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

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

Geomipmapping - це чудова техніка, користується перевагою квадрату і має низьку прогнозовану помилку пікселів, але для планетарного візуалізації вам потрібно буде встановити принаймні 16+ рівнів деталей, це означає, що вам знадобиться (для зшивання залишків) кілька додаткових патчів щоб підключити різні рівні та подбати про рівень свого сусіда, це може бути нудно вирішити, особливо з використанням 6 облич місцевості.

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

Проблеми:

• Джиттер : Більшість сучасних графічних процесорів підтримують лише 32-бітні значення з плаваючою комою, що не забезпечує достатньої точності для маніпулювання великими положеннями в планетарних масштабах. Тремтіння виникає, коли глядач збільшує масштаб і обертається або переміщується, тоді багатокутники починають підстрибувати вперед і назад.

  Найкращим рішенням для цього є використання методу "Візуалізація відносно очей за допомогою GPU". Цей метод описаний у книзі "3D Engine Engine for Virtual Globes" (я впевнений, що ви можете знайти його в Інтернеті), де в основному вам потрібно встановити всі свої позиції з подвійними процесорами (патчі, кліпи, об'єкти, frustrum, камера тощо), а потім MV зосереджується навколо глядача, встановлюючи його переклад на (0, 0, 0) T, а парні кодуються у фіксованому зображенні, використовуючи дроби фракції (mantissa) двох поплавків, низький і високий деяким методом (читайте про Використання реалізації Ohlarik та бібліотеку DSFUN90 Fortran).

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

• Точність буферної глибини : боротьба з Z. Оскільки ми рендеруємо дуже великі рельєфи, у цьому випадку: планети, Z-буфер повинен бути ВЕЛИЧЕЗНИМ, але це не має значення для тих значень, які ви встановили для znear та zfar, завжди будуть проблеми.

  Оскільки Z-буфер залежить від інтервалу поплавкової точки, а також він є лінійним (хоча перспективна проекція є нелінійним), величини біля очей страждають від Z-бою, оскільки недостатня точність 32-бітових поплавців є.

  Найкращий спосіб вирішити цю проблему - використовувати "логарифмічний глибинний буфер" http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

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

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

На закінчення просто перевірте всі наявні варіанти та перейдіть до того, кому ви відчуваєте себе більш комфортно, на мою думку CDLOD робить чудову роботу. Не забудьте вирішити проблеми з тремтінням та Z-буфером, а найголовніше: отримуйте задоволення, роблячи це!

Для отримання додаткової інформації про LOD перевірте це посилання .

Для повної демонстрації щодо сферифікації куба перевірте це посилання .

Для кращого пояснення розв язання тремтіння та Z-Buffer, перевірте цю книгу .

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