תצוגה מקדימה AR של אמנות NFT באפליקציית מובייל: מימוש

למה תצוגת AR של NFT נשברת באפליקציה לנייד

תצוגת AR של NFT — המסך היקר ביותר מבחינת חוויה באפליקציה: המשתמש כבר פתח את הכרטיס, כיוון את המצלמה — וראה ריבוע אפור במקום היצירה. התקלה הראשונה כמעט תמיד בצד הוויטרינה: הטוקן קיים, אבל המטא-דאטה מפנה לקובץ שמוגש פעם בהשהיה ופעם בשגיאה, והאפליקציה לא יודעת לחזור לתצוגה סטטית.

טעינת מודל תלת-ממד מוסיפה בעיה שנייה. קובצי המקור נבנים לצפייה במחשב שולחני: טקסטורות כבדות, עשרות אלפי פוליגונים, בלי אף רמת פירוט. בחיבור נייד סצנה כזאת נטענת 6–10 שניות, והמשתמש עוזב לפני שהוא רואה את היצירה.

מציאות רבודה באפליקציה נשברת בעיגון למשטח. מכשירים מזהים מישור בצורה שונה, מחזיקים קנה מידה וצללים בצורה שונה, ולכן אותו מודל בטלפונים שונים מופיע פעם באוויר ופעם בתוך השולחן. שגיאות עיגון למשטח המשתמש קורא כפגם במוצר, אף שזה הבדל בכיול המצלמות ובמערך החיישנים.

ביצועי אפליקציית המובייל נפגעים אחרונים בשרשרת: מצב התצוגה גורר איתו את כל הסצנה, הפענוח ושאר הלוגיקה של המסך — האפליקציה מתחממת, מפילה פריימים והמערכת סוגרת אותה. נבחן איך מטפלים בזה.

מה נותנת תצוגה מקדימה במציאות רבודה: האפקט במספרים

תצוגה מקדימה במציאות רבודה משנה את המכניקה של הכרטיס: במקום תמונה סטטית המשתמש מקבל אובייקט שאפשר להסתובב סביבו ולבחון אותו בחדר שלו. את הזמן עד לפריים הראשון אנחנו שומרים בשברי שנייה — המודל מוצג בהדרגה בזמן שהפרטים ממשיכים לרדת.

המרת הכרטיס עולה מסיבה מובנת: ההחלטה מתקבלת במקום, בלי השאלה «ואיך זה ייראה אצלי». שיעור המעברים לצפייה ומשם — לרכישה או למנוי — גדל, כי הספק המרכזי מוסר תוך כמה שניות.

מעורבות המשתמשים גם ניתנת למדידה. סשן הצפייה ארוך יותר מאשר בכרטיס סטטי: מסובבים את האובייקט, מקרבים, מצלמים וחוזרים אליהם מאוחר יותר — פתיחות חוזרות קורות בלי תעבורה נוספת.

עמידות במכשירים חלשים מוטמעת בארכיטקטורה: אנחנו מכינים כמה רמות פירוט של המודל ומחליפים ביניהן לפי היכולות של הטלפון הספציפי. שיעור סשני הצפייה המוצלחים במכשירי תקציב שונה ממכשירי דגל בגבולות שגיאה, ולא פי כמה.

במקביל נעלם סוג שלם של כשלים בטעינת המודל: זרם נתונים שנקטע, קישור מיושן לקובץ, פורמט לא תואם — כבר לא הופכים למסך שחור. האפליקציה בודקת את המודל מראש או מציגה תצוגה מקדימה, או מציעה גרסה סטטית — בלי מבוי סתום למשתמש.

פורמטי צפייה: השוואת מצבים והמגבלות שלהם

פורמט הצפייה קובע היכן מחושב הפריים — במכשיר של האורח או בצד שלנו — ומה בדיוק האדם רואה על המסך. מזה תלויים דיוק ההנחה של האובייקט על המשטח, התנהגות הצללים ועל איזה מאגר מכשירים הסצנה תרוץ בלי הפתעות.

