אימות קנה מידה נכון של אובייקטים גרפיים ב-VR

אימות קנה מידה נכון של אובייקטי גרפיקה ב-VR

במשחקים רגילים, קנה מידה הוא מוסכמה. חרב יכולה להיות ארוכה או קצרה יותר — אף אחד לא שם לב. ב-VR, המשתמש עומד ליד אובייקטים. שולחן בגובה 90 ס"מ נתפס על ידי המוח כ"נכון" או "נמוך מדי" — כי האדם התנסה עם שולחנות אמיתיים. משקוף דלת בגובה 1.9 מ' גורם לך להתכופף אינסטינקטיבית. אובייקט בגודל אגרוף שנראה בגודל ראש ב-VR הורס את התפיסה.

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

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

כיצד Unity קובע קנה מידה ל-VR

החוק הבסיסי של Unity ל-VR: יחידה אחת = מטר אחד. זו לא המלצה — זו דרישה. אם סצנה מודלה ביחידות אחרות (סנטימטרים, אינצ'ים) ויובאה ללא המרה, כל האובייקטים יהיו ענקיים או זעירים ב-VR.

מקור תכוף לבעיות הוא ייבוא מעורכי תלת-ממד. Blender עובד במטרים כברירת מחדל, Autodesk Maya בסנטימטרים. קובץ FBX מ-Maya ללא הגדרת יחידות מפורשת מגיע ל-Unity עם Scale Factor של 0.01 ב-ModelImporter. האובייקט נראה "נכון" רק אם איפשהו בשרשרת הטרנספורמציה הגורם הזה מקוזז. אם לא — הוא או קטן פי 100 מהנדרש, או שהמפתח מגדיר ידנית Scale (100, 100, 100) על ה-GameObject, מה ששובר חישובי פיזיקה ו-NavMesh.

הגישה הנכונה בעת ייבוא: ב-ModelImporter → Model → Scale Factor, הגדירו את הערך שמביא את האובייקט למידות מטר אמיתיות. עבור FBX מ-Maya זה בדרך כלל 0.01. לאחר מכן, אמתו: דמות אנושית צריכה להיות 1.7–1.85 מ' מהרגליים עד לראש.

מדוע אובייקטי ייחוס קריטיים ל-VR

לאימות קנה מידה ב-VR, אנו משתמשים באובייקטי ייחוס — רשתות עם גדלים אמיתיים ידועים:

• גובה מבוגר ממוצע: 1.75 מ' (רצפה עד ראש)
• משקוף דלת סטנדרטי: גובה 2.0 מ', רוחב 0.9 מ'
• שולחן אוכל: גובה 0.75 מ'
• כיסא: גובה מושב 0.45 מ' מהרצפה
• מכונית (נוסעים): ~1.5 מ' גובה, 4.5 מ' אורך
• לבנה: 25 × 12 × 6.5 ס"מ

אנו יוצרים ScaleVerificationScene עם אובייקטי ייחוס אלה ומישור רצפה. כל נכס חדש או שונה ממוקם ליד הייחוסים ב-VR ומאומת חזותית. זה לוקח 2–3 דקות לכל נכס ומבטל את מחלקת הבעיות "נראה בסדר בעורך, נראה מוזר ב-VR."

VR Height Reference — כלי מיוחד ב-XR Interaction Toolkit Samples: בובת תצוגה וירטואלית עם פרופורציות סטנדרטיות המוצבת בסצנה לבדיקת קנה מידה חזותית מהירה של אובייקטים אינטראקטיביים.

קנה מידה של ידיים ואזור השגה

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

אזור השגה: זרוע של מבוגר ממוצע נמתחת 0.7–0.8 מ' מהכתף. ב-VR, XRRig.cameraFloorOffsetObject קובע את גובה המצלמה מעל הרצפה. אובייקטים אינטראקטיביים צריכים להיות ממוקמים באזור השגה נוח: גובה 0.5–1.2 מ', לא יותר מ-0.6 מ' אופקית ממרכז הגוף.

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

כיצד לאוטומציה בדיקת קנה מידה

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

1. אוסף את כל ה-GameObjects עם התג Interactable או רכיב XRBaseInteractable.
2. בודק את Bounds.size שלהם מול מינימום/מקסימום מוגדרים מראש לקטגוריית האובייקט (נשק: 0.15–1.5 מ', רהיטים: 0.3–2.5 מ').
3. מוציא רשימה של אובייקטים שנמצאים מחוץ לטווח התקין.

הספים מוגדרים ב-ScriptableObject ScaleVerificationConfig. זה לא מחליף בדיקות VR חזותיות אלא מסנן שגיאות ברורות — Scale מקרי של 0.01 או 100 על אובייקטים מיובאים.

בדיקה נוספת: ModelImporter עבור כל ה-FBX בפרויקט — ודאו שאין אובייקטים עם scaleFactor != 1 לאחר נורמליזציה. זה מטופל על ידי פוסט-מעבד ייבוא (AssetPostprocessor.OnPreprocessModel) שמתעד או מתקן אוטומטית גורם קנה מידה שגוי.

בדיקת קנה מידה אוטומטית מהירה פי 10 מבדיקה ידנית: 0.2–0.5 דקות לכל נכס במקום 2–5, תוך תפיסת עד 90% מהחריגות הגסות.

מה כוללת העבודה

• דוח עם תוצאות ביקורת של מצב הנכסים הנוכחי (Scale Factor, Bounds, אזורי השגה).
• תיקון Scale Factor לכל המודלים המיובאים.
• הקמת סצנת ייחוס ScaleVerificationScene עם אובייקטי ייחוס.
• פיתוח כלי עורך לבדיקת קנה מידה אוטומטית.
• ייעוץ בנושא אינטגרציה ותמיכה נוספת.

using UnityEditor;
using UnityEngine;

public class ScaleFactorNormalizer : AssetPostprocessor
{
    private void OnPreprocessModel()
    {
        ModelImporter importer = (ModelImporter)assetImporter;
        if (importer.scaleFactor != 1f)
        {
            Debug.LogWarning($"FBX {assetPath} has scale factor {importer.scaleFactor}. Consider normalizing.");
        }
    }
}

תהליך האימות

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