Введение

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

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

  • Влияние на поведение ИИ
  • Упростите или отключите симуляцию физики и анимацию
  • Уменьшите объем сетевого трафика, необходимый для репликации позиций игроков в сети.

При оценке ценности системы отбраковки окклюзии, некоторые из желательных свойств:

Он работает автоматически и универсально

В идеале система отсечения окклюзии автоматически работает с любым 3D-контентом, от простых средств просмотра объектов до массивных виртуальных миров, и не требует ручной работы со стороны художников, создающих и моделирующих игровой мир. Кроме того, система не должна накладывать ограничений на творчество художника. Наконец, система не должна зависеть от каких-либо конкретных аппаратных функций, соглашений о рендеринге или методов или инструментов разработки.

Это консервативно правильно

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

Это добавляет ценности

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

Этот подход называется системой отбраковки окклюзии Umbra 3.

Фон

Корни отсечения окклюзии в 3D-графике лежат в алгоритмах определения скрытых линий и скрытых поверхностей. Эти алгоритмы необходимы для создания визуально правильных изображений 2D-проекций в 3D-пространстве.

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

Все современные средства рендеринга растеризации полигонов, как программные, так и аппаратные, отслеживают наименьшее значение расстояния для каждой выборки и обновляют выборку только при обнаружении значения расстояния, меньшего, чем текущий минимум. Это решение известно как Z-буферизация или буферизация глубины, для сохранения дополнительного буфера Z-значений. Учитывая объем работы, уже проделанной для 2D-проекции и выборки растра, вычисление компонента Z относительно дешево и гарантирует правильный визуальный результат. Вычисления могут быть сокращены путем введения примитивов в порядке от начала до конца: рендеринг ближайшего примитива для данного образца сначала означает, что вклад всех других примитивов на том же луче может быть отклонен тестом глубины и, следовательно, любым вычислением для определения окончательного вывода скрытого образца, такого как интерполяция атрибутов вершин или поиск текстуры, можно пропустить.

Z-буферизация с примитивным порядком рендеринга спереди назад довольно близка к идеалу, заключающемуся в вычислении только одного значения для каждого выходного пикселя. К сожалению, отсечение происходит очень поздно в конвейере рендеринга трехмерного игрового приложения. В момент, когда средство визуализации отклоняет закрытый образец, образец прошел несколько этапов графического конвейера от подачи входной геометрии и зависимых ресурсов в графический процессор для обработки каждой вершины, настройки треугольника и растеризации. Существуют методы раннего Z-отсечения в конвейере рендеринга, но в конечном итоге наибольшая экономия вычислений достигается за счет отсева самых крупных рендерируемых объектов движка перед их загрузкой в ​​подсистему рендеринга. Традиционно отсечение преграды относится к этому типу оптимизации рендеринга.

Растеризация окклюдера

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

Одним из широко используемых решений является использование отдельного прохода рендеринга глубины или результатов глубины предыдущего кадра на графическом процессоре и использование запросов окклюзии. Запрос окклюзии возвращает количество образцов, которые потенциально могут пройти тест глубины, без фактической обработки или записи значений пикселей. Проблема с этим подходом - синхронизация между CPU и GPU, необходимая для передачи тестовых данных и получения информации о загорании. На практике этот подход практически невозможно использовать ни для чего другого, кроме оптимизации рендеринга.

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

Потенциально видимые наборы (PVS)

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

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

Порталы и ячейки

Третья категория систем отсечения окклюзии основана на разделении статического игрового мира на ячейки и фиксации видимости между соседними ячейками с помощью 2D-порталов. Операция выполнения заключается в том, чтобы найти ячейку, в которой находится камера, и пройти по сформированному графу ячеек, ограничивая видимость на пути, обрезая пирамиду обзора до пройденных порталов. Объекты назначаются ячейкам на этапе предварительной обработки, и их видимость определяется путем посещения ячейки, в которой они находятся. Этот подход лучше всего работает, когда в мире есть очевидные горячие точки, в которых дизайнер уровней может разместить порталы, например двери или окна, соединяющие комнаты в помещении.

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

Умбра 3: новое поколение устранения окклюзии

Система удаления окклюзии Umbra 3 была разработана для решения проблем, описанных в предыдущих главах.

Umbra 3 основана на идее преобразования трехмерного мира из детализированного полигонального представления, созданного художником, в упрощенный. Преобразование фокусируется на захвате основных свойств преграды, игнорируя при этом информацию о деталях, которые не имеют большого значения или не имеют большого значения в процессе отсечения загораживания. Этот подход напоминает построенный вручную граф порталов и ячеек. Однако модель окклюзии, используемая Umbra 3, представляет собой автоматически сгенерированный граф порталов и ячеек.

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

Умбра 3 состоит из двух компонентов:

Оптимизатор

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

Компонент времени выполнения

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

Концептуальная архитектура Умбры 3 изображена на рисунке ниже:

Инженерные задачи для автоматически созданного графа порталов и ячеек можно резюмировать следующим образом:

  • Суп из случайных полигонов необходимо превратить в типичный граф порталов и ячеек таким образом, чтобы можно было контролировать размер графа в сравнении с гранулярностью окклюзии.
  • Требуется эффективный метод отсева во время выполнения. Он должен использовать граф порталов и ячеек и уметь работать с относительно большим количеством порталов. Более того, он должен давать консервативные результаты отбраковки при фиксированной или ограниченной памяти и делать это достаточно быстро, чтобы не стать узким местом в сценарии минимальной окклюзии.

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

