S3D और WibbleWobble

जिज्ञासु गेमर के लिए
तकनीक का एक लोकप्रिय-स्तरीय विवरण, यह कैसे बनाई गई है और कैसे काम करती है। यदि आप रुचि नहीं रखते हैं, तो इसे पढ़ने की कोई आवश्यकता नहीं है - यह शुष्क सामग्री है।

एक गेम 3D कैसे बनाता है
किसी गेम में 3D छवि बनाने का सामान्य तरीका है दृश्य को दो बार रेंडर करना - बाएँ और दाएँ आँख के लिए अलग-अलग, दृश्य के केंद्र के सापेक्ष कैमरे को आभासी रूप से खिसकाकर। यह संसाधन-गहन है और इसके लिए गेम इंजन से अंतर्निहित समर्थन आवश्यक है। हर गेम यह नहीं कर सकता। WibbleWobble दो अलग-अलग रास्ते प्रदान करता है, और उनके बीच का अंतर मौलिक है - यह छवि गुणवत्ता और छवि कलाकृतियों के सेट दोनों को निर्धारित करता है।

पहला रास्ता: ReShade Client - सपाट फ्रेम से स्टीरियो संश्लेषण
गेम एक सामान्य दृश्य रेंडर करता है। SuperDepth3D ReShade प्रभाव उस फ्रेम को दृश्य के गहराई बफर के साथ लेता है और गहराई के अनुसार पिक्सेल को खिसकाकर उससे दूसरा दृष्टिकोण पुनर्निर्मित करता है। गेम इंजन स्टीरियो के बारे में कुछ नहीं जानता। यह प्रदर्शन के मामले में सस्ता है और लगभग किसी भी DX11/DX12 गेम के साथ काम करता है। इसका नुकसान इस विधि में निहित कलाकृतियाँ हैं। उनका वर्णन नीचे "नुकसान" अनुभागों में किया गया है।

दूसरा रास्ता: OpenVR Client - वास्तविक 3D रेंडरिंग
WibbleWobble स्वयं को SteamVR में एक आभासी VR हेडसेट के रूप में पंजीकृत करता है। VR-सक्षम गेम, या VR मॉड वाला गेम, दृश्य को दो कैमरों से दो बार रेंडर करता है जो इंटरप्यूपिलरी दूरी से अलग होते हैं, ठीक वैसे ही जैसे असली हेडसेट करता है। IPD, प्रति-आँख रिज़ॉल्यूशन, और फोकल लंबाई VR Config में सेट की जाती हैं। यहाँ WibbleWobble कुछ भी संश्लेषित नहीं करता: यह तैयार स्टीरियो जोड़ी लेता है और उसे स्क्रीन पर फ्रेम-अनुक्रमिक रूप से आउटपुट करता है, शटर चश्मे को सिंक्रनाइज़ करते हुए। यह प्रदर्शन में अधिक खर्च करता है, लेकिन 3D ज्यामिति बिल्कुल सही है। समोच्चों के साथ कोई छेद नहीं, कोई "कार्डबोर्ड" प्रभाव नहीं; प्रत्येक आँख को अपने स्वयं के प्रतिबिंब और हाइलाइट्स मिलते हैं। संक्षेप में, यह एक साधारण मॉनिटर पर 3D चश्मे के साथ VR गेम खेलने का एक तरीका है, लेकिन हेडसेट के बिना।