ארבעת המצבים שלמטה נבדלים לא באיכות התמונה, אלא במה שאנחנו יכולים להבטיח: עומק הסצנה, תגובה לתנועה, כיסוי התמיכה במכשירים.

המצבים לא שוללים זה את זה: מודול נייטיב מכסה את המסלול המרכזי, צפייה באינטרנט מכסה דגמים ישנים וכניסה דרך קישור. לפני ההשקה אנחנו מודדים את זמן ההתחלה של הסצנה ואת שיעור המכשירים שבהם המצב עבד בלי תקלות, ורק אחר כך מקבעים את מטריצת התמיכה.

סדר ההטמעה: מניתוח מודלים ועד מסירה

את שלבי ההטמעה אנחנו בונים כך שכל צעד נשען על הקודם שנבדק, ולא על הנחות. קודם כל מנתחים מה כבר קיים בצד הלקוח, ורק אחר כך מתכננים את הסצנה וכותבים קוד — אחרת תיקון מאוחר עולה יותר מאשר ביקורת.

1. ביקורת מודלים ומטא-דאטה. בודקים פוליגונים, טקסטורות, יחידות קנה מידה, התאמה של המודל לטוקן. חלק מהקולקציה עובר אופטימיזציה, חלק מסננים מיד.
2. סכימת סצנה. מקבעים קנה מידה, נקודת הופעה של הפריט, תאורה, רקע והתנהגות בסיבוב — זה החוזה בין העיצוב לפיתוח.
3. בניית מודול התצוגה המקדימה. צפייה, טעינה לפי מזהה טוקן, מטמון מודלים ומצבים «נטען / נכשל» — בנפרד מהלוגיקה של האפליקציה עצמה.
4. בדיקה במכשירים. מריצים על מכשירים חלשים וחזקים, אלכסונים שונים וגרסאות מערכת שונות: יציבות פריימים, צריכת זיכרון, התנהגות בחימום ובמעבר רשת.
5. כשלים ומקרי קצה. שער לא זמין, מודל פגום, סירוב לגישה למצלמה — לכל מקרה מסך משלו ופעולה ברורה למשתמש.
6. תיעוד. דרישות למודלים, סכימת סצנה והוראות לחיבור קולקציה חדשה בכוחות הצוות של הלקוח.
7. מסירת הפתרון. סקירה עם המהנדסים של הלקוח, הרשאות, הדרכה ותקופת ליווי מוסכמת אחרי השקה.

מה נשאר אצלכם אחרי המסירה: קונפיגורציות ותיעוד

אחרי המסירה נשאר לא רק האפליקציה הבנויה, אלא גם כל מה שצריך כדי שתצוגת AR של NFT תמשיך לחיות בלעדינו. אנחנו מוסרים סצנות, מודלים, סכימות החלפת נתונים עם שכבת הבלוקצ'יין וכללים שלפיהם הצוות מוסיף פריטים חדשים. בלי זה הטוקן החדש הראשון הוא ניתוח של קוד זר בניחוש.

• מודלים וחומרים. פריטים לרינדור נייד: צפיפות רשת סבירה, טקסטורות אפויות, חומרים נקיים — התצוגה המקדימה נפתחת במכשיר בינוני בלי ירידות ביצועים.
• קונפיגורציית סצנה. תאורה, סביבה, קנה מידה ונקודות עיגון למישור מוגדרים בקבצים: פריט חדש נכנס לפריים באופן צפוי, בלי התאמה לכל דגם טלפון.
• תיעוד אינטגרציה. סכימת החלפה עם שכבת הבלוקצ'יין: איך מקבלים מטא-דאטה של הטוקן, היכן וכמה זמן שומרים מדיה במטמון, מה מציגים כשאין גישה לצומת.
• הרשאות לאחסון. מפתחות למאגר המודלים ולהפצת התוכן רשומים בחשבונות שלכם, הרשאות פרסום מופרדות מהרשאות עריכה.
• הוראות לצוות. סדר הוספה של פריט חדש וצ'ק-ליסט קבלה: מה לבדוק במכשיר לפני שחרור, אילו פרמטרים נחשבים לפגם.
• נוהל עדכון. ניהול גרסאות של מודלים וסצנות, חלון תאימות לגרסאות ישנות של האפליקציה ונוהל חזרה לאחור אם עדכון הרע את הפריים.