Создание данных окклюзии

На высоком уровне граф для 3D-сцены генерируется путем построения необработанного, равномерно распределенного начального графа портала. Этот график постепенно упрощается за счет удаления данных, которые мало влияют на общую окклюзию. Входные сетки окклюдера используются только на начальной фазе генерации ячеек, чтобы определить, следует ли считать отдельный воксель или прямоугольник с выравниванием по оси сплошным или пустым.

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

Первоначальное создание ячеек

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

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

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

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

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

Упрощение графика

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

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

Иерархическое упрощение также дает возможность выводить версии данных загораживания с уровнем детализации. Алгоритм выполнения может использовать эти выходные данные для выбора используемого уровня окклюзии в зависимости от расстояния до точки обзора.

Просмотр дерева

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

Вкратце, дерево представлений строится следующим образом:

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

Плитка

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

Umbra 3 избегает этой проблемы, разделяя мир на пространственные вычислительные единицы, тайлы, которые можно вычислять независимо друг от друга. Затем мир может быть вычислен по тайлам параллельным или распределенным способом. Память для воксельного представления с высоким разрешением требуется только для текущего обрабатываемого набора тайлов.

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

Отсечение портала во время выполнения

Другой компонент решения Umbra 3 - алгоритм отсечения окклюзии во время выполнения. Этот алгоритм использует упрощенную модель окклюзии для определения видимости из обзора камеры.

Алгоритм отбраковки во время выполнения должен быть быстрым - полная операция должна быть завершена за несколько миллисекунд - чтобы соответствовать требованию добавления ценности в игру, работающую со скоростью 60 кадров в секунду.

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

Обход графика

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

Чтобы ограничить количество повторных входов ячеек, алгоритм отбраковки среды выполнения Umbra 3 пересекает граф в основном в ширину. Вместо решателя геометрического портала используется программная растеризация для сбора информации о видимости в буфер окклюзии экранного пространства. Этот метод практически полностью исключает излишнюю рекурсию. Однако, учитывая способ построения ячеек из исходных кубов сетки, истинный порядок обработки ячеек в ширину может даже не существовать: между ячейками в графе могут существовать циклы, которые не оставляют выбора, кроме как обрабатывать ячейку более одного раза. .

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

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

Растеризация портала

Ход иерархического тайлового графа помогает управлять количеством ячеек, активных в любой момент времени. Еще одна важная оптимизация памяти - это расположение данных в буфере окклюзии. Опять же, тот факт, что требуются только консервативно правильные результаты, предлагает экономичное решение. Прямоугольники портала растрируются в буфер покрытия низкого разрешения, 1 бит на выборку. Каждый установленный бит в буфере представляет собой незащищенный путь к ячейке.

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

Общий объем рабочей памяти, необходимой для алгоритма отбраковки портала, включая структуры данных обхода, буфер глубины вывода и буфер покрытия для активного набора ячеек, составляет 85 килобайт. Это делает его достаточно маленьким, чтобы поместиться в локальной памяти современных потоковых процессоров.

Проверка окклюзии

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

Назначение статических объектов ячейкам легко сделать на этапе предварительной обработки, когда мы можем позволить себе работать в воксельном представлении. Однако для любых динамических сущностей, которые мы хотим протестировать, потребуется другое решение. Для этого алгоритм отбраковки создает глобальный буфер глубины во время обхода. Буфер глубины каждой пройденной ячейки обновляется на основе текущего буфера покрытия, где дальнее расстояние ограничивающего прямоугольника ячейки используется в качестве значения записи глубины. Таким образом, только один 16-битный буфер глубины 128x128 должен храниться в памяти на время обхода.

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

Заключение

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

Система удаления окклюзии Umbra 3 была разработана для преодоления недостатков традиционных решений для удаления окклюзии. Umbra 3 автоматически преобразует любой тип полигональной входной сцены в компактное представление среды выполнения. Это представление можно использовать для эффективного и консервативно правильного исключения окклюзии. Ключевые методы:

  • Дискретизация входной геометрии в процессе вокселизации
  • Растеризация исполняемого программного обеспечения, которая быстро создает список видимых объектов вместе с консервативным буфером глубины с желаемым разрешением.

График портала и параметры разрешения во время выполнения позволяют системе плавно масштабироваться от устройств низкого до высокого уровня. Поэтому Umbra 3 также является жизнеспособным решением, например, для игр для смартфонов.

Подводя итог, можно сказать, что Umbra 3 позволяет создавать массивные трехмерные игровые миры из случайных полигональных супов без ручной разметки для наглядности, всегда гарантируя консервативно правильные результаты отбраковки. Umbra 3 также делает информацию о видимости и пространственных рассуждениях доступной для более широкой категории подсистем игрового движка. Из-за этого разработчики игр по всему миру, такие как Bungie и многие другие, используют Umbra 3 в различных постановках на широком спектре рабочих платформ.

Хотите узнать больше о технологии Umbra? Посетите нас на www.umbra3d.com