أداء عرض الواقع الافتراضي
الضبط والتحسينات

مقدمة

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

• الفصل الثاني: تحديد الاختناق - يساعد هذا القسم المطورين في تحديد مكان الاختناقات.
• الفصلان 3 و4: إعدادات VIVE Wave وVIVE OpenXR - يوضح هذان القسمان الإعدادات المحددة التي قد تؤثر على أداء وحدة المعالجة المركزية/وحدة معالجة الرسومات لتطبيقات VIVE Wave وOpenXR. يمكن للمطورين تجربة تفعيل أو تعطيل هذه الميزات بناءً على مشاكل الأداء التي يواجهونها لتحديد ما إذا كان هناك أي تحسن.
• الفصل 5: التحسين المشترك - يشارك هذا القسم بعض ممارسات التحسين والتجارب الشائعة.

تحديد عنق الزجاجة

عند تحريك شاشة العرض (HMD)، إذا كان تطبيق الواقع الافتراضي/الواقع المعزز يعاني من اهتزاز في الإطارات أو حافة سوداء، وما إلى ذلك، فعادةً ما يكون السبب هو ضعف في أداء العرض. عادةً، يمكن تصنيف مشاكل أداء العرض إلى نوعين: مرتبطة بوحدة المعالجة المركزية (CPU) أو مرتبطة بوحدة معالجة الرسومات (GPU). من المهم جدًا في البداية فهم أنواع حدود تطبيقك لتجنب الضبط غير الفعال.
في هذا الفصل، نقدم لك خطوات بسيطة تمكنك من تحديد مكان مشكلات الأداء بسرعة.

2.1 التحقق من معدل عرض المحتوى (FPS)
أولاً، نبدأ بفحص معدل الإطارات في الثانية (FPS) للمحتوى، وهو عدد الإطارات التي يعرضها المحتوى في الثانية. يجب الحفاظ عليه عند معدل إطارات العرض، وإبقائه ثابتًا. وإلا، فقد يتسبب ذلك في تذبذب الإطارات.
إذا كانت مجموعة أدوات تطوير التطبيقات لديك تستخدم إصدار VIVE WAVE SDK 6.0.0 أو إصدارًا أحدث، فيمكنك استخدام أمر adb التالي للتحقق من معدل الإطارات في الثانية. DK 6.0.0
$adb Logcat -s VRMetric
ستشاهد بيانات السجل التالية.
VRMetric:FPS=89.8/89.8,CPU-27/1,GPU=72/3,GpuBd=0,LrCnt=1,2Stag=1,Pstat=2,AQ=1,FOVED=0/0, FSE=1,TWS-2,PT=0(0), RndrBK=0,GLTA=2D,EB=1720×1720
"FPS=89.8/89.8" يمثل الرقم الأول معدل الإطارات في الثانية للمحتوى، بينما يمثل الرقم الثاني معدل إطارات العرض.
إذا كان إصدار Wave SDK الخاص بك أقل من 6.0.0، فمن المستحسن الترقية إلى الإصدار الأحدث لتحسين أداء العرض وتحسين الميزات الأخرى.
إذا كانت حزمة تطوير البرامج (SDK) الخاصة بتطبيقك مبنية على VIVE OpenXR، يمكنك استخدام أمر adb التالي للتحقق من معدل الإطارات في الثانية (FPS).
$adb Logcat -s RENDER_ATW
سوف ترى بيانات السجل التالية
RENDER_ATW: [FPS] نسيج جديد: 90.00
RENDER_ATW: [FPS] R موجود: 90.00 تخطي: 0 317، -0.0155 0.805527، 0.006788)
RENDER_ATW: [FPS] L الحاضر:90.00 تخطي:0 (0.592301، -0.015502، 0.805539، 0.006773)