Reprojection - दृष्टि क्षेत्र विस्तार तंत्र
Reprojection दोनों मोड में काम करता है, मोनोकुलर सहित। एक उच्च-प्रदर्शन शेडर गेम फ्रेम को लेता है और उसे आपके कार्यक्षेत्र की ज्यामिति पर मैप करता है: एक मॉनिटर पर, या चार मॉनिटरों पर, या एक घुमावदार स्क्रीन पर। हेड-ट्रैकिंग (OpenTrack) के माध्यम से छवि आपके सिर का अनुसरण करने के लिए खिसकती है, और मॉनिटर एक आभासी दुनिया में खिड़की की तरह काम करने लगते हैं - "VR फिशटैंक" प्रभाव। Reprojection का उद्देश्य सही विश्व पैमाना और सही दृष्टि क्षेत्र (FOV) प्राप्त करना है मल्टी-मॉनिटर उपयोग के लिए। Reprojection को पूरी तरह बंद किया जा सकता है (Client Config -> Reprojection: Disabled) और आप केवल स्टीरियो आउटपुट, BFI, और अपस्केलर का उपयोग कर सकते हैं - एकल डिस्प्ले के लिए सामान्य परिदृश्य।
* यह कहना होगा कि परियोजना के लेखक कई पैनलों में "दुनिया का विस्तार" करने के विचार को लेकर अत्यधिक आशावादी थे। इसके लिए शक्तिशाली ग्राफिक्स कार्ड भी पर्याप्त प्रदर्शन नहीं रखते। आप भाग्यशाली होंगे यदि गति एकल 4K डिस्प्ले के लिए पर्याप्त हो। यह कई डिस्प्ले के साथ काम नहीं करेगा...

FOV (Field of View): दृष्टि कोण। यह निर्धारित करता है कि आभासी कैमरा फ्रेम में दुनिया के किस क्षेत्र को कैप्चर करता है। इसे डिग्री में मापा जाता है, ऊर्ध्वाधर और क्षैतिज के लिए अलग-अलग। छोटा FOV (40-50°) टेलीफोटो लेंस जैसा दिखता है: बड़ी वस्तुओं के साथ एक संकीर्ण क्षेत्र। बड़ा FOV (100-120°) वाइड-एंगल है, एक्शन कैमरे की तरह। आप किनारों पर बहुत कुछ देखते हैं, लेकिन किनारे खिंचे हुए हैं और वस्तुएँ दूर और छोटी दिखाई देती हैं। यह WibbleWobble में एक प्रमुख पैरामीटर है। प्रोग्राम को पता होना चाहिए कि गेम ने फ्रेम किस कोण पर बनाया है ताकि इसे आपके भौतिक मॉनिटर पर सही ढंग से प्रोजेक्ट किया जा सके। इसीलिए Game Config में दो फ़ील्ड हैं, FOV Vertical और FOV Horizontal, एक आवश्यकता के साथ: मान गेम में सेट किए गए मान से मेल खाना चाहिए। एक मान बदलें और दूसरा विंडो के पहलू अनुपात से मेल खाने के लिए स्वचालित रूप से पुनर्गणना हो जाता है।

यदि FOV है:
बहुत बड़ा दुनिया खिलौने जैसी लगती है और वस्तुओं का पैमाना विकृत हो जाता है
बहुत कम दुनिया विशाल लगती है और सब कुछ आप पर मंडराता है
3D में गहराई पैमाने के साथ टूट जाती है, और आँखों पर तनाव शुरू हो जाता है

"दुनिया में एक खिड़की" के रूप में हेड-ट्रैकिंग
OpenTrack विधि का उपयोग करते हुए, एप्लिकेशन हैंडलर सिर की स्थिति को ट्रैक करता है और प्रोजेक्शन को इस तरह स्थानांतरित करता है कि मॉनिटर 3D दृश्य में एक आभासी खिड़की प्रस्तुत करता है। यह एक पैरालैक्स प्रभाव बनाता है। जब आप अपना सिर हिलाते हैं, तो छवि थोड़ी सी खिसक जाती है, जैसे कि आप वास्तव में एक खिड़की से देख रहे हों।

