Three.js: गैर-अवरुद्ध संपत्ति लोडर

आपके पास एक वादा + कार्यकर्ता + वृद्धिशील आधारित लोडर हो सकता है (दोनों बिंदुओं के मिश्रण की तरह थोड़ा सा)

स्रोत URL को कार्यकर्ता स्क्रिप्ट में पास करें, संसाधन प्राप्त करें, आवश्यक बफ़र्स, स्ट्रक्चर्स, यहां तक ​​कि ImageBitmaps के साथ हस्तांतरणीय वस्तुओं की एक संरचना लौटाएं; यह इतना सीधा होना चाहिए कि ओवरहेड प्रोसेसिंग के लिए बहुत सारे तीन.जेएस की आवश्यकता न हो।

GPU पर अपलोड डेटा भले ही अवरुद्ध हो जाएगा, लेकिन आप display.rAF के माध्यम से कमांड को विभिन्न फ़्रेमों में वितरित करने के लिए एक कतार बना सकते हैं। आदेशों को प्रति फ्रेम एक समय में निष्पादित किया जा सकता है, या ऑपरेशन के औसत समय की गणना कर सकते हैं और वर्तमान फ्रेम बज में चलाने के लिए "सुरक्षित" चल सकते हैं (अनुरोध के समान कुछ IdleCallback अच्छा होगा, लेकिन यह व्यापक रूप से समर्थित नहीं है , और यह WebVR सत्रों में समस्याग्रस्त है)। बफ़रसबडाटा, टेक्ससबइमेज2डी, आदि का उपयोग करके भी सुधार किया जा सकता है।

श्रमिकों और हस्तांतरणीय वस्तुओं के लिए समर्थन अभी बहुत ठोस है, विशेष रूप से वेबवीआर सक्षम ब्राउज़रों में।

हाय सब, मेरे पास एक प्रोटोटाइप उपलब्ध है जो इस संदर्भ में आपकी रुचि का हो सकता है। निम्नलिखित शाखा देखें:
https://github.com/kaisalmen/WWOBJLoader/tree/Commons
यहाँ के मेश प्रोविज़निंग भाग को WWOBJLoader2 से पूरी तरह से अलग कर दिया गया है:
https://github.com/kaisalmen/WWOBJLoader/blob/Commons/src/loaders/WWLoaderCommons.js

WWLoaderCommons अन्य जाल प्रदाताओं (फ़ाइल प्रारूप लोडर) को लागू करना आसान बनाता है। मूल रूप से, यह परिभाषित करता है कि कैसे एक वेब कार्यकर्ता कार्यान्वयन को मुख्य धागे में वापस जाल डेटा प्रदान करना है और इसे दृश्य में संसाधित/एकीकृत करना है। यादृच्छिक त्रिभुज जंक प्रदाता देखें जो एक तकनीकी प्रदर्शनकर्ता के रूप में कार्य करता है:
https://github.com/kaisalmen/WWOBJLoader/tree/Commons/test/meshspray
https://kaisalmen.de/proto/test/meshspray/main.src.html

वर्तमान कार्यान्वयन में भी WWOBJLoader2 कार्यकर्ता से मुख्य धागे तक Mesh लिए कच्चा BufferedGeometry डेटा प्रदान करने के लिए हस्तांतरणीय वस्तुओं (ArrayBuffers/ByteBuffers) पर निर्भर करता है। समय-समय पर प्रदान किए गए बाइटबफ़र्स से Mesh का निर्माण नगण्य है। जब भी दृश्य में एक बड़ा जाल एकीकृत किया जाता है तो प्रतिपादन रुक जाता है (डेटा प्रतियां, दृश्य ग्राफ समायोजन ...!?)। यह हमेशा स्रोत से स्वतंत्र मामला होता है (अगर मैं गलत हूं तो मुझे सुधारें)।
WWOBJLoader2 का "स्ट्रीम" मोड इन स्टालों को सुचारू करता है, लेकिन अगर आपके OBJ मॉडल के एक जाल के टुकड़े का वजन 0.5 मिलियन वर्टिस है, तो रेंडरिंग लंबे समय तक रुकेगा।

मैंने बीस्पोक शाखा पर वास्तव में क्या किया है और क्यों: मैंने विस्तार से एक नया मुद्दा खोला है:
https://github.com/kaisalmen/WWOBJLoader/issues/11
मुद्दा अभी भी एक आधार है और विवरण जल्द ही आएगा।

कुछ नंबरों की पेशकश करने के लिए, यहां https://threejs.org/examples/webgl_loader_gltf2.html की एक प्रदर्शन प्रोफ़ाइल है, जिसमें 2048x2048 बनावट के साथ 13MB मॉडल लोड हो रहा है।

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

जिज्ञासु के लिए, मुख्य धागे को अवरुद्ध करने वाला अंतिम हिस्सा एक पर्यावरण क्यूबमैप के अतिरिक्त है।

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

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

Gltf पार्सिंग के लिए मैं आमतौर पर अपने परीक्षणों पर 500ms को अवरुद्ध करता हुआ देखता हूं, यह महत्वपूर्ण है और मैं सभी लोडरों के लिए एक वृद्धिशील दृष्टिकोण पसंद करूंगा (जो क्लोन करने योग्य भी होना चाहिए)

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

@kaisalmen लिंक के लिए धन्यवाद

