Лучший метод CLOD для рендеринга планет

Question

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

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

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

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

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

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

PD: Извините за мой английский.

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

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

Answer 1

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

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

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

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

1. Continous Distance-Dependent LOD (CDLOD)
2. GPU Based Geomety Clipmaps (GPUGCM)
3. Chunked LOD
4. Rendering Terrains с OpenGL GPU тесселяции (Book: OpenGL Insight, глава 10)
5. Geometrical MipMapping

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

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

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

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

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

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

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

Проблема:

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

  Лучшим решением для этого является использование «Оказание относительно глаз с использованием метода GPU». Этот метод описан в книге «3D Engine Дизайн для виртуальных глобусов» (я уверен, вы можете найти его в Интернете aswell), где в основном вы должны установить все свои позиции с помощью удвоений на CPU (исправления, клики , объекты, фруст, камера и т. д.) , а затем MV центрируется вокруг зрителя, установив его перевод в (0, 0, 0) T и удваивает кодирование в виде фиксированной точки с использованием доли (мантиссы) бит двух поплавков, низкий и высокий по некоторому методу (читайте об использовании реализации 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 this link.

Для полной демонстрации о сферической проверке куба this link.

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

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