как узнать количество полигонов
Определяем количество полигонов в сцене 3Ds Max
Обычно таким вопросом задаются, если надо уменьшить количество полигонов в 3ds Max или хотя бы не превысить их максимально возможное для этого проекта число. Да и вообще полезно знать, не эта ли маленькая табуреточка на миллион полигонов так тормозит сцену во вьюпортах.
Инструкцию пишу на примере 3ds Max 2017, но для предыдущих версий тоже вполне подходит.
Клик по плюсику в левом верхнем углу вьюпорта, в меню выбираем Configure Viewport.
В открывшемся окне переходим на вкладку Statistic, ставим галочки на параметрах, которые хотим видеть.
Отметьте, хотите ли видеть количество полигонов для всей сцены, выделенного объекта или того и другого одновременно.
Используйте горячую клавишу «7», чтобы включить или выключить отображение статистики во вьюпорте. Данные отображаются в левом верхнем углу — цифры желтого цвета.
Совет. Не держите статистику постоянно включенной! В сложных сценах это может замедлять работу во вьюпортах.
5 модификаторов, меняющие количество полигонов 3ds Max
По своей сути сетка — это набор полигонов. В 3ds Max вы можете управлять единичными полигонами или их группами. Но некоторые модификаторы позволяют пойти дальше и работать целиком со всей сеткой.
Ниже будут рассмотрены 5 модификаторов, которые можно поделить на 2 типа:
Отдельно стоит выделить модификатор Quadify Mesh, так как он может работать в обе стороны. Все модификаторы можно найти в Modify – Modifier List и найти по названию (можно ввести название текстом).
Так как число полигонов изменяется, то его понадобится отслеживать. Чтобы увидеть, сколько в сцене полигонов, нужно нажать клавишу «7» или включить функцию Views – xView – Show Statistics.
Выбрать элементы для подсчета можно в окне Viewport Configuration – Statistics. Там можно выбрать полигоны (Polygon), треугольники (Triangle), ребра (Edge), точки (Vertex), число кадров в секунду (Frames Per Second). Также есть выбор, на каких объектам считать: на всех (Total), на выбранных (Selection), одновременно на всех и на выделенных (Total + Selection).
1. TurboSmooth
Turbosmooth крайне простой модификатор, который сглаживает объекты. Но его преимущество перед Smooth или OpenSubdiv в том, что сглаживание производится добавлением новых полигонов и изменением их положения. Хотя, возможности указанных модификаторов частично присутствуют, но рассматривать их мы не будем.
Главный параметр – Iterations. Чем он выше, тем больше полигонов и более сглаженный объект. Часто этот модификатор используют для более тонкой доработки объекта, которая требует больше полигонов, чем грубая форма. Однако не стоит ставить слишком высокое значение. Из-за этого сцена может зависнуть.
2. Tessellate
Tessellate выполняет схожую с TurboSmooth функция, но несколько иначе. Прежде всего, он имеет 2 типа построения новых ребер на сетке: на основе треугольных «фейсов» (Face) или полигонов (Polygons).
3. Optimize
Модификатор Optimize облегчает сетку, в отличие от модификаторов выше. Самым важным параметром является Face Thresh. Именно его значение показывает, насколько сильно будет уменьшено количество полигонов в процентах. Остальные параметры позволяют более тонко настраивать оптимизацию. В самом низу показано, сколько было точек и фейсов и сколько стало.
Модификатор достаточно полезный, но обладает большим недостатком – большая часть квадратов превращается в треугольники. Из-за этого дальнейшая работа с объектом очень усложняется.
4. ProOptimizer
Принцип работы ProOptimizer очень схож с Optimize, но более автоматизирован. Он не имеет различных параметров настройки новых граней, из-за чего оптимизация менее гибкая. Но сам объект после оптимизации лучше сохраняет форму при меньшей трате времени на настройку. Лучше всего это будет видно на сложных объектах.
В разделе Optimization Level находятся все главные параметры и информация. Сначала вы должны рассчитать оптимизацию кнопкой Calculate, а затем поменять количество точек до результата, который вас устроит. Statistic (Before / After) показывает, на сколько было уменьшено число точек и «фейсов».
Стоит помнить, что чем ниже количество точек во время оптимизации, тем сильнее ломается геометрия объекта. А значит, тем хуже он будет выглядеть.
5. Quadify Mesh
Инструмент Quadify Mesh уникален тем, что он работает не на основе существующей сетки объекта, а создает новую. По простоте он не уступает ни одному перечисленному выше модификатору. Ведь он имеет всего один параметр! Quad Size % отвечает за размеры квадратов, которые будут строиться на объекте. Значение это в процентах и рассчитывается относительно размера объекта. Значения изменяются от 0,2 до 100.
Модификатор очень хорош тем, что старается создать наиболее правильную топологию из прямоугольников. Особенно на углах объекта. Но не всегда получается автоматически создать только квадраты. Поэтому иногда на новой сетке можно встретить треугольники. Бывает и так, что модификатор может делать сетку крайне плохо. В таких ситуациях устоит уменьшить значение Quad Size %.
Каждый из этих инструментов крайне сильно облегчает моделирование, но не стоит ими злоупотреблять. Иногда создание топологии вручную с помощью самых обычных инструментов Cut и Connect может дать лучший результат.
много полигонов в статистике
Возможно, но мешсмус и турбосмус при включении сразу в статистике отображаются ну и не с 8 до 30лямов же! это ж какая модель слонская должна быть
Может быть, в сцене есть дисплейсмент?
30 лямов это на слух много, но для макса не много-много.
На самом деле это так себе показатель.
Потому что он инстансные обьекты показатель полигонажа тоже увеличивает, вот только инстансные объекты в оперативе не прибавляют
Не думаю что из-за этого вообще стоит переживать
Да возможно инстансы, но переживать таки стоит, потому что виснет всё не хило. Это не первый раз такое, уже подобное замечал, тогда все переводил в поли и проходило, при чем полигонов показывало первое (меньшее) количество
Вы недооцениваете мой комп))
Не нашел виновника этого безобразия, выделил все и сконвертил в поли, теперь и во вьюпорте 8 и при рендере, и ничего не виснет. В общем в любой непонятной ситуации КОНВЕРТ ТУ ПОЛИ!
А что виснет то? вьюпорт или рендер?
Если вьюпорт, так так есть же куча метод по оптимизации вращения сцены во вьюпорте
виснет комп в начале рендера, задумывается на минуты 2, вырубаю рендер, статистика меняется на меньшее число и вьюпорты работают нормально. В любом случае конверт ту поли всё профиксило
наверное, сначала выборочно конвертил, потом забил и сконвертил всё.
Статистика отображает только то, что по факту во вьюпорте. Если рендер итерации отличаются от просто итераций, то не покажет. Колапснув геометрию, вы взяли в поли геометрию «как есть» из вьюпорта.
Спасибо, за скриптец, будем юзать
Сконвертировала все в поли и о чудо все заработало а главное 15млн куда то пропали, спасибо тебе
ооо чудо. Спасибо Вам ребята. Все конвертнул в поли. Рендер запускается с пол клика).
Дабы не плодить темы, напишу здесь.
Вечер добрый! Не подскажете в чем заключается проблема? В статистике показывается 5 млн. полигонов, но при выделении всей сцены, только 88 тыс. полигонов.
Из за этого падает фпс, работать становится сложнее
Еще заметил такую особенность
При выделении всех объектов во вкладке
полигонов так же 80 тыс.
Если выделить вкладку
А если же выделить объекты в двух этих вкладках, то получается 5 лямов
Большое спасибо, спас мой проект
Дабы не плодить темы, напишу здесь.
Вечер добрый! Не подскажете в чем заключается проблема? В статистике показывается 5 млн. полигонов, но при выделении всей сцены, только 88 тыс. полигонов.
Из за этого падает фпс, работать становится сложнее
Еще заметил такую особенность
При выделении всех объектов во вкладке
полигонов так же 80 тыс.
Если выделить вкладку
А если же выделить объекты в двух этих вкладках, то получается 5 лямов
Здравствуйте, у меня такая же проблема, показывает 2 ляма полигонов, когда на деле только 120 тыс. а в сцене то нету ничего такого на 2 миллиона полигонов, не подскажите как вы проблему решили?
Оптимизация: почему время важнее полигонов
Многие начинающие 3D-художники и разработчики игр знают, что существует «оптимизация» — нечто, что позволяет повысить частоту кадров. Но зачастую они не разбираются в том, как она работает — и это заставляет их принимать неверные решения.
В этом материале преподаватель курса OutBlock и левел-дизайнер VOID Interactive Денис Куандыков объясняет, как устроена оптимизация, и почему количество полигонов тут — не ключевой фактор.
Если 3D-артист со стороны попытается самостоятельно оценить сложность кадра, то может получиться недоразумение. Художник не знает, какое количество треугольников будет оптимальным, если нет чёткого технического задания.
Если оно есть, это решает проблему. Но иногда техническое задание бывает нечётким не по вине заказчика: например, если вы сами разрабатываете собственную игру, или же если в проекте всё стандартно и нет ничего специфичного.
Как устроена отрисовка кадра
Процесс отрисовки кадра — это та самая «магия под капотом движка». У отрисовки, как и у работы художника, есть стоимость, и рассчитывается она исходя из необходимого времени.
Для того, чтобы оценить время рендера, в редакторах и движках есть отдельные инструменты. Одного лишь значения кадров в секунду в любом случае недостаточно.
«Время кадра» — это время в милисекундах, за которое может быть построен и отрисован один кадр. Чтобы получить 60 кадров в секунду, один кадр должен быть обсчитан за 16 милисекунд или еще быстрее.
Draw Call (вызов отрисовки) — это одна графическая команда, которая должна что то отрисовать.
Сложность кадра можно оценивать именно с помощью вызовов отрисовки. Чем их больше, тем дольше они обсчитываются, тем медленнее выполняется 1 кадр, тем меньше кадров в одной секунде и тем меньше итоговый FPS.
И наоборот — чем меньше вызовов отрисовки, тем быстрее считается кадр, и тем выше FPS.
Примерный разброс лимитов на Draw Call можно описать так:
— Мобильные игры — примерно 100 на средне-высоких настройках, на топовых устройствах можно и больше.
— Игры для ПК и консолей — до 4000.
Например, Battelfield и третий «Ведьмак» в среднем работают на 1000-2000 вызовах отрисовки.
В то же время, некоторые внутренние движки Ubisoft спокойно работают на значениях вплоть до 20 тысяч. Дело в том, что Draw Call — это тоже не идеальное мерило производительности. Вызовы отрисовки бывают разные, и тут всё зависит от того как работает конкретный рендер-пайплайн в конкретном проекте. Подробно разобраться в том, как это устроено, можно здесь.
Рендер-пайплайн — это очень сложная система, и во многих крупных проектах она уникальна. Из-за этого оценить оптимизацию порой практически невозможно.
Однако вы можете самостоятельно проанализировать отрисовку кадра любой ПК игры, используя специальные инструменты:
— Intel Graphics Perfomance Analisys
Подробнее обо всех этих инструментах можно узнать здесь.
Самое важное: нужно оценивать стоимость кадра. А первичное мерило стоимости — это время. Уже затем можно всё раскладывать на процессы, то есть, на те самые вызовы отрисовки.
Когда обсуждают оптимизацию проекта и специфику его контента, в первую очередь речь заходит не о количестве полигонов, а о том, сколько примерно можно позволить себе вызовов отрисовки, — учитывая железо и технологии.
Вызовы отрисовки
Теперь разберёмся, как именно можно подсчитать количество этих вызовов.
Простой пример: у нас есть 10 ящиков и одно дерево. Все десять ящиков имеют один и тот же шейдер, материал и количество полигонов. Логично предположить, что у нас будет 11 вызовов, ведь в кадре 11 объектов.
Всё почти так и есть. Программа рендерит так: «ящик, ящик, ящик, ящик, ящик. и потом дерево. Кадр построен».
Однако, судя по статистике, у нас всего три батча (вызова отрисовки):
Дело в том, что движок сам понимает, что перед ним десять одинаковых ящиков. Он сам «сшивает» ящики в один объект, и теперь процессор отдает нашей видеопамяти на отрисовку один кусок меша, который мы видим как 10 отдельных ящиков.
Этот процесс называется «батчинг». Он бывает динамическим и статическим.
Как устроен батчинг
Динамический батчинг работает, если он включен в движке. Движок сам анализирует геометрию и сшивает те объекты, которые подходят под лимиты.
Обычно у динамического батчинга очень жёсткие лимиты; он не позволяет сшивать тяжёлую геометрию и занимается в основном мелкими деталями в кадре. Например, если от стены динамически отделились мелкие осколки, то они они, скорее всего, будут сшиты динамическим батчингом в каждом отдельном кадре.
Как устроен батчинг
Динамический батчинг работает, если он включен в движке. Движок сам анализирует геометрию и сшивает те объекты, которые подходят под лимиты.
Обычно у динамического батчинга очень жёсткие лимиты; он не позволяет сшивать тяжёлую геометрию и занимается в основном мелкими деталями в кадре. Например, если от стены динамически отделились мелкие осколки, то они они, скорее всего, будут сшиты динамическим батчингом в каждом отдельном кадре.
Партикли (система частиц) умеют «сшиваться» сами по себе, поэтому их стоит использовать, если нужно нарисовать много одинаковых мелких объектов.
Например, тысячи рыб в кадре в Abzu — это на самом деле партикли, геометрия которых дополнительно анимирована шейдером с вертексной анимацией.
Отличие от динамического батчинга в том, что он позволяет перерабатывать огромное количество объектов. За один батч Unity может сшить объектов общим количеством до 64 000 треугольников.
Кроме того, динамический батчинг будет пытаться пересобрать геометрию почти в каждом новом кадре, — а значит будет постоянно увеличивать время расчёта.
Чтобы батчинг сработал, объекты должны быть «одинаковы». Объекты должны иметь один и тот же шейдер, материал на этом шейдере (в Unreal это инстанс материала), текстуру и остальные параметры объекта, а также не должны иметь Non Uniform Scale и не должны быть разбиты светом.
Одна из причин того, почему от художников требуют не текстурить объекты уникальными сетами отдельных текстур, а паковать их в огромные текстурные атласы — как раз в этом. Это позволяет отдать батчингу на обработку сотни разных визуально разных объектов, — ведь они будут отрисованы не отдельно, а группами.
Как уже было сказано, важнейшее мерило оптимизации — время. Иногда один раз загрузить в память один огромный текстурный атлас гораздо выгоднее, чем постоянно гонять туда-сюда отдельные мелкие текстуры — даже если в сумме они будут занимать в памяти меньше места, чем атлас целиком. Загрузка и выгрузка — не бесплатный процесс.
Однако батчинг тоже не «бесплатен» — даже если он статический и обсчитан заранее. Сцены в играх нужно освещать, и даже в случае статичного освещения это будет влиять на батчинг.
Так например, два одинаковых ящика, которые в обычной ситуации превратились бы в один батч, разделят на два батча, так как они привязаны к разным лайт-пробам (Light Probe).
Освещение в реальном времени тоже будет влиять на то, какие объекты сбатчатся, а какие — нет.
Кроме того, нужно учитывать где будет храниться полученный материал. Ведь сбатченная геометрия — это отдельный уникальный меш, который не заменяет ваши ящики на локации. То есть, батчинг требует свободной памяти.
Поэтому иногда применяют «ручной» батчинг, он же просто «мердж» (merge). Берём геометрию, и в любой программе сшиваем так, как нужно под конкретную сцену.
На финальных итерациях, когда весь левел-дизайн и левел-арт готовы, многие мобильные проекты проходят этап ручного сшивания всей локации. А модульные объекты, из которых состояла локация, и вовсе не идут в билд так как заменяются смерженным мешем.
Иногда гораздо выгоднее скормить движку огромный меш в 64 тысячи треугольников, чтобы отрисовать всю локацию целиком. Так поступили, например, разработчики Guns Of Boom.
Уровни детализации
Level of Detail (LOD, или уровень детализации) — простая техника, которая позволяет уместить огромное количество объектов в кадре, не отнимая время на обработку лишней геометрии.
LOD может разбить объекты на разные батчи: и в этом нет ничего страшного, ведь зачастую несколько сотен лишних DrawCall будет быстрее обсчитаны на лодированых мешах чем рисовать их оригиналы — но сбатченные.
Сейчас есть неплохие инструменты автоматической генерации LOD-мешей, и это облегчает работу. При нужной настройке можно выдать результат не сильно хуже ручной ретопологии. Но даже используя автоматику, не стоит делать тысячи разных уровней детализации: все уровни LOD тоже нужно хранить в памяти, а её не стоит забивать просто так.
Обычно используют четыре уровня детализации. LOD-0 — это оригинальная модель, а LOD-3 — дальняя. LOD4 может быть просто 2D спрайтом который всегда смотрит на игрока.
Кроме LOD-0 порой нужно делать отдельную модель для кат-сцен. В ней может быть куда больше полигонов, чем у LOD-0, потому что она появляется лишь в срежиссированных сценах, и, как правило, находится очень близко к камере — поэтому для неё лучше использовать крайне высокую детализацию.
Это касается даже мелких объектов: например, у обычной кружки в одной из стартовых сцен Dead Space 2 было достаточно полигонов, чтобы она не казалась «квадратной», в то время как в остальной игре в LOD-0 у аналогичных объектов не было такого сглаживания.
LOD-ы позволяют не считать лишние сотни полигонов в вашей модели. В первую очередь важно понимать роль модели в сцене и прикидывать, насколько детально игрок сможет её разглядеть.
Если модель, например, можно разглядеть вблизи с максимальным приближением, то просто сделайте LOD-0 достаточно детализированным, — а в самой сцене основным рабочим уровнем будет LOD-1.
Подход, основанный на роли модели в кадре полностью защищает вас от критики сторонников «идеальной сетки», которые без понимания контекста — просто по скриншоту, — заявят, что вы сделали 10 лишних треугольников.
Alpha overdraw
Рендер-пайплайн должен адекватно рассортировать и нарисовать сцену — обработать шейдеры, геометрию, текстуры и пост-процессы. К тому же он должен учитывать, что объекты могут быть прозрачными.
Чем больше площадь прозрачности в кадре, и чем больше прозрачные объекты наслаиваются друг на друга — тем дольше рендер-пайплайн будет рисовать итоговый пиксель, ведь ему придётся каждый раз его перерисовывать. Это называется Alpha overdraw.
Чем меньше альфы, тем быстрее будут обсчитаны пиксели. По сути, шейдер и сам рендер — это процесс/программа, которая рисует конкретный цвет конкретного пикселя на экране. И в этом случае пара десятков лишних треугольников, наоборот, ускорит рендер.
Z-Fight — артефакт, который образуется, если поставить несколько полигонов в одной плоскости. Рендеру не хватает точности глубины, чтобы отсортировать отрисовку этих полигонов в правильном порядке.
Но кроме визуального артефакта, который заметит игрок, это повлияет и на время рендера — ведь пиксели в этом месте будут постоянно «спорить» друг с другом об очереди отрисовки.
Итог
Итак, мы выяснили, что практически ничего «бесплатного» в случае с отрисовкой кадра не бывает: технологии, которые позволяют что-то оптимизировать, не работают по нажатию нужной галочки. Всегда нужно понимать, для чего мы используем тот или иной инструмент.
Нынешнее железо — даже мобильное, — может обрабатывать огромное количество треугольников. Объёмы памяти и скорость растут. Чипы на мобильных устройствах и их батареи, которые перегреваются при высоком FPS, тоже становятся всё совершеннее.
Взять и назвать точные диапазоны количества полигонов попросту невозможно — да и бессмысленно. Всё слишком сильно зависит от того для чего используется модель, и как ей видит игрок.