Elation Engine / JanusWeb में, हम वास्तव में वर्कर थ्रेड्स के पूल का उपयोग करके अपने सभी मॉडल पार्सिंग करते हैं, जो बहुत अच्छी तरह से काम करता है। एक बार जब कार्यकर्ता प्रत्येक मॉडल को लोड करना समाप्त कर लेते हैं, तो हम इसे object.toJSON() का उपयोग करके क्रमबद्ध करते हैं, इसे postMessage() साथ मुख्य थ्रेड पर भेजते हैं, और फिर इसे ObjectLoader.parse() का उपयोग करके लोड करते हैं। यह लोडर कोड के अधिकांश अवरुद्ध भागों को हटा देता है - अभी भी ObjectLoader.parse() में कुछ समय बिताया गया है जिसे शायद अनुकूलित किया जा सकता है, लेकिन समग्र अंतःक्रियाशीलता और लोड गति में काफी सुधार हुआ है। चूंकि हम श्रमिकों के एक पूल का उपयोग कर रहे हैं, हम समानांतर में कई मॉडलों को भी पार्स कर सकते हैं, जो जटिल दृश्यों में एक बड़ी जीत है।

चीजों के बनावट पक्ष पर, हाँ, मुझे लगता है कि तीन.जेएस की बनावट अपलोड करने की कार्यक्षमता के लिए कुछ बदलावों की आवश्यकता है। texSubImage2D का उपयोग करने वाला एक खंडित अपलोडर आदर्श होगा, फिर हम ऊपर बताए अनुसार कई फ़्रेमों पर बड़े बनावट के आंशिक अपडेट कर सकते हैं।

मुझे इस परिवर्तन पर सहयोग करने में बहुत खुशी होगी, क्योंकि इससे कई परियोजनाओं को लाभ होगा जो आधार के रूप में तीन.जेएस का उपयोग करती हैं

मुझे लगता है कि texSubImage2D का उपयोग करना एक अच्छा विचार है।
लेकिन यह भी क्यों WebGL बनावट को अतुल्यकालिक रूप से अपलोड नहीं करता है।
ओपनजीएल और अन्य libs की एक ही सीमा है?

और एक और चीज जो मैं सोच रहा हूं वह है जीएलएसएल संकलन।
क्या यह फ्रेम गिरा देगा? या काफी तेजी से और हमें परवाह करने की जरूरत नहीं है?

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

यदि हम भविष्य में नए ImageBitmap API का उपयोग करते हैं, तो बनावट अपलोड करने में समस्या कम होगी। https://youtu.be/wkDd-x0EkFU?t=82 देखें।

BTW: @spite के लिए धन्यवाद, हमारे पास प्रोजेक्ट में पहले से ही एक प्रयोगात्मक ImageBitmapLoader है।

@ Mugen87 वास्तव में मैं पहले से ही Elation Engine/JanusWeb में ImageBitmap के साथ अपने सभी बनावट भार कर रहा हूं - यह निश्चित रूप से मदद करता है और तीन.जेएस कोर में एकीकृत करने लायक है, लेकिन वेबजीएल में बनावट का उपयोग करने में दो मुख्य खर्च शामिल हैं - छवि डिकोड समय , और छवि अपलोड समय - ImageBitmap केवल पहले के साथ मदद करता है।

यह मेरे परीक्षणों में CPU को अवरुद्ध करने में लगने वाले समय में लगभग 50% की कटौती करता है, लेकिन GPU पर बड़े टेक्सचर अपलोड करने में, विशेष रूप से 2048x2048 और ऊपर, आसानी से एक या अधिक समय ले सकता है।

यह कोशिश करना सुविधाजनक होगा कि @jbaicoianu क्या सुझाव दे रहा है। वैसे भी, यदि मुख्य-थ्रेड विकल्प का चयन करना है, तो यह सेटटाइमआउट के बजाय

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

requestIdleCallback अच्छा होगा, लेकिन यह व्यापक रूप से समर्थित नहीं है, और यह WebVR सत्रों में समस्याग्रस्त है

@ इसके बावजूद मैं आपकी सजा के बारे में उत्सुक हूं, समस्याग्रस्त से आपका क्या मतलब है?

मेरे पास texSubImage2D का उपयोग करके बनावट को क्रमिक रूप से अद्यतन करने के लिए एक THREE.UpdatableTexture है, लेकिन तीन.js के थोड़े से बदलाव की आवश्यकता है। समर्थन जोड़ने के लिए पीआर तैयार करने का विचार है।

requestIdleCallback (आरआईसी) के संबंध में:

• सबसे पहले, यह क्रोम और फ़ायरफ़ॉक्स पर समर्थित है, और यद्यपि इसे आसानी से पॉलीफ़िल किया जा सकता है, पॉलीफ़िल्ड संस्करण उद्देश्य को थोड़ा विफल कर सकता है।

• दूसरा: उसी तरह vrDisplay.requestAnimationFrame (rAF) को पेश करते समय window.rAF के बजाय कॉल करने की आवश्यकता होती है, वही rIC के लिए लागू होता है, जैसा कि इस crbug में चर्चा की गई है। इसका मतलब है कि लोडर को हर समय वर्तमान सक्रिय प्रदर्शन के बारे में पता होना चाहिए, या जो प्रस्तुत कर रहा है उसके आधार पर यह फायरिंग बंद कर देगा। यह बहुत जटिल नहीं है, यह केवल लोडर की तारों में और अधिक जटिलता जोड़ता है (जो आदर्श रूप से प्रस्तुति स्थिति से स्वतंत्र रूप से अपना काम करना चाहिए)। एक अन्य विकल्प थ्रीजे में उस हिस्से को रखना है जो वर्तमान प्रदर्शन को साझा करने के लिए मुख्य धागे में वृद्धिशील कार्य चलाता है; मुझे लगता है कि थ्रीजे में वीआर में नवीनतम परिवर्तनों के साथ अब करना बहुत आसान है।

