Разработка системы управления версиями для ассетов графики
Когда в проекте три художника одновременно правят один FBX-файл персонажа, а система контроля версий — это папка assets_FINAL_v2_NEW_fixed, проблема не в дисциплине команды. Проблема в отсутствии инфраструктуры. Бинарные файлы — меши, текстуры, аудио — это не код: их нельзя смержить через diff, и обычный Git без расширений справляется с ними плохо.
Почему стандартный Git не подходит для графических ассетов
Git хранит каждую версию файла целиком. Текстура 4K в формате PSD весит 80–120 МБ. После 50 итераций один файл занимает 4–6 ГБ в истории репозитория. Клонирование проекта через год занимает час. git checkout на ветку художника — 20 минут.
Git LFS (Large File Storage) решает проблему хранения: бинарники хранятся на отдельном сервере, в репозитории только указатели. Но Git LFS не решает проблему lock'ов: если художник A и художник B одновременно открыли один FBX — один из них потеряет изменения при попытке commit. Git LFS File Locking (через git lfs lock) добавляет механизм эксклюзивных блокировок, но он не интегрирован в DCC-инструменты (Maya, Blender, Substance Painter) — художник должен помнить о lock через CLI, что на практике не работает.
Именно поэтому для графических ассетов в крупных проектах используют специализированные решения.
Perforce Helix Core для графики
Perforce — стандарт де-факто в AAA-разработке. Его preemptive locking (checkout before edit) идеально подходит для бинарников: художник «берёт» файл на редактирование, система блокирует его для других. Это не мешает потоку работы — наоборот, все знают, кто что редактирует прямо сейчас.
Интеграция с DCC: Perforce plugin для Maya, плагин для Houdini, P4V (визуальный клиент) работает с любым приложением через filesystem. Substance Painter поддерживает Perforce через P4 plugin. Для Unity — P4Unity или встроенная поддержка Version Control в Unity Editor (появилась в Unity 2021.2).
Для проектов на 3–15 художников Perforce Helix Core можно развернуть самостоятельно на Linux-сервере (бесплатная лицензия до 5 пользователей и 20 workspace'ов) или использовать Helix TeamHub (облачный вариант).
Limitation: Perforce — это не Git. Разработчики, привыкшие к git workflow, адаптируются около недели. И это неплохое вложение: потеря работы художника из-за merge conflict в бинарнике стоит дороже.
Git LFS + DVC для смешанных команд
Если команда не готова к полноценному переходу на Perforce, рабочая альтернатива — Git LFS для ассетов + DVC (Data Version Control) для больших датасетов и наборов ассетов.
DVC хранит ассеты в S3/GCS/Azure Blob/локальном NAS, а в Git-репозитории хранятся только .dvc-файлы-указатели. dvc pull скачивает нужные версии ассетов. Это даёт возможность работать с ассетами как с кодом (ветки, теги, история) без раздувания Git-репозитория.
Для управления lock'ами поверх Git LFS — Anchorpoint (десктопный клиент с visual locking), или кастомный сервер блокировок через Git LFS Locking API.
Структура системы для игрового проекта
Типовая архитектура для Unity/Unreal проекта с командой 5–20 человек:
Source repository (код): Git + GitHub/GitLab. Всё, кроме бинарников. .gitignore агрессивно исключает PSDs, FBXs, WAVs, PNGs выше 1 МБ.
Asset repository: Perforce или Git LFS + DVC. Структура: assets/characters/, assets/environments/, assets/audio/, assets/vfx/. Версионируются и исходники (PSD, FBX, MA), и финальные экспорты (PNG, glTF, OGG).
Asset pipeline: скрипты автоматической конвертации и оптимизации при commit. Maya → FBX export через Mayapy, PSD → compressed PNG через ImageMagick, аудио → platform-specific форматы. Запускается через CI hook.
Naming convention: строгий, задокументированный. CH_Goblin_Body_Diffuse_D.png (CH = character, Body = mesh part, Diffuse = map type, D = diffuse). Без этого через полгода никто не знает, что означает texture_v3_USE_THIS_ONE.png.
На одном проекте переход с «папки на сетевом диске» на Perforce занял две недели (установка, конвертация истории из NAS в Perforce depot, обучение команды). Первый месяц — вопросы и непривычка. Через два месяца — «почему мы не сделали это раньше», потому что исчезла проблема «кто последний сохранил файл» и появилась полная история изменений каждого ассета с авторством.
Сроки внедрения
| Масштаб | Ориентировочные сроки |
|---|---|
| Git LFS настройка для существующего проекта | 3–5 дней |
| Git LFS + DVC + pipeline для команды 5–10 чел. | 1–2 недели |
| Perforce Helix Core + DCC интеграции | 2–3 недели |
| Полная asset pipeline с CI автоконвертацией | 3–5 недель |
Стоимость рассчитывается после анализа текущей инфраструктуры и размера команды.