फ्रेम-अनुक्रमिक स्टीरियो आउटपुट
एप्लिकेशन गेम से फ्रेम प्राप्त करता है, जैसे ही वे तैयार होते हैं, परिवर्तनीय दर पर, "जैसे भी वे आते हैं।" क्लाइंट तब 60 Hz पर प्लेबैक के लिए फ्रेम दर समायोजित करता है। स्टीरियो जोड़ी का स्रोत SuperDepth3D, एक VR मॉड, या तैयार 3D सामग्री हो सकता है। WibbleWobble इसे साइड-बाय-साइड या चेकरबोर्ड प्रारूप में स्वीकार करता है (Client Config -> Source Format) और इसे FrameBufferDecode में डिकोड करता है। रेंडरर तब इसे 120 Hz फ्रेम-अनुक्रमिक स्ट्रीम में परिवर्तित करता है जबकि शटर चश्मे को सिंक्रनाइज़ करता है। निम्नलिखित एमिटर समर्थित हैं: NVIDIA 3D Vision, Open3DOLED, DLP प्रोजेक्टर, 3D Ready, और एक घर का बना Arduino/VESA IR एमिटर।

मोशन ब्लर और क्रॉस-टॉक से लड़ना
मोशन ब्लर डिस्प्ले द्वारा उत्पन्न धुंधलापन है। आधुनिक LCD और OLED पैनल एक पिक्सेल को फ्रेम की अवधि तक जलाए रखते हैं - सैंपल-एंड-होल्ड मोड। जबकि पिक्सेल एक स्थिति में जलता और स्थिर रहता है, आँखें सहज रूप से गतिमान वस्तु का पीछा करती रहती हैं। परिणामस्वरूप, छवि रेटिना पर ही "धुंधली" हो जाती है, भले ही डिस्प्ले पर प्रत्येक व्यक्तिगत फ्रेम पूरी तरह से तीक्ष्ण हो। एक पिक्सेल जितनी देर जलता रहता है, धुंधलापन उतना ही अधिक होता है। यह दोष बारीक विवरण को छिपा देता है और 3D मोड में छवि को अतिरिक्त रूप से खराब करता है।

पिक्सेल के जलने के समय को कम करने के लिए, WibbleWobble दो उपकरण प्रदान करता है:
ब्लैक फ्रेम इंसर्शन - उपयोगी फ्रेम के बीच एक काला फ्रेम डालना (Client Config में Black Frame Insertion Interval पैरामीटर)।
CRT बीम सिम्युलेटर Blur Busters द्वारा - एक शेडर जो CRT की इलेक्ट्रॉन बीम की स्वीप की नकल करता है: यह छवि को पूरे फ्रेम के बजाय पंक्ति दर पंक्ति खाली करता है। यह बेहतर परिणाम देता है लेकिन डिस्प्ले पर मांग करता है: इसे गामा 2.2 या 2.4, ABL/APL अक्षम, और SDR मोड में OLED की आवश्यकता होती है। FALD और MiniLED पैनलों पर यह खराब काम करता है बैकलाइट जड़ता के कारण।

इन दो मोड को एक ही समय में सक्षम नहीं किया जाना चाहिए। CRT Sim का उपयोग करते समय, Client Config में Black Frame Insertion Interval पैरामीटर शून्य होना चाहिए। यह अलग से जोर देना उचित है कि गेम डिस्प्ले के फ्रेम आउटपुट की तुलना में कम दर पर चल सकता है, और प्रोग्राम डिस्प्ले की दर तक छूटे हुए फ्रेम को भरता है। लेकिन यह नई मध्यवर्ती छवियों की पीढ़ी नहीं है - यह तैयार छवियों की पुनरावृत्ति है। दूसरे शब्दों में, रीसैंपलिंग विधि जो सहजता प्रदान करती है, वह यहाँ नहीं है।

