العودة إلى المدونة

Godot على XREAL AURA: دليل عملي للتطوير المكاني الأصلي

نُشر في 3 نوفمبر 2026
Godot على XREAL AURA: دليل عملي للتطوير المكاني الأصلي تم إنشاؤها بمساعدة الذكاء الاصطناعي

باختصار

اكتشف دليل Godot العملي لتطوير الفضاءات على XREAL AURA: إعداد المحرر على النظارة، بناء المشاهد بالحاويات المكانية، وتجنب انجراف المرساة ومشاكل الإضاءة

خط أنابيب البناء الحالي لتطبيقات XR يعني الربط بجهاز كمبيوتر مكتبي، وتصدير ملف APK، وتثبيته عبر ADB، وارتداء النظارة، واكتشاف خطأ مطبعي، ثم البدء من جديد. XREAL AURA يزيل هذه الحلقة تمامًا، وGodot ضمن قائمة الإطلاق بمحرر كامل يعمل على النظارة نفسها. هذا يغيّر معنى "التكرار" في التطوير المكاني.

يستعرض هذا الدليل سير العمل الفعلي: تشغيل المحرر على AURA، وهيكلة مشهد مكاني باستخدام OpenXR Spatial Containers، والتعامل مع نموذج الرؤية الشفافة (see-through) الذي يميّز النظارات البصرية عن سماعات الواقع الافتراضي، والمزالق التي ستواجهك عند أول تصدير.

لماذا تغيّر الرؤية الشفافة البصرية افتراضاتك التصميمية

XREAL AURA هو أول جهاز رؤية شفافة بصرية على Android XR. هذه الجملة وحدها تكسر الافتراضات المضمنة في معظم دروس Godot الخاصة بتطبيقات XR.

في سماعة الواقع الافتراضي، تقوم كاميرا السماعة برسم كل شيء. يرى المستخدم بيئتك ولا شيء غيرها. أما في النظارات ذات الرؤية الشفافة البصرية، يرى المستخدم من خلال العدسات العالم الحقيقي، ويتم تركيب المحتوى المرسوم فوقه. هذا ليس مثل تمرير الفيديو (video passthrough) في Quest — فتمرير الفيديو يلتقط الواقع بالكاميرات ويعيد عرضه، مما يضيف زمن استجابة وفقدانًا للضوء. أما الرؤية الشفافة البصرية فلديها صفر زمن استجابة للعالم الحقيقي.

نتائج عملية على ميزانية الرسم الخاصة بك:

  • لا يمكنك تعتيم العالم الحقيقي. اللون الأسود على شاشة شفافة يكون شفافًا. لا تملك خلفية معتمة، لذا فإن واجهات المستخدم التي تعتمد على التباين مع اللوحات الداكنة ستفشل في غرفة مضيئة.
  • المحتوى ذو المظهر الإضافي (Additive) هو الأفضل. المحتوى المضيء الساطع يظهر جيدًا؛ بينما يختفي المحتوى الداكن منخفض التشبع. صمّم لوحة ألوانك بسطوع يبلغ 2-3 أضعاف ما تستخدمه في الواقع الافتراضي.
  • مجال الرؤية أضيق من الواقع الافتراضي. المحتوى الموضوع بزوايا متطرفة يخرج عن منطقة العرض. أبقِ أهداف التفاعل الرئيسية ضمن نطاق ±30 درجة تقريبًا من المركز الأمامي.

إذا كنت قد أصدرت تطبيقات واقع افتراضي من قبل، فتوقع إعادة ضبط كل مادة وكل لوحة واجهة. خصص يومًا كاملًا لكل مشهد.

إعداد محرر Godot على النظارة

يتم توزيع المحرر على Google Play، وليس كملف APK مثبّت يدويًا. هذا مهم لأنه يعني أنه يمكنك تحديثه مثل أي تطبيق آخر.

تسلسل الإعداد:

  1. ثبّت محرر Godot على XREAL AURA من متجر Play.
  2. ثبّت تطبيق بيئة بناء Gradle المصاحب. يوفّر هذا التطبيق سلسلة أدوات تصدير Android، لذا لن تحتاج إلى بناء JDK وAndroid SDK من الصفر على الجهاز.
  3. سجّل الدخول بهوية مطوّر Android إذا كنت تخطط لتوقيع ونشر الإصدارات من الجهاز.
  4. شغّل المحرر — يفتح في مساحة عمل مكانية متعددة النوافذ بدلاً من نافذة مسطحة واحدة.

