Питаться маленькими порциями – сытнее

Точно так же как ваш движок отрисовывает объект треугольник за треугольником, он отрисовывает всю сцену объект за объектом. Чтобы визуализировать объект – нужно послать запрос на отрисовку(draw call). Поскольку компьютерное железо создано человеком - оно по природе своей бюрократично.) Вы не можете просто скакать от объекта к объекту и рендерить, что заблагорассудится. Сначала необходимо провести некоторые приготовления. Центральный процессор и Графический процессор распределяют обязанности примерно следующим образом: В том время как ГП занимается непосредственной визуализацией, ЦП собирает информацию и готовит следующие порции к отправке ГП. Для нас с вами тут важно то, что, если ЦП не успеет собрать пакет для ГП к тому моменту, как он закончит с предыдущим, то ГП просто нечего делать. Исходя из этого, мы можем сделать вывод, что визуализация объектов с маленьким количество треугольников совсем не такое эффективное занятие, как кажется на первый взгляд. Вы потратите больше времени на подготовку к визуализации, нежели на саму визуализацию, а так же профукаете драгоценные миллисекунды, в которые ваш графический процессор мог обсчитывать что-нибудь впечатляющее.

A frame from NVidias 2005(?) GDC presentation

Количество треугольников которое ГП может обсчитать до того как ЦП подготовит следующий пакет значительно разнится, но я думаю я смогу привести несколько примеров. Где-то в UDN я видел, что для Unreal Engine 3 это цифра в пределах от 1000 до 2000 треугольников. Работая с движком Big World, мы установили планку на 800, хотя некоторые программисты поговаривали, что 1000 может оказаться ближе к реальности.

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

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

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

Но это ни в коем случае не означает, что вы должны сейчас кидаться и назначать на все ваши игровые объекты turbosmooth. Есть вещи, которых стоит остерегаться и которые требуют как можно меньшего количества вершин. Например стенсильные тени, инстансинг и даже вершинное освещение, к примеру. Плюс ко всему некоторые движки объединяют несколько объектов в один запрос на отрисовку, так что будьте бдительны. Я ещё буду говорить об этом в конце части о “Том, что вам надо знать”.

Вертекс против Пикселя

Если бы я спросил у вас, как у художника, в чём главное различие в производстве арта для предыдущего и текущего поколения консолей, чтобы вы ответили?
Готов поставить свою селезёнку, что самым популярным ответом было бы внедрение потексельного освещения и использование нескольких текстур для переедания различных физических свойств одной поверхности. Да конечно поликаунты подросли, скелеты еще больше обросли костями а процедурно генерируемая физическим движком анимация уже повсюду. На карты блеска и нормалей – главные виновники такого ощутимого визуального различия. И это различие не даётся нам задаром. В последнее время я всё часто слышу такие термины как “движок зависимый от времени отрисовки”, “движок ограниченный временем отрисовки” и “движок ориентированный на время отрисовки”. И должен заметить они не берутся на пустом месте. Причиной их появления явилось то, что в современных движках большинство времени визуализации объекта тратится на то, чтобы обработать и назначить все эти текстуры исходя из направления источников освещения и направления камеры.

Complex/Simple Shaders in UDK

С точки зрения художника, который хочет работать эффективно, это значит следующее:
Оптимизация ваших материалов - занятие намного более полезное, чем оптимизация количества вершин в вашем объекте. Дополнительные 10, 20 или даже 500 треугольников совсем не так страшны для производительности, как ещё один материал. Сбривание сотен треугольников с вашего объекта никогда не даст такой же результат, как решение, о том, что ваш объект обойдётся без карты прозрачности, карты свечения, бамп офсета или даже карты бликов. Кевин Джонстоан(Kevin Johnstone) из Epic Entertainment как-то рассказывал, что во время работ над Unreal Tournament 3 он соптимизировал уровень на 2-3 миллиона треугольников только ради того, чтобы получить прирост производительности в два-три кадра в секунду. Я думаю, что этот пример прекрасно иллюстрирует, то, что совсем не количество треугольников больше всего влияет на скорость визуализации. Количество отрисовок, сложность шейдеров и освещения. Потом затраты на трансформацию вершин в случае всяких сложных ригов и объектов контролируемых физическим движком. Ну и пост процессинг конечно.

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

Если вы знаете, что у вас будет динамическое освещение в сцене, тогда вы не захотите иметь в ней большие объекты, только малая часть, которых будет освещена динамически в данный момент времени. Разбейте его на более мелкие объекты. Или, к примеру, если вы делаете сцену в разрушенном отеле, где игроку придётся освещать фонариком свой путь по тёмным коридорам, то вы, наверное, захотите, чтобы каждый торшер на стене был отдельным объектом. Даже если в нём всего 30-50 треугольников. Может показаться логичным, чтобы соптимизировать локацию, взять и объединить все торшеры в один объект, так как у них всех один и тот же материал и довольно низкий поликаунт. Но результатом будет лишь проседание в производительности из-за рендеринга динамического освещения для настолько обильно распространённого объекта.

Если ваш движок даёт вам выбор между вершинным освещением и лайт мэпингом, то, я думаю, вы предпочтёте второе. В первую очередь потому что вершинное освещение хранит в памяти данные абсолютно для каждой вершины, что заставляет вас хотеть, иметь поменьше вершин, но поскольку мы с вами выяснили, что можем использовать их почти задаром, пока не будет готов следующий пакет, то, я думаю, нам захочется применить эти вершины для каких-нибудь благих целей.
Вы могли бы использовать 128 или 64 или даже 32х32 пиксельный лайт мэп и в некоторых случаях он всё равно будет смотреться лучше вершинного освещения, вот только памяти он будет занимать намного меньше.
К тому же, поскольку лайт мэп по большому счёту обычная текстура, то мы можем органично вплести его в наш конвейер стриминга текстур и практически никак не влиять ими на наш общий бюджет памяти. Если вы хотите сделать свои объекты более дружелюбными к движку, и он поддерживает лайтмэппинг, то я советую вам не медлить и сделать второй UV сет для лайтмэпов.

Самая важная часть

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

Далай Лама как-то сказал:

“Учите свои правила прилежно, чтобы точно знать, где их можно нарушать.”

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

-----------------------------------------------------------------------------------