какое количество полигонов в 3d max нормально

Определяем количество полигонов в сцене 3Ds Max

Обычно таким вопросом задаются, если надо уменьшить количество полигонов в 3ds Max или хотя бы не превысить их максимально возможное для этого проекта число. Да и вообще полезно знать, не эта ли маленькая табуреточка на миллион полигонов так тормозит сцену во вьюпортах.

Инструкцию пишу на примере 3ds Max 2017, но для предыдущих версий тоже вполне подходит.

Клик по плюсику в левом верхнем углу вьюпорта, в меню выбираем Configure Viewport.

В открывшемся окне переходим на вкладку Statistic, ставим галочки на параметрах, которые хотим видеть.

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

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

Совет. Не держите статистику постоянно включенной! В сложных сценах это может замедлять работу во вьюпортах.

Источник

Оптимизация: почему время важнее полигонов

Многие начинающие 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, тоже становятся всё совершеннее.

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

Источник

3D в играх: Полигоны

3D в играх. Часть 2

Как мы выяснили в прошлой части, современные трехмерные компьютерные игры строятся на основе полигонов. Но, что же это за зверь такой?

Полигон (Polygon) – это плоскость в евклидовом пространстве. Пространство имеет размерность три, соответственно, имеются три координаты: X, Y, Z. Условно их можно обозвать как длина, высота и глубина. В программном обеспечении для 3D нет единого стандарта относительно, так сказать, ориентации данных координат, хотя, как правило, координата X параллельна условном горизонту, т.е. это длина, а вот условной высотой может быть как Y так и Z. Соответственно, условной глубиной может быть как Z, так и Y. Но нам это не столь суть важно, примем для последующего материала представление, показанное ниже.

У полигона есть вершины, минимум три, максимум, теоретически, бесконечность. Практически максимум – много. Но в играх используются треугольные полигоны, т.е. полигон имеет три вершины. Почему именно три? Через три точки в пространстве можно провести только одну плоскость, что упрощает расчеты и позволяет избежать искажений (артефактов) на итоговой картинке связанных с тем, что вершины полигона могут лежать не в одной плоскости.

Однако в программах трехмерного моделирования принято пользоваться 4-х угольными полигонами, а вот 5-ти и больше, как правило, под запретом. Поэтому при моделировании приходится следить за тем, чтобы все 4 вершины полигона были в одной или почти одной плоскости. А как же игры? спросите вы. Полигон с 4-мя вершинами математически очень просто превратить в два треугольных с двумя общими вершинами, что и делается автоматически при экспорте в игровой движок.

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

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

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

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

Приведенный выше рисунок показывает как, на самом деле, с помощью плоских поверхностей создаются объекты практически любой формы. Правило тут простое: чем меньше каждый полигон, тем более точно можно передать форму исходного объекта. Это как с мозаикой, про которую разговор был в первой части. Но и увеличивать до бесконечности количество полигонов тоже нельзя, так как это сказывается на производительности, ведь компьютеру желательно не менее 30 раз в секунду пересчитать положение каждой, по крайней мере видимой зрителю, вершины полигона. Но и эти расчеты лишь малая часть того, что видеокарта в сотрудничестве с ЦП делают для расчета финальной картинки. Но об этом мы поговорим в следующих частях.

Кроме координат вершин есть у полигона такое свойство как нормаль. Это вектор, перпендикулярный одной из сторон плоскости полигона. Так как это вектор, то у него есть направление. Это направление указывает лицевую сторону полигона, вернее его начало находится у лицевой стороны полигона. Нужна нормаль для наложения текстур и расчета освещенности. Так же хочу заметить, что математически полигон не имеет никакого отношения к тому, как он выглядит, т.е. к текстурам. Полигон отдельно, текстуры – отдельно.

Так вот, та сторона, из которой «выходит» вектор нормали — и определяет лицевую сторону полигона, поэтому с противоположной стороны полигон прозрачен при визуализации, вернее обратной стороны просто не существует. Именно поэтому когда игровой персонаж из-за некорректных коллизий проваливается сквозь текстуры, то почти все сверху кажется полупрозрачным – текстур, вернее обратной стороны у полигона не существует.
Ниже скриншот из игры Batman Arkham Knight.

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

Внимательный читатель может спросить: а как же быть в том случае, если игровой персонаж должен зайти в помещение? Тогда необходимо, как и в реальном здании, придавать стенам (потолку, крыше, дверям и т.д.) толщину с помощью двух полигонов у которых нормали смотрят в противоположные стороны.

Ниже показан фрагмент модели здания со стеной, имеющей реальную толщину. Синим показано направление нормали у полигонов.

Для совсем тонких предметов, таких как лист бумаги, применяется другой подход и зависит он от конкретного игрового движка. Например, может применяться специальный двухсторонний материал или отключаться параметр Backface culling, и в этом случае объект будет выглядеть одинаково с обеих сторон. (Подробнее про Backface culling можно почитать тут: Полигоны, свободная камера и MGS 5)

Теперь поговорим о том, какие бывают трехмерные полигональные модели.

3D модели принято делить на низкополигональные (low poly) и высокополигональные (high poly). Как несложно догадаться – разница в количестве полигонов, причем разница не абсолютная, а, как и все в нашем мире, относительная.

