То, что вам хотелось бы знать

Предисловие

 

Привет.

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

Информация – это слишком ценный ресурс. А, кроме того, ещё и единственный, кроме уверенности, отличающий новичка от профессионала.

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

И да, конечно. У меня одна просьба. Снабжать людей информацией – это чрезвычайно ответственная задача и меньше всего на свете мне бы хотелось снабдить кого-нибудь неверной информацией. Я не претендую на ультимативные знания. В этой статье описан взгляд на вещи, который в силу определённых обстоятельств сложился у меня. Но обстоятельства бывают очень разные и меняются они чрезвычайно быстро. Так что, если вы заметите в этом тексте какое-то спорное место и можете чётко объяснить почему, то пожалуйста не мешкайте и сообщите мне об этом. Я буду вам чрезвычайно благодарен. Ведь всё это писалось не для того, чтобы быть написанным, а для того, чтобы люди могли этим пользоваться.
And now on to the paper:

 

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

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

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

В начале была точка

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

Я думаю, что все мы привыкли получать количество треугольников, как самую главную директиву для создания объектов или персонажей. И я думаю, тот факт, что, треугольник является строительным элементом трёхмерного пространства, имеет к этому какое-то отношение.)
Но. Это, исходя из человеческой модели мышления. У нас людей и числа от 0 до 9, но у процессоров не так. У них есть только 0 и 1 – бинарная система – самая простая система исчисления. Для выполнения процессором абсолютно любой задачи, она должна быть разбита на самые маленькие и простейшие подзадачи, которые процессор сможет решать последовательно. И мне жаль, что пришлось вас протащить через такую кучу технических и геометрических аспектов, но это было необходимо, чтобы дать вам понять, что процессоры работают так же и в отношении трёхмерной графики – от простого. И даже не смотря на то, что треугольник является строительной единицей трёхмерного пространства, он всё равно состоит из трёх линий, который в свою очередь определяются тремя точками. Отсюда следует, что экономить стоит не треугольники, а точки. Сейчас кто-нибудь должен воскликнуть: “Какая разница? Ведь чем меньше треугольников, тем меньше получается и вершин!”. И он будет абсолютно прав. Но, к сожалению, количество треугольников не единственная вещь, влияющая на количество вершин. Некоторые процессы умудряются проходить абсолютно незаметно для вас.

Мне очень жаль, что опять приходится это делать, но, держитесь – снова программистские штучки)
Трёхмерная модель хранится в памяти компьютера, как набор объектов структур вершины. Структура, выражаясь объектно ориентированным языком программирования(условно), это некоторое количество функций и данных различного типа организованных в одно целое. Таких “целых” может быть огромное количество и все они будут иметь одинаковый набор аргументов и функций, а различаться будут лишь аргументы, хранящиеся в них. Такие “целые” и называются объектами. С точки зрения программирования, у этого типа организации данных огромная глубина. Вот упрощённый пример того, как выглядит структура:

Vertex structure
{
Vertex Coordinates;
Vertex Color;
Vertex Normals;
UV Coordinates;
};

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

Если немного абстрагироваться от технических подробностей, то это означает, что каждый раз, когда вы назначаете ещё одну группу сглаживания группе полигонов или делаете рёбра жёсткими в майе, то незаметно для вас, количество вершин по границе удваивается. То же самое происходит при создании очередного UV шва и для каждого дополнительного материала, который вы назначаете на объект. Если вы хотите создавать эффективные модели, то вы просто обязаны принимать это во внимание. Ребята в больших компаниях об этом уж точно знают. Unreal Development Kit от Epic автоматически сравнивает количество импортированных и сгенерированных вершин во время импорта, и извещает вас, если цифры различаются больше чем на 25 процентов. Это конечно довольно узкие рамки, в которые нужно вписаться, но никто не говорил, что производить эффективный арт – это легко. Если уж программисты из Epic считают это аспектом, достаточно важным, чтобы проверять его при импорте, том вам стоит, как минимум крепко задуматься об этом.

 

Соединяя точки

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

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

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

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

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

Если вы столкнётесь с диллемой – добавить аккуртных скосов(chamfer) по краям объекта, сделать его более гладким, но в тоже время наплодить маленьких треугольников, что вроде как плохо, то я советую вам выбрать вариант, от которого ваша работа визуально выиграет. Это всегда самый важный ориентир. А сотпимизировать лишнего в крайнем случае – дело трёх минут.

 

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

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

Complex/Simple Shaders in UDK

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

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

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

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

 

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

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

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

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

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

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

Предисловие

 

Привет.

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

Информация – это слишком ценный ресурс. А, кроме того, ещё и единственный, кроме уверенности, отличающий новичка от профессионала.

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

И да, конечно. У меня одна просьба. Снабжать людей информацией – это чрезвычайно ответственная задача и меньше всего на свете мне бы хотелось снабдить кого-нибудь неверной информацией. Я не претендую на ультимативные знания. В этой статье описан взгляд на вещи, который в силу определённых обстоятельств сложился у меня. Но обстоятельства бывают очень разные и меняются они чрезвычайно быстро. Так что, если вы заметите в этом тексте какое-то спорное место и можете чётко объяснить почему, то пожалуйста не мешкайте и сообщите мне об этом. Я буду вам чрезвычайно благодарен. Ведь всё это писалось не для того, чтобы быть написанным, а для того, чтобы люди могли этим пользоваться.
And now on to the paper:

 

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

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

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

То, что вам хотелось бы знать