Какой метод LOD является лучшим для рендеринга планет?

В настоящее время я работаю над своей диссертацией, это движок для рендеринга местности планетарного размера.

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

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

Итак, у меня нет времени, чтобы реализовать ВСЕ методы и посмотреть, какой из них является лучшим и более подходящим для планетарного масштаба, и я спрашиваю здесь, чтобы посмотреть, сделал ли кто-то такое сравнение и помочь мне решить, какой метод я должен реализовать и использовать (мой репетитор немного сумасшедший и хочет, чтобы я что-то делал с икосаэдром, но я не могу понять этот метод, если не использую ROAM)

В любом случае, если вы можете помочь мне решить или у вас есть какие-либо другие предложения или метод, я действительно буду благодарен. Одним из условий является то, что метод должен иметь возможность реализовать сторону графического процессора (по крайней мере, большую его часть), чтобы предотвратить узкое место процессора.

Другой запрос заключается в том, что я знаю, что существуют числовые проблемы с точностью с поплавками, когда я получаю много деталей на местности, я не знаю, как ее решить, я читаю решение на форуме, но не могу понять, как Внедрение, я потерял след этого потока, и я хотел бы знать, как решить эту проблему точности.

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

Что-то, что я забыл упомянуть, это то, что поколение является гибридным, я имею в виду, что я должен быть в состоянии полностью отобразить планету, используя GPU (высоты, рассчитанные на лету) и / или используя базовое изображение карты высот, и добавить детали с помощью GPU (вершина). шейдер). Текстурирование будет боковой частью, я буду беспокоиться о последнем, сейчас я рад использовать только цвета в зависимости от высоты или, возможно, использовать какую-то текстуру шума, генерируемую фрагментным шейдером.

Наконец, после долгих исследований я могу сделать вывод, что, как кто-то сказал ранее, не существует универсально «лучшего» метода. Но мои исследования привели меня к знанию следующих вещей:

В зависимости от сетки вы, наконец, будете использовать:

• Spherified Cube: любой метод LOD с реализацией квадродерева будет работать очень хорошо, вам просто нужно позаботиться о специальных случаях, таких как границы между гранями, в этом случае у вашего квадродерева должен быть указатель на соседа на смежной грани на каждом уровне.
• Любое другое: я думаю, что ROAM (более новая версия 2.0 или любое другое расширение, такое как BDAM, CABTT или RUSTIC) преуспеет, однако с этими алгоритмами сложно работать, они требуют больше памяти и немного медленнее, чем другие подходы с кубами.

Есть много методов LOD, которые хорошо подходят, но моя личная пятерка:

1. Непрерывный зависимый от расстояния LOD (CDLOD)
2. Geomety Clipmaps на основе графического процессора (GPUGCM)
3. Ломаный LOD
4. Рендеринг ландшафтов с помощью тесселяции OpenGL GPU (Книга: OpenGL Insight, глава 10)
5. Геометрический MipMapping

Каждый из них предлагает уникальный способ рендеринга ландшафта, например, CDLOD имеет очень простую реализацию с использованием шейдеров (GLSL или HLSL), но также может быть реализован на ЦП (для устаревшего оборудования), однако цель рендеринга планет - взорвать лучше всего подходит для современных графических процессоров, поэтому лучше всего использовать GPUGCM, если вы хотите сжать графический процессор. Они оба очень хорошо работают с основанным на данных, процедурным или смешанным (рельеф на основе фиксированных данных или карт высот и детали, добавленные с процедурной работой) рендеринга больших ландшафтов.

Также существует сферическое расширение базового метода Geometrical Clipmaps, но есть некоторые проблемы, потому что плоские выборки карты высот должны быть параметризованы с использованием сферических координат.

Chunked LOD, с другой стороны, идеально подходит для устаревшего оборудования, не требует каких-либо вычислений на стороне GPU, идеально подходит для больших наборов данных, но не может обрабатывать процедурные данные в режиме реального времени (возможно, с некоторыми модификациями, это может)

Использование шейдеров Tessellation - это еще один метод, очень новый, поскольку вышел OpenGL 4.x, на мой взгляд, он может быть лучшим, но, говоря о рендеринге планет, мы сталкиваемся с проблемой, с которой другие методы могут справиться очень легко, и это о точности.

Если вы не хотите, чтобы ваша точность составляла 1 км между вершинами, используйте шейдеры тесселяции. Проблема с очень большими участками этого метода в том, что джиттер довольно трудно решить (или, по крайней мере, для меня, так как я новичок в тесселяционных шейдерах).

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

Есть еще один метод, очень специфический в своем роде: «Projective Grid Mapping для Planetary Terrain» отлично подходит для визуализации, но имеет свои недостатки, если вы хотите узнать больше, перейдите по ссылке.

Проблемы:

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

  Лучшее решение для этого - использовать метод «Рендеринг по отношению к глазу с использованием графического процессора». Этот метод описан в книге «3D Engine Design for Virtual Globes» (я уверен, что вы также можете найти ее в Интернете), где в основном вам нужно установить все свои позиции с двойными значениями на CPU (патчи, клипы, объекты, frustrum, camera и т. д.), а затем MV центрируется вокруг зрителя, устанавливая его перевод в (0, 0, 0) T, и двойники кодируются в представлении с фиксированной точкой, используя биты дроби (мантиссы) двух чисел с плавающей запятой, низкий и высокий по некоторым методам (читайте об использовании реализации Ohlarik и библиотеке Fortran DSFUN90).

  Хотя вершинный шейдер требует только двух дополнительных вычитаний и одного сложения, графический процессор RTE удваивает объем памяти вершинного буфера, необходимый для позиций. Это не обязательно удваивает требования к памяти, если только не сохраняются только позиции.

• Точность буфера глубины : Z-бой. Так как мы рендерим очень большие ландшафты, в данном случае: планеты, Z-буфер должен быть ОГРОМНЫМ, но не имеет значения, какие значения вы установили для znear и zfar, всегда будут проблемы.

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

  Лучший способ решить эту проблему - использовать «логарифмический буфер глубины» http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

  Логарифмический буфер глубины улучшает точность буфера глубины для удаленных объектов, используя логарифмическое распределение для zscreen. Он меняет точность для близких объектов на точность для удаленных объектов. Поскольку мы выполняем рендеринг методом LOD, для удаленных объектов требуется меньшая точность, поскольку у них меньше треугольников.

Важно отметить, что все перечисленные методы (за исключением проективной сетки) очень хороши при выполнении физики (в основном, столкновений) благодаря базе Quadtree, что является обязательным условием, если вы планируете создать игру.

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

Для получения дополнительной информации о LOD проверьте эту ссылку .

Для полной демонстрации о сферизации куба проверьте эту ссылку .

Для более подробного объяснения решения проблем дрожания и точности Z-буфера, обратитесь к этой книге .

Я надеюсь, что вы найдете этот небольшой обзор полезным.