Структура хранения производственных материалов анимационного проекта (3D)
Используемая в любой студии структура хранения производственных материалов часто является “точкой повышенного внимания” людей, которые приходят из других студий. Первое, на что обращают внимание вновь прибывшие - это то, что структура хранения совсем или не совсем такая, какая была у них раньше, и что старая, которая была у них раньше - “лучше”, и именно “та, которая всех устраивала”, не то, что “эта”. В чём же проблема? Почему ЛЮБАЯ используемая структура хранения становится объектом повышенного внимания тех, кто ранее не работал с ней? Давайте разберёмся с этим вопросом.
Рассуждая о структуре хранения рабочих папок и файлов, о правилах их именования, сотрудники часто не осознают, что говорят они на самом деле не совсем об этом, а о другом! А именно о СТРУКТУРЕ анимационного проекта, которая, в свою очередь, определяет используемую структуру хранения данных! И основные различия в Структуре хранения обусловлены, в первую очередь, различиями в Структуре проекта а также различиями в именовании основных производственных объектов (“Эпизодов”, “Серий”, “Секвенций”, “Сцен”, “Шотов”, “Ассетов”). Структура хранения является лишь следствием, отражением используемой Структуры анимационного проекта!
Поэтому изначально внимание нужно уделять не самой структуре хранения папок и именования файлов, а разработке Структуры анимационного проекта. Она является первичной как по отношению к структуре хранения, так и по отношению к выбору и конфигурированию системы управления задачами.
Как же разрабатывается структура хранения анимационного проекта? Вначале нужно определиться с требованиями к ней. Большая часть таких требований базируется на разработанной Структуре анимационного проекта, которую мы предварительно уже определили в рамках соответствующей статьи. Однако кроме этих базовых требований существуют и дополнительные требования и пожелания, вытекающие из практического опыта.
Рассмотрим подробнее эти требования и пожелания:- Сохранение базовой Структуры анимационного проекта, описанного в Структуре анимационного проекта: Мир проекта (Бренд) -> Проект -> Эпизод (Серия) -> Секвенция -> Шот и Мир проекта (Бренд) -> Ассет.
- Отдельное хранение/дублирование материала для ПРОМО (Тизеры, плакаты, мерчендайзинг) как отдельный Проект или Эпизод.
- Однозначная идентификация производственного материала по его адресу и именованию производственного проекта. Например, необходимо понимать к какому Шоту или Ассету относится расположенный в конкретном месте материал.
- Уникальность именования Ассетов и Шотов в рамках проекта. Это необходимо в том числе для быстрой идентификации их по имени.
- Наличие нескольких типов Ассетов, базирующихся на разных производственных шаблонах, согласно Структуре анимационного проекта
- Обеспечить возможность использования разного производственного программного обеспечения, в зависимости от выбранной технологии анимационного производства. Например, для моделирования возможно использование разных программ, Maya или Blender, или любых других.
- Сохранение возможности перерендера старых версий Шотов. Для этого нужно использовать версифицирование материалов Ассетов и Шотов, для возможности подгрузки предыдущих версий Шотов с предыдущими версиями Ассетов. Сохранение версий Шотов и соответствующих им версий Ассетов возможно как в рамках их именования (например, инкрементный индекс Ассета), так и в рамках используемой системы управления задачами.
- Наличие модификаций Ассетов, когда один Ассет сделан на основе другого. В этом случае, кроме создания необходимой связи в рамках базы данных, возможно отразить этот факт в новом названии
- Разрешается наличие нескольких исходных проектных файлов в одной задаче или в процессе. Например, для реализации задачи “Черновое моделирование персонажа” могут быть созданы отдельные проекты или файлы моделей для головы и тела персонажа в рамках одной и той же задачи.
- Необходимость автоматизации доступа к производственным материалам проекта по их путям и именам. Наличие в связи с этим чётких правил именования папок и файлов.
- Изначальное разделение производственных материалов на этапах Препродакшн, Продакшн, Постпродакшн.
- Наличие групп пользователей с разным уровнем доступа к производственным материалам. Необходимость разделения производственных материалов для регламентирования к ним доступа согласно уровням доступа. Чаще всего уровни доступа регулируются между производственными отделами и стадиями производства - Препродакшн, Продакшн, Постпродакшн
- Возможность выделения части производственных материалов для временного использования, в частности, для кэширования
- Необходимость в полной идентификации производственного объектов - Ассетов, Сиквенсов, Шотов, исходя из названия файла или проекта, в том числе для использования в имеющихся на рынке системах управления задачами
- Полное именование производственных объектов - Ассетов, Сиквенсов, Шотов, должно соответствовать названиям папок, в которых они хранятся, во всех стадиях производства проекта - Препродакшн, Продакшн, Постпродакшн.
- Необходимость полного именования Шотов обусловлена в том числе тем, что в монтаже можно использовать эти же самые полные имена для именования и идентификации файлов превью Шотов.
- Отделение рабочих файлов(work) от публичных(publish), включая возможность по-разному регулировать права на эти материалы. Возможность создания временного публичного доступа к рабочим проектам без необходимости его публикации(publish).
- Возможность доступа к рабочим файлам для простого продолжения работы над проектом в случае отсутствия основного сотрудника.
- Обеспечение возможности частичного или полного бэкапа материалов проекта.
- Сохранение возможности разделения структуры хранения проекта по разным серверам.
- Сохранение материалов с группировкой по процессам - для Секвенций и Шотов
- Сохранение материалов с группировкой по использованному производственному программному обеспечению - для Ассетов.
- Предпочтительное использование текстовых и читаемых форматов файлов проектов вместо бинарных, для обеспечения возможности их пакетной обработки и изменения. Например, использовать .ma а не .mb файлы Maya.
- Учёт имени процесса в именовании файлов и проектов производственных программ.
- Запрет использования тегов в именовании папок и файлов.
- Запрет в использовании не латинского алфавита, в связи с невозможностью использования таких проектов и файлов в разных производственных программах, разных версий и под разными операционными системами.
- Запрет использования любых знаков пунктуации, кроме определённых правилами.
- Сохранение одного и того же имени при использовании разных Операционных систем одновременно. Необходимость учёта различных правил именования файлов и папок в разных Операционных и Файловых системах, в частности, в использовании заглавных букв и национальных алфавитов или ограничению полной длины путей.
- Запрет использования встроенного средства OS Windows для монтирования сетевых папок в локальные диски, например, Z:\ X:\ Y:\. Запрет связан с тем, что эти адреса невозможно монтировать в корень диска при использовании OS Linux. Вместо этого рекомендуется использовать полные сетевые пути, либо специально задавать корень сетевой папки проекта путём определения переменной окружения Операционной системы.
- Предусмотреть возможность загрузки конфигурационных файлов окружения (для производственного программного обеспечения), связанных с конкретным производственным объектом (Шотом, Секвенцией, Ассета).
- Предусмотреть возможность использования систем хранения версий (VCS) для организации хранения производственных материалов.
- Ассеты, из которых состоит комплексный Ассет (например, Сет или Локация), используют ту же схему хранения, что и все другие Ассеты, без дополнительных подпапок. Связи же между ними должны быть обеспечены используемой Системой управления задачами (например, Тегами), или, при необходимости, именованием этих Ассетов.
Далее описана схема хранения, которая базируется на разделении по стадиям анимационного производства, описанном в статье Стадии анимационного производства.
Основная схема хранения, структура папок
(стадия препродакшн + монтаж + звук)
Рекомендуется сохранять материалы стадии препродакшн всех проектов одного Бренда стадии препродакшн в течение всего времени производства проектов Бренда для возможности их повторного использования.
Основная схема хранения, структура папок
(стадия продакшн)
Рекомендуется сохранять производственные материалы Ассетов одного Бренда (папка /assets/) для возможности их повторного использования в течение всего времени производства всех проектов Бренда.
Основная схема хранения
(стадия постпродакшн)
Что касается правил именования папок и файлов, то я предлагаю следующую выборку, собранную из практик ее использования на нескольких анимационных студиях.
Общие правила именования папок и файлов, входящих в Структуру хранения:- при использовании полных слов или их частей используется английский язык;
- используются символы латинского алфавита, строчные и прописные;
- могут использоваться арабские цифры;
- в качестве разделителя частей имени используется знак подчёркивания “_”;
- для дополнительного разделения внутри частей имён используется CamelCase стиль;
- не допускается использовать различные регистры для именования одного и того же объекта, даже если используемая Операционная Система это допускает. Например, использовать одновременно Lava и
LAVAиlava- ошибочно.
- имя Бренда должно быть одним составным словом, состоящим из одной или более составных частей;
- используется CamelCase стиль разделения частей имени Бреда;
- имя Бренда должно быть как можно короче, можно использовать сокращения;
- примеры именования Бренда - Sleepper, Fly, Star, SlowPoke
- имя Проекта должно быть одним составным словом, состоящим из одной или более составных частей;
- используется CamelCase стиль разделения частей имени;
- имя Проекта должно быть как можно короче, можно использовать сокращения;
- примеры именования Проекта - Series, Film, FirstSeason, Sequel
- имя Ассета должно быть одним составным словом, состоящим не менее чем из двух частей;
- используется CamelCase стиль разделения частей имени;
- последняя часть составного имени должна отражать суть ассета или его имя, например, <…>Pen, <…>Rudy, <…>Box
- предпоследняя часть имени должна отражать характерное качество Ассета, например, Gray<…>, Big<…>, Soft<…>
- при необходимости добавить дополнительную информацию к имени Ассета она добавляется в начало имени, используя CamelCase стиль, например, RedCapGrayBoy
- все Ассеты на проектах одного Бренда имеют различающиеся уникальные имена, даже если они используются в разных проектах одного и того же бренда;
- для именования новых подобных Ассетов предпочтительно использовать их уникальные характеристики вместо цифрового индекса, например, BigHouse, SmallHouse вместо
01House, 02House, House03 - примеры именования Ассетов - GreenHouse, VeryGoodBoy
- имя Типа ассета является простым коротким словом;
- используется CamelCase стиль именования, для одной и единственной части имени Типа ассета;
- имя Типа ассета должно быть как можно короче, можно использовать сокращения;
- примеры именований Типов ассета - Chars, Props, Locs, Sets, Objs.
- имя Эпизода должно быть одним составным словом, состоящим из двух составных частей;
- первая составная часть - идентификатор Эпизода - “ep”;
- вторая составная часть - цифровой индекс Эпизода, состоящий из двух или более цифр;
- при исчерпании двух значащих знаков номера Эпизода во второй составной части имени слева добавляется новая цифра, однако изначально может быть использовано нужное количество цифр для идентификации Эпизодов, если их больше 99;
- индекс Эпизода увеличивается согласно порядковому номеру Эпизода в монтаже;
- примеры названия Эпизода - ep01, ep20, ep23, ep152, ep153.
- имя Секвенции должно быть одним составным словом, состоящим из двух составных частей;
- первая составная часть - идентификатор Секвенции - “sq”;
- вторая составная часть - цифровой индекс Секвенции, состоящий из двух или более цифр;
- при исчерпании двух значащих знаков номера Секвенции во второй составной части имени слева добавляется новая цифра, однако изначально может быть использовано нужное количество цифр для идентификации Секвенций, если их в эпизоде может быть больше 99;
- индекс Секвенции увеличивается согласно порядковому номеру Секвенции в монтаже;
- примеры названия Секвенции - sq01, sq20, sq23, sq052
- Сабсеквенция (Subsequence) по структуре хранения находится там же где все остальные Секвенции, но имеет аналогичный дополнительный уникальный идентификатор в своём имени, например, sq020sub01
- состоит из двух частей - названия Эпизода и короткого названия Секвенции, разделённых символом-разделителем (подчёркивание) - “_”;
- примеры полного названия Секвенции - ep01_sq01
- имя Шота должно быть одним составным словом, состоящим из двух составных частей;
- первая составная часть - идентификатор Шота - “sh”
- вторая составная часть - цифровой индекс Шота, состоящий из трёх или более цифр;
- при исчерпании трёх значащих знаков номера Шота во второй составной части имени слева добавляется новая цифра, однако изначально может быть использовано нужное количество цифр для идентификации Шотов;
- индекс Шота увеличивается на десять согласно порядковому номеру Шота в монтаже, например, sh010, sh010, sh030
- в случае необходимости вставки нового Шота между двумя другими его индекс должен находиться между индексами соседних Шотов, например - sh010, sh013, sh020
- примеры названия Шота - sh010, sh020, sh023, sh052
- Сабшот (Subshot) по структуре хранения находится там же где все остальные Шоты Секвенции, но имеет аналогичный дополнительный уникальный идентификатор в своём имени, например, sh020sub01
- состоит из трёх частей - названия Эпизода, короткого названия Секвенции и короткого названия Шота, разделённых символом-разделителем (подчёркивание) - “_”;
- примеры полного названия Шота - ep01_sq01_sh010
- имя Процесса должно быть одним составным словом, состоящим из одного или нескольких составных частей;
- используется CamelCase стиль именования;
- имя Процесса должно быть как можно короче, можно использовать сокращения;
- примеры - LowModel, HiModel, Comp, Render, UV
- проекты хранятся в дополнительных папках с коротким именем, обозначающих выбранный тип производственного программного обеспечения, например, \maya, \max, \zb. В этой папке находятся файлы проектов;
- именование файлов проектов включает в себя имя Ассета, имя процесса, номер версии, состоящий из идентификатора версии и двух цифр, с разделителями, например, ...\maya\GreenHouse_LowModel_v05.ma
- в случае необходимости возможно добавлять дополнительные части имени проекта, между именем Ассета и именем процесса, например, ...\maya\GreenHouse_Loft_LowModel_v05.ma
- финальные проекты (publish) хранятся непосредственно в папках типа производственного программного обеспечения, например - ...\maya\GreenHouse_LowModel_v05.ma
- рабочие файлы, в которых ведётся работа (work) находятся дополнительных подпапках ...\work\, например - ...\maya\work\GreenHouse_LowModel_v05.ma
- номер версии увеличивается в рамках каждого процесса, для рабочей (work) и для публичной (publish) версии каждой задачи - одновременно, но не в рамках всего Ассета. То есть, итоговая рабочая (work) версия и идёт в publish простым копированием файла, с тем же именем и индексом.
- именование файлов проектов включает в себя полное имя Шота, имя процесса, номер версии, состоящий из идентификатора версии и двух цифр, с разделителями, например, ep02_sq02_sh020_Anim_v01.ma
- в случае необходимости возможно добавлять дополнительные части имени проекта, между полным именем Шота и именем процесса, например, ep02_sq02_sh020_Boy_Anim_v01.ma
- финальные проекты (publish) хранятся в папках с добавлением Имени процесса, например - ...\sh020\Anim\ep02_sq02_sh020_Anim_v01.ma
- рабочие файлы, в которых ведётся работа (work) находятся дополнительных подпапках ...\work\, например - ...\sh020\Anim\work\ep02_sq02_sh020_Anim_v01.ma
- номер версии увеличивается в рамках каждого процесса, для рабочей (work) и для публичной (publish) версии каждой задачи - одновременно, но не в рамках всего Шота. То есть, итоговая рабочая (work) версия и идёт в publish простым копированием файла, с тем же именем и индексом.
- именование файлов проектов включает в себя полное имя Секвенции, имя процесса, номер версии, состоящий из идентификатора версии и двух цифр, с разделителями, например, ep02_sq02_Previs_v01.ma
- в случае необходимости возможно добавлять дополнительные части имени проекта, между полным именем Секвенции и именем процесса, например, ep02_sq02_Part_Previs_v01.ma
- финальные проекты (publish) хранятся в папках с добавлением Имени процесса, например - ...\sq02\Previs\ep02_sq02_Previs_v01.ma
- рабочие файлы, в которых ведётся работа (work) находятся дополнительных подпапках ...\work\, например - ...\sq02\Previs\work\ep02_sq02_Previs_v01.ma
- номер версии увеличивается в рамках каждого процесса, для рабочей (work) и для публичной (publish) версии каждой задачи - одновременно, но не в рамках всей Секвенции. То есть, итоговая рабочая (work) версия и идёт в publish простым копированием файла, с тем же именем и индексом.
Пример предложенной структуры папок анимационного проекта можно скачать здесь - animation_proect_paths.zip
Рекомендуется автоматизировать предложенные правила хранения в рамках скриптов и плагинов ко всем используемым производственным программам - Maya, Nuke, etc.
Рекомендуется разделить и регламентировать доступ пользователей к корневым папкам производственных стадий: пре-, пост- и продакшна, используя группы пользователей домена локальной сети.
Рекомендуется разделение корневых папок для пре-, пост-, продакшна на трёх разных физических адресах хранения, потому что они используются для разных производственных стадий проекта. Если же это один сервер, то рекомендуется сделать папки верхнего уровня - pre, prod, post и внутри их реализовать предложенные структуры, начиная с бренда проекта.
На самом деле, из практики, можно резюмировать, что различия между той или иной используемой структурой хранения производственных материалов не существенны по отношению к самому факту наличия и использования разработанной системы хранения. То есть, важность внедрения и полноценного использования ЛЮБОЙ структуры хранения выше того факта, как она устроена изнутри, потому что человек постепенно привыкает к любой используемой структуре хранения, если она полноценно задействована в производстве. Это также означает, что в итоге по мере развития внутренних разработок студии сотрудник вообще не должен самостоятельно заниматься определением места хранения производственного материала, потому что доступ к ним должен обеспечиваться автоматически, согласно назначенному заданию. Это позволит сфокусировать внимание специалистов на создании качественного контента вместо траты внимания по такому техническому вопросу, как система хранения производственных материалов анимационного проекта!
Личная страница автора на Facebook
Наши статьи по теме Организации анимационного производства можно посмотреть в блоге компании
Фейсбук - Facebook.com/animation.standard/
Сайт Стандарта - СОАП.РФ