टीएल, डॉ

मैंने एक डेमो बनाया, जिसमें दिखाया गया है कि एकता में एक खिलाड़ी के शारीरिक आंदोलन की क्लाइंट-साइड भविष्यवाणी को कैसे लागू किया जाए - GitHub ।

परिचय

2012 की शुरुआत में, मैंने एक पोस्ट लिखा कि यूनिटी में एक खिलाड़ी के शारीरिक आंदोलन के ग्राहक पक्ष पर पूर्वानुमान कैसे लागू किया जाए। Physics.Simulate () के लिए धन्यवाद , उस अनाड़ी वर्कअराउंड जिसे मैंने वर्णित किया है, उसकी अब आवश्यकता नहीं है। पुरानी पोस्ट अभी भी मेरे ब्लॉग पर सबसे लोकप्रिय में से एक है, लेकिन आधुनिक एकता के लिए यह जानकारी पहले से ही गलत है। इसलिए, मैं 2018 संस्करण जारी कर रहा हूं।

ग्राहक पक्ष में क्या है?

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

सर्वर से प्राप्त स्नैपशॉट हमेशा क्लाइंट की अनुमानित स्थिति के संबंध में अतीत से आते हैं (उदाहरण के लिए, यदि क्लाइंट से सर्वर और बैक में डेटा ट्रांसफर करने में 150 एमएस लगते हैं, तो प्रत्येक स्नैपशॉट में कम से कम 150 एमएस की देरी होगी)। इसके परिणामस्वरूप, जब क्लाइंट को गलत पूर्वानुमान को ठीक करने की आवश्यकता होती है, तो उसे अतीत में इस बिंदु पर वापस रोल करना होगा, और फिर अंतर में दर्ज की गई सभी जानकारी को पुन: उत्पन्न करने के लिए जहां वह है। यदि खेल में खिलाड़ी की चाल भौतिकी पर आधारित है, तो Physics.Simulate () को एक फ्रेम में कई चक्रों को अनुकरण करने की आवश्यकता है। यदि खिलाड़ी को स्थानांतरित करते समय केवल चरित्र नियंत्रकों (या कैप्सूल कास्ट, आदि) का उपयोग किया जाता है, तो आप भौतिकी के बिना कर सकते हैं। () - और मुझे लगता है कि प्रदर्शन बेहतर होगा।

मैं यूनिटी का उपयोग "नेटवर्क फिजिक्स के ग्लेन फिडलर जेन" नामक एक नेटवर्क डेमो को फिर से बनाने के लिए करूंगा , जिसका मुझे लंबे समय तक आनंद मिला है। खिलाड़ी के पास एक भौतिक घन होता है, जिसे वह दृश्य में धकेलते हुए बल लगा सकता है। डेमो देरी और पैकेट हानि सहित विभिन्न नेटवर्क स्थितियों का अनुकरण करता है।

काम पर लगना

पहली बात यह है कि स्वचालित भौतिकी सिमुलेशन को बंद करना है। यद्यपि Physics.Simulate () हमें सिमुलेशन शुरू करने के लिए भौतिक प्रणाली को बताने की अनुमति देता है, डिफ़ॉल्ट रूप से यह निश्चित परियोजना समय डेल्टा के आधार पर स्वचालित रूप से सिमुलेशन करता है। इसलिए, हम इसे " ऑटो सिमुलेशन " बॉक्स को अनचेक करके एडिट-> प्रोजेक्ट सेटिंग्स-> भौतिकी में अक्षम कर देंगे।

आरंभ करने के लिए, हम एक सरल एकल-उपयोगकर्ता कार्यान्वयन बनाएंगे। इनपुट को नमूना (डब्ल्यू, ए, एस, डी के लिए चलती है और कूदने के लिए जगह), और यह सभी AddForce () का उपयोग करके रिगिडॉडी पर लागू सरल बलों के लिए नीचे आता है।

