Каков достижимый способ задания бюджетов содержимого (например, количества полигонов) для содержимого уровня в 3D-заголовке?

13

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

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

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

MrCranky
источник
1
Это скорее «предпроизводственная», чем «производственная» вещь.
Патрик Хьюз

Ответы:

5

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

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

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

ClassicThunder
источник
2
Хотя на самом деле это не обеспечивает бюджет: «сделайте его настолько сложным, насколько вам нужно, а потом мы его уменьшим» - это производственная стратегия. : - /
MrCranky
16

Итак, наша стратегия такова:

  • Составьте некоторую геометрию заполнителя примерно в правильном масштабе для конечного содержимого. Это могут быть здания или персонажи. Он не должен выглядеть как конечный контент, это могут быть прямоугольники / сферы / и т. Д., Но он должен быть мозаичным, чтобы иметь приличное количество полигонов. Если вы делаете персонажей, сделайте так, чтобы у них было репрезентативное количество костей.
  • В качестве альтернативы используйте чужую геометрию. Если у вас есть заголовок, уровень качества которого вы хотите сопоставить, найдите способ захватить их модели (возможно, с помощью захвата сцен DirectX).
  • Убедитесь, что на вашей геометрии есть типичный шейдер. Если вы собираетесь смешать несколько текстур, сделайте это, даже если все текстуры одного цвета. Убедитесь, что текстуры имеют нетривиальные разрешения, даже если они все одного цвета.
  • Вставьте разумное количество огней.
  • Поставьте камеру в реалистичное место, указав максимально возможное количество геометрии (например, стоя на вершине холма, глядя на уровень)
  • Загрузите сцену на самое медленное и быстрое целевое оборудование и измерьте FPS.
  • Измените значения геометрии / источников света / шейдеров / разрешения текстур вверх или вниз, чтобы понять, каковы компромиссы (например, у вас может быть дюжина дополнительных источников света, но вам придется сократить счетчик пополам).

Наконец: будьте консервативны с вашими цифрами. Рендеринг - не единственное, что должна делать ваша игра, поэтому определитесь, какую часть своего кадра вы хотите потратить, и сделайте это своей целью. Например, если вы хотите потратить две трети своего кадра при рендеринге 30 кадров в секунду, тогда в ваших тестах выберите 1 с / 22 мс (45 кадров в секунду).

Из всего этого вы должны быть в состоянии привести примеры сцен. Например, вот сцена с 200K полигонов, 5 статических источников света и не более 3 динамических источников света на модель, с 15 символами 50K polys и 30 костями, и она работает со скоростью 60 кадров в секунду и занимает 30 МБ в памяти.

MrCranky
источник
2
tl; dr: Оцените сами;)
Никол Болас
+1 Это действительно единственный способ, построить и измерить.
Патрик Хьюз
В самом деле? Я надеялся, что найдется более разумное и дешевое решение, о котором мы не думали.
MrCranky
@MrCranky к сожалению, да. Если вы используете существующий движок, вы можете быстро начать процесс, измерив существующие образцы данных и используя их в качестве основы для настройки чисел для своей игры в частности - каждая игра отличается.
Патрик Хьюз
4

Количество вершин

Я исследовал «Количество полигонов» более 15 лет. Не существует строгого способа определить, сколько у вас ограничений, особенно с использованием более современного программного и аппаратного обеспечения. Пределы были гораздо полезнее в двигателях, которые поддерживали только 4000 треугольников для всего уровня. Теперь вы найдете, что большинство объектов в игровой среде превысят это индивидуально.

В конечном счете, важно то, что делает двигатель с полосами многоугольника.

Когда движок рендерит каждую модель, он берет ваши UV-координаты, текстуру / материал, представленный на треугольниках, и создает треугольные полосы. В большинстве случаев веер треугольника разбивается на отдельные полосы треугольника на треугольник. Это увеличивает количество треугольных полос, снижая производительность.

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

