[ОСНОВЫ] GIT. SVN, CVS. Системы управления контролем версий

Доступно только для студентов курса

Статьи о 3D

GIT. SVN, CVS. Системы управления контролем версий

Документация, Основы

11 июня 2023г.

•

1612 просмотров

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

В работе бывает всякое, иногда необходимо откатить файлы до ранних версий, восстановить их, либо заменить. Когда речь идет об одном компьютере и одном человеке, то всё просто - это можно контролировать и делать вручную средствами Windows и проводника (и высокого уровня ответственности). Но когда речь идет о коллективе, особенно удаленном, ведь компьютеры сотрудников могут находиться даже на разных материках, в дело вступают системы управления версиями, или системы контроля версий (Version Control System, или VCS). Далее мы будем называть их СКВ для краткости.

Что такое системы контроля версий?

Это программное обеспечение, которое призвано обеспечить системное и прозрачное управление файловыми структурами проектов.

Суть его в том, что оно позволяет хранить все версии файлов в одном месте (на сервере со специальными настройками) и дает доступ к манипуляциям с ними. Проще говоря - это комплексная система удаленного менеджмента и контроля проектов.

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

01_системы управления версиями_cgitems.ru.png

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

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

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

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

Виды систем контроля версий

Существует два общих вида систем контроля версий - централизованные и распределенные.

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

Суть двух видов систем в следующем:

Централизованная подразумевает, что есть один сервер с главной версией проекта, а все пользователи могут брать с него копии актуальных файлов.

02_системы управления версиями_cgitems.ru.png

Централизованная система контроля версиями

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

03_системы управления версиями_cgitems.ru.png

Распределенная система контроля версиями

Рассмотрим несколько основных и известных систем двух типов:

Первая и самая старая это CVS, которая была разработана в 80х программистом Диком Груном. Она является централизованной. Собственно, включает в себя все функции описанные выше - хранение и доступ к данным.

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

Ещё одна популярная и значительно более молодая централизованная система это Subversion, или SVN, разработанная в 2000 году компанией CollabNet. Она во многом аналогична CVS, и по сути была разработана как более совершенный аналог, исправляющий недостатки CVS. Также она предлагает более эффективные алгоритмы хранения информации.

Следующая система это GIT. Разработана в 2005 году Линусом Торвальдсом - создателем операционной системы Linux. Её основное отличие заключается в том, что эта система распределенная. Считается что она является одной из самых быстрых систем, но при этом существует мнение о том, что она сложнее для понимания по сравнению, например, с SVN.

Для комфортной работы с системами управления версиями существуют оболочки - программы, в которых все команды для взаимодействия с сервером распределены по кнопкам и меню, то есть вместо командной строки они имеют интерфейс, что сильно облегчает взаимодействие с такими системами. Далее мы коснемся самых популярных из них.

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

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

Общий принцип работы с системами управления версиями

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

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

В свою очередь репозиторий это, по сути, единое место (директория) в котором хранятся все версии файлов одного проекта, а его настройки позволяют взаимодействовать с ними вышеописанным образом - сохранять, копировать, откатывать изменения и.т.д.

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

Подход к работе

Рассмотрим подход к работе с учетом того, что у вас установлен клиент для работы с репозиториями.

Процесс начинается с того, что вы получаете ссылки и пароли для доступа к серверу. После подключения к проекту вы получите возможность загрузить к себе на устройство копию репозитория (либо актуальную версию, в зависимости от типа СКВ). Это действие называется извлечение версии - чаще всего такая команда называется Clone, либо Checkout. В большинстве случаев это будет последняя версия проекта, или его часть, такие условия задаются администратором сервера.

В результате на вашем компьютере появится копия проекта, каждый файл которой будет синхронизирован с хранилищем на сервере. Это называется локальный репозиторий.

Часто бывает так, что помимо основной рабочей копии создается её дубликат - некий эталон, по которому программа может определить изменения в проекте от последнего обновления без обращения к серверу. Этот дубликат называется Fork.

04_системы управления версиями_cgitems.ru.png