public class Logic : MonoBehaviour { public GameObject player; private float timer; private void Start() { this.timer = 0.0f; } private void Update() { this.timer += Time.deltaTime; while (this.timer >= Time.fixedDeltaTime) { this.timer -= Time.fixedDeltaTime; Inputs inputs; inputs.up = Input.GetKey(KeyCode.W); inputs.down = Input.GetKey(KeyCode.S); inputs.left = Input.GetKey(KeyCode.A); inputs.right = Input.GetKey(KeyCode.D); inputs.jump = Input.GetKey(KeyCode.Space); this.AddForcesToPlayer(player.GetComponent<Rigidbody>(), inputs); Physics.Simulate(Time.fixedDeltaTime); } } }

प्लेयर तब चलता है जब नेटवर्क उपयोग में नहीं होता है

सर्वर पर इनपुट भेजना

अब हमें सर्वर को इनपुट भेजने की आवश्यकता है, जो इस गति कोड को भी निष्पादित करेगा, क्यूब की स्थिति का एक स्नैपशॉट बनाएं और इसे क्लाइंट को वापस भेजें।

 // client private void Update() { this.timer += Time.deltaTime; while (this.timer >= Time.fixedDeltaTime) { this.timer -= Time.fixedDeltaTime; Inputs inputs = this.SampleInputs(); InputMessage input_msg; input_msg.inputs = inputs; input_msg.tick_number = this.tick_number; this.SendToServer(input_msg); this.AddForcesToPlayer(player.GetComponent<Rigidbody>(), inputs); Physics.Simulate(Time.fixedDeltaTime); ++this.tick_number; } }

यहां अभी तक कुछ खास नहीं है, केवल एक चीज जिस पर मैं ध्यान देना चाहता हूं वह है tick_number वैरिएबल को जोड़ना। यह आवश्यक है कि जब सर्वर ग्राहक को वापस घन की स्थिति का स्नैपशॉट भेजता है, तो हम यह पता लगा सकते हैं कि ग्राहक इस राज्य से क्या मेल खाता है, ताकि हम इस स्थिति की भविष्यवाणी ग्राहक के साथ कर सकें (जो हम बाद में थोड़ा जोड़ देंगे)।

 // server private void Update() { while (this.HasAvailableInputMessages()) { InputMessage input_msg = this.GetInputMessage(); Rigidbody rigidbody = player.GetComponent<Rigidbody>(); this.AddForcesToPlayer(rigidbody, input_msg.inputs); Physics.Simulate(Time.fixedDeltaTime); StateMessage state_msg; state_msg.position = rigidbody.position; state_msg.rotation = rigidbody.rotation; state_msg.velocity = rigidbody.velocity; state_msg.angular_velocity = rigidbody.angularVelocity; state_msg.tick_number = input_msg.tick_number + 1; this.SendToClient(state_msg); } }

सब कुछ सरल है - सर्वर इनपुट संदेशों की प्रतीक्षा करता है, जब वह इसे प्राप्त करता है, तो यह एक घड़ी चक्र को अनुकरण करता है। फिर वह घन की परिणामी स्थिति का एक स्नैपशॉट लेता है और इसे क्लाइंट को वापस भेजता है। आप देख सकते हैं कि स्थिति संदेश में tick_number इनपुट संदेश में tick_number से एक अधिक है। ऐसा इसलिए किया जाता है क्योंकि यह "व्यक्तिगत रूप से सहज रूप से अधिक सुविधाजनक" मेरे लिए "100 नंबर की शुरुआत में खिलाड़ी की स्थिति" के रूप में "100 में खिलाड़ी की स्थिति" के बारे में सोचना है। इसलिए, माप 100 में खिलाड़ी के इनपुट के साथ संयोजन में माप 100 में खिलाड़ी की स्थिति माप 101 में खिलाड़ी के लिए एक नया राज्य बनाता है।

राज्य _n + इनपुट _n = राज्य _{n + 1}

मैं यह नहीं कह रहा हूं कि आपको इसे उसी तरह से लेना चाहिए, मुख्य बात दृष्टिकोण की स्थिरता है।

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

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

