3D-моделирование персонажей для соло-разработчика игр

Основы 3D-моделирования, топологии и базового пайплайна

Представьте: вы — программист, открыли Blender впервые, за вечер налепили голову персонажа из сферы, импортировали в Unity, нажали Play — и лицо разъехалось в кашу при первом же повороте. Полигоны засвечиваются, тени ложатся пятнами, а при попытке добавить анимацию модель складывается как гармошка. Проблема не в движке и не в Blender — проблема в том, что без понимания топологии и пайплайна любая 3D-модель остаётся красивой болванкой, которая ломается в реальных условиях.

Эта статья — фундамент. Здесь нет ничего про художественный вкус или «почувствуй форму». Здесь — инженерные основы: как устроена полигональная сетка, почему направление рёбер влияет на анимацию, и какой порядок этапов превращает хаос в predictable workflow. Для программиста это самая важная глава курса — потому что топология работает по логике, а не по вдохновению.

Что такое полигональная сетка и почему это важно

Любая 3D-модель в играх — это набор полигонов (плоских граней), соединённых в сетку. Каждый полигон определяется вершинами (точками в пространстве) и рёбрами (линиями между вершинами). В реалтайм-рендере почти всегда используются треугольники — движок триангулирует четырёхугольники автоматически, но от того, как вы построили исходную сетку, зависит всё.

Представьте проволочный каркас, который обтянут плёнкой. Если проволока идёт ровно по контурам формы — плёнка ложится гладко. Если проволока нарезана хаотично — плёнка морщится, провисает, ломается при движении. Топология — это и есть «проволока» вашей модели.

Ключевые понятия, которые нужно запомнить с первого дня:

Вершина (vertex) — точка в 3D-пространстве с координатами , ,

Ребро (edge) — линия между двумя вершинами

Грань (face/polygon) — замкнутая область из трёх или четырёх вершин

Треугольник (triangle/tris) — грань из трёх вершин — минимальная единица рендеринга

Четырёхугольник (quad) — грань из четырёх вершин — предпочтительная единица моделирования

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

Топология: почему направление рёбер решает всё

Топология — это способ организации полигонов на поверхности модели. Не количество, а именно расположение и направление петель (edge loops) — непрерывных цепочек рёбер, обтекающих форму.

Почему это критично? Потому что при анимации скелет деформирует сетку: кость поворачивается, и вершины вокруг сустава смещаются. Если петли идут вдоль естественных линий сгиба — колено сгибается чисто. Если петли пересекают сустав хаотично — появляются артефакты: грани вдавливаются, тени ломаются, модель выглядит как надломленная.

Есть три типа петель, которые нужно уметь строить:

Контурные петли (contour loops) — обтекают форму по контуру мышц, костей, складок одежды. Определяют силуэт

Разделительные петли (edge loops) — проходят вокруг суставов (локоть, колено, плечо, пальцы). Обеспечивают чистую деформацию

Детализирующие петли — добавляют плотность сетки в зонах высокой детализации: лицо, кисти, элементы экипировки

Микропример: представьте локоть. Если петли идут горизонтально вокруг предплечья и плеча, а в зоне локтя есть достаточная плотность вершин — локоть сгибается с плавным радиусом. Если те же петли идут вертикально вдоль руки — при сгибании грани «сжимаются» и появляются острые складки, которых нет на реальной руке.

Quad против Tris и N-gons

В игровом моделировании действует простое правило: рабочая сетка строится из четырёхугольников (quads). Треугольники — финальный формат для движка, но при моделировании quads дают predictable subdivision (гладкое сглаживание), чистые петли и предсказуемую деформацию.

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

| Тип полигона | Использование | Проблемы | |---|---|---| | Quad (4 вершины) | Основная единица моделирования | Нет — стандарт индустрии | | Triangle (3 вершины) | Финальный формат для движка | Сложнее контролировать subdivision | | N-gon (5+ вершин) | Только плоские неподвижные поверхности | Артефакты освещения, ломается при анимации |

Для программиста: если вы пишете инструмент импорта или проверяете модель скриптом — проверяйте соотношение quads и tris. Модель с 90%+ quads — здоровая топология. Модель с 40%+ n-gons — проблема, которую нужно исправлять до рига.

Базовый пайплайн: от идеи до готовой модели

Пайплайн — это последовательность этапов, каждый из которых опирается на результат предыдущего. Пропускать этапы нельзя, но можно оптимизировать — об этом в следующих статьях. Сейчас — классическая десятишаговая схема, которая работает для 90% игровых персонажей:

Концепт-арт — 2D-эскиз с утверждённым силуэтом, пропорциями и ключевыми деталями

Blockout — быстрая 3D-заготовка из примитивов для проверки пропорций в объёме

High-poly скульптинг — детальная лепка формы в ZBrush или Blender Sculpt

Retopology — построение low-poly сетки поверх high-poly с правильной топологией

UV-развёртка — «расплющивание» 3D-поверхности на 2D-плоскость для текстур

Запекание карт (baking) — перенос деталей high-poly в текстурные карты (normal, AO)

Текстурирование — создание PBR-материалов (albedo, roughness, metallic)

Риггинг — построение скелета и настройка весов вершин

Скиннинг — привязка деформации сетки к костям скелета

Интеграция — импорт в движок, настройка шейдеров, тест анимаций

