स्पष्ट बताने के जोखिम पर, लेकिन क्या आपने threeocttree के संस्करण की कोशिश की है जो पहले से ही रेपो ( उदाहरण/js/Octree.js ) में है?

मैं three.js में स्थानिक खोज ट्री के हार्ड-वायर्ड उपयोग के लिए वोट नहीं करता। इस तरह के एल्गोरिदम की ओवरहेड/जटिलता कई अनुप्रयोगों में प्रदर्शन लाभ को बढ़ा देती है।

वास्तविक रेकास्ट करने से पहले बाउंडिंग बॉक्स और गोले की जाँच करना

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

नमस्ते और आपके उत्तरों के लिए धन्यवाद,
@ Mugen87 मैं मानता हूं कि कई उपयोग के मामलों में इतनी तेज खोजों की आवश्यकता नहीं होती है। हालाँकि, 3D वस्तुओं के साथ बातचीत करने के लिए एक तंत्र होना (और मुझे लगता है कि यही वह मामला है जिसके लिए इसका ज्यादातर उपयोग किया जाता है), THREE.Raycaster पहले बाउंडिंग बॉक्स/क्षेत्र की जाँच से कदम (जो मैं पूरी तरह से उचित होने के लिए सहमत हूँ) ) मान लें कि वास्तविक रेकास्ट करते समय एक रैखिक समय प्रयास के लिए निरंतर समय काफी बड़ा होता है। मैं एक वैश्विक खोज पेड़ के बजाय "प्रति-ज्यामिति-खोज पेड़" की कल्पना कर सकता था। जब तक ज्यामिति नहीं बदलती (कई बार परिवर्तन ज्यामिति परिवर्तनों की तुलना में बहुत अधिक होने की संभावना होती है) खोज ट्री को अद्यतन करने की आवश्यकता नहीं होती है।

इसलिए मैंने सोचा, स्थानिक खोज ट्री का उपयोग करके इस प्रकार का अनुकूलन three.js का अधिक अभिन्न अंग हो सकता है। लेकिन मैं यह भी समझता हूं कि यह अतिरिक्त जटिलता और उपरि का कारण बनता है।

@moraxy मैं उदाहरण संस्करण पर एक नज़र डालेगा। मैं सिर्फ यह जानना चाहता था कि क्या ऐसी सुविधा का कोई मतलब होगा।

पुनः धन्यवाद एवं सादर प्रणाम

हो सकता है कि एक सरल खोज ट्री को THREE.BufferGeometry में एकीकृत किया जा सके। उदाहरण के लिए computeBoundingBox पर कॉल करने से एक प्रकार का केवल-पढ़ने के लिए खोज ट्री भी बन सकता है जो संबंधित शीर्षों को संदर्भित करता है। चूंकि THREE.BufferGeometry है

स्थैतिक वस्तुओं के लिए सबसे उपयुक्त है जहाँ आपको ज्यामिति को तत्काल करने के बाद बहुत अधिक हेरफेर करने की आवश्यकता नहीं है

इस सर्च ट्री को इनिशियलाइज़ करने के बाद बदलने की जरूरत नहीं है। यह अद्यतन/हटाने के लिए कुछ ओवरहेड को कम करेगा। एक ऑक्ट्री एक अच्छा प्रारंभिक बिंदु होगा ( बेबीलोनजेएस में समान अवधारणा )।

स्थैतिक वस्तुओं के लिए सबसे उपयुक्त है जहाँ आपको ज्यामिति को तत्काल करने के बाद बहुत अधिक हेरफेर करने की आवश्यकता नहीं है

एफडब्ल्यूआईडब्ल्यू, मुझे विश्वास नहीं है कि यह एक सत्य कथन है।

@WestLangley उद्धरण THREE.BufferGeometry प्रलेखन से

तीन.बफ़र ज्यामिति दस्तावेज़ीकरण

इसे शायद हटा दिया जाना चाहिए - किसी भी मामले में, मुझे नहीं लगता कि इसका मतलब किसी भी प्रकार के तकनीकी कथन के रूप में है, बल्कि इसका मतलब है कि उपयोगकर्ता के लिए ज्यामिति में हेरफेर करने के बाद इसे बनाना मुश्किल है।

इसे शायद हटा दिया जाना चाहिए

सबसे निश्चित रूप से।

