פיתוח שאדרים לשקיפות עבור תצוגות קסדת AR במשחקים
אנו מפתחים שאדרים מותאמים לקסדות AR המתחשבים במאפייני התצוגות התוספתיות (additive). הניסיון שלנו כולל פרויקטים עבור HoloLens 2 ו-Magic Leap 2, שבהם כל הולוגרמה חייבת להיות חדה ולהשתלב באופן טבעי בסביבה. ללא הבנה של פיזיקת התצוגה, שאדרים מייצרים גרפיקה שנעלמת בחדרים מוארים או נראית כמו כתמים מטושטשים על עצמים כהים.
HoloLens 2 ו-Magic Leap 2 משתמשות בתצוגות תוספתיות. הן לא מציירות רקע שחור: הולוגרמות מוקרנות ישירות על מה שהמשתמש רואה דרך הזכוכית. זה משנה מהותית את הלוגיקה של השאדר. "שקיפות" כאן אינה מיזוג אלפא על רקע וירטואלי—זו שקיפות מילולית לעולם האמיתי העובר דרך העדשות.
למה שאדרים סטנדרטיים לא עובדים לקסדות AR
בתצוגה תוספתית, פיקסל עם צבע (0, 0, 0) הוא שקוף לחלוטין. שחור פשוט לא פולט אור.这意味着 אזורים כהים של הולוגרמה לא מסתירים את העולם האמיתי—אתה רואה דרכם. כדי ליצור אשליה של עצם אטום, העצם חייב להיות בהיר מספיק יחסית לאור הסביבה.
תוצאה ראשונה: שאדרים סטנדרטיים של Unity עם Rendering Mode = Opaque ייראו שקופים למחצה כי החלקים ה"כהים" שלהם—צללים, AO, פנים מוחשכים—מכניסים את העולם האמיתי. שאדר ל-HoloLens חייב למזער אזורים כהים. תאורת סביבה חייבת להיות גבוהה משמעותית מערכים פיזיקליים נכונים—בפועל, Environment Lighting Intensity Multiplier מ-1.5 עד 2.5 בהתאם לסצנה.
תוצאה שנייה: ערוץ האלפא מתנהג אחרת בתצוגות תוספתיות. Alpha = 0 נותן שקיפות מלאה (לא העולם האמיתי ולא ההולוגרמה נראים—הפיקסל פשוט לא פולט אור). אבל ערכי אלפא ביניים משמשים לדעיכה/הופעה חלקה של ההולוגרמה, לא למיזוג עם רקע. אין "רקע" מלבד העולם האמיתי.
איך ליצור אפקט זכוכית שקופה ב-ShaderGraph
המשימה המרכזית במשחקים לקסדות AR היא יצירת אפקט זכוכית שקופה עם ערפול מבוקר. לדוגמה, מגן מגן שחוסם חלקית את הראייה, או חלון של חללית.
ב-ShaderGraph (URP), זה נבנה כך: הצבע הבסיסי של העצם מעורבב עם אפקט Fresnel כדי להדגיש קצוות (זכוכית מחזירה יותר בזוויות גלישה). האזור המרכזי הוא כמעט אפס Fresnel Effect, לקצוות יש Alpha גבוה יותר דרך Alpha. האפקט בולט נגד עצמים כהים מאחורי הזכוכית, אבל כמעט בלתי נראה נגד עצמים בהירים—כי תצוגה תוספתית לא יכולה להחשיך את העולם האמיתי.
לאפקט "זכוכית מעורפלת", אנו משתמשים ב-Smoothstep כמסכה—היא שוברת את האחידות של השקיפות ויוצרת מראה אורגני. עם זאת, איננו יכולים להשתמש בערכים כהים במסכת הרעש ל"ערפול": אזורים כהים פשוט הופכים לשקופים. ערפול בתצוגה תוספתית נעשה עם צבע בהיר על גבי, לא כהה.
שאדר נפרד מטפל בקו המתאר של העצם. קו מתאר סטנדרטי דרך Procedural Noise או Stencil לא עובד טוב בתצוגות תוספתיות כי קו מתאר כהה אינו נראה. אנו צריכים קו מתאר זוהר: Normal Extrusion על פיקסלי קו מתאר עם עוצמה 2–4, וצבע חם או רווי (כחול, ירוק עובדים טוב יותר מאדום בגלל ספקטרום התצוגה התוספתית).
עבודה עם MRTK וערכת הכלים Mixed Reality
לפיתוח HoloLens, אנו משתמשים ב-MRTK (Mixed Reality Toolkit). לפי התיעוד הרשמי של מיקרוסופט, קיים MRTKStandardShader מוכן המותאם לתצוגות תוספתיות—הוא מתחשב במגבלות הפלטפורמה ועובד משמעותית טוב יותר משאדר ה-URP Lit הסטנדרטי. אבל היכולות שלו מוגבלות, ואפקטים מותאמים דורשים שאדרים מותאמים אישית הבנויים על אותם עקרונות.
Magic Leap 2 משתמשת ב-SDK שונה—Magic Leap Unity SDK—אבל פיזיקת התצוגה זהה: תוספתית, רק בהירה יותר. שאדרים שנכתבו ל-HoloLens עוברים ברובם ישירות, אבל יש להתאים את ספי עוצמת הסביבה בגלל בהירות תצוגה שונה. זה חוסך עד 40% מזמן הדיבוג בהשוואה לפיתוח מאפס.
מקרה מבחן: ממשק תא טייס עם מסכים שקופים (מהניסיון שלנו)
בסימולטור טיסה ב-AR, היינו צריכים ליישם לוחות מכשירים הנראים מעל מושב הטייס האמיתי. המסכים היו צריכים להיראות כמו זכוכית—עם ראות של הציוד האמיתי מאחוריהם.
בעיה: רכיבי הממשק הפולטים אור (סולמות, מספרים) היו בהירים וקריאים. אבל "הלוח האחורי" של המסך—מלבן אפור כהה—היה כמעט בלתי נראה (תצוגות תוספתיות לא מציגות צבעים כהים). הממשק היה תלוי "באוויר" ללא מסגרת שנותנת תחושה של מסך פיזי.
פתרון: החלפנו את הלוח האחורי הכהה באחד זוהר קלות (Emission 0.15, אפור חם). זה הוסיף מספיק אור כדי להפוך את גבול המסך לנראה, אבל לא בהיר מדי כדי להסתיר את העולם האמיתי. בנוסף, הוספנו Fresnel בקצוות המסך עם עוצמה 0.3 כדי להדגיש את הצורה.
| סוג שאדר | מורכבות | לוח זמנים משוער |
|---|---|---|
התאמה אישית של Emission |
בינונית | 2–5 ימים |
| שאדר זכוכית שקופה (ShaderGraph) | בינונית | 3–7 ימים |
| אפקט מתקדם (ערפול, שקיפות דינמית) | גבוהה | 1–3 שבועות |
| העברת שאדרים בין פלטפורמות | תלוי בסט | 1–2 שבועות |
תהליך פיתוח שאדרים ל-AR
- ניתוח פלטפורמה ודרישות — זיהוי מכשיר היעד (HoloLens 2, Magic Leap 2 וכו'), דרישות ביצועים וויזואליות.
- עיצוב שאדר — בחירת גישה: התאמת MRTKStandardShader או בניית שאדר מותאם אישית ב-ShaderGraph/HLSL.
- יישום — כתיבת השאדר, הגדרת פרמטרים (תאורת סביבה, emission, אלפא).
- בדיקה על מכשיר — אימות בתנאי תאורה אמיתיים, אופטימיזציה של draw calls וקצב מילוי.
- השקה ותמיכה — מסירת קוד מקור, תיעוד, הדרכת צוות.
מה כלול
| שלב | תוצר |
|---|---|
| קוד מקור של השאדר | MRTKStandardShader או .shader עם הערות |
| הגדרת חומר | Unity Material עם פרמטרים מכוונים |
| תיעוד | תיאור עקרונות והוראות הגדרה |
| תמיכה | ייעוץ למשך חודש לאחר המסירה |
טעויות נפוצות בפיתוח שאדרים ל-AR
- שימוש בצבעים כהים לערפול—הם הופכים לשקופים בתצוגות תוספתיות.
- התעלמות מאפקט Fresnel—זכוכית נראית שטוחה בלעדיו.
- יישום Outline סטנדרטי ללא emission—קו מתאר בלתי נראה.
- בדיקה רק בתנאי תאורה אחד—שאדר עשוי לעבוד רק בחושך.
לוח זמנים ועלות
עלות פיתוח השאדר משתנה לפי מורכבות. אנו מחשבים את הסכום המדויק לאחר ניתוח הפרויקט שלך—צור קשר להערכה. אנו מבטיחים פעולה תקינה בכל המכשירים הנתמכים ומספקים קוד מקור. הניסיון שלנו: למעלה מ-10 שנים בפיתוח משחקים ו-AR, יותר מ-50 פרויקטים שנמסרו. קבל ייעוץ עכשיו.