הארטיפקטים נמצאים במאגר שלכם ומיועדים למהנדס שיפתח אותם בעוד חצי שנה בלי המחבר לידו.

מקרה בוחן: איך האיצו את פתיחת המודל בסמארטפונים חלשים

תצוגת AR — אותו תרחיש כמו בשווקים מקוונים כמו OpenSea: הקונה בכרטיס הלוט מכוון מצלמה ורואה אובייקט בחלל הפנימי, בלי לצאת מהאפליקציה. במכשירים ברמת כניסה התרחיש התפרק: המודל או לא נפתח, או הופיע כל כך מאוחר שהמשתמש הספיק לסגור את הכרטיס.

במקרה הבוחן הזה של אפליקציית מובייל בנינו מחדש את ההכנה והטעינה של הנכס ומדדנו את התוצאה על אותה דגימת סשנים.

מה בדיוק שינו בטעינה

ויתרנו על ההמתנה למודל מלא: ראשונה מגיעה עותק קליל של הגאומטריה וטקסטורות באיכות מופחתת, והסט המלא נמשך ברקע כבר בזמן הצפייה. מטמון במכשיר מחזיק את האובייקטים האחרונים שנפתחו, לכן כניסה חוזרת לכרטיס כמעט מיידית, והחילוץ לא חוסם את הממשק.

העומס על המכשיר הוגבל בתקציב: מספר מקורות האור, קצב רענון הסצנה ורזולוציית הצללים מוגדרים לפי מדיניות שמתאימה למחלקת המכשיר, ולא בהגדרות אחידות לכולם.

זה הסיר סוג של כשלים שבהם האפליקציה נסגרה בגלל זיכרון: תקלות כאלה הגיעו בקבוצות דווקא מדגמי תקציב — עכשיו הן בודדות ומשויכות למכשירים ספציפיים, ולא לתרחיש הצפייה בכללותו.

במה שונה צפייה במודל מהצגה על גבי המצלמה?

אלה שני מצבים שונים עם דרישות שונות לנתוני המודל. בצפייה בתלת-ממד המצלמה חגה סביב האובייקט על רקע ניטרלי: הסצנה נשלטת לחלוטין, אין צורך בעיגון למשטח, וקנה המידה מותאם למסך.

במצב הצגה על גבי המצלמה המודל נכנס לסצנה אמיתית, וכל הפרמטרים — מיחידות מידה ועד תאורה — מפסיקים להיות שרירותיים.

קנה המידה של המודל ב-AR מוגדר ביחידות אמת, ולא «לפי הטעם». אם היצירה מיוצאת בלי יחידות תקינות, האובייקט או תלוי באוויר או יורד מתחת למשטח. אנחנו מכיילים את הגאומטריה לפי אמת מידה — בהעברה בין מכשירים הגודל נשאר זהה, ולא «בערך דומה».

דיוק העיגון הוא שכבה נפרדת של עבודה. המישור מזוהה לפי טקסטורה ותאורה, לכן על קיר בגוון אחיד או שולחן מבריק המודל נסחף ומחליק. עוגנים על סימנים יציבים והחלקת מסלול עוזרים: הרעידה נעלמת, אבל מופיעה אינרציה בתגובה לתנועה.

התאורה בסצנה קובעת אם המשתמש יאמין לתמונה. בצפייה בתלת-ממד מספיקה סכימת תאורה סטודיו אחת, ב-AR צריך להעריך את התאורה האמיתית ולהתאים מקורות וצללים, אחרת המודל נראה כמו מדבקה על וידאו.

עבור ויטרינה בשווקים מקוונים כמו OpenSea בדרך כלל מספיקה צפייה בתלת-ממד: היא צפויה ולא תלויה במצלמה. הצגה על גבי המצלמה היא תרחיש נפרד: לנסות את היצירה על הקיר שלך. אנחנו מחזיקים את שניהם על אותו קובץ מודל עם פרופילים שונים של תאורה וקנה מידה, כדי לא לשכפל נכסים.