आप यह भी देख सकते हैं कि यदि इनपुट संदेश छोड़ दिया जाता है और सर्वर तक नहीं पहुंचता है, तो सर्वर क्लाइंट की तुलना में कम घड़ी चक्र का अनुकरण करता है, और इसलिए एक अलग स्थिति बनाएगा। यह सच है, लेकिन अगर हम इन चूक का अनुकरण करते हैं, तो भी इनपुट गलत हो सकता है, जो एक अलग स्थिति को भी जन्म देगा। हम इस समस्या से बाद में निपटेंगे।

यह भी जोड़ा जाना चाहिए कि इस उदाहरण में केवल एक ग्राहक है, जो काम को सरल करता है। यदि हमारे पास कई क्लाइंट्स हैं, तो हमें फ़िज़िक्स कहते समय a) की आवश्यकता होगी। यह प्रमाणित करने के लिए कि सर्वर पर केवल एक खिलाड़ी का क्यूब सक्षम है, या b) यदि सर्वर को कई क्यूब्स से इनपुट प्राप्त हुआ है, तो उन सभी को एक साथ अनुकरण करें।

देरी 75 एमएस (150 एमएस दौर यात्रा)
0% खो पैकेज
पीला घन - सर्वर खिलाड़ी
ब्लू क्यूब - क्लाइंट द्वारा प्राप्त अंतिम स्नैपशॉट

अब तक सब कुछ अच्छा लग रहा है, लेकिन मैं एक गंभीर समस्या को छुपाने के लिए वीडियो पर जो कुछ भी दर्ज किया था, उसके साथ मैं थोड़ा चुनिंदा था।

निश्चय विफलता

अब इस पर एक नज़र डालें:

आउच ...

पैकेज खोए बिना यह वीडियो रिकॉर्ड किया गया था, हालांकि, सिमुलेशन अभी भी उसी इनपुट के साथ भिन्न होते हैं। मुझे यह समझ में नहीं आया कि ऐसा क्यों होता है - PhysX को काफी नियतात्मक होना चाहिए, इसलिए मुझे लगता है कि यह बहुत बार डायवर्जन करता है। यह इस तथ्य के कारण हो सकता है कि मैं गेमऑबजेक्ट क्यूब्स को लगातार सक्षम और अक्षम करता हूं, अर्थात, यह संभव है कि दो अलग-अलग यूनिटी उदाहरणों का उपयोग करते समय समस्या कम हो जाएगी। यह एक बग हो सकता है, यदि आप इसे GitHub पर कोड में देखते हैं, तो मुझे बताएं।

हो सकता है कि यह हो सकता है, गलत पूर्वानुमान ग्राहक पक्ष पर पूर्वानुमान लगाने के लिए एक आवश्यक तथ्य हैं, तो चलो उनके साथ व्यवहार करते हैं।

क्या मैं रिवाइंड कर सकता हूं?

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

 // client private ClientState[] client_state_buffer = new ClientState[1024]; private Inputs[] client_input_buffer = new Inputs[1024]; private void Update() { this.timer += Time.deltaTime; while (this.timer >= Time.fixedDeltaTime) { this.timer -= Time.fixedDeltaTime; Inputs inputs = this.SampleInputs(); InputMessage input_msg; input_msg.inputs = inputs; input_msg.tick_number = this.tick_number; this.SendToServer(input_msg); uint buffer_slot = this.tick_number % 1024; this.client_input_buffer[buffer_slot] = inputs; this.client_state_buffer[buffer_slot].position = rigidbody.position; this.client_state_buffer[buffer_slot].rotation = rigidbody.rotation; this.AddForcesToPlayer(player.GetComponent<Rigidbody>(), inputs); Physics.Simulate(Time.fixedDeltaTime); ++this.tick_number; } while (this.HasAvailableStateMessage()) { StateMessage state_msg = this.GetStateMessage(); uint buffer_slot = state_msg.tick_number % c_client_buffer_size; Vector3 position_error = state_msg.position - this.client_state_buffer[buffer_slot].position; if (position_error.sqrMagnitude > 0.0000001f) { // rewind & replay Rigidbody player_rigidbody = player.GetComponent<Rigidbody>(); player_rigidbody.position = state_msg.position; player_rigidbody.rotation = state_msg.rotation; player_rigidbody.velocity = state_msg.velocity; player_rigidbody.angularVelocity = state_msg.angular_velocity; uint rewind_tick_number = state_msg.tick_number; while (rewind_tick_number < this.tick_number) { buffer_slot = rewind_tick_number % c_client_buffer_size; this.client_input_buffer[buffer_slot] = inputs; this.client_state_buffer[buffer_slot].position = player_rigidbody.position; this.client_state_buffer[buffer_slot].rotation = player_rigidbody.rotation; this.AddForcesToPlayer(player_rigidbody, inputs); Physics.Simulate(Time.fixedDeltaTime); ++rewind_tick_number; } } } }

