The art director asks to revert a character version "as it was three weeks ago, before the artist reworked the armor." Git stores only .unity and .prefab files, while Photoshop and Substance Painter sources sit in a shared folder on a NAS—no version history. This isn't rare. We've faced it dozens of times in studios of all sizes. Experience shows: without a solid asset management process from day one, such problems are guaranteed. Let's break down how to fix this systematically.
Why Git Doesn't Solve the Asset Problem
Git works with text. A 80 MB binary FBX or 200 MB PSD—diff is unreadable and delta doesn't compress. A repo with art assets without LFS swells to gigabytes in months and becomes uncloneable. In a project with 5000+ assets, finding a needed file takes up to 15 minutes.
Git LFS solves storage but not versioning from the artist's perspective. Tracking *.psd *.fbx *.png via .gitattributes is the minimum. Problem: LFS doesn't show revision previews without git lfs fetch, and artists aren't used to git checkout to view previous texture versions.
The professional alternative is Perforce Helix Core or Plastic SCM (now Unity DevOps Version Control). Plastic SCM integrates natively into the Unity Editor, shows visual diff for .unity and .prefab files, supports file locking for binary assets (an artist "locks" a file, preventing parallel edits). Perforce, in turn, provides centralized storage with performance surpassing Git LFS in tasks with thousands of assets.
How to Choose VCS for Graphics?
| System | Binary Versioning | File Locking | Unity Integration | Implementation Complexity |
|---|---|---|---|---|
| Git + LFS | Partial (storage only) | No | Medium | Low |
| Plastic SCM | Full + visual diff | Yes | Native | Medium |
| Perforce Helix Core | Full | Yes | Via plugin | High |
Perforce processes commits with large files 5 times faster than Git LFS. For small teams up to 10, Git LFS with discipline may suffice. But for projects with 50+ artists, Perforce is the industry standard used by AAA studios.
How to Organize the Asset Library?
A chaotic folder structure in Assets/ wastes team time. Finding a texture in a project with 3000+ files without a proper hierarchy takes 10–15 minutes. The right structure depends on game type, but the basic principle: group by feature, not by type.
Bad:
Assets/Textures/characters/hero_diffuse.png
Assets/Models/characters/hero.fbx
Assets/Materials/hero_material.mat
Good:
Assets/Characters/Hero/Textures/hero_diffuse.png
Assets/Characters/Hero/Models/hero.fbx
Assets/Characters/Hero/Materials/hero_material.mat
When removing a feature, you delete one entire folder. When searching, everything is in one place.
For texture atlases: a clear naming system with suffixes _D (diffuse/albedo), _N (normal), _M (metallic), _R (roughness), _AO (ambient occlusion) is critical for proper import into Unity. TextureImporter automatically detects type by suffix when configured correctly.
Where to Store Asset Sources?
Source files (.psd, .spp Substance, .blend, .ma) are not part of the Unity project. Their storage is a separate task. Options:
- Artefactory/Nexus as binary storage with metadata—suitable for large studios. Each source has a version, release tag, link to a Jira task.
-
Google Drive / SharePoint with strict naming conventions—
hero_armor_v003.psd—works for small teams. Cheap but requires discipline. - Git LFS with a separate repo for sources—a middle ground. Splitting engine and art repos reduces performance issues.
For any option, you need a process: artist finishes an iteration → exports the final asset in the required format (PNG/TGA for textures, FBX for meshes) → places it in the Unity project → commits the source version with a tag. The gap between source and exported asset is the main reason for the question "where did this texture come from?" a year later.
What's Included in Audit and Implementation?
- Audit of the current library: inventory, duplicate search (typical: 10–15% duplicates), volume assessment.
- Selection and setup of VCS (Plastic SCM/Perforce/Git LFS) with structure rules.
- Migration of assets to the new system with history preservation where possible.
- Setup of CI pipeline to check for broken assets and unused files.
- Team training: file locking, commit messages, working with previews.
- Documentation of the asset management process.
- One month of post-release support.
How Does the Audit Unfold?
We start with an inventory: how many assets, current volume, any duplicates (same texture in three places with different names—typical). Tools: Find References in Unity plus a custom Editor script to find unused assets via AssetDatabase.FindAssets. Then migration to the chosen VCS, configuration of .gitattributes or Plastic SCM rules, team training on file locking. The entire process takes 1–3 weeks depending on volume. Contact us for an audit—we'll propose an optimal plan.
How Long Does Implementation Take?
| Work | Duration |
|---|---|
| Audit and restructure asset library | 3–7 days |
| Git LFS setup + rules + CI integration | 2–5 days |
| Plastic SCM / Unity DevOps implementation | 1–2 weeks |
The cost is calculated after auditing the current repository state and asset volume. Get a consultation to discuss details.





