הגדרת תאורת סצנת משחק ואופטימיזציה
תאורה שנראית מצוין בעורך לעיתים קרובות נשברת בפלטפורמות היעד. אנחנו מוסמכים כמומחי Unity ו-Unreal Engine. אנו מגדירים תאורת סצנת משחק במפתח סגור, עובדים עם URP/HDRP, ומבטיחים עקביות מהעורך לפלטפורמות היעד. במשך יותר מ-5 שנים, יישמנו סכמות תאורה ל-20+ פרויקטים — ממשחקי קז'ואל למובייל ועד משחקי אימה למחשב. אנו מבטיחים תוצאות שעוברות את Frame Debugger ו-RenderDoc ללא הפתעות.
למה תאורה נשברת בפלטפורמות מובייל
בפרויקטים של URP, טעות נפוצה היא ערבוב של Forward ו-Deferred Rendering Paths מבלי לקחת בחשבון ש-Deferred לא תומך ב-MSAA ועובד differently עם Normal Maps בחלק מהפלטפורמות. חלק ממקורות האור מתחילים להתנהג בצורה בלתי צפויה, במיוחד Point Lights עם Intensity נמוך אבל Range גדול — הם פוגעים במגבלת האור לכל אובייקט (ברירת מחדל 8 אורות נוספים ב-Forward), ובפלטפורמות מובייל המגבלה הזו מחמירה יותר.
כשל קלאסי שני: תאורה נראית טוב בסצנה, אבל אחרי אפיית Lightmap, כל הצללים מוזזים. זה קורה בגלל Shadow Bias שגוי על מקור האור — כאשר ל-Directional Light יש Normal Bias מעל 0.4, צללים סטטיים מאפייה לא תואמים לצללים דינמיים במצב Mixed. התוצאה היא "צל כפול" במפגש בין תאורה אפויה לתאורה בזמן אמת.
איך להגדיר נכון טמפרטורת צבע
מהנדסים לעיתים קרובות מגדירים את צבע האור ישירות דרך בוחר הצבעים. הגישה הנכונה היא להשתמש בטמפרטורת צבע (קלווין). 2700K נותן אור ליבון ערב חם, 5600K אור יום ניטרלי, 8000K גוון כחול קר של שמיים מעוננים. כשמשנים את השעה ביום דרך Timeline או Shader, פשוט מבצעים אנימציה לערך הקלווין, וכל הסצנה משנה גוון באופן אורגני ללא צורך בכיוונון ידני של כל מקור.
ב-URP, טמפרטורת צבע מופעלת דרך Additional Light Data → Use Color Temperature. ב-HDRP זה פרמטר סטנדרטי של HD Additional Light Data.
ארכיטקטורת תאורה: מגדול לקטן
התחילו עם מקור האור המרכזי — שמש/ירח לסצנות חוץ, תאורת תקרה ראשית או חלון לפנים. Directional Light עם טמפרטורת צבע ו-Intensity מוגדרים נכון קובע את הטון לכל הסצנה. ב-HDRP, זה קל יותר באמצעות Physically Based Sky + HDRI Sky כדי לקבל ambient נכון.
השלב הבא הוא אור אחורי/הדגשה לקריאות הדמות מול הרקע. מקור אור נפרד עם Intensity נמוך המכוון מול האור הראשי מונע מהדמות להתבלבל עם הרקע גם באזורים חשוכים. ברוב הפרויקטים, האור הזה מוסתר מהסביבה באמצעות Light Layers (HDRP) או Culling Mask.
תאורת הדגשה — Point Lights ו-Spot Lights — יוצרת עניין ויזואלי בפריים, מדגישה אובייקטים אינטראקטיביים, ומוסיפה אפקטים אווירתיים. כאן חשוב לשלוט בכמות: כל מקור נוסף ב-Forward Rendering מוסיף pass לכל אובייקט מואר. במכשירי מובייל, 4 אורות נוספים הם כבר הרבה.
השוואה בין Forward ו-Deferred Rendering לתאורה
| פרמטר | Forward Rendering | Deferred Rendering |
|---|---|---|
| מספר אורות לכל אובייקט | עד 8 (נוספים) | ללא הגבלה |
| MSAA | נתמך | לא נתמך |
| אובייקטים שקופים | נכון | דורש pass נפרד |
| ביצועים במובייל | נמוכים עם הרבה אורות | גבוהים עם הרבה אורות |
מהניסיון שלנו: משחק אימה עם אזורים חשוכים בהירים מדי
בפרויקט אימה, הלקוח התלונן שמסדרונות חשוכים נראו "סבוניים" — צללים רכים, ללא קונטרסט. הבעיה הייתה ה-Ambient Light: הוא הוגדר דרך Environment Lighting → Source: Color עם Intensity 0.8 — למעשה Fill Light לכל הסצנה. אחרי מעבר ל-Source: Gradient עם Sky Intensity 0.05, Ground Intensity 0.02, והסרת Equator, אזורים חשוכים הפכו לחשוכים באמת, ו-Light Probes החלו להעביר נכון את ההבדל בין אזורים מוארים ולא מוארים לדמות.
תאורה ו-LOD: בעיה שמתגלה מאוחר מדי
בשימוש ב-LOD Groups, יש ניואנס שצץ באופן קבוע באמצע הפרויקט: אורות עם Culling Mask ו-Light Layers מתנהגים differently ברמות LOD שונות רק אם ה-Renderers ברמות האלה имеют הגדרות Layer שונות. אבל לעיתים קרובות יותר הבעיה שונה — ב-LOD2 ו-LOD3 יש לעיתים קרובות Meshes מפושטים ללא Normal Maps, אבל ה-shader זהה לזה שב-LOD0. כתוצאה מכך, כשמתבצע מעבר LOD, התאורה משתנה בפתאומיות: המודל הנורמלי נראה מבריק, בעוד ה-LOD המפושט נראה שטוח.
הגישה הנכונה: עבור LOD2+ השתמשו ב-shaders מפושטים (Lit → Simple Lit או Custom Unlit עם AO אפוי) במקום מחסנית PBR המלאה. זה לא רק נכון יותר ויזואלית אלא גם מפחית את עומס ה-GPU בעת רינדור אובייקטים רחוקים.
נקודה נוספת עם חומרים Emissive ב-Baked GI: אובייקט עם Emissive יכול "לאפות" את הזוהר שלו לתוך lightmaps מסביב רק אם יש לו Contribute GI מופעל ופרמטר ה-Emission ב-shader מחובר ל-Lightmap Emissive. ב-URP/Lit, זה Emission → Baked Emission. אם הדגל הזה לא מופעל, האובייקט זוהר בעצמו אבל לא מאיר שום דבר ב-lightmap האפוי — סיבה נפוצה לכך שמסך או חלון "זוהר" לא מטיל אור על הרצפה סביבו.
כלים לאבחון תאורה
Frame Debugger (Window → Analysis → Frame Debugger) מאפשר לדרוך דרך כל קריאת ציור כדי לראות איזה Pass מטפל באובייקט מסוים. חיוני להבנה למה אובייקט מואר בצורה בלתי צפויה.
Rendering Debugger במצב Lighting (Albedo / Specular / Normal / Direct Diffuse) מפרק את התאורה לרכיבים. אם מפת Normal לא משפיעה על התאורה כמצופה, זה נראה מיד בתצוגת Normal.
GPU Usage Profiler מראה כמה זמן GPU מושקע ב-Shadow Caster Pass עבור כל אור. אם Spot Light אחד עם Shadow Casting מופעל לוקח 3ms, זו סיבה להפחית את Shadow Resolution עבור האור הזה או לעבור למצב ללא צל ולחקות את הצל עם טקסטורת Blob Shadow.
לפרויקטים של HDRP, יש כלי ייעודי — Light Explorer (Window → Rendering → Light Explorer). הוא מציג את כל האורות בסצנה כטבלה עם מצבים, עוצמה וסוג צל. שימושי לבדיקת סצנות עם יותר מ-20 אורות; אין צורך ללחוץ על כל אחד ב-Hierarchy.
מה העבודה שלנו כוללת
- בדיקת תאורה נוכחית ו-render pipeline
- הגדרת אור מרכזי, מילוי ואחורי לפי הבריף האמנותי
- אופטימיזציה לפלטפורמות יעד (כולל מובייל, קונסולות)
- אפיית Lightmaps ו-Light Probes
- תיעוד סכמת התאורה והמלצות לצוות
- תמיכה לשבועיים לאחר המסירה
תהליך ולוחות זמנים
העבודה מתחילה עם בריף אמנותי: רפרנסים, שעה ביום, אווירה, פלטפורמת יעד. לאחר מכן בדיקה טכנית של הסצנה (מספר אורות, Render Path נוכחי, גרסת מנוע). לאחר מכן הגדרת תאורה בסיסית עם אישור איטרטיבי. השלב הסופי: אופטימיזציה ובדיקה על מכשירי יעד.
| סוג סצנה | לוח זמנים |
|---|---|
| פנים קטן יחיד (עד 100 מ"ר, URP) | 1–3 ימים |
| רמה בינונית עם מספר אזורים | 3–7 ימים |
| סצנת חוץ עם מחזור יום/לילה דינמי | 1–3 שבועות |
| מתחם סצנות עם סגנון תאורה אחיד | 3–5 שבועות |
התמחור מחושב באופן אישי לאחר ניתוח הדרישות והמצב הנוכחי של הפרויקט. קבלו ייעוץ לפרויקט שלכם — צרו קשר.