النقطة الرابعة هي المثيرة للاهتمام. يمنحك المحرر مجموعة ميزات بأسلوب سطح المكتب، لكنها مرتبة كنوافذ عائمة في الفضاء. يمكنك إبقاء شجرة المشهد في حجم واحد ومنفذ العرض ثنائي الأبعاد في حجم آخر.

ما الذي توفره لك بالفعل سير العمل على الجهاز

الإجابة الصادقة: تكرار سريع على الإحساس، وتكرار أبطأ على الأصول.

تحرير الـ shaders وضبط تحويلات العقد واختبار تعيينات الإدخال على الجهاز المستهدف يلغي دورة التصدير والاختبار بالكامل. تستغرق هذه الدورة عادةً من 3 إلى 8 دقائق عند احتساب وقت البناء والنقل وإعادة التشغيل. عشر تكرارات تعني ساعة كاملة ضائعة.

ما لا يساعد فيه: استيراد أطالس نسيج كبيرة، أو تنفيذ عمليات خبز خرائط الإضاءة الطويلة، أو أي شيء كثيف الاستخدام لوحدة المعالجة المركزية. قم بذلك على محطة عمل. التقسيم الواقعي هو إنشاء الأصول على سطح المكتب، وتجميع المشهد وضبطه على النظارة.

بناء محتوى مكاني باستخدام OpenXR Spatial Containers

دعم Godot لنظام Android XR يتضمن OpenXR Spatial Containers — وهي مساحات يديرها النظام حيث يضع تطبيقك المحتوى المكاني. التشبيه المقدم من المنصة نفسها قريب من الدقة: التطبيقات التقليدية ترسم محتوى ثنائي الأبعاد داخل نوافذ على سطح المكتب؛ بينما ترسم التطبيقات المكانية محتوى ثلاثي الأبعاد داخل حاويات في الغرفة.

هناك نوعان من الحاويات يستحقان الفهم قبل كتابة الكود:

نوع الحاوية الأفضل لـ المفاضلة
Volume كائنات ثلاثية الأبعاد بعمق حقيقي، وموضع مثبت بالعالم قد يقيّد النظام حدود الحجم
Panel أسطح واجهة المستخدم، النصوص، ألعاب ثنائية الأبعاد تُعرض على مستوى ثابت؛ إشارات العمق مسطحة

الخطأ الذي يقع فيه معظم المطورين هو اختيار الحجم (Volume) لواجهة المستخدم. النص في حاوية الحجم يتم تحجيمه وتحريكه بواسطة النظام بطرق لا يمكنك توقعها بالكامل، وعنصر الرادار الذي وضعته بعناية ينزاح. ضع واجهة المستخدم في حاوية لوحة (Panel) ودع النظام يتولى التنسيب.

العمل مع واجهة برمجة تطبيقات الحاويات المكانية

يكشف Godot عن الحاويات المكانية من خلال فئات إضافية في OpenXR. تعتمد أسماء الفئات الدقيقة على إصدار Godot لديك، لذا تحقق من قائمة ميزات المحرك لمعرفة روابط الحاويات المكانية الحالية قبل كتابة كود الإنتاج. النمط أدناه يعكس كيفية تنظيم محتوى XR القائم على الحاويات عادةً.

extends Node3D

signal container_created(handle: int)

# Spatial container setup for Android XR.
# Class names are version-dependent; verify against the
# OpenXR extension bindings shipped with your Godot build.

var volume_container: SpatialContainer
var panel_container: SpatialContainer

func _ready() -> void:
    var xr_interface: XRInterface = XRServer.find_interface("OpenXR")
    if xr_interface == null or not xr_interface.is_initialized():
        push_error("OpenXR interface unavailable on this device.")
        return

    # Volume container for the 3D board.
    volume_container = SpatialContainer.new()
    volume_container.container_type = SpatialContainer.TYPE_VOLUME
    volume_container.extent = Vector3(0.6, 0.4, 0.6)  # 60cm x 40cm x 60cm
    if volume_container.request_container() != OK:
        push_error("Volume container request failed.")
        return

    # Panel container for the HUD.
    panel_container = SpatialContainer.new()
    panel_container.container_type = SpatialContainer.TYPE_PANEL
    panel_container.extent = Vector3(0.4, 0.4, 0.02)
    panel_container.request_container()

    add_child(volume_container)
    add_child(panel_container)

    container_created.emit(volume_container.get_container_handle())