Наглядный пример клонирования проекта с сервера (скачивание репозитория)

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

После того как проект клонирован и клиент оповестил об успешном завершении, по сути всё готово к работе. Далее, в подавляющем большинстве ситуаций, будет происходить рутинная работа - обновление проекта, модификация файлов (рабочий процесс), фиксация изменений на сервере чтобы другие разработчики могли получить их при обновлении своих копий.

Обновление репозитория

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

Во избежание проблем и для поддержания актуальности версии существует такая команда как Update, Fetch, или Pull (есть некоторая разница между Fetch и Pull, она заключается в том что первая не сливает ветки, а вторая делает это по умолчанию. Это касается систем контроля версий GIT). Она позволяет обновить проект и это стоит делать по возможности как можно чаще, особенно при ежедневной активной работе над разработкой.

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

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

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

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

Модификация проекта

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

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

Фиксация изменений (Commit)

Собственно, когда вы выполнили этапы работы, или всю задачу поставленную перед вами, настает этап фиксации. Эта команда называется Commit - так называемая контрольная точка.

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

Следующая команда это Push. Выполняя её, вы передаете на сервер в основной репозиторий изменения прошедшие Commit, сохраняете рабочий процесс и делаете его доступным для других разработчиков.

05_системы управления версиями_cgitems.ru.png

Графический пример работы пользователя/сотрудника с общими файлами проекта через сервер и его команды Commit и Push

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

Здесь важно учитывать вышеозвученные моменты - правильность путей и имен файлов, своевременность передачи данных на сервер. Также важно добавлять к вашим изменениям комментарии, которые помогут разобраться с тем, что именно вы делали.

Ветки проекта (Branch)

Ещё существует такое понятие как ветвление, или Branch - от единого проекта можно вывести отдельную ветку изменений в каком-то конкретном участке проекта и работать с ней не затрагивая весь проект целиком.

Commit и Push ветки будут затрагивать только её файлы, но не основной репозиторий. В дальнейшем можно произвести слияние этой ветки с основным проектом и зафиксировать изменения, либо перевести её в отдельный проект.

Например - пока программисты работают над текущей сборкой проекта в своей ветке, дизайнеры и 3D художники могут работать над новой локацией, которая войдет в следующую сборку.

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

Merge

Слияние (Merge) это проверка изменений основного и локального репозиториев и их слияние в новую версию на основе зафиксированных изменений. Это общее понятие объединяющее вышеописанные этапы.

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

Конфликты изменений

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

Причины могут быть самыми разными, один из примеров - вы сделали Commit изменений, но не сделали Push. Либо не забрали какие либо изменения связанные с текущей работой, при попытке обновить репозиторий эти изменения могут вызвать конфликт.

В целом это очень ситуационно, и суть здесь в том, что если система не справилась с обновлением, либо отправкой изменений, то она выдаст оповещение и, в зависимости от клиента(оболочки), предложит варианты решения, либо укажет на источник ошибки. Далее вам надо будет либо найти причину и решить её, либо просто произвести откат проекта до последней неконфликтной точки.

Блокировка проекта или его части

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

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

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

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

Это сугубо индивидуальные аспекты отдельно взятых систем и клиентов(оболочек), поэтому не станем углубляться. На любом проекте обязательно будет документация, в которой будут описаны возможности применяемой СКВ.

Итак, мы прошлись по основным принципам и понятиям работы с системами контроля версий.

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

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

В первую очередь вы 3D художник и ваша задача - производить контент. Но понимание основ работы с СКВ облегчит вам жизнь и поможет перестать бояться их, так как на деле все просто и рутинно.

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

Заключение

Собственно, этот список можно продолжать бесконечно, наверняка компетентный программист сможет сказать почему, например, надо выбрать именно SmartSVN а не Tortoise, или почему GIT самый популярный. Или напротив, почему GIT не стоит применять.

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