मैंने अभी PlaneBufferGeometry पर रेकास्टिंग के लिए एक बेहतर तरीका लागू किया है। मैं दूर पैरामीटर का उपयोग करता हूं और पहली और आखिरी इंडेक्स स्थिति ढूंढता हूं। यह प्लेनबफर में काम करता है क्योंकि सूचकांक सरणी x/y क्रम में है। एक बार एक्स/वाई बाउंडिंग बॉक्स के बाहर सभी टकराव दूर सीमा से बाहर होना चाहिए। कहीं ऐसा करने की कोई इच्छा तो नहीं है? वर्तमान कार्यान्वयन मेरे उपयोग के मामले के लिए विशिष्ट है लेकिन अगर वांछित है तो मैं कोशिश करने और अधिक सामान्य बनाने के लिए तैयार हूं। मैं एक बड़े विमान बफर (2.5 सेकंड से 10ms) पर अपने रेकास्टिंग प्रदर्शन को काफी कम करने में सक्षम था।

@kpetrow मुझे लगता है कि तीन.जेएस ऑक्ट्री उदाहरण पर्याप्त हैं। आप निश्चित रूप से GitHub पर अपना कोड साझा करने के लिए स्वतंत्र हैं यदि आपको लगता है कि यह दूसरों के लिए उपयोगी होगा।

मैंने अतीत में स्थानिक सूचकांक को तीनjs में शामिल करने का सुझाव दिया है। इस दिशा में कुछ काम हुए हैं, और मौजूदा ऑक्टा-ट्री उदाहरण उनमें से एक है। अंततः, मुझे लगता है कि तीन में प्रथम श्रेणी के नागरिक के रूप में इस कार्यक्षमता के संबंध में मूल समुदाय से रुचि की कमी है।

मुझे परियोजना के लिए अपना बीवीएच कोड दान करने में खुशी होगी, अगर पर्याप्त रुचि और इसे मुख्य वितरण में शामिल करने का इरादा है (उदाहरण नहीं)।
मेरा कोड 2 पहलुओं पर केंद्रित है:

• गतिशील दृश्य
  
  
  
  • तेजी से डालें
  
  
  • तेजी से हटाना
  
  
  • रीफिटिंग (नोड्स को फिर से डाले बिना आकार बदलने की क्षमता)
  
  
• क्वेरी गति

मेरे पास 2 कार्यान्वयन हैं:

• बाइनरीबीवीएच
  
  
  
  • बाइटबफर का उपयोग करके बहुत कॉम्पैक्ट
  
  
  • DataView के माध्यम से UintX और FloatX प्रकारों का मिश्रण
  
  
  • क्रमांकन के लिए बढ़िया
  
  
  • lzma लाइब्रेरी जैसे मानक उपकरणों का उपयोग करके संपीड़ित किया जा सकता है
  
  
  • अडिग
  
  
  • निर्माण गति अत्यधिक अनुकूलित है
  
  
  • केवल BufferGeometry के लिए काम करता है
  
  
  • एसएएच अनुकूलन
  
  
  • किरण प्रश्न
  
  
• बीवीएच
  
  
  
  • ऑब्जेक्ट ट्री, परिणामस्वरूप बाइनरी कार्यान्वयन से बहुत बड़ा है
  
  
  • परिवर्तनशील
  
  
  • फास्ट बल्क इंसर्ट
  
  
  • फास्ट सिंगल आइटम इंसर्ट
  
  
  • साजोसामान
  
  
  • स्टैक, रिकर्सिव और स्टैक-कम ट्रैवर्सल कार्यान्वयन (विभिन्न प्रदर्शन विशेषताओं)
  
  
  • एसएएच अनुकूलन
  
  
  • कुंठा संबंधी प्रश्न
  
  
  • रे प्रश्न
  
  

व्यक्तिगत रूप से, मैं एक स्थानिक सूचकांक के बिना नहीं रह सकता, यह n ^ 2 और लॉग (n) प्रदर्शन के बीच का अंतर है। उदाहरण के लिए, मेरी वर्तमान परियोजना में निम्नलिखित भाग स्थानिक सूचकांक पर निर्भर करते हैं:

• पर्ण प्रणाली (पेड़, फूल, झाड़ियाँ आदि)
• सभी ऑब्जेक्ट प्लेसमेंट (अक्षर और घर)
• पिकिंग (इंटरैक्शन में प्रयुक्त, जैसे माउस क्लिक)

