מנהל האמנות מבקש להחזיר גרסת דמות "כפי שהייתה לפני שלושה שבועות, לפני שהאמן עיצב מחדש את השריון." Git מאחסן רק קבצי .unity ו-.prefab, בעוד שמקורות Photoshop ו-Substance Painter נמצאים בתיקייה משותפת על NAS—ללא היסטוריית גרסאות. זה לא נדיר. נתקלנו בזה עשרות פעמים באולפנים בכל הגדלים. הניסיון מראה: ללא תהליך ניהול נכסים מוצק מהיום הראשון, בעיות כאלה מובטחות. בואו נפרק איך לתקן את זה באופן שיטתי.
למה Git לא פותר את בעיית הנכסים
Git עובד עם טקסט. קובץ FBX בינארי של 80 MB או PSD של 200 MB—ה-diff לא קריא וה-delta לא דוחס. מאגר עם נכסי אמנות ללא LFS תופח לג'יגה-בייטים תוך חודשים והופך לבלתי ניתן לשכפול. בפרויקט עם 5000+ נכסים, מציאת קובץ נדרש אורכת עד 15 דקות.
Git LFS פותר אחסון אבל לא גרסאות מנקודת מבט של אמן. מעקב אחר *.psd *.fbx *.png דרך .gitattributes הוא המינימום. בעיה: LFS לא מציג תצוגה מקדימה של גרסאות ללא git lfs fetch, ואמנים לא רגילים ל-git checkout כדי לצפות בגרסאות טקסטורה קודמות.
החלופה המקצועית היא Perforce Helix Core או Plastic SCM (כיום Unity DevOps Version Control). Plastic SCM משתלב באופן טבעי בעורך Unity, מציג diff ויזואלי לקבצי .unity ו-.prefab, תומך בנעילת קבצים לנכסים בינאריים (אמן "נועל" קובץ, ומונע עריכות מקבילות). Perforce, בתורו, מספק אחסון מרכזי עם ביצועים שעולים על Git LFS במשימות עם אלפי נכסים.
איך לבחור VCS לגרפיקה?
| מערכת | גרסאות בינאריות | נעילת קבצים | אינטגרציית Unity | מורכבות הטמעה |
|---|---|---|---|---|
| Git + LFS | חלקית (אחסון בלבד) | לא | בינונית | נמוכה |
| Plastic SCM | מלאה + diff ויזואלי | כן | טבעית | בינונית |
| Perforce Helix Core | מלאה | כן | דרך תוסף | גבוהה |
Perforce מעבד commits עם קבצים גדולים פי 5 מהר יותר מ-Git LFS. לצוותים קטנים עד 10, Git LFS עם משמעת עשוי להספיק. אבל לפרויקטים עם 50+ אמנים, Perforce הוא הסטנדרט התעשייתי שבו משתמשים אולפני AAA.
איך לארגן את ספריית הנכסים?
מבנה תיקיות כאוטי ב-Assets/ מבזבז זמן צוות. מציאת טקסטורה בפרויקט עם 3000+ קבצים ללא היררכיה נכונה אורכת 10–15 דקות. המבנה הנכון תלוי בסוג המשחק, אבל העיקרון הבסיסי: קבץ לפי תכונה, לא לפי סוג.
רע:
Assets/Textures/characters/hero_diffuse.png Assets/Models/characters/hero.fbx Assets/Materials/hero_material.mat טוב:
Assets/Characters/Hero/Textures/hero_diffuse.png
Assets/Characters/Hero/Models/hero.fbx
Assets/Characters/Hero/Materials/hero_material.matכשמסירים תכונה, מוחקים תיקייה שלמה אחת. כשמחפשים, הכל במקום אחד.
לאטלסים של טקסטורות: מערכת שמות ברורה עם סיומות Assets/Textures/characters/hero_diffuse.png Assets/Models/characters/hero.fbx Assets/Materials/hero_material.mat (diffuse/albedo), Assets/Characters/Hero/Textures/hero_diffuse.png Assets/Characters/Hero/Models/hero.fbx Assets/Characters/Hero/Materials/hero_material.mat (normal), _D (metallic), _N (roughness), _M (ambient occlusion) היא קריטית לייבוא נכון ל-Unity. TextureImporter מזהה אוטומטית את הסוג לפי סיומת כשמוגדר נכון.
איפה לאחסן מקורות נכסים?
קבצי מקור (_R, _AO Substance, .psd, .spp) אינם חלק מפרויקט Unity. האחסון שלהם הוא משימה נפרדת. אפשרויות:
- Artefactory/Nexus כאחסון בינארי עם מטא-דאטה—מתאים לאולפנים גדולים. לכל מקור יש גרסה, תג שחרור, קישור למשימת Jira.
-
Google Drive / SharePoint עם מוסכמות שמות קפדניות—
.blend—עובד לצוותים קטנים. זול אבל דורש משמעת. - Git LFS עם מאגר נפרד למקורות—אמצע דרך. פיצול מאגרי מנוע ואמנות מפחית בעיות ביצועים.
לכל אפשרות, צריך תהליך: אמן מסיים איטרציה → מייצא את הנכס הסופי בפורמט הנדרש (PNG/TGA לטקסטורות, FBX למשושים) → מניח אותו בפרויקט Unity → מבצע commit לגרסת המקור עם תג. הפער בין מקור לנכס מיוצא הוא הסיבה העיקרית לשאלה "מאיפה הגיעה הטקסטורה הזו?" שנה לאחר מכן.
מה כלול באודיט והטמעה?
- אודיט של הספרייה הנוכחית: מלאי, חיפוש כפילויות (אופייני: 10–15% כפילויות), הערכת נפח.
- בחירה והתקנה של VCS (Plastic SCM/Perforce/Git LFS) עם כללי מבנה.
- העברת נכסים למערכת החדשה עם שימור היסטוריה היכן שאפשר.
- התקנת צינור CI לבדיקת נכסים שבורים וקבצים לא בשימוש.
- הדרכת צוות: נעילת קבצים, הודעות commit, עבודה עם תצוגות מקדימות.
- תיעוד תהליך ניהול הנכסים.
- חודש אחד של תמיכה לאחר השחרור.
איך מתנהל האודיט?
אנחנו מתחילים במלאי: כמה נכסים, נפח נוכחי, יש כפילויות (אותה טקסטורה בשלושה מקומות עם שמות שונים—אופייני). כלים: .ma ב-Unity בתוספת סקריפט Editor מותאם למציאת נכסים לא בשימוש דרך hero_armor_v003.psd. לאחר מכן העברה ל-VCS הנבחר, הגדרת Find References או כללי Plastic SCM, הדרכת צוות על נעילת קבצים. כל התהליך אורך 1–3 שבועות תלוי בנפח. צרו קשר לאודיט—נציע תוכנית אופטימלית.
כמה זמן אורכת ההטמעה?
| עבודה | משך |
|---|---|
| אודיט ושינוי מבנה ספריית הנכסים | 3–7 ימים |
| התקנת Git LFS + כללים + אינטגרציית CI | 2–5 ימים |
| הטמעת Plastic SCM / Unity DevOps | 1–2 שבועות |
העלות מחושבת לאחר אודיט של מצב המאגר הנוכחי ונפח הנכסים. קבלו ייעוץ כדי לדון בפרטים.





