Лучший метод CLOD для рендеринга планет
В настоящее время я работаю над своей диссертацией, это движок для рендеринга местности планетарного размера.
Я все еще заканчиваю свое исследование, и я столкнулся со многими вещами на эту тему, проблема в том, что я не могу выбрать, какой метод LOD мне следует использовать.
Я знаю о геомип-картографии, геометрических клип-картах (GPU) и фрагментах LOD Ульриха, которые хорошо работают на больших территориях и могут использоваться для визуализации 6 граней куба, а затем «сферифицировать» куб с помощью Этот метод и я понимаю, как реализовать все эти методы на GPU с использованием C ++ / OpenGL / GLSL (использование таких методов, как ROAM или любой другой метод, не использующий куб, вне моей досягаемости, поскольку текстурирование — это боль).
Итак, у меня нет времени на реализацию ВСЕХ методов и вижу, какой из них является лучшим и более подходящим для планетарного масштаба, и я спрашиваю здесь, чтобы посмотреть, проводил ли кто-то такое сравнение, и помогите мне выбрать, какой метод я должен реализовать и использовать (мой репетитор немного сумасшедший и хочет, чтобы я что-то делал с икосаэдром, но я не могу понять этот метод, если не использую ROAM)
В любом случае, если вы можете помочь мне решить или у вас есть какие-либо другие предложения или метод, я действительно буду признателен. Одним из условий является то, что метод должен иметь возможность реализовать сторону графического процессора (по крайней мере, большую ее часть), чтобы предотвратить узкое место процессора.
Другая просьба состоит в том, чтобы я знал, что есть числовые проблемы с точностью с поплавками, когда я получаю много деталей на местности, я не знаю, как ее решить, я читаю решение на форуме, но не могу понять, как Внедрение, я потерял след этого потока, и я хотел бы знать, как решить эту проблему точности.
PD: Извините за мой английский.
[РЕДАКТИРОВАТЬ] В настоящее время я читаю о некоторых матричных преобразованиях для решения точности с плавающей точкой, проблем z-борьбы, отбраковки фруструма с динамическими значениями z и представления данных для кусков (используя пространство патчей с плавающими и его положение в мировых координатах как двойной) так что я думаю, что я могу легко решить проблему точности. Мне все еще нужно сравнение методов LOD с вашими мнениями и предложениями, чтобы решить, что лучше для этого проекта. Примите во внимание сложность реализации в сравнении с визуальным качеством и производительностью, я хочу лучшего.Что-то, что я забыл упомянуть, это то, что поколение является гибридным, я имею в виду, что я должен быть в состоянии полностью отобразить планету, используя GPU (высоты, рассчитанные на лету) и / или используя базовую карту высот и добавить детали с помощью GPU (вершинный шейдер) , Текстурирование будет боковой частью, я буду беспокоиться о последнем, сейчас я счастлив использовать только цвета в зависимости от высоты или, возможно, использовать какую-то текстуру шума, генерируемую фрагментным шейдером.
Решение
Наконец, после долгих исследований я могу заключить, что, как кто-то сказал ранее, не существует универсально «лучшего» метода. Но мои исследования привели меня к знанию следующих вещей:
В зависимости от сетки вы, наконец, будете использовать:
- Сферированный куб: любой метод LOD с реализацией quadtree будет работать просто отлично, вам просто нужно позаботиться о специальных случаях, таких как границы между гранями, в этом случае ваше quadtree должно иметь указатель на соседа на смежной грани на каждом уровне.
- Любой другой: Я думаю, что ROAM (более новая версия 2.0 или любое другое расширение, такое как BDAM, CABTT или RUSTIC) преуспеет, однако эти алгоритмы сложны в работе, требуют больше памяти и немного медленнее, чем другие подходы с кубами.
Есть много методов LOD, которые хорошо подходят, но моя личная пятерка:
- Непрерывный зависимый от расстояния LOD (CDLOD)
- Geomety Clipmaps на основе графического процессора (GPUGCM)
- Ломаный LOD
- Рендеринг ландшафтов с помощью тесселяции OpenGL GPU (Книга: OpenGL Insight, глава 10)
- Геометрический MipMapping
Каждый из них предлагает уникальный способ рендеринга ландшафта, например, CDLOD имеет очень простую реализацию с использованием шейдеров (GLSL или HLSL), но также может быть реализован на ЦП (для устаревшего оборудования), однако цель рендеринга планет — взорвать лучше всего подходит для современных графических процессоров, поэтому лучше всего использовать GPUGCM, если вы хотите сжать свой графический процессор. Они оба очень хорошо работают с рендерингом больших ландшафтов, основанным на данных, процедурным или смешанным (рельеф местности на основе фиксированных данных или карт высот и детализация, добавленная с процедурной работой).
Также существует сферическое расширение базового метода Geometrical Clipmaps, но есть некоторые проблемы, потому что плоские выборки карты высот должны быть параметризованы с использованием сферических координат.
Chunked LOD, с другой стороны, идеально подходит для устаревшего оборудования, не требует каких-либо вычислений на стороне GPU, идеально подходит для больших наборов данных, но не может обрабатывать процедурные данные в режиме реального времени (возможно, с некоторыми модификациями, это может)
Использование тесселяционных шейдеров — это еще один метод, очень новый, поскольку вышел OpenGL 4.x, на мой взгляд, он мог бы быть лучшим, но, говоря о рендеринге планет, мы сталкиваемся с проблемой, с которой другие методы могут справиться очень легко, и это о точности.
Если вы не хотите, чтобы ваша точность составляла 1 км между вершинами, используйте шейдеры тесселяции. Проблема с очень большими участками этого метода в том, что джиттер довольно трудно решить (или, по крайней мере, для меня, так как я новичок в тесселяционных шейдерах).
Geomipmapping — это отличный метод, использующий преимущества квадродерева и имеющий низкую ошибку проецируемого пикселя, но для планетарного рендеринга вам потребуется установить не менее 16+ уровней детализации, что означает, что вам понадобятся (для сшивания точек) некоторые дополнительные патчи чтобы соединить разные уровни и позаботиться об уровне вашего соседа, это может быть утомительно, особенно при использовании 6 граней местности.
Есть еще один метод, очень особенный в своем роде: «Проективное сеточное картирование для планетарной местности» отлично подходит для визуализации, но имеет свои недостатки, если вы хотите узнать больше, перейдите по ссылке.
Проблемы:
-
дрожание: Большинство современных графических процессоров поддерживают только 32-битные значения с плавающей точкой, которые
не обеспечивает достаточной точности для манипулирования большими позициями на местности планетарного масштаба. Дрожание происходит, когда зритель увеличивает и вращает или перемещает, тогда многоугольники начинают подпрыгивать назад и вперед.Лучшее решение для этого — использовать «Рендеринг по отношению к использованию глаз».
«GPU». Этот метод описан в книге «3D Engine
Дизайн для виртуальных глобусов «(я уверен, что вы можете найти его в Интернете
а также) где в основном вы должны установить все свои позиции с
удваивается на процессоре (патчи, клипы, объекты, frustrum, камера и т. д.)
а затем MV центрируется вокруг зрителя, устанавливая его перевод
в (0, 0, 0) T и двойники кодируются в фиксированной точке
представление с использованием дробных (мантиссовых) битов двух чисел с плавающей запятой
и высокий по некоторому методу (читайте об использовании реализации Ohlarik
и библиотека Фортрана DSFUN90).Хотя вершинный шейдер требует только двух дополнительных
вычитания и одно сложение, GPU 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-буфера, проверьте эта книга.
Я надеюсь, что вы найдете этот небольшой обзор полезным.
Другие решения
Других решений пока нет …