http://server1.lazy-kitty.com/komrade

इलाके में लगभग 1 मी बहुभुज हैं, और हजारों पेड़ लगाना और उस पर रीयल-टाइम रे-कास्ट चलाना केवल एक नो-गो है, खासकर निचले-छोर वाले उपकरणों के लिए।

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

एक बात जो मैंने नोटिस की है, वह यह है कि एक बार ज्यामिति को अनुक्रमित बफर सरणी में बदल दिया जाता है, यह अब मूल ज्यामिति के गुणों का स्मार्ट तरीके से उपयोग नहीं करता है। जैसा कि ऊपर बताया गया है कि प्लेन बफर ज्योमेट्री को यह जानकर सुपर ऑप्टिमाइज़ किया जा सकता है कि एरेबफ़र प्लेनगोमेट्री से आया है। हो सकता है कि MESH.raycast ( raycaster, intersects ) विधि को ज्यामिति प्रकार के आधार पर अधिलेखित कर दिया जाए?

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

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

• स्थानिक कलिंग (फ्रस्टम कलिंग सोचें)
• दृश्यता प्रश्न करना
• पथ अनुरेखण रेंडरर का निर्माण
• तेजी से छँटाई (डेटा इलाके का शोषण)

वर्तमान में तीन.js इनमें से 2 स्पष्ट रूप से (सॉर्टिंग और कलिंग) करता है और 1 उदाहरणों के माध्यम से (रे-ट्रेसिंग रेंडरर)

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

आप सिर्फ GPU पिकिंग का उपयोग क्यों नहीं करते? आसपास कुछ उदाहरण हैं और इसे लागू करना काफी आसान है। प्रदर्शन रात और दिन है। हमारे उपयोग के मामलों में, एक मिलियन से अधिक पॉलीगॉन के मॉडल के साथ, मॉडल के ऊपर चीजों को खींचते समय पिकिंग लगभग एक सेकंड से 60fps पर रीयलटाइम में चलने के लिए चला गया।

https://github.com/brianxu/GPUPicker

@hccampos
जीपीयू पिकिंग जरूरी नहीं कि सीपीयू पर करने से तेज हो, जीपीयू के लिए आपको अपनी इच्छा के अनुसार आनुपातिक रूप से रिज़ॉल्यूशन पर रेंडर करना होगा, इसलिए यदि आप पिक्सेल सटीकता चाहते हैं - तो आपको 1: 1 स्क्रीन रिज़ॉल्यूशन पर रेंडर करना होगा। ध्यान रखें कि यह एक अलग रेंडर पास है, आप वस्तुओं को अलग अलग रंगों के रूप में प्रस्तुत कर रहे हैं। एक अतिरिक्त रेंडर पास का अर्थ है ग्राफिक्स मेमोरी उपयोग (आस्थगित पाइपलाइन के लिए विशिष्ट)।
बाइनरी स्पेस पार्टीशनिंग इंडेक्स का उपयोग करने से आपको अपनी पिकिंग पर लॉग (एन) टाइमिंग प्रोफाइल मिलती है, इसलिए 1,000,000 पॉलीगॉन के लिए आप रे क्वेरी को हल करने के लिए लगभग 14 ऑपरेशन देख रहे होंगे। आपकी डेटा संरचना के आधार पर - इसमें कुछ माइक्रोसेकंड लगने की संभावना है, जिससे आप अपने फ्रेम बजट में सेंध लगाने से पहले हजारों प्रश्नों की अनुमति दे सकते हैं।

