Development of Version Control System for Graphics Assets
When three artists simultaneously edit single FBX character file and version control is folder assets_FINAL_v2_NEW_fixed, problem is not team discipline. Problem is infrastructure absence. Binary files — meshes, textures, audio — not code: can't merge through diff, standard Git without extensions handles poorly.
Why standard Git unsuitable for graphics assets
Git stores each file version completely. 4K texture in PSD format weighs 80–120 MB. After 50 iterations one file takes 4–6 GB in repository history. Cloning project year later takes hour. git checkout to artist branch — 20 minutes.
Git LFS (Large File Storage) solves storage: binaries stored on separate server, repository has only pointers. But Git LFS doesn't solve lock problem: if artist A and artist B simultaneously opened single FBX — one loses changes on commit. Git LFS File Locking through git lfs lock adds exclusive locks, but not integrated in DCC tools (Maya, Blender, Substance Painter) — artist must remember via CLI, which doesn't work practice.
That's why large projects use specialized solutions.
Perforce Helix Core for graphics
Perforce — de facto standard in AAA development. Its preemptive locking (checkout before edit) ideal for binaries: artist "takes" file for editing, system locks it for others. Doesn't impede workflow — opposite, everyone knows who edits what right now.
Integration with DCC: Perforce plugin for Maya, Houdini plugin, P4V (visual client) works with any app through filesystem. Substance Painter supports Perforce via P4 plugin. For Unity — P4Unity or built-in Version Control in Editor (Unity 2021.2+).
For 3–15 artist projects Perforce Helix Core can deploy self on Linux server (free license up 5 users, 20 workspaces) or use Helix TeamHub (cloud option).
Limitation: Perforce not Git. Developers used to git workflow adapt about week. And this good investment: artist work loss from binary merge conflict costs more.
Git LFS + DVC for mixed teams
If team not ready full Perforce transition, working alternative — Git LFS for assets + DVC (Data Version Control) for large datasets.
DVC stores assets in S3/GCS/Azure Blob/local NAS, repository has only .dvc pointer files. dvc pull downloads needed versions. This gives ability work with assets like code (branches, tags, history) without Git bloating.
For lock management over Git LFS — Anchorpoint (desktop client with visual locking), or custom lock server via Git LFS Locking API.
System structure for game project
Typical architecture for Unity/Unreal project with 5–20 team:
Source repository (code): Git + GitHub/GitLab. Everything except binaries. .gitignore aggressively excludes PSDs, FBXs, WAVs, large PNGs.
Asset repository: Perforce or Git LFS + DVC. Structure: assets/characters/, assets/environments/, assets/audio/, assets/vfx/. Both sources (PSD, FBX, MA) and final exports (PNG, glTF, OGG) versioned.
Asset pipeline: auto conversion and optimization scripts on commit. Maya → FBX export via Mayapy, PSD → compressed PNG via ImageMagick, audio → platform-specific formats. Runs via CI hook.
Naming convention: strict, documented. CH_Goblin_Body_Diffuse_D.png (CH = character, Body = mesh part, Diffuse = map type, D = diffuse). Without this half-year later nobody knows texture_v3_USE_THIS_ONE.png means.
One project transition from "network folder" to Perforce took two weeks (install, history conversion from NAS to Perforce, team training). First month — questions and unfamiliarity. Two months later — "why didn't we do earlier", because "who saved last" problem gone and full asset change history with authorship appeared.
Implementation timeline
| Scale | Timeline |
|---|---|
| Git LFS setup for existing project | 3–5 days |
| Git LFS + DVC + pipeline for 5–10 team | 1–2 weeks |
| Perforce Helix Core + DCC integrations | 2–3 weeks |
| Full asset pipeline with CI auto-conversion | 3–5 weeks |
Cost calculated after current infrastructure analysis and team size.