क्रॉस-टॉक वह प्रभाव है जिसमें एक आँख के लिए इच्छित छवि आंशिक रूप से दूसरी आँख तक पहुँच जाती है। परिणामस्वरूप, दर्शक वस्तुओं के बगल में दोहरे समोच्च या अर्ध-पारदर्शी "भूत" देखता है। यह 3D छवि की गुणवत्ता को खराब करता है और गहराई की भावना को कम करता है। इससे निपटने के लिए, Black Frame Insertion और Blur Busters CRT-बीम सिम्युलेटर का समर्थन अंतर्निहित है। व्यापक क्रॉस-टॉक दमन के लिए, एक चतुर मोड का उपयोग किया जाता है: गेम छवि 60 Hz पर खींची जाती है, चश्मे को 120 Hz पर सिंक मिलता है, और स्क्रीन पर आउटपुट 240 Hz पर फ्रेम पुनरावृत्ति के साथ चलता है।

अपने सभी गुणों के बावजूद, इस तरीके की सीमाएँ हैं जिन्हें अलग से बताया जाना चाहिए। ये प्रोग्राम की किसी अपूर्णता से नहीं, बल्कि चुने गए संचालन सिद्धांत से उत्पन्न होती हैं। दूसरा स्टीरियो दृष्टिकोण दृश्य मॉडल से रेंडर नहीं किया जाता, बल्कि पहले से तैयार फ्रेम और डेप्थ मैप से पुनर्निर्मित किया जाता है। यदि स्रोत फ्रेम में अग्रभूमि वस्तुओं के पीछे क्या छिपा है, इसका डेटा नहीं है, तो इसे कहीं से भी पुनर्प्राप्त नहीं किया जा सकता।

वस्तुओं के किनारों पर छेद - डिसऑक्लूज़न
यह इस तरीके का मुख्य दोष है। जब प्रोग्राम दूसरी आँख या सिर घुमाने के लिए दृष्टिकोण को स्थानांतरित करता है, तो पृष्ठभूमि का वह हिस्सा जो स्रोत फ्रेम में अग्रभूमि वस्तु के किनारे से छिपा था, दिखाई देना चाहिए। लेकिन उन पिक्सेल को किसी ने रेंडर नहीं किया - वे भौतिक रूप से मौजूद नहीं हैं। प्रोग्राम के पास अंतराल भरने के लिए कुछ नहीं है, इसलिए यह या तो किनारे के पिक्सेल को खींचता है, जिससे समोच्चों के साथ एक "रबरी" धुंधला प्रभामंडल बनता है, या एक "विश्वसनीय" लेकिन आमतौर पर गलत पैच प्रतिस्थापित करता है। दृष्टिकोण स्थानांतरण जितना अधिक होगा, प्रभामंडल पट्टियाँ उतनी ही चौड़ी होंगी। यह कार्यान्वयन की बग नहीं है, बल्कि इस तरीके की सीमा है: आप एक ही छवि से वह नहीं निकाल सकते जो वस्तुओं के पीछे छिपा है और उसमें दिखाई नहीं देता।

सिर की गति विकृतियों को बढ़ाती है
साधारण स्टीरियो में दृष्टिकोण बिंदुओं के बीच की दूरी छोटी और स्थिर होती है - पुतलियों के बीच की दूरी के बराबर। लेकिन "दुनिया में एक खिड़की" के साथ, सिर विभिन्न दिशाओं में दसियों सेंटीमीटर चलता है, इसलिए सापेक्ष दृष्टिकोण बदलाव प्राकृतिक से कई गुना बड़ा होता है, और छेद और धुंधलापन बड़ा हो जाता है। यह इस तरह काम करता है: स्थिर बैठें और लगभग कोई कलाकृति नहीं होती, लेकिन 3D प्रभाव भी कमजोर होता है; बहुत हिलें और प्रभाव मौजूद होता है, लेकिन वस्तुओं के किनारों के साथ सब कुछ धुंधला और तैरता हुआ दिखता है।