ספקות טכניים נפוצים לגבי אינטגרציה באפליקציה

לפני ההתחלה לקוחות בודקים אותם מקומות: כמה שוקל המודל, מה יראו הבעלים של טלפונים ישנים, איך הקולקציה מתעדכנת אחרי דרופ ואיזה היקף שינויים ממתין לאפליקציה שכבר שוחררה. את התשובות מקבעים במסמך הפרויקט לפני תחילת העבודה — כדי שהן לא יצופו בקבלה.

מה יראו הבעלים של מכשירים ישנים?

את גבול התמיכה התחתון קובעים לפי מצבור הטלפונים, ולא לפי הדגמים האחרונים. על חומרה חלשה מפעילים סצנה קלה ותצוגה מקדימה סטטית במקום רינדור חי, בודקים במכשירים אמיתיים — אמולטור לא מראה ירידות ביצועים.

איך הקולקציות מתעדכנות אחרי דרופ חדש?

את הקטלוג והמודלים הוויטרינה מקבלת מהשרת, לכן מהדורה חדשה מופיעה בלי פרסום בחנויות. לנכסים יש ניהול גרסאות: בנייה ישנה עובדת עם הסט שלה, וחדשה מושכת את העדכני.

איך התצוגה המקדימה מתנהגת בתוך הוויטרינה?

המודל נטען ברקע ולא חוסם גלילה — המשתמש מדפדף בקטלוג בזמן שהסצנה מתכוננת. במקום שבו מצב AR לא זמין, מציגים רינדור סטטי ומעבר לעמוד הבעלות, כדי שהוויטרינה לא תיראה ריקה.

כמה שינויים נדרשים באפליקציה עצמה?

האינטגרציה מצטמצמת למסך הוויטרינה ולנקודות מעבר — אין צורך לכתוב מחדש את הקוד המרכזי. בענף עדכני השינויים נוגעים בכמה מסכים; בבסיס קוד ישן קודם מעדכנים אותו, אחרת גדל הסיכון לשגיאות במכשיר.

נדבר על המשימה: נעריך את היקף העבודה ונציע תוכנית

תארו את המשימה כמו שהיא: תרחיש שימוש, על אילו פלטפורמות ודגמי מכשירים תצוגת AR צריכה לעבוד, מאיפה נמשכים תמונות ומטא-דאטה של טוקנים, האם נדרשת צפייה לא מקוונת ומה כבר מיושם באפליקציה.

בתגובה אנחנו שולחים לא מצגת כללית, אלא ניתוח למקרה שלכם: איפה מספיקים מודולים מוכנים, ואיפה נדרשת לוגיקה משלכם להצגה ולהכנת מודלים.

• הערכת המשימה — אילו עבודות נכללות בהיקף, מה כבר סגור על ידי הצוות שלכם ומה אנחנו לוקחים על עצמנו.
• ניתוח אפשרויות — מודול מציאות רבודה מובנה לעומת הצגה דרך שכבת דפדפן: במה הם נבדלים באיכות התמונה, במהירות ההפעלה ובמורכבות התחזוקה.
• תוכנית עבודה לפי שלבים ולוחות זמנים — מאב-טיפוס עם מודל אחד ועד שחרור, עם נקודות ביקורת והצגת תוצאה ביניים.
• הרכב הצוות — מי בדיוק מוביל את הפרויקט: מהנדס פיתוח מובייל, מומחה לגרפיקה תלת-ממדית, בודק במכשירים אמיתיים.
• סדר המסירה — מה עובר אליכם: קוד מקור, הגדרות בנייה, סכימת טעינת מודלים ופורמט הוספה של טוקנים חדשים.
• סיכונים והנחות — איפה ייתכנו עיכובים: בדיקה בחנויות האפליקציות, הכנת מודלים בצד הלקוח.

התחילו בתיאור קצר — זה יספיק כדי לחזור עם הערכה ולהציע תוכנית. אם המשימה עדיין לא מגובשת, נפרק אותה לשלבים יחד.