Этот пайплайн — не жёсткий закон, а карта. Для low-poly стилистики шаги 3 и 6 можно упростить. Для процедурных моделей — вообще заменить скриптами. Но если вы не знаете, зачем нужен каждый шаг — вы не сможете решить, что сократить.

Worked example: разбор топологии головы

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

Шаг 1: Петли вокруг глаз. Глаз — это сфера, которая вращается в глазнице. Петли должны идти концентрическими овалами вокруг глазного отверстия. Минимум три петли: одна по краю века, вторая — по орбите, третья — переход к скуле. Это обеспечивает моргание и движение бровей без артефактов.

Шаг 2: Петли вокруг рта. Рот — кольцевая мышца. Петли идут по контуру губ (верхняя и нижняя кайма), затем расходятся к щекам и подбородку. Ключевой момент: петли от рта должны соединяться с петлями от глаз через скуловую дугу — это «магистраль» лица, по которой передаётся деформация при улыбке и гримасе.

Шаг 3: Нос. Нос добавляет сложность: петли от глаз спускаются к переносице, расходятся по крыльям носа и соединяются с петлями от верхней губы. Здесь плотность вершин выше — нос активно деформируется при мимике.

Шаг 4: Уши. Ухо — отдельная «подмодель» с высокой плотностью quads. Оно крепится к голове через зону сглаживания, где петли головы плавно переходят в петли уха. Не пытайтесь строить ухо из той же сетки, что и череп — это усложнит и топологию, и UV.

Шаг 5: Затылок и лоб. Здесь плотность может быть ниже — эти зоны деформируются минимально. Петли от лица расходятся по черепу, постепенно укрупняясь. Главное — сохранить направление, чтобы subdivision давал гладкую поверхность.

Результат: на голове взрослого персонажа обычно 1500–3000 вершин. Для мобильной игры — ближе к 1500, для PC — до 3000. Лицо занимает примерно 30% бюджета вершин головы, хотя по площади это 15% поверхности — потому что деформация требует плотности.

Типичные ошибки начинающих

Программисты, приходящие в 3D, часто совершают одни и те же ошибки — потому что мыслят структурно, а не геометрически:

Слишком много полигонов с самого начала. Начинают sculptить с миллионом полигонов, не сделав blockout. Результат — правильные пропорции найти невозможно, потому что детали мешают видеть форму

Игнорирование направления петель. Сетка выглядит ровной, но петли пересекаются хаотически. При первой же анимации модель ломается

N-gons на лице. «Один пятиугольник не повредит» — повредит. Особенно в зоне рта или глаз, где деформация максимальна

Отсутствие симметрии. Моделируют половину головы без зеркалирования, тратя вдвое больше времени и получая асимметрию, которая бросается в глаза

Смешивание этапов. Начинают текстурировать, не сделав retopology. Или делают риг на high-poly модели. Каждый этап пайплайна существует не просто так

Если из этой статьи запомнить три вещи — это:

Топология — это структура данных вашей модели. Направление петель определяет, будет ли модель правильно деформироваться при анимации

Пайплайн — это последовательность зависимых этапов. Пропуск шага всегда дороже, чем его выполнение

Quads — стандарт моделирования. Триангуляция происходит на этапе экспорта в движок, а не при построении сетки

Создание high-poly и low-poly персонажей, текстурирование и запекание карт

Когда вы видите в игре персонажа с детализированной бронёй, видимыми заклёпками, царапинами на металле и складками на ткани — вы почти наверняка смотрите на low-poly модель с текстурами, а не на миллион полигонов. Вся эта деталь живёт в текстурных картах, которые были «запечены» с high-poly версии. Это центральный трюк реалтайм-рендера: визуальная сложность при минимальной геометрической стоимости.

Для программиста эта связка — high-poly → retopology → baking → texturing — работает как компиляция: вы пишете код на высокоуровневом языке (скульпт), компилируете в оптимизированный байткод (low-poly), а runtime-детали хранятся в ресурсах (текстуры). Понимание этого процесса — ключ к созданию моделей, которые выглядят профессионально и работают на 60 FPS.

High-poly: зачем нужна модель, которая не пойдёт в игру

High-poly модель — это детализированная версия персонажа с сотнями тысяч или миллионами полигонов. В игру она не попадает никогда. Её единственная задача — быть источником деталей, которые будут перенесены в текстуры через процесс запекания (baking).

Скульптинг в ZBrush или Blender Sculpt — это цифровая лепка. Вы работаете кистями, которые смещают вершины: добавляете объём, вдавливаете складки, вырезаете детали. Каждый полигон на high-poly — это инвестиция в будущую текстуру. Чем детальнее скульпт, тем качественнее normal map, тем реалистичнее выглядит low-poly модель.

Типичные бюджеты полигонов для high-poly персонажа:

Голова и лицо: 500 000–2 000 000 полигонов

Тело: 300 000–1 000 000 полигонов

Элементы экипировки: 100 000–500 000 каждый

Итого: 1–4 миллиона полигонов на персонажа

Микропример: на скульпте вы вырезаете каждую заклёпку на нагруднике — по 200 полигонов на штуку, 30 заклёпок — 6000 полигонов. На low-poly модели заклёпок нет вообще — они «живут» в normal map как рельеф, который ловит свет и отбрасывает тени. Визуальный эффект тот же, стоимость рендеринга — в сотни раз ниже.

Retopology: построение игровой модели

Retopology (ретопология) — это построение новой полигональной сетки поверх high-poly модели. Новая сетка имеет на порядки меньше полигонов, но повторяет общую форму и содержит правильные петли для анимации.

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

