Когда я делаю модель для 3D-игры, что я должен принять в качестве меры в своем бюджете полигоны (треугольники) или вершины? Я провел эксперимент с двумя наборами 40000 кубов, один с 8 вершинами и 12 треугольниками, другой с 24 вершинами и 12 треугольниками. Все было сделано в Unity, и оба они были сгенерированы процедурно. К моему удивлению, оба сета сыграли почти одинаково, разница была очень маленькая.
Означает ли это, что мне не нужно беспокоиться о количестве вершин, а только о количестве треугольников?
РЕДАКТИРОВАТЬ: Я сделал еще один эксперимент, я создал плоскость с 19602 треугольников и 10000 вершин и еще один с тем же количеством тиранглов, но 39204 вершин. Я сгенерировал 4000 из обоих. Теперь меньше вершин выиграли от 14 до 19 кадров в секунду. Так что, как правило, чем меньше, тем лучше, но только с большими различиями.
источник
Ответы:
Давайте представим большую сетку сетки, подобную той, которую мы могли бы использовать для ландшафта. Мы будем рендерить
nценность треугольников, покрывая, скажем, половину нашего экрана 1080p, за один вызов отрисовки.Если мы свариваем все наши вершины и не имеем сглаживающих / текстурирующих швов, то у каждого треугольника есть 3 вершины, и каждая вершина разделена на 6 треугольников, поэтому у нас есть
n/2вершины.Чтобы сделать это нам нужно:
Запустите вершинный шейдер хотя бы
n/2раз(«по крайней мере», потому что наш кэш для результатов вершин очень велик. Иногда мы заканчиваем тем, что высвободим уже преобразованную вершину, а затем снова понадобим ее для более позднего треугольника, который разделяет ее, и перезапустим на нем вершинный шейдер Таким образом, мы получаем не так много сбережений, как на бумаге)
Клип & отбраковать
nтреугольники.Растеризация и интерполяция по крайней мере 1920x1080 / 2 или около 1 миллиона пикселей буфера кадра (так как мы сказали, что наш ландшафт покрывает примерно половину экрана).
(«по крайней мере» из-за того, как графические процессоры работают с квадратами пикселей , некоторые фрагменты за пределами границ многоугольников по-прежнему растеризуются, но затем маскируются, что означает, что мы обрабатываем фрагменты дважды. Для неровной сетки мы также получим переопределение в любом месте сетки закрывает себя, если нам не повезло сначала нарисовать самый передний многоугольник в буфере глубины)
Запустите фрагментный шейдер для всех этих> = 1 миллиона фрагментов.
Смешайте ~ 1 миллион результатов в буферах кадров и глубины.
Хорошо, теперь давайте разворачиваем все наши вершины, так что теперь у нас есть
3nвершины, которые нужно визуализировать, в шесть раз больше, чем раньше! Наши шаги ...Запустите время вершинного шейдера
3n.(Нет звездочек из-за кэширования, поскольку каждая вершина используется только один раз, хотя это означает, что кэш не может спасти нас в любое время)
Клип & отбраковать
nтреугольники.Растеризация и интерполяция по крайней мере 1920x1080 / 2 или около 1 миллиона пикселей буфера кадра.
Запустите фрагментный шейдер для всех этих> = 1 миллиона фрагментов.
Смешайте ~ 1 миллион результатов в буферах кадров и глубины.
... подожди, каждый шаг, кроме первого, одинаков! Таким образом, большая часть работы, которую выполняет GPU при типичном вызове отрисовки, не связана напрямую с количеством используемых вершин. Объем покрытия экрана, перерисовка и общее количество треугольников составляют гораздо больше стоимости.
Это не значит, что вершины полностью свободны. Если вы разделяете вершины, когда можете, вы получаете небольшую экономию от кэширования, особенно если ваши вершинные шейдеры сложны, или вершинный конвейер вашего оборудования слаб (как это было в некоторых старых консолях). Но учитывая, что количество вершин отслеживается пропорционально числу треугольников плюс или минус постоянный коэффициент, обычно это не столь интересный показатель общей стоимости сетки.
источник
Ни.
Если вы не говорите по-настоящему огромное количество трис (миллионов), то вам важно:
24 вершины умножить на 4000 кубов дает 96'000 вершин.
640x380 пикселей дает 243'200 фрагментов, и большинство устройств поддерживают значительно большие разрешения.
Вы можете повторно запустить свой эксперимент с 1'000'000 кубов, порций, чтобы избежать узкого места при вызове отрисовки (1 единичная модель на 1'000 кубов).
источник
Стоит отметить, что если вы работаете с приложением WebGL, количество вершин быстро становится узким местом с точки зрения размера файла для загрузки пользователями. Такое же количество треугольников, но часто в 2-3 раза больше вершин, чем показано в программном обеспечении DCC. Лучшая распаковка может сильно помочь в этом случае, если меньше швов.
источник