एक और विचार: texSubImage2D (256x256 या 512x512) का उपयोग करके कई चरणों में एक बड़ी बनावट को अपलोड करने में सक्षम होने के लिए, हमें ऑफसेट और क्लिपिंग सुविधाओं के लिए WebGL2 संदर्भ की आवश्यकता है। अन्यथा छवियों को कैनवास के माध्यम से पूर्व-क्लिप किया जाना है, मूल रूप से अपलोड करने से पहले क्लाइंट-साइड टाइल किया गया है।

@ अच्छी बात है, मैंने नहीं सोचा था कि प्रस्तुत करते समय आरआईसी को नहीं बुलाया जा रहा है, पहले तो मैंने सोचा था कि हमें डिस्प्ले की आवश्यकता होनी चाहिए। आरआईसी लेकिन मेरा मानना ​​​​है कि .rIC को विंडो से जोड़ा जाना चाहिए और जब विंडो या डिस्प्ले हो दोनों बेकार।
मेरा मानना ​​है कि मैंने webvr स्पेक्स चर्चाओं में इससे संबंधित कुछ भी नहीं सुना है @kearwood के पास शायद अधिक जानकारी है, लेकिन निश्चित रूप से यह एक ऐसा मुद्दा है जिसे हमें संबोधित करना चाहिए।

अपने अद्यतन करने योग्य बनावट पीआर को देखने के लिए उत्सुक हैं! :) यहां तक ​​​​कि अगर यह सिर्फ एक डब्ल्यूआईपी है तो हम कुछ चर्चाओं को वहां ले जा सकते हैं।

हो सकता है लोडर कुछ ऐसा बन जाए...