ग्राफिक्स गहराई मानचित्र पर निर्भर करते हैं
प्रोग्राम को दृश्य में प्रत्येक बिंदु की दूरी के बारे में सही जानकारी चाहिए। गेम हमेशा यह प्रदान नहीं करता, या पूरी नहीं करता। पारदर्शी सतहें - पानी, कांच, धुआं, आग, पत्ते - आमतौर पर विस्तृत गहराई नहीं रखतीं, या इंजन इसे बिल्कुल नहीं बनाता। परिणामस्वरूप, वस्तुएं गलत दूरी पर आ जाती हैं: पानी गलत जगह पर चिपक जाता है, धुआं दोगुना हो जाता है, कण हवा में अलग-अलग जगहों पर लटक जाते हैं। इसके अलावा, हर गेम संगत गहराई बफर आउटपुट नहीं करता - कुछ में यह उलटा होता है, अन्य में यह संरक्षित होता है और पढ़ा नहीं जा सकता।

प्रतिबिंब और हाइलाइट्स सबसे ज्यादा टूटते हैं
दर्पण, पानी, गीला डामर, और धातु अपनी सतह की गहराई से परिभाषित होते हैं, न कि उनमें परिलक्षित छवि से। जब दृष्टिकोण बदलता है, तो प्रतिबिंब कहीं और चला जाता है। यदि हाइलाइट सतह पर "चित्रित" है, तो यह वैसा व्यवहार नहीं करता जैसा वास्तविक दुनिया में करना चाहिए। यह ठीक सबसे चमकदार चमकदार सामग्री है जो स्टीरियो में सपाट और गलत दिखती है।

इंटरफेस, क्रॉसहेयर, और HUD
फ्रेम के ऊपर द्वि-आयामी तत्व - स्वास्थ्य बार, मेनू, क्रॉसहेयर - शून्य गहराई पर खींचे जाते हैं, इसलिए प्रसंस्करण के बाद वे गलत स्टीरियो दूरी पर आ जाते हैं। इंटरफेस या तो स्क्रीन में चिपक जाता है या दृश्य के सामने लटक जाता है। क्रॉसहेयर अपने आप में एक सिरदर्द है; इसकी गहराई की स्थिति लगभग हमेशा हाथ से समायोजित करनी पड़ती है।

दोनों आंखों के लिए एक फ्रेम
दोनों आंखें एक ही छवि देखती हैं, बस स्थानांतरित। ईमानदार स्टीरियो रेंडरिंग के साथ प्रत्येक आंख को अपने स्वयं के सही हाइलाइट्स, छाया, और अपवर्तन मिलते हैं; यहां ऐसा नहीं होगा। इसके कारण, वस्तुएं प्लाईवुड से काटी गई सपाट परतों के रूप में और गहराई से व्यवस्थित दिखती हैं, न कि आयतनिक पिंडों के रूप में। अंग्रेजी सामग्री में इस प्रभाव को "कार्डबोर्ड कटआउट" प्रभाव कहा जाता है।

प्रति-गेम ट्यूनिंग
दृष्टि क्षेत्र, गहराई सीमा, और अभिसरण प्रत्येक गेम के लिए अलग से हाथ से सेट किए जाते हैं। चूक से या तो अत्यधिक अभिसरण से आंखों में तनाव होता है, या गलत पैमाना, जहां दुनिया खिलौने जैसी या विशाल दिखती है, या पूरी तरह उलटी गहराई। यह एक "इसे ट्यून करें और समझें" समाधान है, न कि "इसे इंस्टॉल करें और खेलें"।

लेटेंसी और असमान फ्रेम
गेम फ्रेम असमान रूप से रेंडर करता है, और क्लाइंट तैयार फ्रेम को दोहराकर उन्हें डिस्प्ले के स्थिर fps के अनुकूल बनाता है। दोहराव स्वयं कोई विकृति नहीं लाता, लेकिन क्रिया और छवि के बीच की लेटेंसी जमा होती जाती है: फ्रेम कैप्चर, प्रसंस्करण, आउटपुट। हेड ट्रैकिंग के लिए, ऐसी कोई भी लेटेंसी दृश्य के "तैरने" के रूप में महसूस होती है। Game Config में इसके लिए एक Frame Capture Delay पैरामीटर है, कैप्चर क्षण को ट्यून करने के लिए।

