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

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

Complex/Simple Shaders in UDK

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