THREE.MyLoader = ( function () {

    // parse file and output js object
    function parser( text ) {
        return { 'vertices': new Float32Array() }
    }

    // convert js object to THREE objects.
    function builder( data ) {
        var geometry = new THREE.BufferGeometry();
        geometry.addAttribute( new THREE.BufferAttribute( data.vertices, 3 );
        return geometry;
    }

    function MyLoader( manager ) {}
    MyLoader.prototype = {
        constructor: MyLoader,
        load: function ( url, onLoad, onProgress, onError  ) {},
        parse: function ( text ) {
            return builder( parser( text ) );
        },
        parseAsync: function ( text, onParse ) {
            var code = parser.toString() + '\nonmessage = function ( e ) { postMessage( parser( e.data ) ); }';
            var blob = new Blob( [ code ], { type: 'text/plain' } );
            var worker = new Worker( window.URL.createObjectURL( blob ) );
            worker.addEventListener( 'message', function ( e ) {
                onParse( builder( e.data ) );
            } );
            worker.postMessage( text );
        }
    }
} )();

तीन का पहला प्रस्ताव जारी।

आदर्श रूप से यह किसी भी तीन बनावट का हिस्सा होना चाहिए, लेकिन मैं पहले इस दृष्टिकोण का पता लगाऊंगा।

@mrdoob मैं कार्यकर्ता को ठीक उसी कोड को पाइप करने पर योग्यता देखता

साथ ही, आदर्श रूप से संसाधन की प्राप्ति स्वयं कार्यकर्ता में होगी। और मुझे लगता है कि ब्राउज़र में पार्सर() विधि को तीन.जेएस के आयात की आवश्यकता होगी।

लेकिन सिंक/एसिंक लोडर को परिभाषित करने के लिए एक बिंदु किक-गधा होगा!

@mrdoob builder फ़ंक्शन सभी लोडर के लिए पूरी तरह से सामान्य और सामान्य हो सकता है (WIP: https://github.com/kaisalmen/WWOBJLoader/blob/Commons/src/loaders/support/WWMeshProvider.js#LL215- LL367; अद्यतन: किसी फ़ंक्शन में अभी तक अलग नहीं किया गया है)। यदि इनपुट डेटा किसी भी THREE ऑब्जेक्ट्स के संदर्भ के बिना शुद्ध जेएस ऑब्जेक्ट्स तक सीमित है (यही आपके दिमाग में है, है ना?) हम कार्यकर्ता में आयात की आवश्यकता के बिना क्रमिक कार्यकर्ता कोड बना सकते हैं (क्या WWOBJLoader करता है)। यह ज्यामिति के लिए आसान है, लेकिन सामग्री/शेडर्स (यदि फ़ाइल में परिभाषित किया गया है) को केवल बिल्डर में बनाया जा सकता है और केवल parser से पहले JSON के रूप में वर्णित किया जा सकता है।
मुझे लगता है कि एक कार्यकर्ता को हर नए जाल और उसके पूरा होने का संकेत देना चाहिए। इसे इस तरह बदला जा सकता है:

// parse file and output js object
function parser( text, onMeshLoaded, onComplete ) {
    ....
}

parse: function ( text ) {
    var node = new THREE.Object3d();
    var onMeshLoaded = function ( data ) {
        node.add( builder( data ) );
    };

    // onComplete as second callbackonly provided in async case
    parser( text, onMeshLoaded ) );
    return node;
},

एक कार्यकर्ता निर्माता उपयोग सहायक है + कुछ सामान्य संचार प्रोटोकॉल जो पार्सर का उपयोग करने के आपके विचार का खंडन नहीं कर रहा है, लेकिन मुझे लगता है कि इसे कुछ लपेटने की जरूरत है। WWOBJLoader विकास पर वर्तमान स्थिति: https://github.com/kaisalmen/WWOBJLoader/blob/Commons/src/loaders/support/WWMeshProvider.js#LL40 -LL133, जबकि फ्रंट-एंड कॉल रिपोर्ट_प्रगति, मेशडेटा और पूर्ण हैं।

अद्यतन2:

• क्या आपको लगता है कि पार्सर स्टेटलेस होना चाहिए? यह builder लिए ठीक है, लेकिन parser के व्यवहार को समायोजित करने के लिए कुछ पैरामीटर सेट करने में सक्षम होना समझ में आता है। इसका मतलब यह भी है कि कॉन्फ़िगरेशन पैरामीटर पार्सिंग से स्वतंत्र कार्यकर्ता को हस्तांतरणीय होना चाहिए
• एक सामान्य कॉन्फ़िगरेशन ऑब्जेक्ट खाने वाले रन फ़ंक्शन की तरह कुछ अच्छा होगा। एक सामान्य निदेशक तब निर्देशों के साथ किसी भी लोडर को खिला सकता है (यह अब WWOBJLoader की bespoke Commons शाखा में काम कर रहा है, btw)
• चल रहे देव: WWOBJLoader2 अब OBJLoader और यह पार्स को ओवरराइड करता है। तो, हमारे पास दोनों पार्सिंग कैप हैं, लेकिन विभिन्न वर्गों में। यह प्रस्ताव के करीब आता है, लेकिन यह अभी तक लाइन में नहीं है। कुछ पार्सर कोड को एकीकृत करने की आवश्यकता होती है और अंततः दोनों वर्गों को आपस में जोड़ना पड़ता है

अभी के लिए बस इतना ही। प्रतिक्रिया का स्वागत है

@mrdoob मुझे फ्लाई पर लोडर के कोड से कार्यकर्ता को लिखने का विचार पसंद है। मेरा वर्तमान दृष्टिकोण सिर्फ पूरे संयुक्त एप्लिकेशन जेएस को लोड करता है और मुख्य धागे से अलग प्रवेश बिंदु का उपयोग करता है, निश्चित रूप से उतना कुशल नहीं है जितना कि श्रमिकों को केवल कोड की आवश्यकता होती है।

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

इस सरलीकृत दृष्टिकोण के लिए मैं जो दो डाउनसाइड देखता हूं वे हैं:

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

@ इसके बारे में "इसके अलावा, आदर्श रूप से संसाधन की

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

बनावट लोड करने के विषय पर, मैंने एक नए FramebufferTexture वर्ग की अवधारणा का प्रमाण बनाया है, जो एक साथी FramebufferTextureLoader साथ आता है। यह बनावट प्रकार WebGLRenderTarget तक फैली हुई है, और इसके लोडर को किसी दिए गए आकार के खंडित टाइलों में बनावट लोड करने के लिए कॉन्फ़िगर किया जा सकता है, और उन्हें requestIdleCallback() का उपयोग करके फ्रेमबफर में लिखें।

https://baicoianu.com/~bai/three.js/examples/webgl_texture_framebuffer.html

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

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

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

क्या कोई प्रदर्शन या फीचर-संबंधी कारण हैं जो कोई भी सोच सकता है कि मानक बनावट संदर्भ के विपरीत, दृश्य में प्रत्येक बनावट के लिए फ्रेमबफर रखना एक बुरा विचार क्यों हो सकता है? मुझे मैक्स के बारे में कुछ नहीं मिला। फ्रेमबफर प्रति दृश्य, जहां तक ​​​​मैं कह सकता हूं कि एक बार फ्रेमबफर स्थापित हो जाने के बाद, यदि आप इसे प्रस्तुत नहीं कर रहे हैं तो यह किसी अन्य बनावट संदर्भ के समान है, लेकिन मुझे यह महसूस हो रहा है कि मुझे कुछ स्पष्ट याद आ रहा है यह वास्तव में एक बुरा विचार क्यों होगा :)

@jbaicoianu re: फ़ायरफ़ॉक्स का createImageBitmap, इसका कारण यह है कि वे शब्दकोश पैरामीटर का समर्थन नहीं करते हैं, इसलिए यह छवि अभिविन्यास या रंग स्थान रूपांतरण का समर्थन नहीं करता है। यह एपीआई के अधिकांश अनुप्रयोगों को बहुत बेकार बना देता है। मैंने इस मुद्दे से संबंधित दो बग दर्ज किए: https://bugzilla.mozilla.org/show_bug.cgi?id=1367251 और https://bugzilla.mozilla.org/show_bug.cgi?id=1335594

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

Argument 4 of Window.createImageBitmap '1024' is not a valid value for enumeration ImageBitmapFormat.

जो भ्रामक है, क्योंकि मुझे कल्पना में createImageBitmap का कोई भी संस्करण दिखाई नहीं देता है जो एक तर्क के रूप में ImageBitmapFormat लेता है।

