किसी गेम में टकराव का पता लगाने के लिए octree का उपयोग करते समय, क्या पेड़ को हर फ्रेम का पुनर्निर्माण किया जाना चाहिए या क्या आधे ऑब्जेक्ट्स फ्रेम में स्थानांतरित होने का एक बेहतर तरीका है?क्या एक ऑक्टेट हर फ्रेम का पुनर्निर्माण किया जाना चाहिए?
यदि दृश्य प्रत्येक फ्रेम के साथ बदलता है, तो आपको पेड़ को फिर से करना होगा।
यदि आपके दृश्यों में बहुत सी स्थैतिक ज्यामिति है, तो अलग ऑक्टेट बनाने पर विचार करें। आप स्थिर और गैर स्थैतिक ज्यामिति के बीच अंतर करने वाले अधिक जटिल पत्ते नोड्स के साथ एक ही विचार व्यक्त कर सकते हैं।
नीचे पंक्ति: केवल आपके पास क्या पुन: उत्पन्न होती है।
यदि आपके पास प्रत्येक फ्रेम को बहुत गतिशील डेटा चलाना है और अभी भी टक्कर का पता लगाने में तेजी लाने की आवश्यकता है, तो मैं वास्तव में इसके लिए एक निश्चित 3 डी ग्रिड का उपयोग करने की सलाह देता हूं। 2-आयामी बराबर:
यह भी एक नि: शुल्क सूची के रूप में में दोगुनी निरंतर समय निकालने की प्रक्रिया की अनुमति के लिए, की तरह तो (एक ही ग्रिड सेल में अगले तत्व या तो एक सूचकांक के रूप में next सूचकांक का उपयोग कर सकते हैं या मुफ्त ढेर से दूर पॉप करने के लिए अगले मुक्त तत्व अगर यह हटा दिया गया है):
एक और उदाहरण:
अब 3 आयामों में, ऐसा लगता है कि इसे विस्फोटक स्मृति की आवश्यकता होगी। हालांकि, यह चाल सिर्फ प्रत्येक सेल को 32-बिट इंडेक्स को सरणी में स्टोर करना है और मूल रूप से एकल-लिंक्ड इंडेक्स सूची के रूप में कार्य करना है। इससे प्रत्येक सेल का आकार 32-बिट तक कम हो जाता है। अब यदि आप 100x100x100 ग्रिड (1 मिलियन सेल्स) स्टोर करते हैं, तो इसमें 4 मेगाबाइट से कम लेना होगा।
जब तत्व चारों ओर घूमते हैं, तो आप उन्हें उन कोशिकाओं से हटा सकते हैं जिन्हें वे कब्जा करते हैं, उन्हें ले जाते हैं, और उन्हें नई कोशिकाओं में डालें। ऐसा करने के लिए आपको बस इतना करना है कि कुछ 32-बिट इंडेक्स (कोशिकाओं के एक सेट से दूसरों के लिए तत्वों को स्थानांतरित करने के लिए कोई स्मृति आवंटन/अस्वीकरण नहीं) का उपयोग करें। यह सभी निरंतर समय है और इसमें पेड़ या विभाजन करने वाले ऑक्टों को पुनर्व्यवस्थित करने की आवश्यकता नहीं होती है जो बहुत भीड़ या ऐसा कुछ भी बन जाते हैं।
आप ग्रिड के पदानुक्रम का भी उपयोग कर सकते हैं (यह एक ऑक्टेट की तरह लग सकता है लेकिन अलग)। मेरा मतलब यह है कि आपके दृश्य में पूरे जाल वस्तुओं के लिए आपके पास एक मोटे ग्रिड हो सकता है। फिर प्रत्येक जाल वस्तु अपने प्रत्येक हिस्से के लिए एक मोटे ग्रिड को स्टोर कर सकती है, कहें, 10x10x10। फिर प्रत्येक भाग अपने प्रत्येक बहुभुज के लिए एक अच्छी ग्रिड या ऑक्टेट स्टोर करता है। यह उन गैर-कार्बनिक मेषों को अनुमति देता है, जो कि बहुभुज के ठीक ग्रिड/ऑक्टेट्री को अद्यतन करने से बचने के लिए रोबोट की तरह घूर्णन कर रहे हिस्सों के साथ कठोर हैं और केवल अपने स्वयं के मोटे ग्रिड को हिस्सों और विश्व वस्तुओं के मोटे ग्रिड को अपडेट करते हैं यह अपने पैरों और बाहों को घूमना शुरू करता है, उदाहरण के लिए केवल जैविक मॉडलों को उनकी अच्छी ग्रिड को अपडेट करने की आवश्यकता होती है जब वे हड्डियों से विकृत हो जाते हैं, उदा।
octree मैं आपके पूरी तरह से स्थिर तत्वों/भागों के लिए रखता हूं जिन्हें प्रति फ्रेम को अद्यतन करने की आवश्यकता नहीं होती है और मैं कैश-फ्रेंडली मेमोरी एक्सेस के लिए कुछ पोस्ट-प्रोसेसिंग के साथ एक अच्छा ऑक्टेट्री का उपयोग करता हूं। उन लोगों में खोजों को तेज़ करने के लिए आपके पास थोड़ा और समय उपलब्ध है और उनके मेमोरी उपयोग को कम करें यदि आप यह मान सकते हैं कि ऑक्टेट्री को इसे बनाए जाने के बाद अद्यतन करने की आवश्यकता नहीं है।
यदि दृश्य प्रत्येक फ्रेम के साथ बदलता है, तो आपको पेड़ को अपडेट करना होगा। पूरे पेड़ को "फिर से" करना हमेशा जरूरी नहीं है। जब वस्तुएं बढ़ती हैं तो मेरा स्वयं का कार्यान्वयन आवश्यकतानुसार अपडेट हो सकता है।मौसम जो आप कर सकते हैं या नहीं, इस पर निर्भर करता है कि आप इसे कैसे कार्यान्वित करते हैं। – phkahler
redo == अपडेट; मैं उन्हें समानार्थी मानता हूं। लेकिन आपका बिंदु सही है - यह लगभग है कि आपको बदले गए टुकड़ों को चिह्नित करने के लिए एक गंदे झंडे की आवश्यकता होगी। – duffymo