आइए तुलना करें, मान लें कि आपके पास 1m पॉली मॉडल है, और आप स्क्रीन स्पेस से सीधे कैमरे की दिशा के साथ दृश्य में एक किरण डालना चाहते हैं (उपयोग-मामला चुनना)। आइए मान लें कि आप बैरल रिज़ॉल्यूशन के निचले भाग, "पूर्ण एचडी", या 1920 × 1080 के साथ जा रहे हैं। मान लें कि आप केवल आरजीबी (24 बिट प्रति पिक्सेल) प्रस्तुत करते हैं, आपको रेंडर करने के लिए 6220800बाइट (लगभग 6 एमबी) या ग्राफिक्स रैम की आवश्यकता होगी। वह। यदि आप CPU समाधान का उपयोग करते हैं, तो मान लें कि आप AABB BVH के साथ 10 पॉलीगॉन प्रति पत्ती के साथ जाते हैं, इसका मतलब है कि आपको लगभग 200,000 नोड्स की आवश्यकता है, मान लें कि प्रत्येक नोड निर्देशांक के लिए लगभग 6 * 8bytes है, इंटरमीडिएट नोड्स में चाइल्ड पॉइंटर्स के लिए अतिरिक्त 2 * 4 बाइट्स हैं। और लीफ नोड्स में पॉलीगॉन पॉइंटर के लिए 10 * 4 बाइट्स हैं, जो कि 14,400,000 बाइट्स (लगभग 14Mb) हैं। मुख्य अंतर तब सामने आता है जब आप इस तथ्य पर विचार करते हैं कि GPU केस की तुलना में आपके BVH प्रश्नों की RAM बैंडविड्थ पर बहुत कम मांग है, और पूर्ण 1m पॉली ज्योमेट्री प्रदान करने की तुलना में प्रति क्वेरी केवल कुछ मुट्ठी भर ऑपरेशन शामिल हैं।
यदि आप 2560x1440 जैसे डेस्कटॉप के लिए अधिक विशिष्ट संकल्प लेते हैं, तो आप 11059200बाइट रेंडर लक्ष्य (11Mb) के साथ समाप्त होते हैं।

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

@Usnul बिल्कुल, लेकिन यह शायद लागू करने का सबसे आसान समाधान है। स्थानिक सूचकांक डेटा संरचनाओं को लागू करना और बनाए रखना संभवतः थ्रीजे अनुरक्षकों के लिए एक गैर-महत्वपूर्ण बोझ होगा।

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

मैं अपने इस्तेमाल किए गए ज्यामिति के लिए इस तरह के एक स्थानिक सूचकांक को लागू करने के बारे में उत्सुक था, इसलिए मैंने एक बहुत ही सरल ऑक्ट्री (केवल बनाएं और खोजें) को लागू किया जो मेरी बफरजीओमेट्री को विभाजित करता है। इस सरल समाधान के साथ मैंने काफी आशाजनक परिणाम प्राप्त किए: लगभग 500K कोने के साथ एक ज्यामिति पर लागू किया गया, जिससे रेकास्ट का समय ~ 120ms से ~ 2.3ms तक कम हो गया। पेड़ के निर्माण में वर्तमान में ~ 500ms लगते हैं, लेकिन चूंकि एक वेब कार्यकर्ता के अंदर ज्यामिति और वृक्ष निर्माण केवल एक बार आवेदन शुरू होने पर किया जाता है, यह ऐसी कोई समस्या नहीं है।

मुझे लगता है कि एल्गोरिदम को THREE.BufferGeometry में आसानी से एकीकृत किया जा सकता है और शायद THREE.BufferAttribute के dynamic जैसे ध्वज का उपयोग करके चालू या बंद किया जा सकता है। इस तरह, इसका उपयोग केवल तभी किया जा सकता है जब BufferGeometry को बदलना नहीं चाहिए। दुर्भाग्य से, मुझे THREE.Mesh की raycast विधि को अधिलेखित करना पड़ा, हालांकि मुझे इसमें केवल दो पंक्तियों को बदलने की आवश्यकता थी (ऑक्ट्री खोज कॉल और स्थिति सरणी पुनरावृत्ति)।

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

अद्यतन करें मैंने रेकास्ट समय को मापने में गलती की है। सही मान ~2.3ms (~0.3ms के बजाय) है। मैंने उपरोक्त मान को तदनुसार बदल दिया।

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

@ मैथियास-डब्ल्यू मैंने एक ओबीजे मॉडल के लिए रेकास्टर की कोशिश की लेकिन नियंत्रक कुछ भी पता नहीं लगा रहा है। किरणें मॉडल से गुजर रही हैं। क्या आप मुझे बता सकते हैं कि आपने उस समस्या को कैसे ठीक किया

वैकल्पिक स्थानिक सूचकांक रखने के विषय पर। मेरा मानना ​​है कि यह रेंडरर के लिए भी पर्याप्त रूप से उपयोगी है (जैसे: कलिंग के लिए) इंजन का एक अभिन्न अंग होना। यहाँ एक संबंधित चर्चा है:

13909

अरे! मुझे इसमें थोड़ी दिलचस्पी थी, साथ ही (हालांकि मुझे तब से हमारी रेकास्ट जरूरतों के लिए अन्य समाधान मिल गए हैं), लेकिन मुझे लगा कि मैं अपने कुछ प्रयोगों में भी योगदान दूंगा। यह थोड़ा मोटा है, लेकिन मैंने इसे कुछ महीने पहले एक साथ रखा था:

https://github.com/gkjohnson/threejs-fast-raycast

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

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

@Usnul @matthias-w क्या आपके ऑक्ट्री/बीवीएच कार्यान्वयन में से कोई एक खुला स्रोत है या ऑनलाइन उपलब्ध है? मुझे निश्चित रूप से एक नज़र डालने में दिलचस्पी होगी!

@gkjohnson

क्या आपका कोई ऑक्ट्री/बीवीएच कार्यान्वयन खुला स्रोत है या ऑनलाइन उपलब्ध है? मुझे निश्चित रूप से एक नज़र डालने में दिलचस्पी होगी!

कोड वर्तमान में खुला स्रोत नहीं है। यदि आप मुझसे निजी तौर पर संपर्क करते हैं तो मैं आपको स्रोत प्रदान कर सकता हूं।

उदाहरण के लिए मैंने एक उदाहरण दिया है:
http://server1.lazy-kitty.com/tests/instanced-foliage-1mil/
उपरोक्त उदाहरण में निम्नलिखित शामिल हैं:

• BVH को गतिशील रूप से अपडेट किया जाता है क्योंकि ट्री में नए इंस्टेंस डाले जाते हैं
• BVH को मक्खी पर 1-2 घुमावों की गहराई का उपयोग करके क्रमिक रूप से अनुकूलित किया गया है
• BVH को एक फ्रस्टम क्वेरी के साथ सैंपल किया जाता है, जिसमें इंस्टेंस को रेंडर करना होता है

मेरे पास इसका एक संस्करण है जो उस गेम में चल रहा है जिस पर मैं काम कर रहा हूं:
http://server1.lazy-kitty.com/komrade/

आपके कार्यान्वयन के संबंध में। मुझे यह पसंद है, मेरा 2 प्रमुख तरीकों से अलग है:

• मैं प्रदर्शन पर ध्यान केंद्रित करता हूं
• मैं स्मृति पदचिह्न पर ध्यान केंद्रित करता हूं
• मैं कई जगहों पर कूड़ा उठाने से बचता हूं

कुछ और विशिष्ट बिंदु:

• आप बीवीएच के साथ क्या करना चाहते हैं, इसके आधार पर मैं पारदर्शी तरीके से बंटवारे की रणनीतियों के मिश्रण का भी उपयोग करता हूं
• मेरा बीवीएच एएबीबी आधारित है
• मैं रीफिटिंग के माध्यम से नोड सीमाओं के अपडेट का समर्थन करता हूं

@Usnul मैं आपका ईमेल पता या कुछ भी नहीं देख सकता, लेकिन मुझे आपके स्थानिक अनुक्रमण समाधान का अध्ययन करने में काफी दिलचस्पी है।

वर्तमान में मैं सिर्फ सभी प्रासंगिक दृश्य वस्तुओं के माध्यम से लूप करता हूं और कैमरे से दूरी की गणना करता हूं। सबसे इष्टतम तरीका नहीं है।

@titansofttime
यह है
travnick at gmail com
यह नहीं पता था कि यह सार्वजनिक रूप से उपलब्ध नहीं है। मेरी गलती।

@ उस्नुल मुझे 1 मिलियन प्रोजेक्ट में भी दिलचस्पी है। हो सके तो 10 या 20 करोड़ भी। कृपया मुझे ईमेल करें: kaori.nakamoto। [email protected]

बहुत-बहुत धन्यवाद!

http://server1.lazy-kitty.com/tests/instanced-foliage-10mil/
यह 10 मिलियन वाला संस्करण है

देरी से जवाब देने के लिए माफी।
@gkjohnson कोड खुला स्रोत नहीं है। इसके अतिरिक्त, आपका समाधान मेरे से कहीं अधिक परिष्कृत लगता है। इस प्रकार, मुझे लगता है कि मेरे समाधान से सीखने के लिए बहुत कुछ नहीं है।