बफर इनपुट और स्टेटस डेटा को एक बहुत ही सरल परिपत्र बफर में संग्रहित किया जाता है, जहां माप पहचानकर्ता को एक सूचकांक के रूप में उपयोग किया जाता है। और मैंने भौतिकी की घड़ी की आवृत्ति के लिए 64 हर्ट्ज का मान चुना, अर्थात् 1024 तत्वों का एक बफर हमें 16 सेकंड के लिए जगह देता है, और यह हम की आवश्यकता की तुलना में बहुत अधिक है।

सुधार जारी है!

निरर्थक इनपुट स्थानांतरण

इनपुट संदेश आमतौर पर बहुत छोटे होते हैं - दबाए गए बटन को थोड़े से फ़ील्ड में जोड़ा जा सकता है जो केवल कुछ बाइट्स लेता है। हमारे संदेश में अभी भी एक माप संख्या है, जिसमें 4 बाइट्स हैं, लेकिन हम आसानी से उन्हें कैरी के साथ 8-बिट मान का उपयोग करके संपीड़ित कर सकते हैं (शायद अंतराल 0-255 बहुत छोटा होगा, हम सुरक्षित हो सकते हैं और इसे 9 या 10 बिट तक बढ़ा सकते हैं)। जैसा कि हो सकता है, ये संदेश काफी छोटे हैं, और इसका मतलब है कि हम प्रत्येक संदेश में बहुत इनपुट डेटा भेज सकते हैं (यदि पिछले इनपुट डेटा खो गया था)। हमें कितनी दूर वापस जाना चाहिए? खैर, क्लाइंट को सर्वर से प्राप्त अंतिम स्थिति संदेश की माप संख्या पता है, इसलिए इस उपाय से आगे जाने का कोई मतलब नहीं है। हमें ग्राहक द्वारा भेजे गए निरर्थक इनपुट डेटा की मात्रा पर एक सीमा लगाने की आवश्यकता है। मैंने अपने डेमो में ऐसा नहीं किया, लेकिन इसे तैयार कोड में लागू किया जाना चाहिए।

 while (this.HasAvailableStateMessage()) { StateMessage state_msg = this.GetStateMessage(); this.client_last_received_state_tick = state_msg.tick_number;

यह एक साधारण परिवर्तन है, ग्राहक केवल अंतिम प्राप्त स्थिति संदेश की माप संख्या लिखता है।

 Inputs inputs = this.SampleInputs(); InputMessage input_msg; input_msg.start_tick_number = this.client_last_received_state_tick; input_msg.inputs = new List<Inputs>(); for (uint tick = this.client_last_received_state_tick; tick <= this.tick_number; ++tick) { input_msg.inputs.Add(this.client_input_buffer[tick % 1024]); } this.SendToServer(input_msg);

क्लाइंट द्वारा भेजे गए इनपुट संदेश में अब केवल एक आइटम नहीं, बल्कि इनपुट डेटा की एक सूची होती है। माप संख्या वाले भाग को एक नया मान मिलता है - अब यह इस सूची में पहले इनपुट का माप संख्या है।

 while (this.HasAvailableInputMessages()) { InputMessage input_msg = this.GetInputMessage(); // message contains an array of inputs, calculate what tick the final one is uint max_tick = input_msg.start_tick_number + (uint)input_msg.inputs.Count - 1; // if that tick is greater than or equal to the current tick we're on, then it // has inputs which are new if (max_tick >= server_tick_number) { // there may be some inputs in the array that we've already had, // so figure out where to start uint start_i = server_tick_number > input_msg.start_tick_number ? (server_tick_number - input_msg.start_tick_number) : 0; // run through all relevant inputs, and step player forward Rigidbody rigidbody = player.GetComponent<Rigidbody>(); for (int i = (int)start_i; i < input_msg.inputs.Count; ++i) { this.AddForcesToPlayer(rigidbody, input_msg.inputs[i]); Physics.Simulate(Time.fixedDeltaTime); } server_tick_number = max_tick + 1; } }

जब सर्वर को एक इनपुट संदेश प्राप्त होता है, तो यह संदेश में पहले इनपुट की माप संख्या और इनपुट डेटा की मात्रा को जानता है। इसलिए, यह संदेश में अंतिम इनपुट के माप की गणना कर सकता है। यदि यह अंतिम माप सर्वर माप संख्या से अधिक या उसके बराबर है, तो यह जानता है कि संदेश में कम से कम एक इनपुट शामिल है जिसे सर्वर ने अभी तक नहीं देखा है। यदि ऐसा है, तो यह सभी नए इनपुट डेटा का अनुकरण करता है।

आपने देखा होगा कि यदि हम इनपुट संदेश में निरर्थक इनपुट डेटा की मात्रा को सीमित करते हैं, तो पर्याप्त मात्रा में खोये हुए इनपुट संदेशों के साथ, हमारे पास सर्वर और क्लाइंट के बीच एक सिमुलेशन गैप होगा। यही है, सर्वर 100 का अनुकरण कर सकता है, माप 101 शुरू करने के लिए एक स्थिति संदेश भेज सकता है, और फिर माप 105 पर शुरू होने वाला एक इनपुट संदेश प्राप्त कर सकता है। उपरोक्त कोड में, सर्वर 105 पर जाएगा, यह नवीनतम ज्ञात इनपुट डेटा के आधार पर मध्यवर्ती उपायों को अनुकरण करने का प्रयास नहीं करेगा। आपको जरूरत है कि यह आपके निर्णय पर निर्भर करता है और खेल क्या होना चाहिए। निजी तौर पर, मैं सर्वर को नेटवर्क की खराब स्थिति के कारण खिलाड़ी को मानचित्र पर सट्टा और स्थानांतरित करने के लिए मजबूर नहीं करूंगा। मेरा मानना है कि जब तक कनेक्शन बहाल नहीं हो जाता तब तक खिलाड़ी को छोड़ना बेहतर है।

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

निरर्थक इनपुट डेटा भेजने से पहले: जब 25% पैकेट खो जाते हैं, तो क्यूब की गति धीमी और हिलती है, इसे वापस फेंक दिया जाता है।

निरर्थक इनपुट डेटा भेजने के बाद: पैकेट के 25% के नुकसान के साथ, अभी भी एक चिकोटी सुधार है, लेकिन क्यूब्स एक स्वीकार्य गति से चलते हैं।

चर स्नैपशॉट आवृत्ति

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

स्नैपशॉट आवृत्ति 64 हर्ट्ज

स्नैपशॉट आवृत्ति 16 हर्ट्ज

स्नैपशॉट आवृत्ति 2 हर्ट्ज

जाहिर है, स्नैपशॉट की आवृत्ति जितनी अधिक होती है, उतना बेहतर होता है, इसलिए आपको उन्हें जितनी बार संभव हो भेजना चाहिए। लेकिन यह अतिरिक्त ट्रैफ़िक की मात्रा, इसकी लागत, समर्पित सर्वरों की उपलब्धता, सर्वरों की कंप्यूटिंग लागत और इसी तरह निर्भर करता है।

चौरसाई सुधार

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

मैंने इस समस्या के समाधान को पुरानी पुरानी चौरसाई के साथ दरारों पर चमकाने के लिए किया! जब कोई सुधार होता है, तो क्लाइंट केवल कई फ़्रेमों के लिए सही स्थिति की दिशा में खिलाड़ी की स्थिति और रोटेशन को सुचारू करता है। भौतिक घन अपने आप ही तुरंत ठीक हो जाता है (यह अदृश्य है), लेकिन हमारे पास केवल प्रदर्शन के लिए एक दूसरा घन है, जो चौरसाई करने की अनुमति देता है।

 Vector3 position_error = state_msg.position - predicted_state.position; float rotation_error = 1.f - Quaternion.Dot(state_msg.rotation, predicted_state.rotation); if (position_error.sqrMagnitude > 0.0000001f || rotation_error > 0.00001f) { Rigidbody player_rigidbody = player.GetComponent<Rigidbody>(); // capture the current predicted pos for smoothing Vector3 prev_pos = player_rigidbody.position + this.client_pos_error; Quaternion prev_rot = player_rigidbody.rotation * this.client_rot_error; // rewind & replay player_rigidbody.position = state_msg.position; player_rigidbody.rotation = state_msg.rotation; player_rigidbody.velocity = state_msg.velocity; player_rigidbody.angularVelocity = state_msg.angular_velocity; uint rewind_tick_number = state_msg.tick_number; while (rewind_tick_number < this.tick_number) { buffer_slot = rewind_tick_number % c_client_buffer_size; this.client_input_buffer[buffer_slot] = inputs; this.client_state_buffer[buffer_slot].position = player_rigidbody.position; this.client_state_buffer[buffer_slot].rotation = player_rigidbody.rotation; this.AddForcesToPlayer(player_rigidbody, inputs); Physics.Simulate(Time.fixedDeltaTime); ++rewind_tick_number; } // if more than 2ms apart, just snap if ((prev_pos - player_rigidbody.position).sqrMagnitude >= 4.0f) { this.client_pos_error = Vector3.zero; this.client_rot_error = Quaternion.identity; } else { this.client_pos_error = prev_pos - player_rigidbody.position; this.client_rot_error = Quaternion.Inverse(player_rigidbody.rotation) * prev_rot; } }

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

 this.client_pos_error *= 0.9f; this.client_rot_error = Quaternion.Slerp(this.client_rot_error, Quaternion.identity, 0.1f); this.smoothed_client_player.transform.position = player_rigidbody.position + this.client_pos_error; this.smoothed_client_player.transform.rotation = player_rigidbody.rotation * this.client_rot_error;

प्रत्येक फ्रेम में, क्लाइंट 10% तक सही स्थिति / रोटेशन की ओर lerp / slerp करता है, यह आंदोलन को औसत करने के लिए एक मानक शक्ति-कानून दृष्टिकोण है। यह फ्रेम दर पर निर्भर करता है, लेकिन हमारे डेमो के प्रयोजनों के लिए यह काफी पर्याप्त है।

250 एमएस देरी
10% पैकेज खो दिया
चौरसाई के बिना, सुधार बहुत ध्यान देने योग्य है

250 एमएस देरी
10% पैकेज खो दिया
चौरसाई के साथ, सुधार को नोटिस करना अधिक कठिन है।

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

एकता में क्लाइंट-साइड भौतिकी भविष्यवाणी

टीएल, डॉ

परिचय

ग्राहक पक्ष में क्या है?

काम पर लगना

सर्वर पर इनपुट भेजना

राज्य _n + इनपुट _n = राज्य _{n + 1}

निश्चय विफलता

क्या मैं रिवाइंड कर सकता हूं?

निरर्थक इनपुट स्थानांतरण

चर स्नैपशॉट आवृत्ति

चौरसाई सुधार

More articles:

एकता में क्लाइंट-साइड भौतिकी भविष्यवाणी

टीएल, डॉ

परिचय

ग्राहक पक्ष में क्या है?

काम पर लगना

सर्वर पर इनपुट भेजना

राज्य n + इनपुट n = राज्य n + 1

निश्चय विफलता

क्या मैं रिवाइंड कर सकता हूं?

निरर्थक इनपुट स्थानांतरण

चर स्नैपशॉट आवृत्ति

चौरसाई सुधार

More articles:

राज्य _n + इनपुट _n = राज्य _{n + 1}