Бюджеты полигонов для low-poly персонажа зависят от платформы:

| Платформа | Тело | Голова | Всего на персонажа | |---|---|---|---| | Мобильные игры | 3 000–7 000 | 1 500–3 000 | 5 000–15 000 | | PC / Консоли (средний) | 15 000–30 000 | 5 000–10 000 | 20 000–50 000 | | PC / Консоли (AAA) | 30 000–80 000 | 8 000–20 000 | 40 000–100 000 |

При ретопологии соблюдайте три правила:

Петли вокруг суставов — минимум три петли в зоне каждого сгиба (локоть, колено, плечо, пальцы). Меньше — деформация будет ломаться

Равномерный размер полигонов — резкие переходы от крупных к мелким граням создают артефакты при subdivision и baking

Симметрия — моделируйте половину, зеркальте. Экономит время и гарантирует симметричную деформацию

Инструменты для ретопологии: в Blender — модификатор Shrinkwrap + ручное построение или аддон RetopoFlow. В ZBrush — ZRemesher для автоматического варианта (но он даёт приемлемый, а не идеальный результат). Для программистов, которые любят контроль, ручная ретопология — единственный способ получить действительно чистую сетку.

UV-развёртка: распаковка 3D в 2D

UV-развёртка — это процесс «расплющивания» трёхмерной поверхности модели на двумерную плоскость, чтобы на неё можно было наложить текстуру. Буквы U и V — это оси координат текстурного пространства (аналог и , но чтобы не путать с мировыми координатами).

Представьте, что вы разрезаете бумажную модель по швам и раскладываете на столе. Там, где разрез — шов (seam). Там, где бумага мнётся при раскладывании — искажение (distortion). Задача — минимизировать швы на видимых поверхностях и добиться равномерного распределения текстуры.

Ключевой параметр — texel density (плотность текселей). Это количество пикселей текстуры на единицу площади модели. Если texel density неравномерен — лицо персонажа выглядит чётким, а спина — размытой. Для игровых моделей texel density должен быть одинаковым на всех видимых участках, допустимое отклонение — не более 20%.

Практические правила UV для персонажа:

Швы прячутся: под волосами, за ушами, в подмышках, по внутренней стороне ног, под подошвой

Голова — отдельный остров (UV island) с минимальным количеством швов. Лицо — приоритетная зона, texel density выше среднего

Симметричные детали (руки, ноги) можно зеркалировать в UV — одна текстура на обе стороны. Экономит память, но создаёт заметную симметрию на деталях (царапины, грязь)

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

Запекание карт: перенос деталей с high-poly на low-poly

Baking (запекание) — это процесс проецирования деталей с high-poly модели на текстурные карты low-poly модели. Результат — набор изображений, которые заставляют плоскую сетку выглядеть как детализированный скульпт.

Основные карты, которые запекаются:

Normal map — хранит информацию о направлении поверхности (нормали) каждого пикселя. Заставляет свет отражаться так, будто на модели есть мелкий рельеф, которого нет в геометрии. Фиолетово-синяя текстура, которую вы наверняка видели

Ambient Occlusion (AO) — карта теней в углублениях и местах контакта поверхностей. Добавляет глубину и объём без дополнительного освещения

Curvature — карта кривизны: белым отмечаются выпуклые рёбра, чёрным — вогнутые. Используется при текстурировании для автоматического нанесения износа и грязи на рёбра и углубления

Position / World Space — положение каждой точки в мировых координатах. Используется для процедурных эффектов в шейдерах

При запекании возникают типичные проблемы, которые нужно уметь решать:

Расхождение сеток (cage mismatch) — если low-poly модель не совпадает с high-poly, лучи проекции «промахиваются», и на карте появляются артефакты. Решение — настроить cage (оболочку проекции) или увеличить ray distance

Пересечение UV-островов — если два острова накладываются друг на друга, детали одного участка «протекают» на другой. Решение — проверить UV на отсутствие пересечений и добавить отступы (padding) между островами

Швы на normal map — видимые линии на границах UV-островов. Решение — достаточный padding (4–8 пикселей на 2K текстуру) и правильная настройка tangent space

Микропример: вы запекаете normal map для рук персонажа. На high-poly каждая жилка и морщина проработана. После baking на low-poly руке (500 полигонов) видны все эти детали — при боковом освещении кожа выглядит реалистично, хотя геометрически это просто цилиндр.

Текстурирование в PBR-подходе

PBR (Physically Based Rendering) — это подход к созданию материалов, при котором текстуры описывают физические свойства поверхности, а не «цвет под определённым освещением». PBR гарантирует, что материал будет выглядеть корректно при любом освещении — в тёмном подземелье и на ярком солнце.

Базовый PBR-набор текстурных карт для персонажа:

| Карта | Что хранит | Пример | |---|---|---| | Albedo (Base Color) | Чистый цвет без теней и бликов | Цвет кожи, металла, ткани | | Roughness | Шероховатость: 0 — зеркало, 1 — матовое | Кожа — 0.5, полированный металл — 0.1 | | Metallic | Металличность: 0 — диэлектрик, 1 — металл | Броня — 1.0, кожа — 0.0 | | Normal | Направление поверхности (запекается) | Рельеф складок, заклёпок | | AO | Тени в углублениях (запекается) | Тень под ремнём, между пальцами |