Почти наверняка вам не придётся столкнуться с подавляющим большинством программ, но их обилие говорит о том, что это очень востребованное направление в области работы с данными. Т.к. профессия 3D художника является важной частью разработки игр (и не только игр), то просто надо понимать, что рано или поздно вы столкнетесь с необходимостью работы с системами контроля версиями. А понимание общих принципов того, как они функционируют, позволит вам легче влиться в рабочий процесс и сосредоточиться на самом важном - создании качественного контента.

11_системы управления версиями_cgitems.ru.png

Платформер. Жанр видеоигр
Платформер. Жанр видеоигр Индустрия

11868 просмотров

Что такое топология

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

Топология относится к геометрическим характеристикам поверхности 3D сетки. Также можно встретить понятие «Polygon Flow» - поток полигонов, но расположение вершин и ребер сетки также играет важную роль в создании 3d моделей.

Можно сказать, что по сути не существует четких стандартов или железных правил в работе с топологией. Это та сфера, успеха в которой можно достигнуть только посредством практики, анализа и наработки опыта, «насмотренности».

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

В чем же заключается важность топологии?

В принципе, это зависит от задачи стоящей перед художником.

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

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

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

Из чего состоит 3D модель

Любая модель будет состоять из трех элементов - полигон, ребро, вершина (Polygon, Edge, Vertex). Вы часто (всегда) будете слышать следующие обозначения - вертекс, эдж, полигон.

Vertex - это позиция точки в трехмерном пространстве, которая определяется координатами X, Y, Z. Она может хранить в себе такую информацию как цвет, направление нормали, текстурные координаты. Несколько эджей и полигонов могут иметь один вертекс.

Edge - это линия, которая соединяет два вертекса. Как и в случае с вертексом, несколько полигонов могут иметь общий эдж. Важно - лучше не называть их линиями и сразу привыкнуть к понятию Edge (ребро).

Polygon - многоугольник. Состоит из трех или более вертексов, с замкнутым контуром эджей. Это как раз та самая форма, которая определяет поверхность трехмерной сетки. Polygon flow - помните такое понятие, верно?

Полигон также называют Face - поверхность. Обычно 3D сетка содержит в себе от десятков до сотен и тысяч полигонов. Зависит от задачи, под которую мы делаем свою модель.

Всем известное понятие «оптимизация» в том числе включает в себя то, какое количество полигонов (а если точнее, то треугольников) включает в себя сетка, часто оно может быть жестко ограничено под требования проекта (в случае с играми). С каждым годом эти требования становятся все более размытыми, благодаря развитию вычислительных технологий. НО, это не единственный аспект оптимизации.

Наглядный пример как подразделяется 3D модель на её составляющие

Виды и особенности полигонов

Полигоны имеют названия исходя из их количества сторон. Давайте выделим три вида, которые вы будете встречать чаще всего.

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

Quadrangle (quad, квад) - полигон с четырьмя сторонами. Это тот вид полигона, который мы должны знать, любить и уважать, так как он является основой нашей модели при создании её сетки.

N-Gon - это полигон с количеством сторон более чем четыре. Важно - если вы видите квад в котором пять вертексов, то это уже n-gon, несмотря на то что визуально он квадратный.

Triangle, Quadrangle, N-Gon

Существует ряд мнений среди 3D сообщества на тему применения N-Gon и Triangle полигонов в создании модели. На деле все зависит от ситуации и целей, с которой создается модель.

Отдельная тема, это модели под анимацию, например персонажи. У них есть ряд своих, особых требований по применению полигонов в топологии. Давайте возьмем за основу следующий принцип - «То что я могу, не значит что так и надо», и будем стремиться к тому, чтобы строить свои сетки на quad - квадратных полигонах.

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

Planar и NON-Planar полигоны (плоские и неплоские)

Полигон является планарным, если все его вершины лежат в одной плоскости, также треугольный полигон является планарным, так как три его вершины всегда будут лежать в одной плоскости.

Большинство полигонов в ваших моделях будут планарные - лежать вершинами в одной плоскости. В свою очередь не планарным полигоном будет считаться такой полигон, в котором одна или более вершина не лежит в плоскости с остальными, создавая «загиб».

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

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

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