क्या कोई प्रदर्शन या फीचर-संबंधी कारण हैं जो कोई भी सोच सकता है कि मानक बनावट संदर्भ के विपरीत, दृश्य में प्रत्येक बनावट के लिए फ्रेमबफर रखना एक बुरा विचार क्यों हो सकता है? मुझे मैक्स के बारे में कुछ नहीं मिला। फ्रेमबफर प्रति दृश्य, जहां तक ​​​​मैं कह सकता हूं कि एक बार फ्रेमबफर स्थापित हो जाने के बाद, यदि आप इसे प्रस्तुत नहीं कर रहे हैं तो यह किसी अन्य बनावट संदर्भ के समान है, लेकिन मुझे यह महसूस हो रहा है कि मुझे कुछ स्पष्ट याद आ रहा है यह वास्तव में एक बुरा विचार क्यों होगा :)

@jbaicoianu THREE.WebGLRenderTarget एक फ्रेमबफर, एक बनावट और एक रेंडर बफर रखता है। जब आपके पास बनावट इकट्ठी हो जाती है, तो आप फ्रेमबफर और रेंडर बफर को हटा सकते हैं और केवल बनावट को रख सकते हैं। ऐसा कुछ ऐसा करना चाहिए (परीक्षण नहीं किया गया):

texture = target.texture;
target.texture = null; // so the webgl texture is not deleted by dispose()
target.dispose();

@wrr यह जानना अच्छा है, धन्यवाद। मुझे निश्चित रूप से इस पर स्मृति दक्षता पर भी पास करना होगा - यदि आप पर्याप्त पैरामीटर बदलते हैं तो यह अनिवार्य रूप से किसी बिंदु पर दुर्घटनाग्रस्त हो जाता है, इसलिए मुझे पता है कि कुछ सफाई है जो मैं अभी तक नहीं कर रहा हूं। इस तरह के किसी अन्य संकेत की बहुत सराहना की जाएगी।

@mrdoob और @jbaicoianu मैं यह बताना भूल गया कि मुझे भी यह विचार पसंद है। मैं
मैंने OBJLoader और WWOBJLoader और सभी उदाहरणों ( code ) के
निर्देशित WWOBJLoader2 परीक्षण:
https://kaisalmen.de/proto/test/wwparallels/main.src.html
जेनेरिक का निर्देशित उपयोगकर्ता WorkerSupport :
https://kaisalmen.de/proto/test/meshspray/main.src.html
बड़ा ज़िपित OBJ फ़ाइल परीक्षण:
https://kaisalmen.de/proto/test/wwobjloader2stage/main.src.html

उपलब्ध होने पर मैं उपरोक्त उदाहरणों को नए कोड के साथ अपडेट कर दूंगा और आपको बता दूंगा।
अद्यतन 2017-07-30: OBJLoader2 और WWOBJLoader2 अब समान पार्सर्स का उपयोग करें। वे सीधे या कार्यकर्ता से आम बिल्डर फ़ंक्शन को डेटा पास करते हैं।
अद्यतन 2017-07-31: WWOBJLoader2 चला गया है। OBJLoader2 प्रदान करता है parse और parseAsync , load और run ( LoaderDirector या मैन्युअल द्वारा फ़ीड)

अद्यतन 2017-08-09:
अद्यतन को नई पोस्ट पर ले जाया गया।

OBJLoader2 OBJLoader साथ फिर से संगत हस्ताक्षर और व्यवहार है (मैंने विकास के दौरान इसे तोड़ दिया), OBJLoader2 parseAsync और load साथ useAsync इसके अलावा
https://github.com/kaisalmen/WWOBJLoader/tree/V2.0.0-Beta/src/loaders

मैंने लोडर सपोर्ट क्लासेस (ओबीजे से स्वतंत्र) निकाली हैं जो उपयोगिताओं और आवश्यक समर्थन उपकरण के रूप में काम करती हैं। संभावित अन्य कार्यकर्ता आधारित लोडर के लिए उनका पुन: उपयोग किया जा सकता है। सभी कोड पर क्लिक करके मेरे नाम स्थान में रखा THREE.LoaderSupport से अपनी निर्भरता को उजागर करने के OBJLoader2 :

• Builder : सामान्य जाल निर्माण के लिए
• WorkerDirector : प्रतिबिंब के माध्यम से लोडर बनाता है, PrepData को कर्मचारियों की कॉन्फ़िगर की गई राशि के साथ कतार में संसाधित करता है। लोडर को पूरी तरह से स्वचालित करने के लिए प्रयुक्त (MeshSpray और Parallels डेमो)
• WorkerSupport : मौजूदा कोड से श्रमिकों को बनाने और एक सरल संचार प्रोटोकॉल स्थापित करने के लिए उपयोगिता वर्ग
• PrepData + ResourceDescriptor : ऑटोमेशन के लिए या उदाहरणों के बीच एकीकृत विवरण के लिए उपयोग किया जाने वाला विवरण
• Commons : लोडर के लिए संभावित आधार वर्ग (सामान्य मापदंडों को बंडल करता है)
• Callbacks : (onProgress, onMeshAlter, onLoad) स्वचालन और दिशा के लिए उपयोग किया जाता है और LoadedMeshUserOverride का उपयोग onMeshAlter से वापस जानकारी प्रदान करने के लिए किया जाता है (नीचे objloader2 परीक्षण में सामान्य जोड़)
• Validator : शून्य/अपरिभाषित चर जांच