Для программиста: в шейдере PBR-материал выглядит примерно так — albedo умножается на освещение, roughness определяет ширину блика, metallic переключает между диэлектрической и металлической моделью отражения. Если вы пишете кастомный шейдер — эти пять карт дают полный контроль над внешним видом любой поверхности.

В Substance Painter текстурирование идёт слоями: базовый материал → маски износа → грязь → детали. Каждый слой использует запечённые карты (AO, curvature) для автоматического распределения: грязь скапливается в углублениях, краска облупливается на рёбрах, пот разводится в складках.

Если из этой главы запомнить три вещи — это:

High-poly существует только как источник деталей для текстур. В игру идёт low-poly, а визуальная сложность живёт в normal map и PBR-картах

Retopology — это не упрощение, а построение новой, чистой архитектуры. Правильные петли вокруг суставов критичны для анимации

PBR-текстуры описывают физические свойства, а не цвет. Пять карт (albedo, roughness, metallic, normal, AO) дают полный контроль над любым материалом

Композиция, пропорции, силуэт и readability персонажей в игровой сцене

В 2017 году Blizzard выпустила Overwatch, и игроки мгновенно узнавали любого персонажа по чёрному силуэту на белом фоне — даже без текстур, без цвета, без анимации. Это не магия и не талант отдельных художников. Это результат осознанной работы над силуэтом, пропорциями и readability — тремя китами визуального дизайна персонажа, которые важнее полигонов и текстур.

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

Силуэт: первый и главный тест

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

Почему силуэт так важен? Потому что человеческий мозг распознаёт формы быстрее, чем детали. В геймплее игрок видит персонажа доли секунды — на периферии зрения, на расстоянии, в хаосе боя. Силуэт — это первое, что считывается. Цвет и текстура — вторичны.

Три приёма для усиления силуэта:

Асимметрия. Симметричный персонаж — это статуя. Одно плечо выше другого, наклон головы, непропорциональный элемент (огромное плечо, длинный плащ, перекошенный шлем) мгновенно делают силуэт запоминающимся

Контраст масштабов. Тонкие ноги и массивный торс. Огромная голова и хрупкое тело. Маленький персонаж с гигантским оружием. Контраст пропорций создаёт характер без единого слова

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

Микропример: представьте двух рыцарей в полной броне. Первый — симметричный, стандартный, с мечом и щитом. Второй — с асимметричным наплечником, перекошенным забралом и копьём за спиной. На расстоянии 50 метров в игре вы мгновенно отличите второго от любого другого NPC. Первый сольётся с окружением.

Проверка: нарисуйте или сгенерируйте силуэт персонажа в чёрном на белом. Покажите знакомому на 2 секунды и спросите: «Это танк или ассасин? Это босс или обычный враг?» Если ответ правильный — силуэт работает.

Пропорции: язык тела без слов

Пропорции — это соотношение частей тела друг к другу. В реалистичном дизайне используется 7.5–8 голов на тело (академический канон). Но в играх пропорции почти всегда искажены — и это осознанное решение, которое передаёт роль персонажа.

Как пропорции кодируют информацию:

Танк / тяжёлый класс: голова маленькая относительно тела, широкие плечи, толстые конечности, низкий центр тяжести. 5–6 голов на тело. Передаёт: мощь, несокрушимость, медлительность

Ассасин / лёгкий класс: голова крупнее, узкие плечи, длинные конечности, высокий центр тяжести. 7–8 голов на тело. Передаёт: скорость, хрупкость, гибкость

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

Для соло-разработчика практическое правило: определите пропорции на этапе blockout и не меняйте их после начала скульптинга. Решение о пропорциях — это геймдизайнерское решение, а не художественное. Оно определяет hitbox, скорость анимации, размер на экране и читаемость роли.

Таблица пропорций для типовых ролей:

| Роль | Рост (головы) | Ширина плеч | Длина ног | Ключевой акцент | |---|---|---|---|---| | Танк | 5–6 | 3–4 головы | Короткие | Торс, наплечники | | Воин | 6–7 | 2.5–3 головы | Средние | Оружие, щит | | Ассасин | 7–8 | 2–2.5 головы | Длинные | Конечности, клинок | | Маг | 6.5–7.5 | 2–2.5 головы | Средние | Руки, посох, голова |

Readability: видно ли персонажа в реальной сцене

Readability — это способность персонажа считываться в контексте игровой сцены: на фоне окружения, в движении, при сложном освещении, на разных расстояниях и размерах экрана. Силуэт — часть readability, но не вся.

Readability ломается по трём причинам:

Персонаж сливается с фоном. Зелёный эльф в лесу, серый робот на бетонном заводе. Решение — контрастный акцент: яркий цвет на ключевых элементах (пояс, наплечники, оружие), не совпадающий с палитрой окружения

Мелкие детали теряются на расстоянии. Кружево на манжетах, тонкая гравировка на мече — на расстоянии 20 метров в игре это просто шум. Решение — крупные цветовые пятна и чёткие формы, которые видны и вблизи, и издали

В движении персонаж распадается. Если при беге плащ, волосы и аксессуары болтаются в разные стороны — силуэт теряется. Решение — контролировать динамические элементы, не перегружать их количество

Приём, который используют арт-директора AAA-студий: трёхсекундный тест. Персонаж появляется на экране. Если за три секунды игрок понимает, кто это, что он делает и представляет ли угрозу — readability работает. Если нет — нужна доработка.