अवशिष्ट क्रॉस-टॉक और उच्च मॉनिटर आवश्यकताएं
सॉफ़्टवेयर तकनीकें - ब्लैक फ़्रेम इंसर्शन और 60/120/240 मोड - घोस्टिंग को दबाती हैं, लेकिन इसे पूरी तरह से हटाती नहीं हैं, क्योंकि क्रॉस-टॉक कई कारकों से निर्धारित होता है: डिस्प्ले पैनल और चश्मे की भौतिकी। यह पिक्सेल रिस्पॉन्स टाइम, स्विचिंग स्पीड, चश्मे के लेंस के कंट्रास्ट, और स्क्रीन की वर्टिकल ड्रॉ रेट पर निर्भर करता है। इसके अलावा, सबसे आक्रामक मोड के लिए एक तेज़ 240 Hz पैनल की आवश्यकता होती है जिसमें कम पिक्सेल पर्सिस्टेंस हो, जो हर उपयोगकर्ता के पास नहीं होता। NVIDIA 3D Vision के विपरीत, ReShade एक तैयार वॉल्यूम को पुन: उत्पन्न नहीं करता बल्कि इसे एक सपाट फ़्रेम से संश्लेषित करता है। इसलिए कंटूर के साथ छेद, गलत रिफ्लेक्शन, और तैरते किनारे इस विधि के स्थायी आर्टिफैक्ट हैं, न कि एक अस्थायी कमी।

यहाँ स्टीरियो ज्यामिति ईमानदार है, और छवि-संश्लेषण के कोई भी आर्टिफैक्ट - डिसऑक्लूज़न, "कार्डबोर्ड," टूटे रिफ्लेक्शन - यहाँ मौजूद नहीं हैं। लेकिन इस विधि की भी अपनी कीमत है, और यह एक अलग है।

गेम को VR का समर्थन करना चाहिए
यह मुख्य सीमा है। यह विधि किसी भी मनमाने गेम के साथ काम नहीं करती: इसके लिए या तो अंतर्निहित VR समर्थन या एक VR मॉड की आवश्यकता होती है। यदि कोई तैयार मॉड मौजूद नहीं है, तो OpenVR पथ काम नहीं करेगा, और केवल ReShade अपने सभी आर्टिफैक्ट के साथ बचता है। दूसरे शब्दों में, जिस व्यापक संगतता के लिए पहला पथ मौजूद है, वह यहाँ पूरी तरह से खो जाती है।

ग्राफ़िक्स कार्ड पर दोहरा भार
दृश्य वास्तव में दो कैमरों से दो बार रेंडर किया जाता है। एकल व्यू के रीप्रोजेक्शन से जो बचत मिलती है, वह यहाँ नहीं है: प्रदर्शन उसी तरह गिरता है जैसे असली VR में। यह आंशिक रूप से VR Config में Resolution सेटिंग द्वारा संतुलित किया जाता है - प्रति-आँख रिज़ॉल्यूशन को कम किया जा सकता है, और WibbleWobble छवि को डिस्प्ले के रिज़ॉल्यूशन तक स्केल कर देगा।

जटिल इंस्टॉलेशन
SteamVR इंस्टॉल होना चाहिए। ड्राइवर Install.bat के माध्यम से एडमिनिस्ट्रेटर अधिकारों के साथ रजिस्टर किया जाता है, जिसके बाद config\steamvr.vrsettings फ़ाइल में मैन्युअल रूप से दो लाइनें जोड़नी होती हैं: "forcedDriver": "WibbleWobbleVR" और "activateMultipleDrivers": "true"। फिर STANDING ONLY मोड में Room Setup पूरा करें। किसी भी चरण में त्रुटि और, स्टीरियो के बजाय, आपको कारण के बारे में स्पष्ट संदेश के बिना एक काली स्क्रीन मिलती है।

