פיתוח אפליקציות AR: היכן הפרויקט נשבר כבר בהתחלה
פיתוח אפליקציות AR נדיר שנשבר בהדגמה — וכמעט תמיד זה קורה באובייקט אמיתי. בהדגמה יש שולחן ישר, תאורה טובה ותנועת מצלמה איטית, ולכן הכול מחזיק מעמד. בשטח הסצנה מתנהגת אחרת: אובדן טראקינג של הסצנה קורה על קיר אחיד בצבעו, בסיבוב חד של המכשיר או בחלל עם השתקפויות ומשטחים מחזירי אור.
המצלמה מפסיקה לזהות את הסביבה, מערכת הצירים נבנית מחדש — והאובייקט, שעוד רגע עמד על השולחן, מתרחק מהמשטח בסנטימטרים, ולפעמים במטרים.
הסוג השני של תקלות — דריפט של אובייקטים תלת-ממדיים. עיגון לעוגן (anchor) בלי השוואה סדירה לגאומטריה המזוהה צובר שגיאה: האובייקט "צף" לאט לאורך המישור, משנה קנה מידה ונטייה. בסשן קצר זה לא מורגש, בסשן ארוך — הפער נעשה ברור, ואף מודל תלת-ממד מדויק לא מפצה על זה. הסיבה כמעט תמיד בארכיטקטורת הסצנה, ולא בתוכן: העוגן הוצב פעם אחת ולא נבדק שוב.
השלישי — התחממות המכשיר. המצלמה, הרינדור והזיהוי עובדים בו-זמנית וברצף, והתקציב התרמי של מכשיר ממוצע נגמר מהר יותר ממה שנדמה. המערכת קודם מורידה את קצב הפריימים, התמונה מתחילה לפגר אחרי תנועת היד, ואחר כך האפליקציה נסגרת. במכשירי דגל הבעיה מוסווית, ולכן קל לפספס אותה בשלב הבדיקות ולגלות אותה על מצבת טלפונים רגילים.
כל שלוש התקלות נמצאות במישור אחד — באופן שבו בנוי מחזור הסשן, בחירת העוגנים ותקציב העומס לפריים. בהמשך נפרט איך זה נסגר ברמת הארכיטקטורה ופרופיל המכשירים, ולא בתיקונים קוסמטיים.
מה משתנה אחרי ההטמעה: חמישה אפקטים מדידים
האפקט הראשון — החזקת האובייקט הווירטואלי בתוך הפריים. קודם המודל החליק מנקודת העיגון כשהמצלמה הסתובבה: העוגן אבד, והיה צריך למקם את האובייקט מחדש.
כעת המיקום מחושב מחדש לפי הגאומטריה של הסצנה, האובייקט נשאר במקומו בזמן שהמשתמש מקיף אותו, והשגיאה המצטברת לאורך הסשן נמדדת בסנטימטרים ולא גדלה עם הזמן.
השני — יציבות הטראקינג בתנאים אמיתיים: תאורה חלשה, משטחים אחידים, סיבובים חדים של המכשיר. מרווח הביטחון לתרחישים האלה נקבע כבר באב-טיפוס, ולכן בדוח רואים לא מספר ממוצע, אלא את שיעור הסשנים שבהם הטראקינג לא אבד אף פעם והאובייקט לא "זז" ממקומו.
השלישי והרביעי — זמן ההפעלה הקרה של מצב AR והתגובה לפעולת המשתמש. המעבר הראשון למצלמה מסתיים בתוך כמה שניות, כי המודלים והטקסטורות נטענים ברקע ולא חוסמים את הסצנה.
התגובה למגע — שברירי שנייה: בהלבשה וירטואלית או בכיוון אל אובייקט השהיה נקראת כ"התקלקל", לא כ"איטי".
החמישי — שיעור המכשירים שבהם הפונקציה עובדת בצורה צפויה: זו מצבת מכשירים שעברה בדיקה על בילד חי, ולא רשימה מתוך התיעוד. כאן גם נסגר סוג שלם של כשלים — חוסר סנכרון בין מיקום המצלמה לסצנה הווירטואלית, שבגללו האפליקציה מציגה את האובייקט לא במקום או עוברת למסך שחור.
אפשרויות מימוש: מודול נייטיב, מנוע או ווב
שלוש הגישות נבדלות לא באיכות התמונה, אלא במקום שאליו מוטמעת המציאות הרבודה ובמחיר שאתם משלמים על התחזוקה. מודול AR נייטיבי נשען על הערכות של הפלטפורמה — ARKit ו-ARCore: הגישה לטראקינג מישורים, להערכת תאורה ולמצלמה מלאה, אבל הלוגיקה משוכפלת לכל פלטפורמה.
סצנת ווב בדפדפן מסירה את מחסום ההתקנה: המשתמש עובר בקישור ורואה מיד את המודל בפריים. המחיר על כך — גישה מוגבלת לחיישנים, ירידה בביצועים בסצנות כבדות ותלות בגרסת הדפדפן. להלן — מה מתאים לאיזה תרחיש.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מודול AR נייטיבי | AR משלים אפליקציה שכבר יצאה לאור | שני בסיסי קוד, מהדורות נפרדות לכל פלטפורמה |
| אפליקציית AR חוצת-פלטפורמות | קוד אחיד וסצנה תלת-ממדית מורכבת | גודל בילד ניכר, פיגור אחרי היכולות החדשות של הפלטפורמות |
| סצנת ווב בדפדפן | הפעלה מהירה בלי התקנה, פרומו והדגמות | חסרים חלק מהחיישנים, סצנות כבדות חלשות יותר, תלות בדפדפן |
| מימוש היברידי | צריך גם תפוצה וגם איכות טראקינג | הרכבה ובדיקות מורכבות יותר: שני ענפי תצוגה |
בתרשים היברידי בוחרים כשסצנת הווב מכסה את הכניסה המהירה, והמודול הנייטיבי לוקח על עצמו את הסצנות הכבדות בתוך האפליקציה. וריאנט כזה יקר יותר לתחזוקה, ולכן אנחנו מקבעים את הגבול בין הענפים לפני תחילת הפיתוח — אחרת פער בהתנהגות צף דווקא אצל המשתמשים.
שלבי העבודה: מהגדרת המשימה ועד המסירה
את שלבי הטמעת ה-AR אנחנו בונים כך שהסיכונים הטכניים יוסרו לפני שרוב העבודה תיכנס לפרויקט: היקר מכל הוא טעות בתרשים הסצנה שמתגלה בבילד הסופי. לכן הצעדים הראשונים עוסקים בתרחיש ובגאומטריה, ולא בקוד.
- ניתוח התרחיש. מקבעים לאן מכוונת המצלמה, מה המשתמש עושה בידיים ואיזו פעולה נחשבת להצלחה. בתוצאה — קריטריון קבלה מדיד, ולא "צריך להיראות מרהיב".
- תרשים הסצנה. פורשים את העוגנים, מישורי ההתייחסות, אזורי האינטראקציה וקנה המידה של האובייקטים ביחס לגובה האדם. תרשים הסצנה נעשה למסמך משותף לעיצוב, לפיתוח ולקבלה.
- אב-טיפוס של פונקציית AR. בונים גרסה מינימלית על דגם מכשיר אחד: בודקים שהתרחיש משוחזר בחלל אמיתי, ולא רק על סימון בדיקה.
- טראקינג ואוקלוזיה. מכווננים את זיהוי המשטחים, את הכיסוי של אובייקטים וירטואליים על ידי אמיתיים ואת התנהגות הסצנה באובדן טראקינג — זה קובע אם התמונה "מחזיקה" בתנועה ובתאורה חלשה.
- בדיקה על מצבת מכשירים. מריצים את הבילד על דורות שונים של מצלמות ועל ביצועים שונים (ARKit ו-ARCore מתנהגים אחרת באותו חלל). מתעדים היכן היציבות נחלשת.
- קבלה. עוברים על צ'ק ליסט לפי תרחישים ומכשירים, משווים לקריטריונים מהשלב הראשון, ומגישים פרוטוקול עם המגבלות הידועות.
- מסירה. מוסרים את קוד המקור, את תרשים הסצנה, את מדיניות העדכונים ואת ההוראות להוספת מודלים חדשים — צוות הלקוח יכול לפתח את בלוק ה-AR בלעדינו.
מה מוסרים לידיים: בילד, תרשימים, נהלים
מסירה היא לא ארכיון של קוד מקור, אלא סט של חפצי מסירה, שלפיהם הצוות שלכם או מהנדסי התמיכה שלנו משחזרים את הבילד, מתקנים את הסצנה ומעדכנים תוכן בלי לפענח קוד זר. להלן — מה כלול בחבילה של מודול AR.
- בילד עובד — גרסאות מורכבות של האפליקציה לפלטפורמות היעד, הגדרות הסביבה וסקריפטים שבאמצעותם הבילד משוחזר מאפס על מכונה נקייה.
- תרשים הסצנה — היררכיית הצמתים, עיגון העוגנים ונקודות המיקום, הלוגיקה של זיהוי מישורים והתנהגות האובייקטים באובדן טראקינג.
- כללי גישה לתוכן — תפקידים והרשאות: מי מפרסם ומוריד מודלים, איפה נמצאים קבצי המקור, איך בנויים ניהול גרסאות וחזרה לאחור של פרסום.
- תיעוד של מודול AR — נקודות הרחבה, חוזים בין השכבות, תלויות של רכיבי הפלטפורמה וסדר העדכון שלהם.
- נוהל עדכון מודלים — דרישות לפורמטים ולמטוב (אופטימיזציה), בדיקות לפני פרסום, סדר החלפת התוכן בלי לבנות את האפליקציה מחדש.
- הוראות לתמיכה — כשלים אופייניים, למה להסתכל בלוגים, איך לחזור לאחור בגרסת האפליקציה ולהשיב את גרסת הסצנה הקודמת.
- מטריצת הרשאות — היכן נשמרים מפתחות החתימה וחשבונות הפרסום, מי הבעלים, ואיך הם מועברים בהחלפת ספק.
החבילה מתעדכנת בכל שינוי של המודול: אם תיקון לא בא לידי ביטוי בתרשים הסצנה או בנוהל, המסירה נחשבת חלקית.
קייס: חדר הלבשה באפליקציה — מה היה לפני ומה אחרי
באפליקציה של רשת האופנה Модный дом ההלבשה הייתה מסך נפרד, שאליו הגיע קונה אחד משבעה. הסצנה עם הבגדים נפתחה תוך 4–5 שניות, המודל "צף" ביחס לגוף, ובסיבוב המצלמה נקטע; באולם המכירה, בתאורה חלשה, הטראקינג אבד כמעט מיד.
לפי הלוגים: 62% מהסשנים של ההלבשה הסתיימו בשגיאה, משך ממוצע — 8 שניות, הוספות לסל מחדר ההלבשה כמעט לא היו.
מה נבנה מחדש בסצנה ובטראקינג
הבגדים נבנו מחדש לתצוגה במובייל: גאומטריה מפושטת וטקסטורות מוכנות מראש במקום מודלים כבדים מהמקור — משקל הסצנה ירד פי כמה, והפריים הראשון מופיע מוקדם בהרבה. בטראקינג הוספנו חיזוי של מיקום הגוף והחלקה — הבגד נשאר במקומו בתנועות מהירות ובסיבובים, ולא "מתקלף".
במקום מודל אחד אוניברסלי אנחנו מחזיקים כמה גזרות ומתאימים אותן לפי המידות של הקונה, ולכן ההלבשה הפסיקה להיות "על העין".
סף התאורה נקבע לפי מדידות באולמות אמיתיים: במקום הודעת שגיאה, האפליקציה מרמזת היכן לעמוד. זה הסיר את תרחיש הכשל הנפוץ ביותר — הקונה לא נטש את ההלבשה, אלא השלים אותה עד הסוף.
מדדים לפני ואחרי
שיעור הסשנים המוצלחים של ההלבשה — מ-38% ל-94%. הזמן עד הפריים הראשון — מ-4–5 שניות ל-1.5. משך ההלבשה הממוצע עלה מ-8 שניות לדקה וחצי, שיעור ההוספות לסל אחרי ההלבשה — פי שלושה, והחזרות עם הסיבה "לא התאים בגזרה" ירדו בכרבע בערך.
במה נבדלת הלבשת AR מתצוגת 3D באתר
תצוגת 3D חיה בתוך המסך: המודל מסתובב על רקע ניטרלי, ואת קנה המידה המשתמש משלים לעצמו — האם החפץ ייכנס ליד הספה, האם יתאים בגובה למדף. הלבשת AR מסירה את ההנחה הזו: המצלמה מציגה את החלל, האפליקציה מזהה מישור וממקמת את האובייקט שם בפרופורציות אמיתיות.
מבחינה טכנית ההבדל הוא בעיגון למשטח. האפליקציה מזהה את המישור, עוקבת אחרי מיקום המכשיר בחלל, מתאימה את קנה המידה ומתחשבת בתאורה, ולכן האובייקט לא צף ולא שוקע, והצל נופל מתחת לרגליים. זה גם עונה על השאלה "האם זה ייכנס", שאין מודל מסתובב יכול לענות עליה.
התרחיש של השימוש קובע את הבחירה, ולא הטכנולוגיה עצמה. נעליים, שעונים, אקססוריז, מוצרי חשמל באריזה — לצורה ולצבע מספיק מודל מסתובב: נטען מהר, נפתח בכל מכשיר. רהיטים, מוצרי חשמל גדולים, דקור וכל מה שמלבישים "על עצמך" דורשים עיגון למשטח: שם הגודל הוא שקובע.
ההתנהגות של המשתמש שונה. התצוגה מגדילה את עומק הצפייה ואת מספר ההשוואות, הלבשת AR — את שיעור המגיעים להזמנה, ומורידה החזרות של "לא התאים במידה". המחיר — צעדים מיותרים: הרשאה למצלמה, כיוון אל המשטח, המתנה לזיהוי, וחלק מהקהל נושר בגללם.
לכן אנחנו לא מציבים בחירה של "או". בתרחיש טיפוסי התצוגה מכסה את הכניסה לקטלוג, והלבשת AR — את שלב ההחלטה על פריטים שבהם הגודל חשוב; החלוקה נקבעת לפי קטגוריות, וממנה נגזרת שאר הארכיטקטורה של האפליקציה.
ספקות טכניים: מכשירים, תאורה, דיוק
את המגבלות של הסצנה קובע לא הקוד, אלא השילוב של מצלמה, חיישנים אינרציאליים וספריות הפלטפורמה. להלן — ארבע שאלות שעולות לרוב בשלב הקבלה, ואיך אנחנו סוגרים כל אחת.
על אילו דגמים האפליקציה בכלל תפעיל מצב AR?
הסצנה נשענת על שכבת הפלטפורמה — ARKit ו-ARCore של הענפים העדכניים, ולכן אנחנו מקבעים את רשימת המכשירים לפני תחילת הפיתוח. אנחנו מחזיקים שתי רמות: מורחבת בדגמים עם חיישן עומק ובסיסית בשאר, שבהם הטראקינג מבוסס על מצלמה וג'ירוסקופ. בדגמים שמחוץ לרשימה האפליקציה מותקנת, אבל במקום סצנה מציגה רמז — זה הוגן יותר מסירוב בהתחלה.
מה קורה בתאורה חלשה?
המצלמה לא מוצאת נקודות אופייניות: הסצנה "צפה", האובייקטים רועדים וזזים. אנחנו מציגים מחוון איכות טראקינג, מבקשים להוסיף תאורה ומעבירים את האובייקט למצב עיגון למישור במקום התאמה פריים-אחר-פריים. מתחת לסף התאורה אנחנו מציגים הודעה מובנת, ולא ארטיפקטים.
עד כמה מדויקות המדידות בסצנה?
השגיאה תלויה במרחק ובמרקם המשטח: מקרוב, על מישור מסומן, אלו סנטימטרים בודדים; בקטעים רחוקים ואחידים היא גדלה. במקומות שהדיוק בהם קריטי אנחנו מגבילים את אזור העבודה ומציגים סימן ייחוס בגודל ידוע — כך השגיאה לא מצטברת עם ההקפה.
האם הסצנה עובדת בלי רשת?
הזיהוי והטראקינג מחושבים על המכשיר, ולכן במצב לא מקוון הסצנה עולה ומחזיקה. רשת נדרשת לתוכן ולאנליטיקה: את החומרים אנחנו אורזים למטמון מקומי, את האירועים צוברים ושולחים במקבץ כשהחיבור חוזר. תוכן כבד נטען ברקע באזור Wi-Fi, כדי שבשטח המשתמש לא ימתין להורדה.
נדבר על המשימה ונחזור עם אומדן ותוכנית עבודה
כדי שהאומדן של פרויקט AR יהיה ענייני ולא "על העין", אנחנו צריכים נתוני פתיחה על המשימה: מה מזהים, באילו תנאים זה אמור לעבוד ועל אילו מכשירים.
מציאות רבודה רגישה לתרחיש — טראקינג לפי מרקר, לפי מישור ולפי קואורדינטות נותן עומק עבודה שונה ודרישות שונות לתוכן שיהיה צריך להכין.
מה לשלוח להתחלה:
- תיאור התרחיש: מה המשתמש רואה במצלמה ומה קורה אחרי הזיהוי;
- רשימת מכשירים וגרסאות מינימליות של מערכות המובייל שצריך לתמוך בהן;
- חומרים — מודלים, תמונות, וידאו, שרטוטים; אם אין, פשוט תכתבו, ומקורות התוכן יידונו בנפרד;
- 2-3 אפליקציות-רפרנס והסבר מה בדיוק מוצא חן בעיניכם בהן מבחינת התנהגות;
- מגבלות: תאריך האירוע או ההשקה, דרישות לגבי גישה לנתונים, תשתית קיימת;
- האם יש אפליקציה מוכנה שאליה ה-AR מוטמע, או שהבילד נבנה מאפס.
בנפרד נבהיר את מה שבדרך כלל צף כבר בעבודה: איך הסצנה מתנהגת בתאורה חלשה, האם נדרשת עבודה בלי רשת, מה קורה באובדן טראקינג ואיך האפליקציה תחזיר את המשתמש לסצנה.
בתשובה נחזור עם תוכנית עבודה: הרכב הצוות עם התפקידים, השלבים ומשכם, מה אנחנו עושים בכל שלב ומתי אתם מקבלים את התוצאה. בסעיף נפרד — הסיכונים של התרחיש והמרווח עליהם. תארו את המשימה בצורה חופשית — בהמשך נבין את הפרטים תוך כדי השיחה.