Ещё один инструмент — цветовая иерархия. На персонаже должно быть не более трёх доминирующих цветов. Один — основной (60–70% площади), второй — акцентный (20–30%), третий — детальный (5–10%). Слишком много цветов — персонаж выглядит как новогодняя ёлка. Слишком мало — сливается в монотонное пятно.

Микропример: в Team Fortress 2 каждый класс имеет уникальный силуэт И уникальный цвет. Пулемётчик — красный, толстый, с огромным оружием. Скаут — красный, худой, с двустволкой. Даже если оба красные — силуэт не даёт их спутать. А если силуэт похож — цвет разводит.

Композиция персонажа: баланс и фокус

Композиция внутри самого персонажа — это распределение визуального веса: где детали гуще, где пустота, куда падает взгляд. Хорошая композиция ведёт взгляд игрока к ключевым элементам: лицу, оружию, символу фракции.

Принцип фокусной точки: на персонаже должна быть одна зона, которая притягивает взгляд первой. Обычно это лицо или оружие. Всё остальное — поддержка. Если каждая часть персонажа одинаково детализирована — взгляд блуждает и не зацепляется.

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

Приём «градиент детализации»: от центра (лицо, грудь) к периферии (ноги, спина) детализация убывает. Это имитирует естественное зрение — мы смотрим на лицо и верхнюю часть тела, а ноги и спину воспринимаем периферийно.

Worked example: проектирование NPC-торговца

Давайте спроектируем NPC-торговца для фэнтези-RPG, следуя принципам этой главы.

Шаг 1: Роль и readability. Торговец — не боевой NPC. Игрок должен мгновенно отличить его от врага. Решение: открытая поза (руки разведены, жест «подходи»), отсутствие оружия, яркая одежда, контрастирующая с бронированными NPC.

Шаг 2: Силуэт. Торговец сидит за прилавком или стоит с расставленными ногами. Силуэт — широкий, устойчивый, низкий центр тяжести. Добавляем выступающие элементы: высокий колпак, кувшин за поясом, фонарь на палке. Силуэт становится узнаваемым — вы его не спутаете с воином.

Шаг 3: Пропорции. 6 голов на тело, пузатый торс, короткие ноги. Это передаёт: неопасность, комичность, доступность. Игрок интуитивно понимает — с этим NPC можно торговать, а не драться.

Шаг 4: Цветовая иерархия. Основной цвет — тёплый коричневый (кожа, ткань, 60%). Акцентный — золотой (монеты, пряжка, 25%). Детальный — красный (шарф, 15%). На фоне серого каменного города торговец выделяется тёплой палитрой.

Шаг 5: Фокусная точка. Лицо — улыбка, усы, блестящие глаза. Вторичный фокус — прилавок с товарами (визуальный индикатор «здесь можно торговать»). Взгляд игрока находит лицо, затем скользит к прилавку — и понимает функцию NPC без единого диалога.

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

Если из этой главы запомнить три вещи — это:

Силуэт — первый и главный тест персонажа. Если по чёрному контуру нельзя определить роль — дизайн провален. Проверяйте каждый персонаж через «чёрный силуэт на белом фоне»

Пропорции кодируют информацию о роли без слов. Танк — широкий и низкий, ассасин — узкий и высокий. Определите пропорции на этапе blockout и не меняйте их

Readability — это не красота, а функциональность. Трёхсекундный тест, контраст с фоном, цветовая иерархия из трёх цветов — вот инструменты, которые гарантируют видимость персонажа в реальной сцене

Оптимизация моделей для игровых движков: полигоны, LOD, текстуры и draw calls

В 2020 году Genshin Impact запустился на смартфонах с открытым миром, десятками персонажей и эффектами частиц — и стабильно держал 30 FPS на средних устройствах. Секрет не в магии движка, а в жёсткой оптимизации: каждый персонаж имел точный бюджет полигонов, текстуры были сжаты под мобильные форматы, а LOD-система подгружала упрощённые модели на расстоянии. Без этой работы игра бы не запустилась ни на чём, кроме флагманов.

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

Полигональный бюджет: сколько полигонов допустимо

Полигональный бюджет — это лимит на количество треугольников, которое движок может отрисовать за один кадр на целевом устройстве. Бюджет распределяется между всеми объектами сцены: персонажами, окружением, эффектами, интерфейсом.

Бюджет — не произвольное число. Он зависит от fill rate (скорости заполнения пикселей), вершинной обработки на GPU и количества объектов в сцене. Формула проста: чем больше объектов в кадре — тем меньше полигонов на каждый.

Ориентиры по платформам для одного персонажа:

| Платформа | Тело | Голова | Оружие / аксессуары | Итого | |---|---|---|---|---| | Мобильные (средние) | 3 000–5 000 | 1 500–2 500 | 500–1 500 | 5 000–10 000 | | Мобильные (флагманы) | 7 000–15 000 | 3 000–5 000 | 1 500–3 000 | 12 000–25 000 | | PC / Консоли | 15 000–50 000 | 5 000–15 000 | 3 000–10 000 | 25 000–80 000 | | VR | 10 000–25 000 | 5 000–10 000 | 2 000–5 000 | 18 000–40 000 |

Микропример: в сцене вашего платформера 10 врагов на экране одновременно, каждый по 8000 треугольников — это 80 000 трисов только на врагов. Добавьте окружение (50 000), героя (15 000), эффекты (10 000) — итого 155 000 трисов. Для мобильного GPU это уже близко к потолку. Если каждый враг будет по 20 000 — вы удвоите нагрузку и получите просадки FPS.

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

