Потоковая передача больших 3D-сцен

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

Данные представлены в виде огромного списка 3D-сетей без связи между ними, поэтому я не могу создавать порталы, я думаю...

Основная цель — иметь возможность запускать этот движок на системах с небольшим объемом оперативной памяти (500 МБ-1 ГБ), а загруженные в него сцены очень большие и могут содержать миллионы треугольников, что приводит к очень интенсивному использованию памяти. На самом деле я сейчас работаю со свободным октодеревом, построенным на загрузке, оно хорошо работает на небольших и средних сценах, но многие сцены просто слишком велики, чтобы полностью поместиться в памяти, поэтому вот мой вопрос:

Как бы вы обрабатывали сцены для динамической загрузки и выгрузки чанков (и в идеале плавно) и на чем бы вы основывались, чтобы определить, следует ли загружать/выгружать чанки? При необходимости я могу создать пользовательский формат файла, так как сцены экспортируются с помощью специального экспортера в известных инструментах разработки 3D.

Важная информация: Многие сцены не могут быть эффективно закрыты из-за их конструкции. Пример: очень большая сеть каналов, поэтому не так много окклюзии, но очень много элементов.


3d scene opengl octree
person ingham    schedule 13.09.2014    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Я думаю, что лучшим решением будет «пакет решений», набор различных техник.

  • Уровень детализации (LOD) может уменьшить объем памяти, если неиспользуемые уровни не загружены. Его можно изменить более или менее плавно, используя альфа-микс между старой и новой деталью. Самый простой контроллер будет использовать расстояние сетки до камеры.
  • Освобождение памяти хоста (ОЗУ), когда объект был загружен на графический процессор (устройство), и, очевидно, освобождение всей неиспользованной памяти (ресурсы OpenGL также). Valgrind может помочь вам с этим.
  • Используйте сетки низкого качества и используйте тесселяцию для повышения визуального качества.
  • Используйте индексирование VBO, это должно уменьшить использование VRAM и повысить производительность.
  • Не используйте меши, если это возможно, ландшафт можно визуализировать с помощью карт высот. Некоторые вещи можно сгенерировать процедурно.
  • Используйте бамп и/или карты нормалей. Это улучшит качество, а затем вы сможете уменьшить количество вершин.
  • Разделите эти «трубы» на разные сетки.
  • Поддельные 3D-сетки с 2D-изображениями: самозванцы, небесные купола...
person dv1729    schedule 18.09.2014

arrow_upward
0
arrow_downward

Если для текстур будет использоваться огромное количество оперативной памяти, доступны коммерческие пакеты, такие как GraniteSDK, которые предлагают бесшовную потоковую передачу текстур на основе LOD с использованием виртуального кэша текстур. См. http://graphinesoftware.com/granite. В качестве альтернативы вы можете посмотреть на http://ir-ltd.net/

На самом деле вы можете использовать ту же технику для создания полигонов на лету из текстурных данных в шейдере, но это будет немного сложнее.

Для вокселей есть методы построения октодеревьев полностью в памяти графического процессора и выгрузки/выгрузки тех частей, которые вам действительно нужны. Затем рендеринг может быть выполнен с использованием raycasting. См. этот пост: Используйте octree для организации трехмерных объемных данных в графическом процессоре , http://www.icare3d.org/research/GTC2012_Voxelization_public.pdf и http://www.cse.chalmers.se/~kampe/highResolutionSparseVoxelDAGs.pdf

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

person StarShine    schedule 19.09.2014
comment
Спасибо за ответ, нет текстур в сценах нет. Является ли воксельный движок реальным решением, имея в виду, что мои сцены - это просто наборы полигонов, я понятия не имею об объемах объектов. Сцена полностью статична, ни один объект никогда не будет двигаться. Но я должен иметь возможность скрывать некоторые объекты по требованию (не имеет большого значения) - person ingham; 13.10.2014
comment
Это зависит от типа объектов. Если вы визуализируете полигоны и ожидаете, что некоторые или все объекты будут иметь очень высокую детализацию, то решение на основе LOD для каждого объекта может быть более подходящим. Если многие объекты геометрически идентичны, за исключением матрицы преобразования или параметра шейдера, обратите внимание на инстансный рендеринг (т. е. на пример конвейера). - person StarShine; 13.10.2014
comment
А как насчет сцены, содержащей большой набор различных мелких объектов (например: ~ 500 000 объектов по ~ 100-300 треугольников каждый)? - person ingham; 13.10.2014
comment
Если сцена плотно упакована, вы можете создать потенциальные списки видимости, чтобы вы могли запросить, какие объекты вам нужно визуализировать заранее. Если сцена динамическая, то вам нужны деревья dPVS. Если ваша сцена просторна (окклюдеры довольно малы), то выигрыш от PVS будет слишком мал, и решения должны исходить из билбордов, инстанс-рендеринга, скайбоксинга, предположений об отсечении части пространства и т. д. Какие? объектов вы думаете о в настоящее время? - person StarShine; 14.10.2014