मैं फिलिप के जवाब से थोड़ा असहमत हूं ; या कम से कम उसने इसे कैसे प्रस्तुत किया। यह धारणा देता है कि खिलाड़ी के चारों ओर दुनिया घूमना बेहतर विचार हो सकता है; जब यह ठीक विपरीत है। तो यहाँ मेरा अपना जवाब है ...
दोनों विकल्प काम कर सकते हैं, लेकिन आम तौर पर दुनिया भर के खिलाड़ी के बजाय खिलाड़ी के चारों ओर दुनिया को स्थानांतरित करके "भौतिकी को पलटना" एक बुरा विचार है।
प्रदर्शन हानि / बर्बादी:
दुनिया में आमतौर पर बहुत सारी वस्तुएं होंगी; कई नहीं तो अधिकांश, स्थिर या नींद। खिलाड़ी के पास एक, या अपेक्षाकृत कुछ वस्तुएं होंगी। खिलाड़ी के चारों ओर पूरी दुनिया को हिलाने का मतलब है, खिलाड़ी को छोड़कर दृश्य में सब कुछ हिलना। स्थिर वस्तुएँ, सोई हुई गतिशील वस्तुएँ, सक्रिय गतिशील वस्तुएँ, प्रकाश-स्रोत, ध्वनि-स्रोत आदि; सभी को स्थानांतरित करना होगा।
यह (स्पष्ट रूप से) केवल वास्तव में आगे बढ़ने से ज्यादा महंगा है (खिलाड़ी, और शायद कुछ और सामान)।
स्थिरता और विस्तार:
खिलाड़ी के चारों ओर दुनिया घूमना दुनिया को बनाता है (और इसमें सब कुछ) वह बिंदु है जहां चीजें सबसे अधिक सक्रिय रूप से हो रही हैं। सिस्टम में कोई बग या परिवर्तन का अर्थ है कि, संभवतः, सब कुछ बदल जाता है। चीजों को करने का यह एक अच्छा तरीका नहीं है; आप बग्स / बदलावों को यथासंभव अलग करना चाहते हैं, ताकि आपको अप्रत्याशित व्यवहार न मिले कहीं आपने बदलाव नहीं किया है।
इस दृष्टिकोण के साथ कई अन्य समस्याएं भी हैं। उदाहरण के लिए, यह कई धारणाओं को तोड़ता है कि कैसे इंजन में काम करना चाहिए। आप RigidBodyउदाहरण के लिए, खिलाड़ी के अलावा किसी अन्य चीज़ के लिए गतिशील का उपयोग करने में सक्षम नहीं होंगे ; RigidBodyकीनेमेटिक पर सेट नहीं की गई किसी वस्तु के रूप में स्थिति / रोटेशन / स्केल सेट करते समय अप्रत्याशित रूप से व्यवहार करेगा (जो आप प्रत्येक फ्रेम के लिए कर रहे हैं, दृश्य में प्रत्येक वस्तु के लिए, खिलाड़ी को छोड़कर)
तो इसका उत्तर केवल खिलाड़ी को स्थानांतरित करना है!
खैर ... हां और नहीं । जैसा कि फिलिप के उत्तर में उल्लेख किया गया है, एक अनंत-धावक प्रकार के खेल में (या किसी बड़े सहज क्षेत्र के साथ कोई भी खेल), मूल से बहुत दूर जाने पर अंततः ध्यान देने योग्य FPPEs ( फ्लोटिंग-पॉइंट प्रिसिजन एरर्स ) का परिचय होगा , और आगे भी, अंततः संख्यात्मक प्रकार के अतिप्रवाह, या तो आपके गेम को क्रैश करने का कारण बनते हैं, या, मूल रूप से, गेम-वर्ल्ड स्मोक क्रैक ... स्टेरॉयड पर! 😵 (क्योंकि इस बिंदु से, FPPEs खेल को पहले से ही "सामान्य" दरार पर बना देगा)
वास्तविक समाधान:
ना तो करो और ना दोनों करो! आपको दुनिया को स्थिर रखना चाहिए, और इसके चारों ओर खिलाड़ी को स्थानांतरित करना चाहिए। लेकिन "री-रूट" दोनों खिलाड़ी और दुनिया, जब खिलाड़ी दृश्य की जड़ (स्थिति [0, 0, 0]) से बहुत दूर होने लगता है ।
यदि आप चीजों की सापेक्ष स्थिति (इसके चारों ओर दुनिया के खिलाड़ी) रखते हैं, और इस प्रक्रिया को एकल फ्रेम-अपडेट में करते हैं, तो (वास्तविक) खिलाड़ी को नोटिस भी नहीं होगा!
ऐसा करने के लिए, आपके पास दो प्राथमिक विकल्प हैं:
- खिलाड़ी को दृश्य के मूल में ले जाएं, और खिलाड़ी के सापेक्ष नई स्थिति में दुनिया को स्थानांतरित करें।
- एक ग्रिड की तरह दुनिया के बारे में सोचो; ग्रिड के उस हिस्से को स्थानांतरित करें जो खिलाड़ी रूट में है, और खिलाड़ी को ग्रिड के उस हिस्से के सापेक्ष नई स्थिति में ले जाएं।
कार्रवाई में इस प्रक्रिया का एक उदाहरण है
लेकिन, कितनी दूर है?
आप एकता के स्रोत-कोड को देखें, तो वे का उपयोग 1e-5( 0.00001) "बराबर" दो फ्लोटिंग प्वाइंट मूल्यों को देखते हुए के अंदर के लिए आधार के रूप में Vector2और Vector3(वस्तुओं की स्थिति के लिए जिम्मेदार डेटा-प्रकार, [euler-] रोटेशन और तराजू)। चूंकि फ्लोटिंग-पॉइंट सटीक नुकसान शून्य से दोनों तरीके से होता है, इसलिए यह मान लेना सुरक्षित है कि दृश्य रूट / उत्पत्ति से दूर 1e+5( 100000) इकाइयों के तहत कुछ भी काम करने के लिए सुरक्षित है।
परंतु! जबसे...
- इन री-रूटिंग प्रक्रियाओं को स्वचालित रूप से संभालने के लिए एक सिस्टम बनाना अधिक उपयुक्त है।
- आपका खेल चाहे जो भी हो, दुनिया के 100000 यूनिट (मीटर [?]) चौड़े होने के लिए एक सन्निहित "खंड" की कोई आवश्यकता नहीं है।
... तो यह शायद एक अच्छा विचार है कि 100000 इकाइयों के निशान की तुलना में जल्द / अधिक बार फिर से रूट करें। उदाहरण के लिए मैंने जो वीडियो प्रदान किया है, वह प्रत्येक 1000 इकाइयों या ऐसा करने के लिए लगता है, उदाहरण के लिए।