LOD-система: разная детализация на разных расстояниях

LOD (Level of Detail) — это система, которая переключает между несколькими версиями одной модели в зависимости от расстояния до камеры. Вблизи показывается LOD0 (полная детализация), на среднем расстоянии — LOD1 (упрощённая), вдали — LOD2 (максимально простая).

Зачем это нужно? Потому что человеческий глаз не различает детали на расстоянии. Персонаж в 200 метрах от камеры — это 50 пикселей на экране. Зачем рисовать на нём 50 000 треугольников, если 5 000 дадут тот же визуальный результат?

Типичная LOD-цепочка:

| Уровень | Полигоны | Дистанция переключения | Примечание | |---|---|---|---| | LOD0 | 100% (например, 30 000 трисов) | 0–10 м | Полная модель | | LOD1 | 50% (15 000 трисов) | 10–25 м | Укрупнённые детали | | LOD2 | 25% (7 500 трисов) | 25–50 м | Только силуэт | | LOD3 / Cull | 10% или скрытие | 50+ м | Billboards или полное скрытие |

В Unity LOD-система настраивается через компонент LOD Group: вы назначаете несколько мешей и задаёте пороги переключения по проценту высоты экрана. Когда персонаж занимает менее 20% высоты экрана — показывается LOD1, менее 5% — LOD2.

Важный нюанс: LOD-переключение не должно быть заметным. Если при переходе с LOD0 на LOD1 модель «прыгает» — игрок это замечает и это раздражает. Решение: плавный кроссфейд между LOD-уровнями (dithering) или аккуратное выравнивание силуэтов на стыках.

Для программиста: LOD можно генерировать автоматически (модификатор Decimate в Blender, Simplygon, встроенная генерация в Unity). Но автоматика часто ломает топологию в критических зонах — лице, руках, суставах. Проверяйте LOD1 и LOD2 визуально, особенно анимацию лица.

Текстурная оптимизация: форматы, сжатие, атласы

Текстуры — главный потребитель видеопамяти (VRAM). Одна некомпрессированная текстура 4096×4096 в формате RGBA — это 64 МБ. Персонаж с пятью картами PBR (albedo, normal, roughness, metallic, AO) — 320 МБ только текстур. На мобильном устройстве с 2–4 ГБ общей памяти это катастрофа.

Форматы сжатия текстур и их применение:

| Формат | Платформа | Степень сжатия | Качество | |---|---|---|---| | ASTC | Мобильные (современные) | 8:1–16:1 | Хорошее, гибкие блоки | | ETC2 | Android (старые) | 4:1–8:1 | Среднее, артефакты на градиентах | | DXT / BC | PC | 4:1–8:1 | Хорошее для diffuse, хуже для normal | | BC7 | PC (современные) | 3:1–4:1 | Отличное, но тяжёлое |

Практические правила:

Albedo — можно сжимать агрессивно. Глаз прощает потерю мелких цветовых деталей

Normal map — сжимать осторожно. Артефакты на нормалях проявляются как «ступенчатые» блики и неровности освещения. Используйте форматы с минимальными потерями или двухканальные normal maps (RG вместо RGB)

Roughness / Metallic — часто можно хранить в одном канале (R — roughness, G — metallic), экономя одну текстуру целиком

AO — можно запекать в канал albedo (применять как multiply-слой в шейдере), убрав отдельную карту

Текстурные атласы — объединение нескольких мелких текстур в одну большую. Если у персонажа 10 отдельных материалов (кожа, металл, ткань, дерево, пластик) — это 10 draw calls на каждый. Объединив их в один атлас, вы сокращаете draw calls до одного. Особенно критично для мобильных платформ, где лимит draw calls — 100–200 на весь кадр.

Draw calls: скрытый убийца производительности

Draw call — это команда GPU на отрисовку одного набора полигонов с определённым материалом. Каждый draw call — это overhead: CPU готовит данные, отправляет команду, GPU переключает состояние. Чем больше draw calls — тем больше времени CPU тратит на подготовку, а не на логику игры.

Для программиста: draw call — это как вызов функции. Если вы вызываете 500 функций по одной — это медленнее, чем вызвать 5 функций, каждая из которых обрабатывает 100 элементов. Batching — это объединение draw calls.

Источники draw calls на персонаже:

Каждый отдельный материал = 1 draw call

Каждый отдельный меш = 1 draw call (если не батчится)

Каждая текстура, не входящая в атлас = потенциально +1 draw call

Практический пример: персонаж с 5 материалами (кожа, броня, ткань, металл, волосы) — это 5 draw calls. Если волосы — отдельный меш с отдельным материалом — +1. Оружие в руке — +1–2. Итого: 7–8 draw calls на одного персонажа. При 20 персонажах в сцене — 140–160 draw calls только на персонажей.

Как сокращать draw calls:

Объединение мешей: Merge все части тела в один меш (если не нужна раздельная видимость)

Текстурные атласы: один материал на весь персонаж = один draw call

GPU Instancing: если десятки одинаковых NPC — instancing рисует их все за один draw call

SRP Batcher (Unity URP/HDRP): автоматическое батчирование шейдеров с одинаковой структурой

Микропример: в Hollow Knight каждый враг — это спрайт на одном атласе. Даже в пиковых сценах с 30+ врагами draw calls не превышают 50. В 3D-аналоге: если все враги используют один материал с атласом и GPU instancing — вы получаете тот же эффект.