@mrdoob @jbaicoianu OBJLoader2 अब सुझाव के अनुसार एक पार्सर लपेटता है (इसे वैश्विक स्तर पर सेट किए गए पैरामीटर के साथ कॉन्फ़िगर किया गया है या चलाने के लिए PrepData द्वारा प्राप्त किया गया है)। Builder प्रत्येक कच्चे जाल को प्राप्त करता है और पार्सर बेस नोड लौटाता है, लेकिन इसके अलावा यह ब्लूप्रिंट से मेल खाता है।
पार्सर के क्रमांकन के लिए OBJLoader2 में अभी भी कुछ सहायक कोड हैं जिनकी आवश्यकता नहीं है।
बिल्डर को सफाई की जरूरत है क्योंकि buildMeshes फ़ंक्शन के लिए अनुबंध/पैरामीटर ऑब्जेक्ट अभी भी ओबीजे लोडिंग से काफी प्रभावित है और इसलिए अभी भी निर्माणाधीन माना जाता है।

कोड को कुछ चमकाने की जरूरत है, लेकिन फिर यह प्रतिक्रिया, चर्चा, आलोचना आदि के लिए तैयार है...

उदाहरण और परीक्षण

रन और लोड का उपयोग कर ओबीजे लोडर:
https://kaisalmen.de/proto/test/objloader2/main.src.html
OBJ लोडर async और parseAsync चलाएँ:
https://kaisalmen.de/proto/test/wwobjloader2/main.src.html
रन async OBJLoader2 का निर्देशित उपयोग:
https://kaisalmen.de/proto/test/wwparallels/main.src.html
जेनेरिक वर्कर सपोर्ट का निर्देशित उपयोग:
https://kaisalmen.de/proto/test/meshspray/main.src.html
बड़ा ज़िपित OBJ फ़ाइल परीक्षण:
https://kaisalmen.de/proto/test/wwobjloader2stage/main.src.html

जंच रहे हो! क्या आप OBJLoader में इन परिवर्तनों से अवगत हैं? #11871 565c6fd0f3d9b146b9434e5fccfa2345a90a3842

हां, मुझे इसे पोर्ट करने की जरूरत है। मैंने कुछ पुन: उत्पादित पूर्ण माप का प्रस्ताव दिया। दोनों इस वीकेंड पर काम करना शुरू कर देंगे। आप r87 को कब रिलीज़ करने की योजना बना रहे हैं? एन-गॉन समर्थन इसे तारीख के आधार पर बना सकता है।

@mrdoob और https://github.com/mrdoob/three.js/pull/11928 n-gon सपोर्ट

स्थिति अद्यतन ( कोड ):
बनाए गए कार्यकर्ता अब किसी संदेश द्वारा प्राप्त मापदंडों के माध्यम से कार्यकर्ता के अंदर किसी भी पार्सर को कॉन्फ़िगर करने में सक्षम हैं। WorkerSupport एक संदर्भ कार्यकर्ता धावक कार्यान्वयन ( कोड ) प्रदान करता है जिसे वांछित होने पर या यदि आवश्यक हो तो पूरी तरह से स्वयं के कोड से बदला जा सकता है।
कार्यकर्ता बना सकते हैं और में पदव्याख्यायित्र चलेंगे run की विधि WorkerRunnerRefImpl ( Parser कार्यकर्ता दायरे के अंदर उपलब्ध है; this.applyProperties कॉल setters या के गुणों पार्सर):

WorkerRunnerRefImpl.prototype.run = function ( payload ) {
    if ( payload.cmd === 'run' ) {

        console.log( 'WorkerRunner: Starting Run...' );

        var callbacks = {
            callbackBuilder: function ( payload ) {
                self.postMessage( payload );
            },
            callbackProgress: function ( message ) {
                console.log( 'WorkerRunner: progress: ' + message );
            }
        };

        // Parser is expected to be named as such
        var parser = new Parser();
        this.applyProperties( parser, payload.params );
        this.applyProperties( parser, payload.materials );
        this.applyProperties( parser, callbacks );
        parser.parse( payload.buffers.input );

        console.log( 'WorkerRunner: Run complete!' );

        callbacks.callbackBuilder( {
            cmd: 'complete',
            msg: 'WorkerRunner completed run.'
        } );

    } else {

        console.error( 'WorkerRunner: Received unknown command: ' + payload.cmd );

    }
};

OBJLoader2.parseAsync से संदेश इस तरह दिखता है:

this.workerSupport.run(
    {
        cmd: 'run',
        params: {
            debug: this.debug,
            materialPerSmoothingGroup: this.materialPerSmoothingGroup
        },
        materials: {
            materialNames: this.materialNames
        },
        buffers: {
            input: content
        }
    },
    [ content.buffer ]
);

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

मुझे लगता है कि OBJLoader2 का विकास और समर्थन कार्यों का निष्कर्षण अब उस बिंदु पर पहुंच गया है जहां आपकी प्रतिक्रिया की आवश्यकता है। जब सभी उदाहरणों को इसके रेपो से ऊपर की शाखा में भेज दिया गया है, तो मैं एक संपूर्ण सारांश के साथ एक पीआर खोलूंगा और फिर प्रतिक्रिया का अनुरोध करूंगा

https://webkit.org/blog/7846/concurrent-javascript-it-can-work/

FYI करें, यहाँ ImageBitmapLoader एक कार्यकर्ता का उपयोग करने के लिए एक कार्य-प्रगति है जैसा कि ऊपर चर्चा की गई है। शायद अधिक दिलचस्प, परिणामों पर कुछ कठिन संख्याएँ: https://github.com/mrdoob/three.js/pull/12456