Случай 1: вертекс выделенного полигона уведен вниз, что делает его не планарным, ребро триангуляции в показанной ситуации делает его выпуклым, получается переход вниз от ребра.

Случай 2: вертекс также уведен вниз, но ребро триангуляции лежит по другой оси, это создает перегиб и полигон становится вогнутым.

Subdivision Surface (SubD)

Subdivision Surface - это алгоритм подразделения поверхностей, который создает гладкую поверхность из «грубой» полигональной сетки. Когда сетка подразделяется, она становится более плавной, её детали принимают более финальный вид.

Это преобразование является обратимым, только если вы не применили финальное сглаживание (например, перед выгрузкой High Poly для запекания).

Слева направо: полигональная сетка, сетка с примененным SubD и Control Cage (контрольной клеткой), Final Smooth (финальное сглаживание)

Наиболее часто используемым алгоритмом subdivision surface является Catmull - Clark (CC SubD). Его разработали Эдвин Катмулл и Джеймс Кларк в 1978 году. Обратите внимание, насколько давно удачная идея стала инструментом актуальным до сих пор.

Если объяснять простыми словами, то суть его заключается в том, что по полигонам модели под SubD размещаются центроиды - вершины в центральных точках полигонов, далее они соединяются ребрами, оставшиеся вершины смещаются, чтобы снять напряжение - происходит «округление» формы.

Этот алгоритм итеративен, то есть может повторяться раз за разом, наращивая количество подразделений. Таким образом, мы получаем high poly модель, и именно этот процесс нам надо учитывать при построении модели под SubD.

Схема подразделения полигонов по алгоритму CC SubD

Слева: Эдвин Катмулл - американский инженер-мультипликатор, специалист по компьютерной графике, президент DisneyToon Studios, Pixar и Walt Disney Animation Studios, тьюринговский лауреат, член Национальной инженерной академии США, четырёхкратный лауреат «Оскара».

Справа: Джеймс Кларк - бизнесмен, технолог, миллиардер. Основал Silicon Graphics, Netscape Communications, myCFO, Healtheon, «Neoteris», «Sciences DNA», Shutterfly.

Чистая и аккуратная работа с топологией под Subdivision Surface, это залог того, что на выходе вы получите правильную модель без артефактов.

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

Важные определения и понятия топологии, которые надо знать и учитывать

PolyLoop - петля полигонов. Представляет собой набор последовательно и непрерывно связанных квадратных полигонов. Polyloop является важным элементом построения 3D модели, умение работать с петлями станет залогом вашего успеха.

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

PolyLoop позволяет вам точнее и равномернее распределять полигоны, выделять отдельные участки и редактировать модель, при применении SubD правильные PolyLoop подразделяются и сглаживаются лучше всего.

Именно по этому вам стоит сразу, заранее планировать свою работу и стараться мыслить комплексно - правильное начало работы, это залог того, что на финальных этапах вы сэкономите себе немало времени и сил.

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

Простой пример PolyLoop - полигональной петли

EdgeLoop - в свою очередь это петля из эджей (ребер). Как и с PolyLoop - петля ребер это разрезы, которые вы будете делать на модели, и они буду замыкаться.

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

Также бывают ситуации, когда петля ребер заканчивается звездой (еще их называю «полюс»), об этом мы поговорим далее. Каждый EdgeLoop призван служить форме вашего объекта. Посмотрите на положение петель в своей модели и скажите себе - какие из них служат какой то функции, а какие нет. Это покажет вам, где вы сделали лишнюю работу.

В работе с EdgeLoop также стоит мыслить именно петлями, а не отдельными ребрами.

Пример EdgeLoop - замкнутой петли рёбер

Звезда (pole, star, полюс) - это вершина в сетке, в которую приходит 3 и более ребер. В зависимости от ситуации это может быть как плохо, так и хорошо для вашей сетки.

Неправильное размещение звезд может привести к артефактам на сглаженной модели.

Если в вашей сетке есть звезды, то посмотрите откуда они взялись и несут ли в себе какую-то практическую функцию.

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

Это, опять же, тот случай, когда понимание таких моментов приходит с опытом и насмотренностью. Делайте топологию свой модели вдумчиво, смотрите на результат.