Возьмите в качестве ориентира количество полигонов и позаботьтесь о том, как вы моделируете, и нанесите UV-карту на сетку. Меньше расколов в сетке, когда UV Mapping часто может быть более выгодным.

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

Дизайн игры

При разработке игры учитывайте следующее:

  1. Определите тип игры (например, действие / приключение / гонки / скроллер)
  2. Определите тип вида (например, от первого лица / от третьего лица / орфографический)
  3. Определите вычислительную мощность для вашего рынка. (например, энтузиаст / случайный игрок)
  4. Создайте визуальный стиль, которого хотите достичь. Вы хотите, чтобы он выглядел, например, как Crysis 2, Borderlands, Bloodforge или Gears of War?
  5. Определите важные объекты для игрока. Ваши реквизиты станут центром фокуса или просто фоном?
  6. Являются ли визуальные сетки также сеткой столкновений?

Используя тип игры и вид, определите глубину обзора. Собираетесь ли вы увидеть отдаленные объекты и с какой ясностью? Вы делаете что-то с ограниченным обзором, например, шутер в коридоре? (например, Gears of War) Вы делаете что-то свободное в роуминге с открытыми пейзажами? (например, Скайрим)

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

Анимация ограничит вашу способность увеличивать количество полигонов. Статические сетки, все, что остается в той же позиции, является самым дешевым на GPU и CPU. Особенно, если они не являются физическими объектами. Для физических объектов вы можете часто создавать простые оболочки столкновений и сложные визуальные сетки. В большинстве игр недостаточно взаимодействия, чтобы заметить разницу. Анимация перемещает вашу модель 3-мерно, с несколькими костями на вершину, смешивая весовые коэффициенты от каждой из них. Это может быть дорого из-за процессорного времени, которое может конфликтовать с искусственным интеллектом и программной физикой. Чем больше вершин зависит от количества костей во всей модели, тем ниже производительность ЦП. Это еще одна причина, по которой игровые персонажи считаются «искусством». Очень трудно определить предел многоугольника.

Мой пример

Я использую UDK, делая медленный шутер от третьего лица, с ограниченным количеством игроков и NPC на экране в любое время. Для этого я стремлюсь получить примерно 10 000 треугольников на игрока, 5000 треугольников для типичных, общих врагов, а если бы я делал персонажа в стиле «босс», то около 15 000. Кроме того, оружие для третьего лица около 4000 треугольников будет очень подробно. Транспортные средства около 10000 треугольников. Все будет требовать уровня детализации, потому что мне нужны большие расстояния просмотра.

Если бы я делал от первого лица, я бы основывал руки на 2000 треугольников, оружие на 5000 треугольников, с обычным отображением для каждого.

Вывод

Это то, что, вероятно, означает «это зависит», но я подумал, что это может прояснить некоторые вещи, о которых люди часто задаются вопросом.

  1. Используйте количество полигонов в качестве руководства.
  2. Посмотрите на области, которые могут быть нормально отображены, а не смоделированы.
  3. Будьте осторожны при размещении треугольных вентиляторов, если возможно, создайте полосу.
  4. Используйте меньше расколов на сетке при УФ-картировании, помня о полосах.
Маркхэм Уорд
источник
2

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

  1. Получить большой объем активов (потенциально может быть создан автоматически).

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

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

  4. Соберите как можно больше информации и выбросьте ее в базу данных; fps, poly count, изменения шейдеров, количество источников света, вызовы и т. д.

  5. Сделайте / получите некоторые инструменты для отображения данных в вашей базе данных как можно больше способов.

Эта ссылка может предоставить еще несколько идей: Dead Rising Tools

OriginalDaemon
источник
Мне нравится этот ответ, так как он затрагивает самую дорогую часть нашей собственной стратегии: кто-то должен приложить усилия для создания репрезентативных сцен. Генерация алгоритмов или сценариев для быстрого размещения большого количества объектов разумного размера значительно ускорила бы создание тестируемой сцены. Я собираюсь принять более популярный ответ, но я думаю, что этот стоит награды.
MrCranky