फ़ायरफ़ॉक्स का createImageBitmap, इसका कारण यह है कि वे शब्दकोश पैरामीटर का समर्थन नहीं करते हैं, इसलिए यह छवि अभिविन्यास या रंग स्थान रूपांतरण का समर्थन नहीं करता है। यह एपीआई के अधिकांश अनुप्रयोगों को बहुत बेकार बना देता है।

यह दुर्भाग्यपूर्ण है। ️

@mrdoob आप स्विच करने के लिए एक योजना है ImageLoader करने के लिए ImageBitmapLoader में TextureLoader क्योंकि ImageBitmap बनावट को अपलोड करने के लिए कम-अवरुद्ध किया जाना चाहिए? createImageBitmap() अगर हम केवल पहला तर्क पास करते हैं तो अब तक फ़ायरफ़ॉक्स पर काम कर रहा है। (शायद हमें TextureLoader माध्यम से दूसरे और अधिक तर्क पारित करने की आवश्यकता नहीं है?)

return createImageBitmap( blob );

यह वास्तव में महत्वपूर्ण है कि createImageBitmap () विकल्प शब्दकोश का समर्थन करता है। अन्यथा आप इमेज ओरिएंटेशन (फ्लिप-वाई) जैसी चीजें नहीं बदल सकते हैं या प्रीमल्टीप्लाइड अल्फा इंगित नहीं कर सकते हैं। बात यह है कि आप WebGLRenderingContext.pixelStorei लिए ImageBitmap उपयोग नहीं कर सकते। विशिष्टता से :

_अगर TexImageSource एक इमेज बिटमैप है, तो इन तीन पैरामीटर (UNPACK_FLIP_Y_WEBGL, UNPACK_PREMULTIPLY_ALPHA_WEBGL, UNPACK_COLORSPACE_CONVERSION_WEBGL) पर ध्यान नहीं दिया जाएगा। इसके बजाय समकक्ष ImageBitmapOptions का उपयोग वांछित प्रारूप के साथ ImageBitmap बनाने के लिए किया जाना चाहिए।_

इसलिए मुझे लगता है कि हम केवल ImageBitmapLoader स्विच कर सकते हैं यदि FF विकल्प शब्दकोश का समर्थन करता है। इसके अलावा, जैसे गुण Texture.premultiplyAlpha और Texture.flipY साथ काम नहीं करते ImageBitmap अभी। मेरा मतलब है कि यदि उपयोगकर्ता उन्हें सेट करते हैं, तो वे ImageBitmap पर आधारित बनावट को प्रभावित नहीं करेंगे जो कुछ हद तक दुर्भाग्यपूर्ण है।

आह अच्छा। मैं उस युक्ति से चूक गया हूं।

विकल्प शब्दकोश के महत्व पर भी यहाँ चर्चा की गई है:

https://bugzilla.mozilla.org/show_bug.cgi?id=1335594