func _process(_delta: float) -> void:
    # Containers can be rejected or resized by the system.
    if volume_container and not volume_container.is_active():
        _handle_container_loss()

func _handle_container_loss() -> void:
    push_warning("Volume container lost - repositioning.")
    # Never assume the container survives; re-request on loss.
    volume_container.request_container()

السطر الحرج هو _handle_container_loss(). الحاويات التي يديرها النظام هي، بحكم تعريفها، مُدارة بواسطة النظام. قد يبتعد المستخدم، أو يعيد المساعد ترتيب المحتوى، أو يستعيد الجهاز المساحة. إذا لم يتحمل معالج الإدخال لديك فقدان الحاوية، فسيظل تطبيقك هناك بلوحة غير مرئية ولاعب يضغط الأزرار.

المأزق الذي يقع فيه الجميع تقريبًا: انجراف المرساة

إليك المشكلة المحددة، وهي التي ستكلفك معظم وقت التصحيح.

تضع لوحة ثلاثية الأبعاد في حاوية حجم. تضغط تشغيل. يبدو كل شيء صحيحًا. تخلع النظارة، وتعيد ارتداءها بعد دقيقتين، فتجد اللوحة الآن على بعد نصف متر إلى اليسار ومدوّرة بمقدار 20 درجة.

لماذا؟ لأنك ثبتّ محتواك على أصل العالم بدلاً من الحاوية. أصل العالم على جهاز مكاني ليس مكانًا مستقرًا — فهو معرّف بالنسبة إلى وضع بداية الجلسة. عندما يعيد النظام تثبيت الجلسة، يتحرك أصل العالم.

الحل هو إبقاء كل قطعة من مشهدك كطفل لتحويل الحاوية، وعدم قراءة أو كتابة الموضع العام للمحتوى المكاني أبدًا:

# WRONG: assumes world origin is stable
func place_piece(piece: Node3D, board_pos: Vector3) -> void:
    piece.global_position = board_pos

# RIGHT: position relative to the container transform
func place_piece(piece: Node3D, board_pos: Vector3) -> void:
    piece.position = board_pos   # local to container
    piece.rotation = Vector3.ZERO

قم بعمل grep عبر مشروعك عن .global_position و .global_transform قبل الإصدار. كل ظهور في محتوى مكاني هو خطأ انجراف محتمل. هذا النوع من الأخطاء يظهر أيضًا في العمل ثلاثي الأبعاد التقليدي والعمل في Multiplayer — فالأخطاء في التثبيت والملكية على تحويل مكرر تنتج نفس عرض "الكائن انتقل فجأة لبعض العملاء"، ولهذا فإن التعامل مع التحويلات كمحلية للحاوية بدلاً من مطلقة عادة تستحق أن تحملها إلى أي مشروع Godot شبكي.

التحقق من الحل

لتأكيد صحة التثبيت:

  1. شغّل مشهدك ولاحظ موضع اللوحة.
  2. انزع الجهاز، وانتظر 60 ثانية، ثم أعد الدخول إلى التطبيق.
  3. يجب أن تظهر اللوحة في نفس الموقع الفعلي بالنسبة إلى الغرفة، وليس بنفس الإزاحة من مكان وقوفك.
  4. كرر مع توجيه الجهاز بشكل مختلف — اجلس ثم قف.

إذا انجرفت، فإن شجرة المحتوى لديك لا تزال تحتوي على مراجع مطلقة. إذا قفزت لكنها ظلت ثابتة بعد القفزة، فهذا يعني أن الحاوية يتم إعادة تموضعها وأن المحتوى يتبعها بشكل صحيح — هذا سلوك متوقع، وليس خطأ.

التعامل مع هوية اللاعب والحالة المستمرة

تطبيقات الفضاءات على Android XR هي تطبيقات Android. تتوقف مؤقتًا، وتستأنف، وقد يكون لدى المستخدم هويات متعددة مسجلة الدخول على الجهاز، وبيانات الحفظ الخاصة بك تعيش في نفس نظام الحسابات مثل أي شيء آخر.