Примеры того, в каких ситуациях появляются звезды

E-pole - полюсы, которые состоят из пяти ребер, пересекающихся в одной вершине. N-pole - полюсы, которые состоят из трех ребер также пересекающихся в одной вершине.

Hold Edges (support edges, поддерживающие ребра) - подразделение поверхностей создает сглаженную поверхность модели.

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

Также во многих современных 3D редакторах есть такая функция, как Edge Creasing (иногда её называют Edge Weighting или вес ребра) - заострение ребра. Эта функция позволяет задать «натяжение» на выбранных ребрах. В целом Hold Edges также является очень мощным и многофункциональным инструментом, который можно и нужно использовать и знать, как он работает.

Пример применения Hold Edges слева направо: без поддержек, с обычными поддержками (support edges), edge creasing. Как видите, они дают очень разные результаты. Пробуйте и экспериментируйте с hold edges чтобы лучше понять, как они работают

Еще один пример работы с Support Edges. Также на этом примере можно отследить Edge Loops, Poly Loops и Poles

Немного о топологии в Low Poly

Процесс создания модели для игры включает в себя такой процесс, как ретопология.

Суть его в том, чтобы на основе вашей High Poly модели сделать её облегченную версию, которая будет, скажем так, «облеплять» High Poly модель. Это необходимо для процесса запекания (baking) и дальнейшей выгрузки готовой модели в движок.

Работа с Low Poly связана с упрощением модели и сокращением числа полигонов, но при этом важно не потерять силуэт модели - её ключевые формы.

В процессе создания Low Poly модели вам надо будет избавиться от Support Edges, лишних Edge Loops, которые не влияют на силуэт и форму модели, сократить количество граней на цилиндрах, избавиться от фасок, удалить скрытые полигоны, сшить пересекающиеся элементы, проверить врезки «элемент в элемент», иначе говоря пересекающиеся элементы.

Так же как и в High Poly, в Low Poly нет четких условий в моделировании - все ситуативно и необходимо смотреть на финальный результат, при необходимости возвращаясь назад и внося корректировки.

Давайте возьмем за основу принцип «отрезать все лишнее и ненужное, оставляя суть модели». На этом этапе нас уже не интересует SubD, нам важна легкая, упрощенная модель дающая четкий силуэт, которую мы сможем триангулировать и отправить на запекание\в движок.

Пробуйте, смотрите, экспериментируйте. Понимание аспектов создания Low Poly также приходит с опытом и насмотренностью.

Несколько примеров того, как могут выглядеть Low Poly модели. Разница с High Poly очевидна, не так ли?

Итак, давайте подытожим

Начинайте построение модели с анализа референсов, заранее прикиньте, где у вас будут более сложные участки с повышенной плотностью полигонов, сделайте блокинг, иначе говоря - драфт модели.

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

Используйте меньше полигонов там, где это возможно.

Часто бывает так, что после применения SubD к финальной модели оказывается, что некоторые полигоны в вашей сетке не несут никакой функции.

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

Треугольники и многоугольники (N-GONs) это не всегда плохо. Но стоит учитывать, что в некоторых ситуациях они могут создать артефакты на вашей модели после применения SubD (например на углах, или цилиндрических формах).

Соответственно, создавайте модель вдумчиво, ориентируйтесь на визуальный результат.

Ну и конечно помните о том, что хорошая сетка, это сетка на квадах.

Следите за размерами полигонов и снова - за их количеством.

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

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

Естественность направлений петель - наблюдайте, насколько естественно и логично ложатся ваши петли в сетке модели.

Не важно, в какой программе вы работаете, или сколько плагинов применяете в работе - важно, насколько хорошо вы понимаете основы работы с топологией, они будут одинаковы для любого редактора.

Работая с LowPoly помните про количество полигонов, силуэт модели и то, что надо срезать все лишнее оставив самое важное.

Учитывайте всю информацию, что прочли выше, практикуйтесь, изучайте работы 3D художников и у вас все получится!

[~DETAIL_TEXT] =>