बगजिला (https://bugzilla.mozilla.org/show_bug.cgi?id=1367251, https://bugzilla.mozilla.org/show_bug.cgi?id=1335594) पर बग्स को अछूते रखा गया है ... दो अब साल? मैंने नहीं सोचा था कि इसे ठीक करने में उन्हें इतना लंबा समय लगेगा।

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

व्यावहारिक समाधान फीचर डिटेक्शन कर रहा है: फ्लिप फ्लैग के साथ सीआईबी का उपयोग करके 2x2 छवि बनाएं, और फिर वापस पढ़ें और सुनिश्चित करें कि मान सही हैं।

फायरफॉक्स बग्स के बारे में, मैं उनसे आंतरिक रूप से भी संपर्क करने वाला हूं। आइए देखें कि उनकी योजना सुनने के बाद हमें समाधान की आवश्यकता है या नहीं।

बगजिला (https://bugzilla.mozilla.org/show_bug.cgi?id=1367251, https://bugzilla.mozilla.org/show_bug.cgi?id=1335594) पर बग्स को अछूते रखा गया है ... दो अब साल? मैंने नहीं सोचा था कि इसे ठीक करने में उन्हें इतना लंबा समय लगेगा।

हां इसके लिए खेद है कि मैंने वास्तव में कुछ समय के लिए इसका पालन नहीं किया -_-

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

व्यावहारिक समाधान फीचर डिटेक्शन कर रहा है: फ्लिप फ्लैग के साथ सीआईबी का उपयोग करके 2x2 छवि बनाएं, और फिर वापस पढ़ें और सुनिश्चित करें कि मान सही हैं।

हां, मैं मानता हूं कि दोनों समाधान वास्तव में बेकार हैं और हमें उनसे बचने की कोशिश करनी चाहिए ताकि इनमें से किसी में भी खुदाई करने से पहले देखें कि क्या हम इसे अपनी तरफ से अनब्लॉक कर सकते हैं

मैंने प्रदर्शन परीक्षण अपलोड करने के लिए ImageBitmap बनाया। हर 5 सेकंड में बनावट अपलोड कर रहा है।

आप रेगुलर इमेज बनाम इमेज बिटमैप की तुलना कर सकते हैं।

https://rawgit.com/takahirox/three.js/ImageBitmapTest/examples/webgl_texture_upload.html (नियमित छवि)
https://rawgit.com/takahirox/three.js/ImageBitmapTest/examples/webgl_texture_upload.html?imagebitmap (ImageBitmap)

मेरी खिड़कियों पर मैं देखता हूँ

| ब्राउज़र | 8192x4096 जेपीजी 4.4एमबी | 2048x2048 पीएनजी 4.5 एमबी |
| ---- | ---- | ---- |
| क्रोम छवि | 500ms | 140ms |
| क्रोम इमेज बिटमैप | 165ms | 35ms |
| फायरफॉक्स इमेज | 500ms | 40ms |
| फायरफॉक्स इमेज बिटमैप | 500ms | 60ms |

( texture.generateMipmaps है true )

मेरे विचार

1. क्रोम पर ImageBitmap के साथ 3x बेहतर प्रदर्शन। बहुत बढ़िया सुधार।
2. फ़ायर्फ़ॉक्स में अब ImageBitmap प्रदर्शन समस्या है? क्या आप अपने कंप्यूटर पर भी कोशिश कर सकते हैं? मोबाइल पर प्रयास करना भी स्वागत योग्य है।
3. यहां तक ​​​​कि ImageBitmap के साथ, बनावट अपलोड करना अभी भी बड़ी बनावट के लिए अवरुद्ध है। हो सकता है कि हमें वृद्धिशील आंशिक अपलोडिंग तकनीक या गैर-अवरुद्ध करने के लिए कुछ चाहिए।

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

मुझे लगता है कि इस समस्या का एक समाधान बनावट संपीड़न प्रारूप का उपयोग और जेपीजी या पीएनजी (और इस प्रकार ImageBitmap ) से बचाव हो सकता है। इस संदर्भ में कुछ प्रदर्शन डेटा देखना दिलचस्प होगा।

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

या अनुसूचित/अनुरोध का उपयोग करेंIdleCallback texSubImage2D

आरआईसी = requestIdleCallback?

हाँ, मैंने एक निंजा संपादन किया है

ठीक है। हाँ सहमत।

BTW, मैं अभी तक संकुचित बनावट से परिचित नहीं हूँ। मुझे अपनी समझ की पुष्टि करने दो। हम संपीड़ित बनावट का उपयोग ImageBitmap साथ नहीं कर सकते क्योंकि compressedTexImage2D ImageBitmap स्वीकार नहीं करता है, है ना?

https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/compressedTexImage2D

मैं अपने पुराने टाइलेडटेक्चर लोडर प्रयोगों को फिर से देखने के लिए वापस गया - ऐसा लगता है कि वे अब मेरे वीडियो ड्राइवर को क्रैश और पुनरारंभ करने का कारण बन रहे हैं :(

(संपादित करें: वास्तव में, ऐसा लगता है कि सबसे बड़ी बनावट (16k x 16k - https://baicoianu.com/~bai/three.js/examples/textures/dotamap1_25.jpg) को सीधे क्रोम में लोड करना क्रैश का कारण बन रहा है। यह ठीक काम करता था, इसलिए क्रोम की इमेज हैंडलिंग में कुछ रिग्रेशन लगता है)

मैंने GPU पर अपलोड करने के लिए एक बड़ी बनावट को कई हिस्सों में विभाजित करने के लिए requestIdleCallback, ImageBitmap, और ES6 जनरेटर का उपयोग करके कुछ प्रयोग किए हैं। मैंने नियमित बनावट के बजाय फ्रेमबफर का उपयोग किया, क्योंकि भले ही आप छवि डेटा को पॉप्युलेट करने के लिए texSubimage2D का उपयोग कर रहे हों, फिर भी आपको स्मृति को पूर्व-आवंटित करने की आवश्यकता है, जिसके लिए GPU को खाली डेटा का एक गुच्छा अपलोड करने की आवश्यकता होती है, जबकि एक फ्रेमबफर बनाया जा सकता है और एक जीएल कॉल के साथ आरंभ किया गया।

उन परिवर्तनों के लिए भंडार अभी भी यहां उपलब्ध है https://github.com/jbaicoianu/THREE.TiledTexture/

मुझे जो प्रयोग याद हैं उनमें से कुछ नोट्स:

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

मेरे परिणाम समान थे: अपलोड गति और जानदारी के बीच एक समझौता था। (बीटीडब्ल्यू मैंने इसे https://github.com/spite/THREE.UpdatableTexture बनाया है)।

मुझे लगता है कि दूसरे विकल्प के लिए WebGL 1 में काम करने के लिए, आपको वास्तव में दो बनावटों की आवश्यकता होगी, या यूवी निर्देशांक के लिए कम से कम संशोधक की आवश्यकता होगी। वेबजीएल 2 में मुझे लगता है कि उन स्रोतों की प्रतिलिपि बनाना आसान है जो लक्ष्य बनावट से भिन्न आकार के हैं।

हाँ, texSubImage2D के साथ मुझे लगता है कि इस तरह का आकार बदलना संभव नहीं होगा, लेकिन फ्रेमबफर का उपयोग करते समय, मैं बनावट के टुकड़े के साथ एक विमान को प्रस्तुत करने के लिए ऑर्थोग्राफिक कैमरा का उपयोग कर रहा हूं, इसलिए यह विमान के पैमाने को बदलने का मामला है कि ड्रा कॉल।

फायरफॉक्स पर इमेजबीटमैप के प्रदर्शन के मुद्दे के बारे में, मैंने बगजिला पर एक बग खोला

https://bugzilla.mozilla.org/show_bug.cgi?id=1486454

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