نمط الفشل خفي: يلعب اللاعب مكانيًا على النظارة، ثم يفتح نفس اللعبة على هاتفه. إذا كانت حالة الحفظ محلية على الجهاز، فسيصبح لديه الآن عالمان متباعدان ولا طريقة للتوفيق بينهما. إصلاح هذا ليس مشكلة رسم، بل مشكلة هوية حساب.

تنفيذ ذلك بشكل صحيح بنفسك يعني بناء تدفقات تسجيل الدخول، ومخزن حفظ على الخادم، والجزء الذي يقلل الجميع من شأنه — معالجة التعارضات عندما يكتب جهازان إلى نفس خانة الحفظ. نموذج القراءة/الكتابة المدرك للتنقيحات، حيث يقارن العميل الإصدارات ويحل التعارضات صراحةً، هو النموذج الوحيد الذي يصمد أمام الاستخدام الفعلي. بناء ذلك من الصفر مهمة تستغرق أسابيع؛ horizOn يوفّر حفظًا سحابيًا مرتبطًا بالحساب مع قراءة وكتابة مدركة للتنقيحات لهذه الحالة تحديدًا، بالإضافة إلى مصادقة عبر البريد الإلكتروني والحسابات المجهولة وGoogle وApple، بحيث تنتقل هوية اللاعب نفسها بين النظارة والهاتف.

أيًا كان الـ backend الذي تستخدمه، حدد سياسة التعارض قبل الإصدار. سياسة آخر كتابة تفوز تدمر التقدم بصمت. مطالبة اللاعب أفضل من فقدان البيانات.

أفضل الممارسات للإصدار على XREAL AURA

  1. صمّم للإضاءة المحيطة. اختبر كل لوحة واجهة في الخارج عند الظهيرة وفي غرفة خافتة الإضاءة. إذا أصبح النص غير مقروء في أي منهما، ارفع التباين وأضف مخططًا ساطعًا خفيفًا بدلاً من ظل داكن — الظلال لا تفعل شيئًا على شاشة شفافة.
  2. أبقِ الحاويات صغيرة وقابلة لإعادة الطلب. حجم 60 سم أسهل للنظام في تثبيته بشكل موثوق من حجم 2 متر. افترض أن كل حاوية يمكن فقدانها في أي وقت واكتب مسار الاسترداد أولاً، وليس أخيرًا.
  3. حدد ميزانية الرسم بشكل صارم. هذه نظارات، وليست وحدة معالجة رسومات مكتبية. استهدف زمن إطار أقل من 11 مللي ثانية (فئة 90 هرتز) مع إيقاف الصقل الزمني لصالح MSAA، الذي يكلف أقل في الدقة المكانية.
  4. ضع واجهة المستخدم في اللوحات، والمحتوى في الأحجام. لا تقاوم منطق النظام في تنسيب النصوص. خصص الأحجام للأشياء ذات العمق الحقيقي التي يفحصها اللاعب من زوايا متعددة.
  5. تحقق على الجهاز قبل كل مرحلة رئيسية. محرر النظارة يجعل هذا رخيصًا. نتائج المحاكي لن تكشف انجراف المرساة، أو فشل السطوع، أو سلوك فقدان الحاوية.

اتخاذ الخطوة التالية

المحرر على الجهاز هو العنوان الرئيسي الحقيقي هنا. يضغط حلقة التكرار المكاني من دقائق إلى ثوانٍ، وهذا هو الفرق بين ضبط تصميم والتخمين بشأنه.

ابدأ بتثبيت المحرر وتطبيق Gradle المصاحب على AURA، ثم أعد بناء مشروع صغير موجود كمشهد مكاني بدلاً من البدء من الصفر — ستظهر مشاكل التثبيت والسطوع فورًا، على محتوى تفهمه بالفعل. من هناك، أضف حاوية حجم ثلاثية الأبعاد ولوحة واجهة مستخدم واجعل كلاهما مستقرًا عبر دورة إيقاف/استئناف. بمجرد أن يثبت ذلك، تكون جاهزًا للتصميم من أجل المنصة بدلاً من ضدها.

إذا كانت حالة اللاعب المستمرة عبر الأجهزة على قائمتك، فإن horizOn يتعامل مع الحفظ السحابي المرتبط بالحساب مع حل التعارضات من جانب العميل بحيث تظل جلسة الفضاء الخاصة بك وجلسة الشاشة المسطحة متوافقتين.


المصدر: جاهز لـ XREAL AURA