الرقم الذي يلي "نسيج جديد" يمثل معدل الإطارات في الثانية الحالي. الرقم الذي يلي "R موجود" و"L موجود" يمثل معدل إطارات العرض.
في بعض الأحيان، قد يكون هناك اختلاف طفيف بين معدل FPS للمحتوى ومعدل إطارات العرض.
على سبيل المثالampفي الحالة أعلاه، يمكن اعتبار 89.8 إطارًا في الثانية بمثابة 90 إطارًا في الثانية.
إذا كان معدل إطارات محتوى التطبيق أقل باستمرار من معدل إطارات العرض أو ظل غير مستقر، فهذا يشير إلى وجود مشكلة في أداء العرض. لذلك، تتمثل الخطوة التالية في تحديد ما إذا كان الاختناق ناتجًا عن وحدة المعالجة المركزية (CPU) أم وحدة معالجة الرسومات (GPU).
2.2 التحقق من استخدام وحدة المعالجة المركزية ووحدة معالجة الرسومات
إذا كانت مجموعة أدوات تطوير التطبيقات الخاصة بك تستخدم VIVE WAVE SDK 6.0.0 أو إصدارًا أحدث، فيمكنك استخدام أمر adb التالي للتحقق من معدل FPS.
$adb logcat -s VRMetric
ستشاهد بيانات السجل التالية.
VRMetric:FPS=89.8/89.8,CPU=27/1,GPU=72/3,GpuBd=0,LrCnt=1,2Stag=1,Pstat=2,AQ=1,FOVED=0 /0, FSE=1,TWS=2,PT=0(0),RndrBK=0,GLTA=2D,EB=1720×1720
كما ترى في نتيجة السجل أعلاه، فإن استخدام وحدة المعالجة المركزية هو 27% واستخدام وحدة معالجة الرسومات هو 72%. إذا كان إصدار Wave SDK الخاص بك أقل من 6.0.0، فمن المستحسن الترقية إلى أحدث إصدار لتحسين أداء العرض وتحسينات أخرى.
بالنسبة لتطبيق VIVE OpenXR، يمكنك استخدام الأمر التالي للتحقق من استخدام وحدة المعالجة المركزية ووحدة معالجة الرسومات.
# على لينكس/أوبونتو
$ adb logcat | grep CPU_USAGE
# على باورشيل
$ adb logcat | Select-String -Pattern CPU_USAGE
سوف ترى السجل التالي
متوسط ​​وحدة المعالجة المركزية CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 وحدة معالجة الرسومات CPU_USAGE [الحمل] 25.67% 32.22% 25.29% 30.77% 29.35% 21.35% 22.09% 18.39% 24.14% 73%
إذا لاحظتَ أن معدل الإطارات في الثانية لا يحافظ على معدل إطارات العرض، وأن استخدام وحدة معالجة الرسومات مرتفع جدًا، ويتجاوز عادةً 85%، يمكنك محاولة تعديل دقة Eyebuffer (القسم 3.1.2، القسم 4.1.2) لمعرفة ما إذا كان ذلك يُحسّن معدل الإطارات في الثانية. إذا أدى هذا التعديل إلى تحسين
بالنسبة للأداء، يمكننا أن نستنتج أن المشكلة مرتبطة بوحدة معالجة الرسومات ونركز جهود التحسين لدينا وفقًا لذلك.
من ناحية أخرى، إذا لم يؤدِ ضبط دقة Eyebuffer إلى تحسن ملحوظ في الأداء، فمن المحتمل أن يكون الاختناق مرتبطًا بوحدة المعالجة المركزية، ويجب أن نركز على تحسين أداء وحدة المعالجة المركزية.
من الممكن أيضًا أن يكون التطبيق مرتبطًا بوحدة المعالجة المركزية (CPU) ووحدة معالجة الرسومات (GPU) في آنٍ واحد. في هذه الحالات، ينبغي بذل جهود التحسين لكلٍّ من وحدة المعالجة المركزية ووحدة معالجة الرسومات (GPU) لتحقيق تحسينات متوازنة في الأداء.
2.3 مرتبط بوحدة معالجة الرسومات
عندما يكون تطبيق الواقع الافتراضي مقيدًا بوحدة معالجة الرسومات (GPU)، فهذا يعني أن وحدة معالجة الرسومات هي العائق الرئيسي، وأنها غير قادرة على مواكبة متطلبات العرض الخاصة بالتطبيق. لتخفيف مشاكل وحدة معالجة الرسومات، يُرجى مراعاة التوصيات التالية:
أولاً، استخدم أدوات إنشاء الملفات التعريفية مثل RenderDoc أو Game Engine profiler (يونيتي بروfileاستخدم Unreal Insights لتحليل أين تقضي وحدة معالجة الرسومات (GPU) معظم وقتها. حدد العمليات الأكثر تكلفةً وركّز على تحسينها.
بالنسبة لمطور Native Developer، يمكنك استخدام RenderDoc لتحديد استدعاء الرسم الذي يتسبب في تحميل وحدة معالجة الرسوميات بشكل زائد.
بالنسبة لمطور Unity، يمكنك متابعة Unity من خلال هذه الوثيقة أو استخدام RenderDoc لتحليل مشكلة أداء العرض، ومتابعة وثائق تحسين رسومات Unity للحصول على إرشادات لتحسين تطبيقك.
بالنسبة إلى Unreal Developer، يمكنك استخدام GPU Visualizer أو استخدام RenderDoc لتحليل مشكلة أداء العرض، واتباع إرشادات أداء Unreal للحصول على إرشادات لتحسين تطبيقك.
ثانيًا، يمكنك أيضًا محاولة ضبط ميزات Wave أو إعدادات معينة لتقليل تحميل وحدة معالجة الرسومات.

1. ضبط معدل تحديث العرض بشكل أبطأ (القسم 3.1.1، القسم 4.1.1)
2.  ضبط دقة Eyebuffer (القسم 3.1.2، القسم 4.1.2)، 14.1.1)
3.  حاول تمكين التركيز البؤري (القسم 3.1.4، القسم 4.1.4).

