माउस

Question

द्वारा नियंत्रित रैकेट के साथ तेज गति से चलने वाली गेंद की टक्कर का पता लगाने में समस्या, एकता में, मेरे पास एक रैकेट है जो गेंद को मारने वाला होता है, और रैकेट सीधे माउस द्वारा नियंत्रित होता है, यानी बल्ले को स्थानांतरित किया जा रहा है माउस अक्षों का उपयोग कर माउस और रैकेट को स्थानांतरित करने के लिए transform.translate() फ़ंक्शन का उपयोग कर।

मुझे उम्मीद थी कि यूनिटी 3 डी के भौतिकी सीधे माउस द्वारा रैकेट के आंदोलन का सही ढंग से अनुवाद नहीं करेंगे और तदनुसार गेंद को प्रभावित करेंगे, और मुझे कुछ कस्टम लिखना होगा, और यह सच साबित हुआ।

लेकिन जब रैकेट चल रहा है तो गेंद की टकराव ठीक से नहीं मिल रही है। जब भी यह है, सब ठीक है, और गेंद मुझे पसंद है व्यवहार करता है।

अब मैं एक कस्टम भौतिकी स्क्रिप्ट लिख रहा हूं (मैं स्क्रिप्टिंग के लिए सी # का उपयोग करता हूं) जिसमें मैंने गेंद को लंबाई 0.6 एफ के 4 रेएक्स संलग्न किए हैं, और कुछ जटिल वेक्टर गणना करने के बाद, गेंद की वेग की गणना करें रैकेट को मारने के बाद, और सीधे rigidbody.velocity = गणना velocity() का उपयोग कर गेंद की वेग पर लागू करें। रैकेट चलने पर यह फिर से ठीक काम कर रहा है, लेकिन जब मैं रैकेट को स्थानांतरित नहीं करता हूं। सटीक (लक्षण) के लक्षण हैं:

अंतर्निहित भौतिकी और टकराव का पता लगाने का उपयोग करना: जब रैकेट चल रहा है, तो गेंद कभी-कभी सीधे रैकेट के माध्यम से गुजरती है, और कभी-कभी, यह धीमा हो जाती है (अविश्वसनीय स्तर तक)।

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

बातें मैं कोशिश की है:

1. (यह रैकेट पर व्यापक बॉक्स कोलाइडर के साथ काम करता है, लेकिन फिर स्पष्ट रूप से गेंद दूर रैकेट से काफी दूर से ले जाता है कोलाइडर का आकार बढ़ाने से, और मेरी अपनी स्क्रिप्ट यहां काम करती है, रैकेट को स्थानांतरित होने पर डिफ़ॉल्ट भौतिकी अजीब परिणाम देती है), संक्षेप में मुझे वह वास्तविकता नहीं मिलती जो मैं चाहता हूं।

2. 0.001 पर निश्चित टाइमस्टैम्प को कम करना, जो चीजों में काफी सुधार हुआ है, लेकिन अभी भी परिणाम से बहुत दूर है, और गेंद बार-बार गेंद के गलत पक्ष को चुन रही है।

3. निरंतर गतिशीलता के लिए टकराव का पता लगाना। जिसने चीजों को बेहतर नहीं किया।

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

यह भी स्पष्ट है कि रैकेट के "आंदोलन" पहलू को यूनिटी 3 डी के भौतिकी में निर्मित नहीं किया जा रहा है, जिसके परिणामस्वरूप माउस का उपयोग करके रैकेट चल रहा है जब अजीब व्यवहार होता है।

मैं अटक गया हूं, मुझे नहीं पता कि यहां से कहाँ जाना है। कृपया मुझे बताएं कि मैं क्या कर रहा हूं।

Answer 1

जैसा कि अन्य ने बताया है, समस्या यह है कि गेंद एक फ्रेम में पैड के एक तरफ से दूसरी तरफ होने के लिए होती है। तेजी से चलती वस्तुओं को ऐसा लगता है कि यदि बाधाएं बहुत पतली हैं।

• पैड या गेंद, जो है क्या हुआ जब आप कोलाइडर आकार बदल का आकार बढ़ाएं:

  इस समस्या के लिए तीन बहुत ही सरल समाधान कर रहे हैं।

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

चलती वस्तुओं के लिए अधिकतम गति निर्धारित करना हमेशा ऐसा होना चाहिए जो हमेशा किया जाना चाहिए। आप खेल के दौरान एक महत्वपूर्ण वस्तु skyrocket होने का जोखिम नहीं उठा सकते हैं और सब कुछ एक अनियंत्रित राज्य में छोड़ दें।

Answer 2

यह एक पूर्ण उत्तर नहीं है, लेकिन मुझे धीमे मशीनों पर कई साल पहले इस तरह की समस्या से निपटना याद है।

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

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

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

Answer 3

मुझे लगता है कि क्या हो रहा है यह है कि प्रत्येक अंतराल जो गेंद/रैकेट होता है उसे स्थानांतरित किया जाता है और फिर टकराव के लिए चेक किया जाता है। मुद्दा यह है कि गेंद/रैकेट एक ही अंतराल में दूर तक चले जाते हैं और टक्कर से चूक जाते हैं।

1) Ball before racquet 
2) Ball after racquet 

not 

1) Ball before racquet 
2) Ball touching racquet 

तो तुम क्या करना है पिछले गेंद स्थान के लिए वर्तमान गेंद स्थान से एक किरण डाली है अपने FixedUpdate() अपने गेंद GameObject की विधि में है। यदि उन दो बिंदुओं के बीच कुछ भी है जो हिट होना चाहिए (यानी रैकेट) गेंद को गेंद पर रिपोर्ट किए गए हिट पॉइंट पर वापस ले जाएं। यह आपकी मौजूदा टक्कर पहचान सामग्री को ट्रिगर करेगा।

कोलाइडर के आकार के आकार में वृद्धि का कारण यह भी है क्योंकि गेंद लेजर कोलाइडर को छोड़ नहीं रही है। आपके प्रश्न में आपके द्वारा उल्लिखित दोषों में यह कमी है। रे कास्टिंग इस मुद्दे से बचाता है और गेंद/रैकेट को तेज़ या धीमी गति से आगे बढ़ने की इजाजत देता है।

Answer 4

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