@ sid3007 मुझे यकीन नहीं है कि मैं आपकी समस्या को समझता हूं। मैं अपने दृष्टिकोण की व्याख्या कर सकता हूं। शायद यह मददगार है।

मेरा उपयोग मामला काफी सरल है। जब मेरा आवेदन शुरू होता है, तो विभिन्न मॉडलों के लिए ज्यामिति लोड हो जाती हैं। इन मॉडलों को उपयोगकर्ता द्वारा रूपांतरित किया जा सकता है। ज्यामिति नहीं बदलती है। कोई ज्यामिति विकृति नहीं हैं। इसलिए, मैंने एक बहुत ही सरल ऑक्ट्री लागू किया जो कि एप्लिकेशन शुरू होने पर प्रत्येक ज्यामिति के लिए एक बार बनाया जाता है। ऑक्ट्री गतिशील नहीं है। यह दी गई ज्यामिति के बाउंडिंग बॉक्स और शीर्षों की सरणी के आधार पर बनाया गया है। इसके निर्माण के दौरान यह जांचता है कि क्या ऑक्टेंट में एक शीर्ष है या ऑक्टेंट का Box3 बाउंडिंग बॉक्स एक त्रिभुज (गैर-अनुक्रमित ज्यामिति में लगातार तीन कोने) के साथ प्रतिच्छेद करता है और ऑक्ट्री के नोड के साथ शीर्ष सरणी संदर्भों को संग्रहीत करता है।
प्रति जाल ऑक्ट्री तब जाल के साथ जमा हो जाती है। मैं वास्तव में ऑक्ट्री चौराहे परीक्षण विधि को कॉल करने के लिए अपने जाल उदाहरणों' THREE.Mesh की raycast विधि (सिर्फ एक पंक्ति) को भी अधिलेखित कर देता हूं। यह ज्यामिति का सामना करता है जो शीर्ष सूचकांकों का सामना करता है जिसका उपयोग जाल के डिफ़ॉल्ट चौराहे तर्क द्वारा किया जा सकता है।
मैंने एक अनुकूलन किया: ऑक्ट्री निर्माण एक बार वेबवर्कर (वास्तव में श्रमिकों का एक पूल) के अंदर ऐप शुरू होने पर किया जाता है। इसका कारण यह है कि बड़ी ज्यामिति के लिए वृक्ष निर्माण में काफी समय (कुछ सेकंड) लगता है। यह ब्राउज़र UI को ब्लॉक कर देगा इसलिए मैंने इसे दूसरे थ्रेड में स्थानांतरित कर दिया।
मुझे आशा है कि मेरा दृष्टिकोण स्पष्ट हो जाएगा।

@ मथायस-डब्ल्यू बहुत अच्छा काम लगता है! मैंने स्वतंत्र रूप से लगभग ऐसा ही किया, लेकिन मुझे नहीं लगता कि मैंने प्रदर्शन में लगभग उतना ही बड़ा सुधार किया है। https://discourse.threejs.org/t/octree-injection-for-faster-raytracing/8291/2 (वस्तु-उन्मुख ऑक्ट्री कार्यान्वयन, और Mesh.raycast में कम साफ संशोधन)

क्या आपके लिए ऑक्ट्री कार्यान्वयन को ओपन-सोर्स/योगदान देना संभव होगा, जिससे दूसरों द्वारा अधिक प्रयोग किए जा सकें?

@EliasHasle धन्यवाद। वास्तव में, प्रदर्शन लाभ उतना अच्छा नहीं है, क्योंकि मैंने अपने पहले उपायों में गलती की थी। मैंने मूल्य को सही किया (ऊपर मेरी पोस्ट देखें)। ऑक्ट्री की लॉगरिदमिक खोज जटिलता के संबंध में समय अब ​​अधिक समझ में आता है। दुर्भाग्य से, मैं इस समय कोड उपलब्ध नहीं करा सकता, लेकिन शायद इस वर्ष के अंत में। वैसे भी, मेरा कार्यान्वयन काफी सीधा है (और वह साफ BTW नहीं है;))। इसलिए मुझे लगता है कि कोई विशेष अंतर्दृष्टि नहीं होगी।

