"Технические Знания Видеоигрового Художника"

Предисловие

Привет.

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

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

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

И да, конечно. У меня одна просьба. Снабжать людей информацией – это чрезвычайно ответственная задача и меньше всего на свете мне бы хотелось снабдить кого-нибудь неверной информацией. Я не претендую на ультимативные знания. В этой статье описан взгляд на вещи, который в силу определённых обстоятельств сложился у меня. Но обстоятельства бывают очень разные и меняются они чрезвычайно быстро. Так что, если вы заметите в этом тексте какое-то спорное место и можете чётко объяснить почему, то пожалуйста не мешкайте и сообщите мне об этом. Я буду вам чрезвычайно благодарен. Ведь всё это писалось не для того, чтобы быть написанным, а для того, чтобы люди могли этим пользоваться. 
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) по краям объекта, сделать его более гладким, но в тоже время наплодить маленьких треугольников, что вроде как плохо, то я советую вам выбрать вариант, от которого ваша работа визуально выиграет. Это всегда самый важный ориентир. А сотпимизировать лишнего в крайнем случае – дело трёх минут.

Точно так же как ваш движок отрисовывает объект треугольник за треугольником, он отрисовывает всю сцену объект за объектом. Чтобы визуализировать объект – нужно послать запрос на отрисовку(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 сет для лайтмэпов. 

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

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

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

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

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

Ну что ж, я надеюсь, что в этой стене из текста вы смогли что-то для себя почерпнуть. Я считаю всю эту информацию о том, как что поработает бесспорно полезной, но это не совсем то, чем вы могли бы пользоваться на ежедневной основе. Это всё неплохо прочитать разок, но если бы я вдруг что-то забыл, то я сомневаюсь что мне бы захотелось всё это снова перечитывать. И, несмотря на то, что я считаю что все “почему” чрезвычайно важными, будучи художником(или человеком который хочет быть художником) мне хотелось бы иметь какое-то место в котором все ”как” собраны в одном месте, безо всякой ненужной отвлекающей информации. А к разделу с “почему” можно обращаться в качестве пособия, если друг что-то станет непонятно.

А теперь представьте, что вы наконец-то закончили со своей моделью. Капельку передохнув, вы всё же захотите убедится, что всё чисто и максимально соптимизировано. Вот список вещей, которые я бы последовательно стал проверять: 

- Информация о трансформациях(Deleted History, Frozen Transformations/Reset XForm, Collapsed Stack) 

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

В Майе не забудьте выделить свой объект.

- Вывернутые нормали(Inverted Normals) 

Когда вы отражаете объект(масштабируете его на отрицательное число) или на самом деле выполняете ещё целую кучу различных операций, ваши вершинные нормали могут незаметно для вас оказаться вывернутыми на изнанку. Чтоб вовремя заметить эту проблему у вас должны быть выставлены соответствующие настройки в вашем 3д редакторе. В 3ds Max вы можете зайти в свойства объекта(object properties) и включить “Backface cull”(отключение двусторонней визуализации), а потом исследовать свою сетку, на предмет зияющих отверстий 

В Майе просто отключите “Double Sided Lighting” во вкладке Lighting(если её нет, нажмите “shift + m”), а потом убедитесь в том, что Backface Culling отключен во вкладке Shading, и вы увидите, что все места с вывернутыми нормалями, будут отображаться черним.

- Несшитые вершины, открытые рёбра(Mesh splits/ Open Edges ) 

Иногда случается, что во время работы вы забываете сшить некоторые вершины или случайно разделяете парочку. Это не только повлечёт за собой не самое адекватное сглаживание и окажется, хоть и не большой, но тратой памяти. Но и будет прямым признаком неаккуратно выполненной работы. А вам бы этого не хотелось. Открытые рёбра – это вопрос о котором вы, возможно, захотите подумать дважды. И не только потому что в некоторых случаях они усложняют просчёт динамического освещения, но и потому что их наличие нешуточно уменьшает возможности многократного использования вашего объекта. Если даже вы просто заделаете дыру и найдёте место на текстуре, куда сможете кинуть новоиспечённый шелл – это всё равно будет намного более предпочтительно.
Чтобы обнаружить обе вышеописанные проблемы в 3ds Max просто выберите режим выделения границ(border, по умлочанию “3”) и выделите всё( по умолчанию “ctrl+a”).

Общие рёбра для компланарных плоскостей буду казаться сглаженными, даже если это не так. Увидеть, какие рёбра на самом деле сглажены, а какие нет, нам поможет инструмент Custom Polygon Display . Просто кликните на радиобаттон “Soft/Hard” прямо напротив “Edges:”.

- Расшитые UV(UV splits) 

Вашим UVшкам стоило бы иметь минимально возможное количество швов, но, только до тех пор, пока с ними удобно работать. Тут не стоит перебарщивать с растяжениями, просто будьте аккуратны и логичны.
Остерегайтесь неоправданно расшитых UV. 3д Макс сигнализирует вам о них другим цветом в окошке “Edit UVWs”

• telegram
• VK