Знакомая ситуация: в Houdini ваш меш гордо показывает 10k полигонов, вы импортируете его в Unreal Engine 5, открываете статистику и видите... 20k, а то и все 30k «вертексов».

Где ошибка? Нигде. Просто PolyCount в DCC-софте и игровом движке — это две разные реальности. Давайте разберём, почему цифры расходятся и за чем на самом деле нужно следить Tech Artist-у.

Houdini — мир процедурной логики, где мы обожаем Quads (четырёхугольники). Это удобно для топологии и деформаций. Но видеокарты работают только с треугольниками, поэтому любой движок триангулирует меш при импорте.

С чистыми квадами всё предсказуемо: 1 квад → 2 треугольника, поликаунт удваивается. Но если в вашей сетке есть нгоны (5+ рёбер) — будьте осторожны: алгоритм триангуляции в Houdini и в Unreal может разбить их по-разному. Итог — артефакты на поверхности или неожиданная топология уже в движке.

Золотое правило: триангулируйте меш сами в Houdini нодой divide перед экспортом — и вы точно знаете, что получите на той стороне. Если меш состоит из чистых квадов, треугольников станет ровно в 2 раза больше. Если есть нгоны — итоговое число зависит от сложности их разбиения.

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

В Houdini Point — это просто точка в пространстве. В Unreal (и на уровне GPU) существует понятие GPU Vertex — уникальная комбинация данных:

Если хотя бы один из этих параметров «разрывается» — видеокарта дублирует вершину.

UV Seams (Швы): точка на границе UV-островка превращается в две и более вершины, потому что у них разные UV-координаты.

Hard Edges (Жёсткие рёбра): нормали соседних полигонов смотрят в разные стороны — движок дробит одну точку на несколько, чтобы записать разные данные нормалей.

Классический пример — куб:

3. Фактор Nanite: треугольники больше не проблема?

С приходом UE5 и Nanite количество треугольников перестало быть узким горлышком для рендера. Но это не значит, что на оптимизацию можно забить.

Три момента, которые Nanite не решает:

Overshading: слишком плотная сетка с треугольниками меньше пикселя всё равно убивает производительность шейдинга.

Стоимость памяти: каждый треугольник и вершина — это данные на диске и в VRAM. Миллионы лишних полигонов раздувают билд.

Draw Calls: Nanite крут, но количество материалов на объекте по-прежнему влияет на количество вызовов отрисовки.

Это большая отдельная тема — в следующем посте разберу Nanite подробно: как он стримит геометрию, где реально помогает, а где создаёт ложное чувство безопасности.

Синхронизация швов: делайте Hard Edges только по границам UV-островков. Это стандарт, который экономит тысячи GPU-вершин.

Houdini-контроль: используйте ноду Labs Calculate Vertex Count — она даст цифру, максимально близкую к реальности движка, ещё до экспорта.

Unreal-статистика: смотрите не на общее количество треугольников в сцене, а на Resource Usage и конкретно на параметр Vertices в Static Mesh Editor.

Минимизируйте UV-островки: чем меньше островов, тем меньше дублей вершин. Но ищите баланс с потяжками (stretching).

PolyCount в DCC — это про удобство работы. PolyCount в движке — это про стоимость кадра.

Понимание разницы между Point и GPU Vertex — это то, что отличает моделлера от технического специалиста. Оптимизируйте не то, что красиво выглядит в Houdini, а то, что эффективно считается видеокартой.