إذا كان تطبيقك أيضًا تطبيق MR، فيمكنك ضبط إعدادات Passthrough أيضًا.

1. اضبط جودة الصورة العابرة على مستوى أقل. (القسم 3.2.1)
2. ضبط معدل الإطارات العابر بشكل أبطأ. (القسم 3.2.2).

لمزيد من الإعدادات الأخرى حول أداء وحدة معالجة الرسوميات، يمكنك الرجوع إلى الفصل 2.6.

2.4 مرتبط بوحدة المعالجة المركزية
عندما يكون تطبيق الواقع الافتراضي مقيدًا بوحدة المعالجة المركزية، فهذا يعني أن وحدة المعالجة المركزية هي العائق الأساسي، لذا ضع في اعتبارك التوصيات التالية:
أولاً، استخدم أدوات إنشاء الملفات التعريفية مثل Systrace أو Game Engine profiler (يونيتي بروfileاستخدم r وUnreal Insights لتحليل وتحديد أجزاء الكود التي تستهلك معظم موارد وحدة المعالجة المركزية. ركّز على تحسين هذه الأجزاء وأعد تصميم خوارزميات حاسوبية مكثفة لتقليل حمل وحدة المعالجة المركزية.

• بالنسبة للمطور الأصلي، يمكنك استخدام Systrace للاحترافfileر مشروعك.
• بالنسبة لمطور Unity، يمكنك استخدام CPU Usage Profileوحدة r للعثور على مشكلة أداء وحدة المعالجة المركزية.
• بالنسبة لمطور Unreal، يمكنك استخدام Insights من Unreal للعثور على مشكلة أداء وحدة المعالجة المركزية.

ثانيًا، يمكنك أيضًا محاولة ضبط ميزات Wave أو إعدادات معينة لتقليل تحميل وحدة معالجة الرسومات.

1. ضبط معدل تحديث العرض بشكل أبطأ (القسم 3.1.1، القسم 4.1.1)
2.  استخدم متعددView التقديم (القسم 3.1.4، القسم 4.1.4)

إذا كان تطبيقك أيضًا تطبيق MR، فيمكنك ضبط إعدادات Passthrough أيضًا.

1. ضبط معدل الإطارات العابر بشكل أبطأ (القسم 3.2.2).

لمزيد من الإعدادات الأخرى حول أداء وحدة المعالجة المركزية، يمكنك الرجوع إلى الفصل 2.6.

2.5 الملخص
أخيرًا، قمنا بتنظيم سير عمل فحص الأداء أعلاه في الشكل 2-5-1. ابدأ بفحص معدل الإطارات في الثانية للمحتوى. إذا كان أقل من معدل إطارات العرض أو ظل غير مستقر، فقم بتحليل استخدام وحدة معالجة الرسومات/وحدة المعالجة المركزية لتحديد ما إذا كان مرتبطًا بوحدة معالجة الرسومات أم بوحدة المعالجة المركزية. وأخيرًا، استخدم برنامجًا احترافيًا.fileلتحديد مشكلات الأداء المحتملة أو ضبط ميزات Wave أو الإعدادات لتحسين أداء وحدة المعالجة المركزية.

2.6 مرجع سريع للإعدادات التي يمكنها تحسين تحميل وحدة المعالجة المركزية/وحدة معالجة الرسومات

اذكر إعدادات SDK المتعلقة بتحميل وحدة المعالجة المركزية/وحدة معالجة الرسومات كما هو موضح أدناه. يمكنك التحقق من إعدادات التحسين المناسبة بناءً على مشكلة التطبيق.

متعلق بوحدة المعالجة المركزية:

• إعدادات VIVE Wave SDK
  o محتوى الواقع الافتراضي
  ▪ 3.1.1 معدل تحديث الشاشة
  ▪ 3.1.4 متعددView تقديم
  ▪ 3.1.6 الجودة التكيفية
  ▪ 3.1.7 مُركِّب الحركة التكيفية
  o محتوى MR
  ▪ 3.2.2 ضبط معدل الإطارات العابرة
• إعدادات VIVE OpenXR SDK
  o محتوى الواقع الافتراضي
  ▪ 4.1.1 معدل تحديث الشاشة
  ▪ 4.1.4 متعددView تقديم
• التحسين المشترك
  o ارتفاع وحدة المعالجة المركزية 5.5

متعلق بوحدة معالجة الرسوميات:

• إعدادات VIVE Wave SDK
  o محتوى الواقع الافتراضي
  ▪ 3.1.1 معدل تحديث الشاشة
  ▪ 3.1.2 دقة العين المؤقتة
  ▪ 3.1.3 متعددView تقديم
  ▪ 3.1.4 التركيز البؤري
  ▪ 3.1.5 تحسين حدة الإطار (FSE)
  ▪ 3.1.6 الجودة التكيفية
  ▪ 3.1.7 مُركِّب الحركة التكيفية
  ▪ 3.1.8 قناع العرض [لا يدعم Unreal] o محتوى الواقع المعزز
  ▪ 3.2.1 ضبط جودة المرور
  ▪ 3.2.2 ضبط معدل الإطارات العابرة
• إعدادات VIVE OpenXR SDK
  o محتوى الواقع الافتراضي
  ▪ 4.1.1 معدل تحديث الشاشة
  ▪ 4.1.2 دقة العين المؤقتة
  ▪ 4.1.3 متعددView تقديم
  ▪ 4.1.4 التركيز البؤري [لا يدعم Unreal] ▪ 4.1.5 قناع العرض [لا يدعم Unreal]
• التحسين المشترك
  o 5.1 إيقاف تشغيل وضع الأداء العالي
  o 5.2 متعددampلينغ
  o 5.3 تحميل/تخزين GMEM
  o 5.4 طبقة التركيب (متعددة الطبقات)

إعداد موجة VIVE

VIVE Wave منصة مفتوحة ومجموعة أدوات تُمكّنك من تطوير محتوى الواقع الافتراضي بسهولة، وتُحسّن أداء الأجهزة للشركاء الخارجيين. تدعم VIVE Wave محركات الألعاب Unity وUnreal.
نقوم باستمرار بتحسين وإصلاح الأخطاء المختلفة، لذا نوصي بالحفاظ على تحديث مجموعة أدوات التطوير البرمجية (SDK).
حاليًا، يدعم VIVE Wave OpenGL ES فقط. فيما يلي قائمة بالميزات مرتبة حسب تأثيرها على أداء وحدة معالجة الرسومات. سنقسمها إلى قسمين: محتوى الواقع الافتراضي (VR) ومحتوى الواقع المختلط (MR).
3.1 محتوى الواقع الافتراضي
3.1.1 معدل تحديث الشاشة

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

• بالنسبة للمطور الأصلي، راجع WVR_SetFrameRate.
• بالنسبة لمطوري Unity، راجع هذا الدليل.
• بالنسبة لمطوري Unreal، راجع هذا الدليل.

3.1.2 دقة Eyebuffer
دقة Eyebuffer هي حجم الملمس الذي سيتم عرض محتوى التطبيق عليه، وسيتم إرسال الملمس المعروض إلى وقت التشغيل لإجراء عملية النشر وعرضه على شاشة HMD.
مع أن زيادة حجم حاجز العين قد يُنتج صورًا أوضح وأكثر تفصيلًا، إلا أنه يُثقل كاهل وحدة معالجة الرسومات (GPU) بشكل كبير. لذلك، يُعدّ تحقيق التوازن الأمثل بين جودة الصورة والأداء أمرًا بالغ الأهمية.
إذا كان التطبيق يعاني من مشكلة في وحدة معالجة الرسومات (GPU)، يمكنك محاولة تقليل حجم المخزن المؤقت للعين بضرب معامل القياس. مع ذلك، نوصي بعدم تقليل معامل القياس إلى أقل من 0.7، فقد يؤدي ذلك إلى جودة صورة غير مقبولة.

• للمطورين الأصليين، راجع WVR_ObtainTextureQueue. عند تعديل الحجم، يجب ضرب العرض بالارتفاع بنسبة معينة.
• بالنسبة لمطور Unity، راجع WaveXRSettings.
  وبدلاً من ذلك، يمكنك إجراء التغييرات عبر الكود مثل belwoe.
  XRSettings.eyeTextureResolutionScale = ResolutionScaleValue؛ // C#
• بالنسبة لمطوري Unreal، راجع SetPixelDensity.

3.1.3 متعددView تقديم
في الرسم التقليدي، نرسم العينين اليمنى واليسرى بشكل منفصل، مما يتطلب رسمين لنفس المشهد.View يعالج العرض هذه المشكلة عن طريق تنفيذ مكالمة رسم واحدة فقط.
تُخفِّف هذه الميزة حمل وحدة المعالجة المركزية (CPU) بتقليل عدد عمليات السحب. كما تُوفِّر وحدة معالجة الرسومات بعض المزايا، إذ يُخفَّض عبء عمل مُظلِّل الرؤوس أيضًا، إذ لا يحتاج إلى تشغيل مُظلِّل إضافي للعين الأخرى، بينما يبقى عبء عمل مُظلِّل الأجزاء دون تغيير، إذ لا يزال بحاجة إلى تقييم كل بكسل لكلتا العينين. نوصي بتفعيل هذه الميزة.

• بالنسبة للمطور الأصلي، يمكنك الرجوع إلى wvr_native_hellovr sampليه.
• بالنسبة لمطور Unity، راجع وضع العرض، والمرور الفردي متعددview ميزة.
• بالنسبة لمطوري Unreal، راجع هذا الدليل.

3.1.4 التركيز البؤري
صُمم العرض المُركز أساسًا لتقليل حمل وحدة معالجة الرسومات. فهو يُقلل تفاصيل الإطار في محيط الشاشة، ويحافظ على دقة عالية في منتصف مجال الرؤية. viewإذا كان التطبيق يعاني من مشكلة مرتبطة بوحدة معالجة الرسومات، فيمكنك محاولة تمكين عرض Foveation.

هناك شيء يجب ملاحظته أثناء استخدام التركيز البؤري:

➢ عادةً لا يلاحظ المستخدمون انخفاض التفاصيل في المناطق الطرفية عند تطبيق وضع التركيز البؤري الافتراضي. ولكن إذا تم ضبط جودة التركيز البؤري الطرفية على مستوى منخفض جدًا، فقد يصبح ذلك ملحوظًا للمستخدم.
قد تكون تأثيرات التركيز البؤري أكثر وضوحًا مع بعض مواد القوام، مما قد يلفت انتباه المستخدم. ينبغي على المطورين إدراك ذلك وتقييمه بناءً عليه.
➢ يتطلب تفعيل ميزة العرض البؤري تكلفة ثابتة لأداء وحدة معالجة الرسومات، والتي تتراوح بين 1% و6% حسب حجم ذاكرة العين. عند استخدام مُظلل بسيط في المشهد، قد يكون تحسين الأداء الناتج عن توفير الموارد أقل من تكلفة أداء وحدة معالجة الرسومات الثابتة، مما يؤدي إلى انخفاض في الأداء.

• بالنسبة للمطورين الأصليين، راجع هذا الدليل.
• لمطوري Unity، يُرجى مراجعة هذا الدليل. تجدر الإشارة إلى أنه عند تفعيل المعالجة اللاحقة أو HDR، لا يمكن الاستفادة الكاملة من التركيز البؤري. لأن Unity سيعرض الكائنات على نسيج العرض المُولّد من قِبله، بدلاً من نسيج العرض المُولّد في وقت التشغيل والذي يدعم التركيز البؤري.
• لمطوري Unreal، يُرجى مراجعة هذا الدليل. تجدر الإشارة إلى أنه لا يمكن الاستفادة الكاملة من التركيز البؤري على Multi-View العرض، لأن Unreal لا يمكنه عرض الكائنات بشكل مباشر على نسيج العرض الذي تم إنشاؤه أثناء وقت التشغيل والذي يدعم التركيز.

3.1.5 تحسين حدة الإطار (FSE)
يوفر FSE نتائج عرض أكثر وضوحًا من خلال استخدام مرشح الوضوح، مما يجعل المحتوى أكثر وضوحًا ويساعد في تحسين وضوح النص في المشهد. إذا كان التطبيق يعاني من مشكلة في وحدة معالجة الرسومات (GPU)، فيمكنك تعطيل FSE إذا لم يكن ضروريًا.

• بالنسبة للمطورين الأصليين، راجع هذا الدليل.
• بالنسبة لمطوري Unity، راجع هذا الدليل.
• بالنسبة لمطوري Unreal، راجع هذا الدليل.

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

• بالنسبة للمطورين الأصليين، راجع هذا الدليل.
• لمطوري Unity، يُرجى مراجعة هذا الدليل. في ملحق Unity الخاص بنا، يُمكن تعديل حجم مُؤقت العين تلقائيًا بناءً على الأداء الحالي؛ سيقوم حجم النص بتصفية قيم المقياس الصغيرة جدًا في قائمة الدقة. نوصي باستخدام نص بحجم 20 ديسيبل مم على الأقل أو أكبر.
• بالنسبة لمطوري Unreal، راجع هذا الدليل.

3.1.7 مُركِّب الحركة التكيفية
هذه الميزة تجريبية تتضمن UMC وPMC. ستعمل UMC على خفض معدل الإطارات إلى النصف، واستخراج إطار جديد في الوقت الفعلي للحفاظ على سلاسة الصورة. إلا أنها قد تتضمن بعض التأخير، وبعض التشويش، وتحميل وحدة معالجة الرسومات.
يستخدم PMC بشكل أساسي مُخزّن العمق للسماح لـ ATW بمراعاة ترجمة HMD، وتوسيع نطاق التعويض إلى 6 درجات حرية. تُقلّل هذه الميزة زمن انتقال الترجمة بمقدار إطار إلى إطارين، ولكنها تزيد من تحميل وحدة معالجة الرسومات.

• بالنسبة للمطورين الأصليين، راجع هذا الدليل.
• بالنسبة لمطوري Unity، راجع هذا الدليل.
• بالنسبة لمطوري Unreal، راجع هذا الدليل.

3.1.8 قناع العرض [لا يدعم Unreal]
تصبح البكسلات عند الحواف شبه غير مرئية بعد التشويه، ويُعدِّل قناع العرض قيم مخزن العمق لهذه البكسلات غير المرئية. إذا فعَّلتَ اختبار العمق، بسبب تقنية Early-Z، فلن تُعرَض هذه البكسلات غير المرئية، مما يُخفِّف حمل وحدة معالجة الرسومات. تُفيد هذه الميزة في حال وجود كائنات عرض ذات تحميل كثيف في هذه المناطق غير المرئية؛ أما في حال عدم وجود كائنات عرض في هذه المناطق، فيُنصح بتعطيلها لأنها ستستهلك قدرًا ضئيلًا من طاقة وحدة معالجة الرسومات.

• للمطورين الأصليين، راجع هذا الدليل. يجب ربط مخزن العمق قبل استدعاء RenderMask؛ وإلا، فسيكون غير فعال.
• بالنسبة لمطوري Unity، راجع هذا الدليل.
• بالنسبة لمطوري Unreal، لا يدعم حاليًا ميزة Render Mask.

3.2 محتوى الواقع المعزز
3.2.1 ضبط جودة المرور
هناك 3 مستويات لجودة الصورة المارة:
➢ WVR_PassthroughImageQuality_DefaultMode – مناسب لمحتوى الواقع المعزز دون الحاجة إلى طلب محدد.
➢ WVR_PassthroughImageQuality_PerformanceMode – مناسب لمحتوى الواقع المعزز الذي يحتاج إلى المزيد من موارد وحدة معالجة الرسوميات لعرض المشهد الافتراضي.
➢ WVR_PassthroughImageQuality_QualityMode – مناسب لمحتوى الواقع المعزز الذي يسمح للمستخدمين برؤية البيئة المحيطة بوضوح، ولكن المشهد الافتراضي للمحتوى يجب أن يتمتع بضبط أكثر دقة للأداء.
يمكنك ضبط جودة Passthrough على PerformanceMode لتقليل استخدام وحدة معالجة الرسومات.

• بالنسبة للمطورين الأصليين أو Uunity أو Unreal، راجع هذا الدليل.

3.2.2 ضبط معدل الإطارات العابرة
كما هو الحال مع معدل تحديث الشاشة، يوفر معدل الإطارات الأعلى في Passthrough صورًا أكثر سلاسة، ولكنه يأتي على حساب زيادة تحميل النظام. على العكس، تُخفِّف معدلات التحديث المنخفضة حمل النظام، ولكنها تُؤدي إلى صور أقل سلاسة. يوجد وضعان لمعدل الإطارات في Passthrough: Boost وNormal.

• بالنسبة للمطور الأصلي، يمكنه ضبط جودة المرور باستخدام WVR_SetPassthroughImageRate.
• بالنسبة لمطور Unity، يمكن التغيير عبر الكود، على سبيل المثالampالإعدادات هي كما يلي // C#
  Interop.WVR_SetPassthroughImageQuality(WVR_PassthroughImageQuality.PerformanceMode);
• بالنسبة لمطور Unreal، راجع طريقة الإعداد لعقدة المخطط في الشكل 3-2-2.

إعدادات VIVE OpenXR

OpenXR هو معيار مفتوح المصدر، يُوفر مجموعة مشتركة من واجهات برمجة التطبيقات (APIs) لتطوير تطبيقات الواقع الافتراضي (VR) التي تعمل على مجموعة واسعة من أجهزة الواقع الافتراضي، من تطوير مجموعة Khronos Group. يدعم كلٌ من VIVE Focus 3 وVIVE XR Elite أيضًا OpenXR. توفر حزمة تطوير برامج VIVE OpenXR دعمًا شاملاً لأجهزة HTC VR، مما يسمح للمطورين ببناء محتوى متكامل باستخدام محركي Unity وUnreal على أجهزة HTC VR. نعمل باستمرار على تحسين وإصلاح العديد من الأخطاء، لذا يُنصح المطورون بتحديث إصدار FOTA الخاص بأجهزتهم لضمان تحديثها باستمرار. حاليًا، تدعم حزمة تطوير برامج VIVE OpenXR OpenGL ES وVulkan.

4.1 محتوى الواقع الافتراضي
4.1.1 معدل تحديث الشاشة
المفهوم هنا مشابه لمعدل تحديث الشاشة 3.1.1.

• بالنسبة للمطورين الأصليين، راجع XrEventDataDisplayRefreshRateChangedFB.
• بالنسبة لمطوري Unity، راجع هذا الدليل.
• بالنسبة لمطوري Unreal، راجع هذا الدليل.

4.1.2 دقة Eyebuffer
المفهوم هنا مشابه لـ 3.1.2 Eyebuffer Resolution. نوصي بعدم تقليل عامل المقياس إلى أقل من 0.7، حيث قد يؤدي هذا إلى جودة بصرية غير مقبولة.

• للمطورين الأصليين، راجع xrCreateSwapchain. عند تعديل الحجم، يجب ضرب العرض بالارتفاع بنسبة معينة.
• بالنسبة لمطور Unity، راجع المثال التاليample // C#
  XRSettings.eyeTextureResolutionScale = 0.7f؛ //الموصى به 1.0f~0.7f
• بالنسبة لإعدادات Unreal، راجع هذا الدليل.

4.1.3 متعددView تقديم
المفهوم هنا مشابه لـ 3.1.3 متعددView التقديم. تُخفِّف هذه الميزة العبء على وحدة المعالجة المركزية (CPU)، كما أن لوحدة معالجة الرسومات (GPU) بعض المزايا. نوصي بتفعيل هذه الميزة.

• بالنسبة للمطورين الأصليين، توفر KhronosGroup نظام OpenXR متعدد الاستخداماتView exampيرجى الرجوع إلى هذا الدليل.
• بالنسبة لمطور Unity، راجع وضع العرض، والمرور الفردي متعددview ميزة.
• بالنسبة لمطوري Unreal، كما هو الحال مع إعدادات VIVE Wave، راجع هذا الدليل.

4.1.4 التركيز البؤري [لا يدعم Unreal]
المفهوم هنا مشابه لـ 3.1.4 التركيز البؤري. صُمم العرض التركيزي أساسًا لتقليل حمل وحدة معالجة الرسومات، ولكن تفعيله سيؤدي إلى تكلفة ثابتة لأداء وحدة معالجة الرسومات، وإذا تم ضبط التركيز البؤري على مستوى منخفض جدًا وتم استخدام مواد أو قوام معين، فقد يصبح...
ملحوظة للمستخدم. لذلك، يُنصح بتفعيل الميزة أو تعطيلها بناءً على متطلباتك الخاصة واعتبارات الأداء. حاليًا، لا تُدعم وظيفة Foveated إلا في OpenGL ES على VIVE OpenXR SDK.

• بالنسبة للمطور الأصلي، هذه الميزة متاحة، ولكن لا توجد حاليًاampيتم توفير ليه.
• بالنسبة لمطوري Unity، راجع هذا الدليل.
• بالنسبة لمطوري Unreal، لا يدعمون هذه الميزة في الوقت الحالي.

4.1.5 قناع العرض [لا يدعم Unreal]
المفهوم هنا مشابه لـ 3.1.8 Render Mask.

• للمطورين الأصليين، استخدم XrVisibilityMaskKHR للحصول على الشبكة. قبل عرض المشهد، استخدم هذه الشبكة لملء قيم مخزن العمق قبل عرضه.
• بالنسبة لمطور Unity، يتم تمكين ميزة Render Mask بشكل افتراضي لـ OpenGL ES، ويمكن تعطيلها باستخدام الكود التالي؛ لا يدعم Vulkan هذه الميزة حاليًا. //C# UnityEngine.XR.XRSettings.occlusionMaskScale = 0.0f؛
• بالنسبة لمطوري Unreal، لا يدعم حاليًا ميزة Render Mask.

4.2 محتوى الواقع المعزز
لا يدعم OpenXR حاليًا ضبط جودة التمرير ومعدل الإطارات. سنواصل تحسين ميزة التمرير وإصلاحها، لذا نوصي المطورين بتحديث إصدار FOTA الخاص بالجهاز لإبقائه محدثًا.

التحسين المشترك

5.1 إيقاف تشغيل وضع الأداء العالي
قد يؤدي إيقاف "وضع الأداء العالي" إلى تقليل حجم شاشة الجهاز، وبالتالي تقليل استخدام وحدة معالجة الرسومات. لكن عيبه هو انخفاض دقة الشاشة. يمكنك الموازنة بين الجودة والأداء لتحديد ما إذا كنت ترغب في تفعيله.
يظهر موقع الإعداد لجهاز VIVE Focus 3 في الشكل 5-1-1:

يظهر موقع الإعداد لجهاز VIVE XR Elite في الشكل 5-1-2:

5.2 مالتيسampلينغ مكافحة التعرج
مالتيسampling هي تقنية تنعيم تُستخدم لتنعيم الحواف الخشنة، وعادةً ما يتم تسريعها باستخدام الأجهزة، مما يُثقل كاهل أداء وحدة معالجة الرسومات. نوصي بعدم ضبط MSAA على قيمة أعلى من 2x، لأن ارتفاع القيمة سيؤدي إلى استهلاك طاقة أكبر لوحدة معالجة الرسومات.

• للمطورين الأصليين، MSAA OpenGL ES exsampيمكن الرجوع إلى هذا؛ MSAA فولكان السابقينampيمكن للقارئ أن يشير إلى هذا.
  توفر وحدة معالجة الرسوميات Adreno امتدادًا يعمل على تحسين MSAA.
• لمطوري Unity، راجع هذه النقابة.
• لمطوري Unreal، يُرجى مراجعة هذه المجموعة. يُوفر Unreal أيضًا خاصية التنعيم بعد المعالجة، يُرجى مراجعة هذه المجموعة.

5.3 تحميل/تخزين GMEM
في بنية وحدة معالجة الرسومات Adreno، توجد ميزة تتيح، عند ربط هدف عرض، إذا لم يتم مسحه أو إبطاله، ففي كل مرة يتم فيها العرض، تُحمّل قيم هدف العرض إلى ذاكرة الرسومات، وهو ما يُسمى تحميل GMEM. إذا لم تكن القيم السابقة ضرورية، يُمكنك مسح أو إبطال هدف العرض قبل العرض، لتجنب هذا الموقف وتحسين أداء وحدة معالجة الرسومات.
يمكنك تجنب تحميل GMEM باستخدام الطرق التالية. في OpenGL ES، بعد ربط FBO، يمكنك استدعاء glClear وglClearDepth لمسح مخزن اللون والعمق والاستنسل، أو استدعاء glInvalidateFramebuffer لإبطال هدف العرض المحدد. في Vulkan، لا حاجة لتعليمات إضافية؛ يمكنك تحديد ما إذا كنت تريد مسح المرفق قبل الاستخدام في VkAttachmentDescription.loadOp.
وبالمثل، يُطلق على تخزين نتيجة عرض البلاط في الذاكرة الرئيسية من ذاكرة الرسومات اسم "مخزن GMEM"، وهذه العملية مكلفة أيضًا لوحدة معالجة الرسومات. لتجنب ذلك، نوصي بربط أهداف العرض المطلوبة فقط لتجنب عمليات التخزين غير الضرورية.

5.4 طبقة التركيب (متعددة الطبقات)
تتميز القوام المعروضة باستخدام الطبقات المتعددة بجودة بصرية أفضل. ومع ذلك، تُحسّن هذه الميزة أداء وحدة معالجة الرسومات بشكل ملحوظ مع زيادة عدد الطبقات وحجم القوام. نوصي بعدم تجاوز ثلاث طبقات.

• للمطور الأصلي،
  تستخدم VIVE Wave SDK WVR_SubmitFrameLayers لتمرير البيانات لكل طبقة.
  o يضع VIVE OpenXR SDK بيانات الطبقة في XrFrameEndInfo ويرسلها عبر xrEndFrame.
• لمطور Unity،
  o إعدادات VIVE Wave SDK، راجع هذا الدليل،
  لإعدادات VIVE OpenXR، راجع هذا الدليل.
• للمطورين Unreal،
  لإعدادات VIVE Wave SDK، راجع هذا الدليل.
  لإعدادات VIVE OpenXR، راجع هذا الدليل.

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

• لمطوري Unity، راجع ميزة تكوين سلاسل عمليات أندرويد. إذا كنت تستخدم VIVE Wave SDK، فلدينا ميزة في WaveXRSettings تتيح لك ضبط الأولوية، كما هو موضح في الشكل 5-5-2. تشير القيمة الأصغر إلى أولوية أعلى.

• لا توجد طريقة غير واقعية لتغيير خيط اللعبة وخيط العرض وأولوية خيط RHI من خلال الإعدادات الخارجية إلا إذا قمت بتعديل كود المحرك.

جميع الحقوق محفوظة لشركة HTC © ٢٠٢٤

المستندات / الموارد

أداء عرض الواقع الافتراضي VIVE [بي دي اف] دليل المستخدم أداء عرض الواقع الافتراضي، أداء العرض، الأداء

مراجع

• دليل المستخدم