OpenVR की स्वयं की सीमाएँ
कुछ सेटिंग्स को उड़ते हुए बदला नहीं जा सकता। यदि आप रिज़ॉल्यूशन या आउटपुट रेट बदलते हैं, तो SteamVR को पुनः आरंभ करना आवश्यक है। यह एक प्लेटफ़ॉर्म सीमा है, प्रोग्राम की नहीं, लेकिन यह गेम्स की ट्यूनिंग को काफ़ी धीमा कर देती है।

रेंडर ऑप्टिमाइज़ेशन कुछ गेम्स को तोड़ देता है
VR Config में एक Optimise Single Eye पैरामीटर है जो केवल एक आँख या आधे FOV पर दोनों को रेंडर करने की अनुमति देता है। प्रोजेक्ट के लेखक सीधे चेतावनी देते हैं: "Both" मोड सबसे समस्याग्रस्त है - विग्नेटिंग और आँखों का डीसिंक्रोनाइज़ेशन संभव है, और छवि "शिफ्ट" हो सकती है। कुछ गेम्स में ऑप्टिमाइज़ेशन को पूरी तरह से बंद करना पड़ेगा।

विंडो फ़ोकस के लिए संघर्ष
कुछ गेम्स WibbleWobble इंटरफ़ेस को फ़ोकस नहीं देते: SHIFT + END कुंजी संयोजन काम नहीं करता, या UI तो बनता है लेकिन नियंत्रित नहीं किया जा सकता। आपको ALT + TAB के माध्यम से मैन्युअल रूप से स्विच करना पड़ता है। एक अलग समस्या: WibbleWobble विंडो को बंद नहीं करना चाहिए - प्रोग्राम इसके बाद रिकवर नहीं होता, और गेम को पुनः आरंभ करना पड़ेगा।

हर लॉन्च पर रीसेंटरिंग
ट्रैकिंग को हर बार स्टार्टअप पर मैन्युअल रूप से केंद्रित करना होता है (SHIFT + .), और इसे स्क्रीन के सामने कार्य क्षेत्र के ठीक केंद्र में रखना होता है। यदि केंद्रित करते समय सिर वहाँ नहीं था, तो रीप्रोजेक्शन अजीब व्यवहार करने लगता है और स्केल "ड्रिफ्ट" होने लगता है। लेखक के अपने कथन के अनुसार, सही स्थिति प्राप्त करने के लिए अभ्यास की आवश्यकता होती है। इसे बाद में अधिक बुद्धिमान ट्रैकिंग सॉफ़्टवेयर का उपयोग करके ठीक किया जा सकता है।

व्यक्तिगत अनुप्रयोगों की विचित्रताएँ
कुछ प्रोग्राम केवल कुछ विशेष ब्रांड के हेडसेट के साथ काम करते हैं। उनके लिए, VR Config में एक Headset Identification पैरामीटर होता है जो WibbleWobble को एक अलग डिवाइस - उदाहरण के लिए Vive - के रूप में प्रस्तुत करता है, जिसके बिना DEOVR में हेड ट्रैकिंग काम नहीं करती। दूसरे शब्दों में, कई जगहों पर संगतता इस तरह के वर्कअराउंड पर निर्भर करती है।

पहले पथ के साथ साझा आधार
हार्डवेयर से संबंधित सब कुछ दोनों विधियों पर लागू होता है: अवशिष्ट क्रॉस-टॉक, तेज़ पैनल की आवश्यकता, सटीक चश्मा सिंक्रोनाइज़ेशन की आवश्यकता। स्टीरियो आउटपुट, एमिटर, BFI, और CRT Sim उसी तरह काम करते हैं चाहे स्टीरियो जोड़ी कहीं से भी आई हो।