Сколько полигонов в сцене может достичь современное оборудование, поддерживая в режиме реального времени, и как туда добраться?


11

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

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


2
Я не думаю, что вопрос обязательно слишком открытый, но любой числовой ответ будет неправильным в течение 12 месяцев.
Дэн Халм

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

7
Это действительно невозможно ответить. Прежде всего, что такое «в реальном времени» - 60 кадров в секунду? 30? Меньше? Во-вторых, ответ будет сильно различаться в зависимости от того, какой у вас графический процессор и какое разрешение вы рендерите. В-третьих, ответ будет сильно различаться в зависимости от деталей работы рендеринга. Ограничения на сложность сцены более сложны, чем просто количество полигонов как таковых, но включают такие вещи, как количество вызовов отрисовки, изменения состояния, проходы рендеринга и т. Д., На которые влияет то, как работает механизм, как художники создавали сцена и так далее ...
Натан Рид

1
@Llamageddon Учитывая ваши комментарии, я не совсем уверен, что вы на самом деле просите. С одной стороны, заголовок вашего вопроса достаточно ясен (максимально геометрический и как это сделать), но, как отметил Натан, на этот вопрос невозможно ответить. С другой стороны, в своих комментариях вы говорите, что хотите знать, как минимизировать стоимость кадра. Это чрезвычайно широкий вопрос, потому что вы можете улучшить / оптимизировать свои шейдеры, граф сцены, модели, текстуры, использование API, просто все, что делает какую-то часть вашего рендеринга. Вы могли бы написать целые книги об этом (если не кто-то уже сделал).
Nero

1
это немного поздно, но здесь вы можете увидеть СТАТИЧЕСКУЮ сетку с 24.000.000 вершин в Blender. И я могу вращать его плавно с 40 FPS. Я думаю, это просто удивительно, что могут сделать современные графические карты.
user6420

Ответы:


5

Я думаю, что общепризнанно, что в режиме реального времени все, что выше интерактивного. И интерактивный определяется как «реагирует на ввод, но не является гладким в том, что анимация кажется неровной».
Поэтому реальное время будет зависеть от скорости движений, которые нужно представлять. Кинотеатр проецирует со скоростью 24 FPS и достаточно в режиме реального времени для многих случаев.

Тогда сколько полигонов может обработать машина, легко проверить, проверив себя. Просто создайте небольшой патч VBO в виде простого теста и счетчика FPS, многие образцы DirectX или OpenGL предоставят вам идеальный тестовый стенд для этого теста.

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

У тебя есть:

  • скорость заполнения
    • выборка текстуры
    • Выход ROP
  • рисовать звонки
  • рендеринг целевых переключателей
  • обновления буфера (равномерное или другое)
  • перерисовки
  • сложность шейдера
  • сложность конвейера (какая-либо обратная связь использовала «итеративное затенение геометрии» окклюзия »)
  • синхронизировать точки с процессором (пиксельное считывание?)
  • богатство многоугольников

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

РЕДАКТИРОВАТЬ:

Я хотел добавить, что нельзя использовать спецификацию GFlops для одной конкретной карты и отображать ее линейно в соответствии с емкостью выталкивания полигонов. Из-за того, что обработка полигонов должна проходить через последовательное узкое место в графическом конвейере, как подробно объяснено здесь: https://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-graphics -pipeline-2011-part-3 /
TLDR: вершины должны помещаться в небольшой кэш перед примитивной сборкой, которая изначально является последовательной (порядок буфера вершин имеет значение).

Если вы сравните GeForce 7800 (9-летнего возраста?) С 980-м годом в этом году, то число операций в секунду, на которые она способна, увеличилось в тысячу раз. Но вы можете поспорить, что он не будет толкать полигоны в тысячу раз быстрее (что составляет около 200 миллиардов в секунду по этой простой метрике).

EDIT2:

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

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

Один пакет - это то, что может быть обработано одним вызовом отрисовки.
Содержит идентификаторы для:

  • буфер вершин
  • индексный буфер
  • камера (дает проход и рендер цели)
  • идентификатор материала (дает шейдер, текстуры и UBO)
  • расстояние до глаза
  • виден

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

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

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

После всего этого упорядочения можно применять мега-текстурирование, виртуальное текстурирование и рендеринг без атрибутов ( ссылка ), если это необходимо.

В API движка также есть одна общая вещь - отложить выдачу команд установки состояния, требуемых клиентом. Если клиент запрашивает «установить камеру 0», лучше всего сохранить этот запрос, и если позже клиент вызовет «установить камеру 1», но между ними нет других команд, механизм может обнаружить бесполезность первой команды и отбросить ее. , Это устранение избыточности, что возможно при использовании «полностью сохраненной» парадигмы. В противоположность «немедленной» парадигме, которая будет просто оберткой над нативным API и выдаст команды в порядке, указанном клиентским кодом. ( пример: виртрев )

И, наконец, на современном оборудовании очень дорогой (в разработке), но потенциально очень полезный шаг - переключить API в стиле metal / mantle / vulkan / DX12 и подготовить команды рендеринга вручную.

Механизм, который готовит команды рендеринга, создает буфер, который содержит «список команд», который перезаписывается в каждом кадре.

Обычно существует понятие кадра «бюджет», которое может себе позволить игра. Вам нужно сделать все за 16 миллисекунд, чтобы четко разделить время графического процессора: «2 мс для прохода света», «4 мс для прохода материалов», «6 мс для непрямого освещения», «4 мс для постобработки» ...


1
Миллион кажется мне немного низким.
Джуджаа

просто возьмите, сколько MPoly / s способна карта, и это тот FPS, при котором она выдаст 1 миллион. Я только что вспомнил эксперимент для рендера местности на ATI4800HD. Если вы возьмете этот список en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units, они не предоставят информацию о вершинах, начиная с эпохи унифицированной архитектуры. но 10-летнее оборудование, кажется, рекламирует около 40 FPS для 1 миллиона треугольников. + ср редактировать в моем ответе
v.oddou

@ v.oddou Да, но чтобы приблизиться к этому числу, вам нужно выполнить группировку геометрии или создание экземпляров в случае динамических сцен, и это то , о чем я спрашиваю. Как не ограничивать себя 2% пути к тому, что может сделать аппаратное обеспечение.
Лламагеддон

@ Лламагеддон ааа, я вижу, это действительно вопрос. Дай мне посмотреть, что я могу сказать по этому поводу. (EDIT2)
v.oddou

Большой глубокий ответ! Я сделал несколько небольших правок, как пользователь, а не как модератор. Не стесняйтесь отменить все / все, если они не соответствуют вашим намерениям.
Трихоплакс
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.