Профилирование: как найти узкое место

Оптимизация без данных — это гадание. Любой движок предоставляет инструменты профилирования, которые показывают, где именно уходит время.

В Unity: Profiler (Window → Analysis → Profiler) — показывает CPU usage, GPU usage, rendering, memory. Ключевые метрики:

CPU: Rendering — время на подготовку draw calls. Если высокое — проблема в количестве объектов или материалов

GPU: Render — время на отрисовку. Если высокое — проблема в полигонах, шейдерах или разрешении

Memory — потребление RAM и VRAM. Если текстуры съедают 80% — нужна оптимизация текстур

Batches и SetPass calls — прямые индикаторы количества draw calls

В Unreal Engine: Stat GPU, Stat Unit, GPU Visualizer — аналогичные инструменты с более детальной разбивкой по pass'ам рендеринга.

Алгоритм оптимизации:

Запустите профайлер на целевом устройстве (не в редакторе — на реальном телефоне или консоли)

Найдите самый тяжёлый кадр (спайк)

Определите: CPU-bound или GPU-bound?

Если CPU — сокращайте draw calls, упрощайте физику, оптимизируйте скрипты

Если GPU — снижайте полигонаж, упрощайте шейдеры, уменьшайте разрешение текстур или экрана

Повторяйте, пока FPS не станет стабильным

Если из этой главы запомнить три вещи — это:

Полигональный бюджет — это не рекомендация, а лимит. Ведите таблицу бюджета и проверяйте каждый импортированный ассет. Для мобильных — 5 000–15 000 трисов на персонажа, для PC — до 80 000

LOD-система экономит до 60–80% GPU-нагрузки на удалённых объектах. Настройте LOD Group для каждого персонажа и проверяйте визуальные прыжки при переключении

Draw calls — скрытый потребитель производительности. Один материал на персонажа, текстурные атласы, GPU instancing — вот три инструмента, которые сокращают draw calls в разы

Профессиональный workflow соло-разработчика: от концепта до интеграции в игру

Когда вы работаете в одиночку, у вас нет роскоши делегировать. Нет арт-директора, который утвердит концепт. Нет технического художника, который проверит топологию. Нет QA, который найдёт артефакт на десятом LOD. Вы — и программист, и художник, и продюсер, и тестировщик. И единственный способ не сойти с ума — это workflow: заранее спланированный порядок действий, где каждый шаг имеет чёткий критерий готовности и точку возврата.

Эта статья — практическая карта. Не абстрактные принципы, а конкретный пайплайн с таймингами, чек-листами и решениями для ситуации, когда вы не уверены в художественной стороне. Потому что для программиста главная проблема не в том, как нажимать кнопки в Blender — а в том, как не потратить три недели на модель, которая не работает в сцене.

Принцип «сначала работает, потом красиво»

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

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

Порядок, который экономит время соло-разработчику:

Концепт — 2D-силуэт, максимум 2 часа. Не рисуйте детали — рисуйте формы

Blockout в движке — 1–2 часа. Примитивы (капсулы, цилиндры) вместо финальной модели. Проверяете пропорции, размер, readability в реальной сцене

Скульптинг — 4–12 часов. Только после утверждённого blockout

Retopology — 3–6 часов. Строго по бюджету полигонов вашей целевой платформы

UV и baking — 2–4 часа. Проверяете карты в движке до начала текстурирования

Текстурирование — 3–8 часов. Начинайте с базовых материалов, добавляйте детали итеративно

Риг и скиннинг — 2–4 часа. Тестируйте деформацию ключевых поз в движке

Анимации — по необходимости. Не делайте 50 анимаций сразу — начните с 5–7 ключевых

Финальная интеграция и оптимизация — 2–4 часа. LOD, проверка draw calls, профилирование

Итого: 20–40 часов на одного персонажа от концепта до готового ассета. Для первого персонажа — ближе к 40, для пятого — ближе к 20. Это нормальный темп для соло-разработчика.

Инструментарий: минимум для максимума

Соло-разработчику не нужно 15 программ. Нужен стабильный набор, в котором вы уверены:

| Задача | Рекомендуемый инструмент | Альтернатива | |---|---|---| | Моделирование и скульптинг | Blender | ZBrush (платный, мощнее для скульпта) | | Текстурирование | Substance Painter | Quixel Mixer (бесплатный с Megascans) | | UV-развёртка | Blender (встроенный) | RizomUV (специализированный) | | Риггинг | Blender (Armature) | Maya (индустриальный стандарт) | | Игровой движок | Unity или Unreal Engine | Godot (бесплатный, лёгкий) | | Профилирование | Встроенный Profiler движка | RenderDoc (детальный GPU-анализ) |

Blender — ваш центральный хуб. Бесплатный, open-source, с сообществом, которое генерирует тонны обучающих материалов. Для соло-разработчика Blender закрывает 80% задач: моделирование, скульпт, retopology, UV, простой риг, экспорт. Substance Painter — для текстур, потому что его слойная система и PBR-инструменты на порядок эффективнее ручного рисования в Photoshop.

Микропример: вы закончили retopology в Blender. Экспортируете low-poly как FBX, импортируете в Substance Painter, запекаете карты с high-poly, текстурируете, экспортируете текстуры и меш обратно. Импортируете в Unity. Весь цикл — три программы, ни одной лишней.

Управление ассетами: как не потеряться в файлах

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

Структура папок, которая работает:

Правила именования: CharacterName_Part_LOD0.fbx, CharacterName_Albedo_2K.png. Версионирование: _v01, _v02 — или Git LFS для бинарных файлов. Не используйте «финальная», «финальная2», «финальная_НАСТОЯЩАЯ» — это путь к хаосу.

Чек-лист готовности персонажа

Перед тем как считать персонажа «готовым», пройдитесь по этому списку. Каждый пункт — конкретная проверка, а не общее «всё работает»:

Пропорции совпадают с blockout и концептом

Полигональный бюджет не превышен (проверить в Inspector движка)

Топология: 90%+ quads, нет n-gons на деформируемых участках

UV: нет пересечений островов, texel density равномерный, швы спрятаны

Normal map запечена без артефактов (проверить при боковом освещении)

PBR-текстуры корректны: metallic 0 или 1 для стандартных материалов, roughness в диапазоне

Риг: все кости на месте, иерархия правильная, симметрия соблюдена

Скиннинг: проверить деформацию в крайних позах (согнутый локоть, поднятая рука, поворот головы)

LOD: LOD1 и LOD2 сгенерированы, визуальные прыжки отсутствуют

Draw calls: один материал на персонажа (или минимальное количество)

Модель корректно отображается при разном освещении (дневной свет, точечный, тёмная сцена)

Анимации работают без артефактов (проверить бег, прыжок, атаку)

Worked example: создание NPC-стражника от начала до конца

Давайте пройдём весь пайплайн на конкретном примере — NPC-стражника для 3D-RPG.

Шаг 1: Концепт (1.5 часа). Рисуем три силуэта: стандартный рыцарь, лёгкий разведчик, тяжёлый гвардеец. Выбираем гвардейца — массивный, с закрытым шлемом и алебардой. Силуэт уникален: широкий торс, высокий шлем, вертикальное оружие. Фиксируем: 5.5 голов на тело, тёмно-синяя броня с золотыми акцентами.

Шаг 2: Blockout (1 час). В Blender собираем фигуру из капсул и цилиндров. Экспортируем в Unity. Проверяем: стражник вписывается в окружение замка, не перекрывает UI, readability на расстоянии 15 метров — отличная (силуэт шлема + алебарды считывается мгновенно).

Шаг 3: Скульптинг (8 часов). Лепим high-poly в Blender Sculpt: тело, броня с заклёпками и гравировкой, шлем с забралом, алебарда. Итого: ~1.5 миллиона полигонов.

Шаг 4: Retopology (4 часа). Строим low-poly поверх high-poly. Бюджет: 12 000 трисов (мобильная RPG). Петли вокруг суставов — по три. Шлем — отдельный меш (чтобы можно было снимать в кат-сценах). Алебарда — отдельный меш (для физики).

Шаг 5: UV и baking (3 часа). Швы: подмышками, по внутренней стороне ног, под шлемом. Все части тела — один UV-сет. Запекаем: normal, AO, curvature. Проверяем в Unity — артефактов нет.

Шаг 6: Текстурирование (5 часов). Substance Painter: базовый металл → маска износа на рёбрах → грязь в углублениях (по curvature) → золотые инкрустации на наплечниках. Экспортируем: albedo, normal, roughness-metallic (packed), AO.

Шаг 7: Риг (2 часа). Используем стандартный Humanoid rig из шаблона. Скиннинг: проверяем локти, колени, плечи. Шлем жёстко привязан к голове (без деформации).

Шаг 8: Анимации (4 часа). Пять базовых: idle, walk, run, attack, hit reaction. Используем готовые анимации из Mixamo + ручная коррекция.

Шаг 9: Интеграция (2 часа). LOD1 и LOD2 через Decimate. Один материал (все части тела + шлем + алебарда). Проверка draw calls: 1 на стражника. Профайлер: 0.2 мс на стражника при 20 NPC в сцене.

Итого: 30.5 часов. Результат: персонаж, который выглядит профессионально, работает на 60 FPS на среднем смартфоне и уникально считывается в любой сцене.

Типичные ловушки и как их избежать

Даже с правильным пайплайном соло-разработчики попадают в одни и те же ловушки:

«Сделаю идеально с первого раза». Не сделаете. Планируйте минимум две итерации на персонажа. Первая — рабочая, вторая — полированная

«Сначала все персонажи, потом все анимации». Нет. Заканчивайте персонажа целиком (модель + текстуры + риг + 5 анимаций) перед переходом к следующему. Иначе у вас будет 10 моделей без анимаций, и ни одна не протестирована в геймплее

«Экономлю на текстурах». Текстуры 512×512 на персонажа, который занимает пол-экрана — это не оптимизация, а потеря качества. Используйте 2048 для основных персонажей, 1024 для NPC, 512 только для фоновых объектов

«Не проверяю в движке до конца». Каждый этап — импорт, проверка, фикс. Модель, которая отлично выглядит в Blender, может выглядеть ужасно в Unity из-за другого освещения, шейдера или масштаба

Если из этой главы запомнить три вещи — это:

Workflow — это последовательность с точками проверки. Каждый этап заканчивается импортом в движок. Не переходите к деталям, пока основа не подтверждена в реальной сцене

Минимальный инструментарий: Blender + Substance Painter + ваш движок. Три программы закрывают весь пайплайн. Не распыляйтесь на 10 софтов

Чек-лист готовности — ваш QA. 12 пунктов проверки гарантируют, что персонаж работает в движке, а не только выглядит хорошо в редакторе