Tech Art Bible עבור Unity: תקני גרפיקה ואוטומציה של Pipeline
מבוא
לעתים קרובות אנו נתקלים במצב שבו אמן חדש מצטרף לצוות ושואל, "מה תקציב הפוליגונים לדמות?" מנהל הצוות עונה, "בערך בין 5 ל-15 אלף, תלוי בחשיבות." זה לא תקן. זה הסכם מילולי שכל אחד מפרש אחרת ושבור עם כל עובד או קבלן חדש. ללא תקנים מתועדים בבירור, צוות מבזבז עד 30% מזמנו על עיבוד מחדש של נכסים. הניסיון שלנו מראה: לאחר יישום Tech Art Bible, מספר העיבודים מחדש יורד פי 3 בהשוואה להסכמים מילוליים. חיסכון בתקציב על הפקת אמנות יכול להגיע ל-30%. במשך 5 שנות עבודה, יצרנו Tech Art Bible לעשרות פרויקטים—ממשחקי מובייל ועד קונסולות AAA. המסמך קובע מספרים, פורמטים ונהלים, ומבטל אי-בהירות. בדיקות אוטומטיות ב-Pipeline עובדות פי 5 מהר יותר מבדיקה ידנית ומפחיתות את מספר התקלות ב-40%. קבלו ייעוץ על יישום תקנים ב-Pipeline שלכם.
למה לתעד תקנים "מובנים מאליהם"?
הפער בין מה שנחשב "מובן מאליו" בתוך הצוות לבין מה שאמנים בפועל עושים הוא עצום. דוגמאות לפערים אמיתיים:
-
רזולוציות טקסטורה: אמן אחד משתמש ב-2K לאובייקטי רקע, אחר משתמש ב-4K. ב-VRAM זה נראה מיד—פרופיילינג מראה
Texture Memoryב-800 MB במקום 400 המתוכננים. והמסמך רק אומר "השתמשו ברזולוציות סבירות." -
שמות:
hero_body_d.png,Hero_Body_Albedo.png,character_1_diffuse_final.png—שלוש טקסטורות מאותו סוג משלושה אמנים בפרויקט אחד.AssetDatabase.FindAssetsלפי תבנית לא עובד, ייבוא אוטומטי לפי סיומת לא עובד, בדיקות CI על מוסכמות שמות לא עובדות. -
נקודות ציר ב-FBX: אמן Blender אחד מייצא עם נקודת ציר במרכז הגיאומטרי, אחר במקור העולם. המפתח מקבל אובייקט שמסתובב סביב נקודה בלתי צפויה כשקוראים ל-
transform.Rotate().
מה כלול ב-Tech Art Bible
תקציבי פוליגונים
טבלה לפי קטגוריית אובייקט עם פילוח לפי פלטפורמה:
| קטגוריה | PC (LOD0) | מובייל (LOD0) | מובייל (LOD1) |
|---|---|---|---|
| דמות ראשית | 10,000–15,000 | 5,000–8,000 | 1,500–3,000 |
| NPC משני | 5,000–8,000 | 2,000–4,000 | 500–1,000 |
| אביזר גדול | 3,000–5,000 | 1,000–2,000 | 200–500 |
| אביזר קטן | 500–1,500 | 200–500 | 50–150 |
תקני טקסטורה
רזולוציות לפי קטגוריה, פורמטים (PNG למקורות, TGA למפות נורמליות בייבוא ל-Unity—לא PNG, BC7 כפורמט הדחיסה היעד ל-PC, ASTC לאנדרואיד/iOS), ערוצים חובה (Albedo, Normal, Metallic/Roughness, AO—בנפרד או ארוזים).
מוסכמת שמות
מוסכמות עם דוגמאות. לטקסטורות: {object}_{part}_{type}_{resolution}.ext, למשל hero_body_albedo_2k.png. למשושים: {category}_{name}_{LOD}.fbx. אנו מתעדים לא רק את הכלל אלא גם את ההגיון שמאחוריו—זה מפחית התנגדות במהלך היישום.
תקני UV
גודל טייל, חפיפת UV מקובלת ל-lightmap UV (רק LOD0, ערוץ UV 2), דרישות מיקום תפרים (לא על קצוות גלויים, לא על מפרקים).
נהלי ייצוא מכל כלי
הגדרות ייצוא FBX ב-Blender (Apply Transform, ציר Forward, יחידות), תבנית ייצוא Substance Painter ל-Unity (באופן ספציפי אילו ערוצים נכנסים לאילו חריצים), רשימת בדיקה לייצוא ב-Maya. עמידה בנהלים מפחיתה שגיאות ייבוא פי 3 בהשוואה להגדרות אד-הוק.
דוגמה לרשימת בדיקה לייצוא ב-Blender
- Apply Transform (Scale = 1, Rotation = 0)
- ציר Forward = -Z, ציר Up = Y
- יחידות = סנטימטרים (ייבוא ל-Unity עם מכפיל 1)
- Mesh Smooth = Edge, לא Face
- ייצוא רק אובייקטים גלויים
איך מפתחים את ה-Tech Art Bible לפרויקט שלכם?
אנו מתחילים בביקורת של נכסים קיימים: מה כבר בשימוש בפרויקט, מהם הערכים המיושמים בפועל. המסמך צריך לשקף מציאות פלוס שיפורים, לא תקן מושלם מאפס—אחרת הצוות יתעלם ממנו.
ראיונות עם אמנים: אילו שאלות נשאלות הכי הרבה, איפה נוצרים קונפליקטים במהלך בדיקת נכסים, מה צריך לעבוד מחדש. זה המקור הטוב ביותר לקביעת סדרי עדיפויות במסמך.
פורמט: Confluence או Notion—אינטראקטיבי, תומך בטבלאות מקוננות וצילומי מסך. לא PDF—אף אחד לא קורא PDF אחרי שישה חודשים. מבנה: תוכן עניינים עם קישורי עוגן, "הפניה מהירה" בעמוד הראשון (הנתונים הנדרשים בתדירות הגבוהה ביותר), סעיפים מלאים למטה.
גרסאות מסמך—תאריך עדכון אחרון ו-changelog. תקן ללא גרסה מאבד אמון: "האם זה רלוונטי לפלטפורמה הנוכחית שלנו?"
איך לאוטומט את עמידה בתקנים?
מסמך לא עובד ללא בדיקות אוטומטיות. סקריפטים של Unity Editor לבדיקה:
- בדיקת טקסטורות מיובאות לעמידה במוסכמת שמות דרך
AssetPostprocessor.OnPreprocessTexture() - בדיקת רזולוציה מקסימלית בייבוא: אם טקסטורה > 4096 לקטגוריית רקע—אזהרה בקונסולה
- בודק משושים דרך
AssetPostprocessor.OnPostprocessModel(): בדיקת ספירת פוליגונים לפי שם קטגוריה משם הקובץ
זה לא תחליף למסמך, אלא משוב בזמן אמת כשהתקנים מופרים—לפני בדיקת קוד. הזמינו שילוב של בודקים בפרויקט שלכם—אנו מבטיחים הפחתה בזמן בדיקת נכסים. קראו עוד על גישות אוטומציה בתיעוד AssetPostprocessor.
לוחות זמנים ליישום
| היקף המסמך | לוח זמנים |
|---|---|
| תקן בסיסי (שמות + תקציבים + ייצוא) | 1–2 שבועות |
| Tech Art Bible מלא + בודקי CI | 3–6 שבועות |
| עדכון מסמך קיים לפלטפורמה חדשה | 3–7 ימים |
העלות מחושבת לאחר ביקורת של הנהלים הנוכחיים של הצוות ופלטפורמות היעד של הפרויקט. צרו קשר לייעוץ מקדים וקבלו הצעה מסחרית תוך יום. אנו מבטיחים הפחתה של 30% בעיבודים מחדש והאצת קליטת אמנים חדשים.
למה לבחור בתקנים שלנו?
מעל 5 שנים בשוק תיעוד משחקים. עזרנו לעשרות אולפנים לאחד pipelines—מאינדי ועד AAA. הלקוחות שלנו מדווחים על הפחתה של 40% בזמן בדיקת קוד ואיכות נכסים גבוהה יותר בנקודת הבדיקה הראשונה. הזמינו ביקורת של הנהלים הנוכחיים שלכם—קבלו תוכנית ליישום Tech Art Bible מחר.