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

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

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

Я думаю, что общепризнанно, что в режиме реального времени все, что выше интерактивного. И интерактивный определяется как «реагирует на ввод, но не является гладким в том, что анимация кажется неровной».
Поэтому реальное время будет зависеть от скорости движений, которые нужно представлять. Кинотеатр проецирует со скоростью 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 мс для постобработки» ...