@ मैथियास-डब्ल्यू मुझे लगता है कि 500k वर्टेक्स जाल पर एक रेकास्ट के लिए 2.3 एमएस बनाम 120 एमएस अभी भी एक महत्वपूर्ण सुधार है, उदाहरण के लिए, गेम में फायर की गई गोलियों के रीयल-टाइम रिज़ॉल्यूशन को सक्षम बनाता है (गणना के काफी बड़े हिस्से पर) प्रति फ्रेम बजट)।

क्या आपने भी पुन: अनुरेखण की कोशिश की?

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

@EliasHasle

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

निर्माण समय में कुछ अलग तरीकों से सुधार किया जा सकता है, लेकिन मैं इसके साथ जो करना चाहता था उसके लिए यह काफी अच्छा रहा है - हालांकि सूची में सुधार करना है।

मैं बहुत सारे मेश वाले दृश्यों के लिए बेहतर रेकास्टिंग और टक्कर का पता लगाने में सक्षम करने के लिए एक गतिशील दृश्य-आधारित ऑक्ट्री बनाना चाहता हूं, लेकिन मेरे पास स्वयं एक अच्छा उपयोग केस नहीं है। शायद किसी दिन!

@EliasHasle मेरा कार्यान्वयन JS क्लास ऑब्जेक्ट्स का एक ट्री है (मैं ES6 क्लासेस, यानी प्रोटोटाइप इंस्टेंस का उपयोग करता हूं)। मूल रूप से, मेरे कार्यान्वयन में एक नोड एक पेड़ है। हालांकि, मेरे पास एक अतिरिक्त ऑक्ट्री क्लास है जो रूट नोड रखती है और पेड़ के निर्माण और खोज (और कुछ डिबगिंग और विज़ुअलाइज़ेशन) के तरीकों को प्रदान करती है।

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

मैं एक ऐसी पुस्तक की सिफारिश कर सकता हूं जो टक्कर का पता लगाने के दृष्टिकोणों का एक बहुत अच्छा संग्रह है: सी एरिक्सन, रीयल-टाइम कोलिजन डिटेक्शन, सीआरसी प्रेस, 2004

@gkjohnson यह बहुत अच्छा लग रहा है! प्रदर्शन प्रभावशाली है। आप किस प्रकार के बीवीएच का उपयोग कर रहे हैं?

@ मथायस-डब्ल्यू धन्यवाद!

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

@gkjohnson तो फिर बीवीएच कार्यान्वयन एक प्रकार का असंतुलित केडी-पेड़ है जिसमें धुरी चयन बॉक्स आकार पर निर्भर है, है ना? यदि ऐसा है, तो मैं ऐसा कुछ करने के बारे में सोच रहा था जहां रूट बीबी घन से बहुत दूर था, और फिर सशर्त विभाजन के बाद ऑक्टेट का उपयोग कर रहा था। यह संभवतः @Usnul के मानचित्र की दुनिया जैसे मामलों पर अच्छी तरह से लागू होगा, जहां प्रारंभिक विभाजन दो "मानचित्र" आयामों में होगा और बाद में विभाजन 3D में आगे बढ़ेगा। मुझे लगता है कि यह मेरी तुलना में एक बेहतर समाधान है, जो रूट बीबी को एक ही केंद्र के साथ एक बाउंडिंग क्यूब में विस्तारित करना है, और फिर सभी तरह से ऑक्ट्री स्प्लिटिंग का उपयोग करना है।

मैंने अभी PlaneBufferGeometry पर रेकास्टिंग के लिए एक बेहतर तरीका लागू किया है।

@kpetrow मुझे लगता है कि PlaneBufferGeometry पर रेकास्ट को अनुकूलित करना, यह धारणा कि शीर्ष पदों में बदलाव नहीं किया जाएगा, उच्च-रिज़ॉल्यूशन ज्यामिति के लिए मान्य नहीं होगा जहां एक रैखिक खोज अपर्याप्त है। जहां तक ​​​​मैं बता सकता हूं, उच्च-रिज़ॉल्यूशन PlaneBufferGeometry का मुख्य उपयोग टोपोलॉजी को बनाए रखते हुए, जैसे कि इलाके का निर्माण करने के लिए, कोने को स्थानांतरित करके इसे फिर से आकार देना है।

#13909 के पक्ष में समापन।