Высокополигональной можно назвать модель с самодостаточной геометрией, т.е. когда даже мелкие детали (в разумных, конечно, пределах) смоделированы с помощью полигонов и при этом модель выглядит достаточно правдоподобно даже без текстур. Непосредственно в играх high poly модели, как правило, не применяются, однако они необходимы в процессе разработки 3D игры, о чем будет рассказано ниже.

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

Низкополигональные модели применяются в основном в играх или для анимации, когда визуальный реализм не имеет первостепенного значения. Есть два основных способа получения низкополигональной модели: непосредственное моделирование с прицелом на малое количество полигонов или упрощение высокополигональной модели. То же справедливо и для high poly моделей (если не брать в расчет 3D сканирование): их получают путем усложнения и добавления полигонов низкополигональной модели, либо моделируют сразу из расчета максимально необходимого количества полигонов. Какой подход применятся в том или ином случае зависит от многих факторов, как то: геометрии самой модели, применяемого программного обеспечения, наличия похожих моделей, принятого в студии-разработчике порядка разработки, предпочтений 3D-художника и т.п.

Хочу особо обратить внимание на то, что разделение на high poly и low poly очень и очень относительно. Зависит от многих факторов, и одна и та же модель может быть как низкополигональной, так и высокополигональной. Например, для игры для ПК была разработана высокополигональная модель персонажа, затем из нее получили низкополигональную, условно, уменьшив количество полигонов в два раза. А позже решили портировать игру на мобильные устройства. И количество полигонов, опять же, условно, для этого сократили в четыре раза по сравнению с изначальной моделью, или в два раза по сравнению с моделью для ПК-версии игры. Ведь мобильные устройства мало того, что не такие мощные, как ПК, так еще и размер экрана не позволяет различить мелкие детали, поэтому такая высокая детализация, как для полноразмерного монитора, там попросту не нужна.

Ниже показаны сферы одинакового диаметра с различным количеством полигонов.

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

Ниже представлена эволюция полигональной Лары Крофт.

Как же получают 3D модели? Традиционно для этого используется полигональное моделирование в специальных программных пакетах, как то: 3ds Max, Maya, Cinema 4D и т.п. В последнее время к разработке также подключают программы для так называемой трехмерной лепки, к примеру ZBrush и 3D-Coat. Ну, и с развитием технологии 3D сканирования, модели получают путем этого самого сканирования с последующей оптимизацией полигональной сетки.

Если используется традиционное полигональное моделирование, то 3D художнику необходимо от чего-то отталкиваться. Для этого используются так называемые референсы, или, по-другому, изображения того, что необходимо смоделировать. Это могут быть фотографии (для реальных предметов или персонажей), концепт-арты (для вымышленных), или даже существующие объекты. К примеру, необходимо смоделировать существующие кубики Lego. Самая в данном случае хорошая идея – иметь их под рукой и моделировать, непосредственно вертя в руках эти самые кубики.
Ниже изображение референса и 3D модели (без текстур).

Теперь вернемся к вопросу: а зачем при разработке 3D игры иметь в наличии сразу две модели одного и того же объекта — high poly и low poly? Высокополигональная модель непосредственно в игре использоваться не будет, но она необходима для такого важного процесса, как запекание текстур. Так называют подготовку целого ряда текстур или, как их еще называют, карт. Это обычные файлы изображений (с необычными, на первый взгляд, рисунками в них) цель которых как можно реалистичнее представить модель в игре и взять на себя, так сказать, часть геометрии. По сути – это создание 3D иллюзии там, где добиться этого полигонами сложно, неподъемно по производительности или просто нецелесообразно.

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

Ниже упрощенно схематически показано как смешивание запеченных с high poly модели карт, в сочетании с текстурой дерева, в результате дает реалистичное изображение.

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

Правда, тут есть один недостаток: эффект лучше всего действует когда наблюдатель расположен под углом 90° относительно полигонов с такой вот имитацией дополнительной геометрии. С уменьшением или увеличением угла обзора «обман» становится виден все отчетливее и отчетливее. Но это неизбежная плата за возможность приблизить картинку к реализму, не превратив игру в неиграбельную.

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

Если уж мы говорим про 3D в играх, то следует обязательно упомянуть такую технологию, как LOD, сокращенно от Level of Detail, она же уровень детализации. Суть ее сводится к тому, что в зависимости от того, насколько тот или иной объект близко располагается от игрового персонажа, или какой процент высоты экрана занимает, то используются модели с различного рода детализацией. Опять же, все ради оптимизации. Чем ближе к виртуальной камере тот или иной объект, тем более детализированная модель подставляется. На практике часто количество таких моделей ограничивается тремя: для переднего, среднего и заднего планов. И обозначаются, как правило: LOD_0, LOD_1, LOD_2. Это все варианты низкополигональной игровой модели.

Различные варианты полигональной детализации могут создаваться как в сторонних программах, так и автоматическими игровыми движками (очевидно, не всеми). Причем автоматически в сторону упрощения геометрии, т.е. загруженный в игровой движок вариант по умолчанию воспринимается как LOD_0. Иногда в играх, особенно с большими открытыми мирами, можно заметить как изначально угловатый и неказистый объект вдруг скачкообразно «похорошел» — это произошла замена на более высокополигональный LOD.

Вот, наверно, вкратце и все про полигоны. Если остались необозначенные или нераскрытые моменты – пишите про это в комментариях.

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

Источник