Three.js: محمل الأصول غير المحظور

يمكن أن يكون لديك محمل قائم على Promise + worker + (يشبه إلى حد ما مزيج من النقطتين)

قم بتمرير عنوان URL المصدر إلى البرنامج النصي العامل ، وجلب الموارد ، وأعد بنية الكائنات القابلة للتحويل مع المخازن المؤقتة ، والبنى ، وحتى ImageBitmaps المطلوبة ؛ يجب أن يكون واضحًا بما يكفي بحيث لا يحتاج إلى الكثير من تكاليف معالجة الملفات الثلاثة.

سيتم حظر بيانات التحميل إلى GPU بغض النظر ، ولكن يمكنك إنشاء قائمة انتظار لتوزيع الأوامر عبر إطارات مختلفة ، عبر display.rAF. يمكن تنفيذ الأوامر واحدًا تلو الآخر لكل إطار ، أو حساب متوسط ​​وقت العملية وتشغيل العديد من الأوامر "الآمنة" للتشغيل في زحزحة الإطار الحالي (سيكون أمرًا مشابهًا لـ requestIdleCallback أمرًا رائعًا ، ولكنه غير مدعوم على نطاق واسع ، وهي مشكلة في جلسات WebVR). يمكن أيضًا تحسينها باستخدام bufferSubData و texSubImage2D وما إلى ذلك.

دعم العمال والأشياء القابلة للتحويل قوي جدًا في الوقت الحالي ، خاصة في المتصفحات التي تدعم WebVR.

مرحبًا بالجميع ، لدي نموذج أولي متاح قد يثير اهتمامك في هذا السياق. راجع الفرع التالي:
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 على الكائنات القابلة للتحويل (ArrayBuffers / ByteBuffers) لتوفير البيانات الخام BufferedGeometry لـ Mesh من العامل إلى الخيط الرئيسي. من ناحية الوقت ، فإن إنشاء Mesh من ByteBuffers المقدم لا يكاد يذكر. كلما تم دمج شبكة أكبر في المشهد ، يتم إيقاف العرض (نسخ البيانات ، تعديلات الرسم البياني للمشهد ...!؟). هذه هي الحالة دائمًا بغض النظر عن المصدر (صححني إذا كنت مخطئًا).
يعمل وضع "الدفق" الخاص بـ WWOBJLoader2 على تنعيم هذه الأكشاك ، ولكن إذا كانت قطعة شبكة واحدة من طراز OBJ تزن 0.5 مليون رأس ، فسيتم إيقاف العرض مؤقتًا لفترة أطول من الوقت.

لقد فتحت عددًا جديدًا لتفاصيل ما قمت به بالضبط في الفرع المخصص ولماذا:
https://github.com/kaisalmen/WWOBJLoader/issues/11
لا تزال المشكلة صعبة وستتبع التفاصيل قريبًا.

لتقديم بعض الأرقام ، إليك ملف تعريف أداء https://threejs.org/examples/webgl_loader_gltf2.html ، تحميل نموذج 13 ميجابايت مع زخارف 2048 × 2048.

في هذه الحالة ، فإن الشيء الأساسي الذي يحظر الخيط الرئيسي هو تحميل الزخارف إلى وحدة معالجة الرسومات ، وبقدر ما أعرف أنه لا يمكن القيام بذلك من WW .. إما أن يضيف المحمل نسيجًا تدريجيًا ، أو يجب على three.js التعامل معها داخليًا.

بالنسبة للفضوليين ، فإن الجزء الأخير الذي يحجب الخيط الرئيسي هو إضافة خريطة مكعب البيئة.

لا يتمثل الهدف الرئيسي لـ reaction-vr بالضرورة في الحصول على أفضل أداة تحميل من حيث وقت ساعة الحائط ولكن عدم التسبب في حدوث فجوات مفاجئة وغير متوقعة للإطار أثناء تحميل محتوى جديد. أي شيء يمكننا القيام به لتقليل هذا الأمر مفيد للجميع باستثناء الواقع الافتراضي.

تعتبر الأنسجة مشكلة بالتأكيد والخطوة الأولى الواضحة هي تحميلها بشكل اختياري - مجموعة من الخطوط في وقت واحد للحصول على نسيج كبير. نظرًا لأن التحميل مخفي لبرامج العملاء ، سيكون من الصعب عليهم إدارتها ، لكنني سأكون معرضًا بشكل أكثر انفتاحًا لعارض webgl لتخفيف الضغط عن three.js

بالنسبة لتحليل gltf ، أرى عادةً حظرًا لمدة 500 مللي ثانية في اختباراتي ، وهذا أمر مهم وأنا أفضل كثيرًا اتباع نهج تدريجي لجميع اللوادر (والتي يجب أن تكون قابلة للاستنساخ أيضًا)

تتمثل فرضية React VR في تشجيع المحتوى الديناميكي السهل المدفوع بأسلوب الويب لتشجيع المزيد من المطورين ، وهذا سيدفع مزيدًا من التركيز على تحسين المعالجة الديناميكية. في معظم الأوقات ، لا نعرف الأصول المطلوبة في بداية التطبيقات التي أنشأها المستخدم.

kaisalmen شكرا على الرابط

في Elation Engine / JanusWeb ، نقوم في الواقع بتحليل جميع نماذجنا باستخدام مجموعة من خيوط العاملين ، والتي تعمل بشكل جيد. بمجرد انتهاء العمال من تحميل كل نموذج ، نقوم بتسلسله باستخدام object.toJSON() ، وإرساله إلى السلسلة الرئيسية باستخدام postMessage() ، ثم تحميله باستخدام ObjectLoader.parse() . يؤدي هذا إلى إزالة معظم أجزاء الحظر من كود اللودر - لا يزال هناك بعض الوقت الذي يتم إنفاقه في ObjectLoader.parse() والذي يمكن تحسينه على الأرجح ، ولكن تم تحسين التفاعل الكلي وسرعة التحميل بشكل كبير. نظرًا لأننا نستخدم مجموعة من العمال ، يمكننا أيضًا تحليل نماذج متعددة بشكل متوازٍ ، وهو فوز كبير في المشاهد المعقدة.

على الجانب الملمس للأشياء ، نعم ، أعتقد أن بعض التغييرات مطلوبة لوظيفة تحميل نسيج three.js. سيكون برنامج التحميل المقسم الذي يستخدم texSubImage2D مثاليًا ، ثم يمكننا إجراء تحديثات جزئية للأنسجة الكبيرة عبر إطارات متعددة ، كما هو مذكور أعلاه.

يسعدني جدًا التعاون في هذا التغيير ، حيث إنه سيفيد العديد من المشاريع التي تستخدم Three.js كأساس

أعتقد أن استخدام texSubImage2D فكرة جيدة.
ولكن أيضًا لماذا لا يقوم WebGL بتحميل النسيج بشكل غير متزامن.
OpenGL و libs الأخرى لها نفس القيد؟

وشيء آخر أفكر فيه هو تجميع GLSL.
هل سيسقط الإطار؟ أم بالسرعة الكافية ولسنا بحاجة إلى الاهتمام؟

نعم ، هذه مشكلة في برنامج OpenGL الأصلي أيضًا - فتجميع التظليل وتحميل بيانات الصور هي عمليات متزامنة / محظورة. هذا هو السبب في أن معظم محركات الألعاب توصيك أو تجبرك على تحميل كل المحتوى مسبقًا قبل بدء المستوى - يُعتبر بشكل عام قدرًا كبيرًا جدًا من الأداء لتحميل موارد جديدة حتى من محرك الأقراص الثابتة ، ونحن هنا نحاول القيام بذلك بشكل غير متزامن عبر الإنترنت ... لدينا بالفعل مشكلة أكثر صعوبة من معظم مطوري الألعاب ، وسيتعين علينا اللجوء إلى استخدام تقنيات أكثر تقدمًا إذا أردنا أن نكون قادرين على بث محتوى جديد بسرعة.

سيكون تحميل الزخارف أقل صعوبة إذا استخدمنا واجهة برمجة تطبيقات ImageBitmap في المستقبل. راجع https://youtu.be/wkDd-x0EkFU؟t=82 .

راجع للشغل: بفضل spite ، لدينا بالفعل ImageBitmapLoader التجريبي في المشروع.

@ Mugen87 في الواقع ، أنا أقوم بالفعل بجميع عمليات تحميل النسيج الخاصة بي باستخدام ImageBitmap في Elation Engine / JanusWeb - إنه يساعد بالتأكيد ويستحق الاندماج في جوهر Three.js ، ولكن هناك نوعان من النفقات الرئيسية المرتبطة باستخدام القوام في WebGL - وقت فك تشفير الصورة ، ووقت تحميل الصور - يساعد ImageBitmap فقط في الأول.

يؤدي هذا إلى تقليل الوقت الذي يحظر وحدة المعالجة المركزية بحوالي 50٪ في اختباراتي ، ولكن تحميل مواد كبيرة إلى وحدة معالجة الرسومات ، خاصة 2048 × 2048 وما فوق ، يمكن أن يستغرق ثانية أو أكثر بسهولة.

سيكون من المناسب تجربة ما يقترحهjbaicoianu . على أي حال ، في حالة اختيار بديل مؤشر الترابط الرئيسي ، يبدو هذا تطابقًا مثاليًا مع requestIdleCallback بدلاً من setTimeout.

أتفق معك جميعًا ، وأعتقد أن طريقة تحميل كل شيء وتحليله على العامل ، وإنشاء الكائنات المطلوبة مرة أخرى على الخيط الرئيسي (إذا كانت باهظة الثمن ، فيمكن القيام بذلك في عدة خطوات) ثم تضمين تحميل إضافي على العارض.
بالنسبة إلى MVP ، يمكننا تحديد maxTexturesUploadPerFrame (بشكل افتراضي لانهائي) ، وسيتولى التجسيد التحميل من المجموعة وفقًا لهذا الرقم.
في التكرارات التالية ، يمكننا إضافة منطق ، كما علق spite ، لقياس المتوسط ​​وتحميلها تلقائيًا استنادًا إلى النطاق الآمن قبل الحظر. يمكن القيام بذلك مبدئيًا لكل نسيج كوحدة ، ولكن بعد ذلك يمكن تحسينه لتحميل الأجزاء بشكل متزايد للحصول على مواد أكبر.

سيكون requestIdleCallback أمرًا رائعًا ، لكنه غير مدعوم على نطاق واسع ، كما أنه يمثل مشكلة في جلسات WebVR

spite أنا أشعر بالفضول بشأن بالمشكلة ؟

لديّ THREE.UpdatableTexture لتحديث القوام تدريجيًا باستخدام texSubImage2D ، لكنني بحاجة إلى القليل من التغيير والتبديل في three.js. الفكرة هي إعداد العلاقات العامة لإضافة الدعم.

بخصوص requestIdleCallback (rIC):

• أولاً ، يتم دعمه على Chrome و Firefox ، وعلى الرغم من أنه يمكن تعبئته بسهولة ، إلا أن الإصدار متعدد التعبئة قد يتعارض مع الغرض قليلاً.

• ثانيًا: يجب استدعاء vrDisplay.requestAnimationFrame (rAF) بنفس الطريقة بدلاً من window.rAF عند التقديم ، وينطبق الشيء نفسه على rIC ، كما تمت مناقشته في هذا crbug . هذا يعني أن المحمل يجب أن يكون على دراية بالشاشة النشطة الحالية في جميع الأوقات ، أو سيتوقف عن إطلاق النار اعتمادًا على ما يتم تقديمه. إنه ليس معقدًا بشكل رهيب ، فهو يضيف المزيد من التعقيد إلى أسلاك اللوادر (التي يجب أن تؤدي وظيفتها بشكل مثالي ، بغض النظر عن حالة العرض). خيار آخر هو الحصول على الجزء في threejs الذي يدير وظائف متزايدة في السلسلة الرئيسية لمشاركة العرض الحالي ؛ أعتقد أنه من الأسهل القيام به الآن مع أحدث التغييرات على VR في threejs.

اعتبار آخر: لكي نتمكن من تحميل نسيج كبير واحد في عدة خطوات باستخدام texSubImage2D (256 × 256 أو 512 × 512) ، نحتاج إلى سياق WebGL2 للحصول على ميزات الإزاحة والقص. خلاف ذلك ، يجب قص الصور مسبقًا عبر قماش ، بشكل أساسي من جانب العميل قبل التحميل.

spite Good point ، لم أفكر في عدم استدعاء rIC عند التقديم ، اعتقدت في البداية أننا بحاجة إلى display.rIC لكنني أعتقد أنه يجب إرفاق .rIC بالنافذة ويتم استدعائي عندما تكون النافذة أو العرض كلاهما خاملا.
أعتقد أنني لم أسمع أي شيء متعلق بهذا في مناقشات مواصفات webvr ، ربما يحتوي

نتطلع إلى رؤية UpdatableTexture العلاقات العامة! :) حتى لو كانت مجرد عمل قيد التقدم ، فيمكننا نقل بعض المناقشة هناك.

ربما يمكن أن تصبح اللوادر شيئًا كهذا ...

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 );
        }
    }
} )();

إصدار الاقتراح الأول لـ THREE.UpdatableTexture

من الناحية المثالية ، يجب أن تكون جزءًا من أي مادة ثلاثية ، لكنني سأستكشف هذا النهج أولاً.

mrdoob أرى ميزة الحصول على نفس الرمز بالضبط إلى العامل ، إنه شعور خاطئ جدًا 😄. أتساءل ما هو تأثير تسلسل النص وإخفاءه وإعادة تقييمه ؛ لا يوجد شيء فظيع للغاية ، لكنني لا أعتقد أن المتصفح مُحسّن لهذه المراوغات 🙃

أيضًا ، من الناحية المثالية ، سيحدث جلب المورد نفسه في العامل. وأعتقد أن طريقة parser () في المتصفح ستحتاج إلى ملف importScripts من three.js نفسها.

لكن النقطة الوحيدة لتحديد لوادر المزامنة / غير المتزامنة ستكون ركلة الحمار!

mrdoob يمكن أن تكون الوظيفة builder عامة تمامًا ومشتركة لجميع برامج التحميل (WIP: https://github.com/kaisalmen/WWOBJLoader/blob/Commons/src/loaders/support/WWMeshProvider.js#LL215- LL367 ؛ التحديث: لم يتم عزله بعد في دالة). إذا كانت بيانات الإدخال مقيدة بكائنات js خالصة دون الرجوع إلى أي كائنات THREE (هذا ما يدور في ذهنك ، أليس كذلك؟) يمكننا إنشاء رمز عامل قابل للتسلسل دون الحاجة إلى عمليات الاستيراد في العامل (ما هو WWOBJLoader يفعل). يعد هذا أمرًا سهلاً بالنسبة إلى Geometry ، ولكن يمكن إنشاء المواد / Shaders (إذا تم تحديدها في الملف) فقط في المنشئ ويتم وصفها فقط بـ JSON من قبل بواسطة parser .
يجب على العامل الإشارة إلى كل شبكة جديدة وإكمالها ، على ما أعتقد. يمكن تغييره على النحو التالي:

// 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 ، في حين أن مكالمات الواجهة الأمامية هي report_progress و meshData وكاملة.

التحديث 2:

• هل تعتقد أن المحلل اللغوي يجب أن يكون عديم الجنسية؟ لا بأس بالنسبة لـ builder ، ولكن قد يكون من المنطقي أن تكون قادرًا على تعيين بعض المعلمات لضبط سلوك parser . هذا يعني أيضًا أن معلمات التكوين يجب أن تكون قابلة للتحويل إلى العامل بشكل مستقل عن التحليل
• سيكون من الرائع أن يكون لديك شيء مثل وظيفة التشغيل التي تأكل كائن تكوين عام. يمكن للمدير العام بعد ذلك إطعام أي محمل بالتعليمات (يعمل هذا الآن في فرع العموم المخصص WWOBJLoader ، راجع للشغل)
• جاري التطوير: WWOBJLoader2 يمتد الآن OBJLoader ويتجاوز التحليل. لذلك ، لدينا أحرف استهلالية للتحليل ، ولكن في فئات مختلفة. إنه يقترب من الاقتراح ، لكنه لا يتماشى حتى الآن. يجب توحيد بعض كود المحلل اللغوي وفي النهاية يجب دمج كلا الفئتين

هذا كل شيء في الوقت الراهن. نرحب بالتعليقات 😄

mrdoob تعجبني فكرة تأليف العامل من كود

يعجبني أسلوب استخدام تنسيق نقل مقتطع للتمرير بين العمال ، لأنه من السهل وضع علامة على هذه المصفوفات على أنها قابلة للتحويل عند الرجوع إلى مؤشر الترابط الرئيسي. في نهجي الحالي ، أستخدم طريقة .toJSON() في العامل ، ولكن بعد ذلك أذهب واستبدل مصفوفات JS للرؤوس والأشعة فوق البنفسجية وما إلى ذلك بنوع TypedArray المناسب ، وقم بتمييزها على أنها قابلة للتحويل عند الاتصال postMessage. هذا يجعل استخدام التحليل / الذاكرة أخف قليلاً في الخيط الرئيسي ، على حساب المزيد من استخدام المعالجة / الذاكرة في العامل - إنها مقايضة جيدة ، ولكن يمكن جعلها أكثر كفاءة من خلال تقديم تنسيق إرسال جديد كما تقترح ، أو عن طريق تعديل .toJSON() لتزويدنا اختياريًا بالمصفوفات المطبوعة بدلاً من مصفوفات JS.

الجانبان السلبيان اللذان أراهما في هذا النهج المبسط هما:

• يحتاج إلى إعادة كتابة لوادر النموذج الحالية. تستخدم العديد من برامج التحميل ثلاث فئات ووظائف مدمجة ذات مساحة اسم لأداء مهمتها ، لذلك ربما يتعين علينا سحب مجموعة صغيرة من أكواد three.js - ومع العمال يصبح هذا الأمر صعبًا
• يجب أن يلتقط تنسيق الإرسال التسلسل الهرمي للكائن بشكل صحيح ، بالإضافة إلى أنواع الكائنات المختلفة (Mesh ، SkinnedMesh ، Light ، Camera ، Object3D ، Line ، إلخ.)

spite بخصوص "أيضًا ، من الأفضل أيضًا أن يحدث جلب المورد نفسه في العامل". - كان هذا هو تفكيري عندما قمت لأول مرة بتطبيق محمل الأصول المستند إلى العمال لـ Elation Engine - كان لدي مجموعة من 4 أو 8 عمال ، وكنت سأقوم بتمرير وظائفهم عندما تصبح متاحة ، ومن ثم يقوم العمال بإحضار الملفات وتحليلها منهم ، وإعادتهم إلى الخيط الرئيسي. ومع ذلك ، فإن ما يعنيه هذا عمليًا هو أن التنزيلات ستمنع التحليل ، وستفقد الفوائد التي ستحصل عليها من التسلسل ، وما إلى ذلك إذا طلبتها جميعًا مرة واحدة.

بمجرد أن أدركنا ذلك ، أضفنا طبقة أخرى لإدارة جميع تنزيلات الأصول ، ثم يقوم برنامج تنزيل الأصول بإطلاق الأحداث لإعلامنا عندما تصبح الأصول متاحة. ثم نقوم بتمريرها إلى مجموعة العمال ، باستخدام أدوات النقل في بيانات الملف الثنائي لإيصالها إلى العامل بكفاءة. مع هذا التغيير ، تتم جميع التنزيلات بشكل أسرع على الرغم من وجودها في الخيط الرئيسي ، ويقوم الموزعون بتشغيل التجويف الكامل في المعالجة ، بدلاً من العبث بإبهامهم في انتظار البيانات. بشكل عام ، كان هذا أحد أفضل التحسينات التي أجريناها من حيث سرعة تحميل الأصول.

فيما يتعلق بموضوع تحميل النسيج ، فقد قمت ببناء دليل على مفهوم فئة FramebufferTexture ، والتي تأتي مع رفيق FramebufferTextureLoader . يمتد هذا النوع من النسيج إلى WebGLRenderTarget ، ويمكن تكوين أداة التحميل الخاصة به لتحميل مواد في مربعات مجزأة بحجم معين ، وتكوينها في حافظة الإطارات باستخدام requestIdleCallback() .

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

في هذا المثال ، ما عليك سوى تحديد حجم الصورة وحجم البلاط وسيبدأ عملية التحميل. أولاً نقوم بتهيئة النسيج إلى اللون الأحمر النقي. نبدأ تنزيل الصور (حجمها حوالي 10 ميغا بايت ، لذا أعطها قليلاً) ، وعندما يكتمل نغير الخلفية إلى اللون الأزرق. في هذه المرحلة ، نبدأ في تحليل الصورة باستخدام createImageBitmap() لتحليل الملف ، وعندما يتم ذلك ، قمنا بإعداد عدد من عمليات الاسترجاعات الخاملة التي تحتوي على استدعاءات أخرى لـ createImageBitmap() والتي تقسم الصورة بكفاءة إلى مربعات . يتم عرض هذه المربعات في الإطار المؤقت على عدد من الإطارات ، ويكون لها تأثير أقل بشكل ملحوظ على أوقات الإطارات مقارنة بفعل كل ذلك مرة واحدة.

ملاحظة - يبدو أن FireFox حاليًا لا يطبق جميع إصدارات createImageBitmap ، وهو يلقي حاليًا بخطأ بالنسبة لي عندما يحاول الانقسام إلى مربعات. نتيجة لذلك ، لا يعمل هذا العرض التوضيحي حاليًا إلا في Chrome. هل لدى أي شخص مرجع لخريطة طريق الدعم createImageBitmap في FireFox؟

هناك بعض عمليات التنظيف التي أحتاج إلى القيام بها ، هذا النموذج الأولي فوضوي بعض الشيء ، لكنني سعيد جدًا بالنتائج وبمجرد أن أتمكن من اكتشاف طريقة للتغلب على مشكلات المتصفحات (قماش احتياطي ، وما إلى ذلك) ، فأنا يعتبر استخدام هذا الخيار الافتراضي لجميع القوام في JanusWeb. يعد تأثير التلاشي أنيقًا نوعًا ما أيضًا ، ويمكننا حتى الحصول على نسخة خيالية ومتناسقة أولاً ، ثم تحميل البلاط ذي التفاصيل الأعلى تدريجيًا.

هل هناك أي أسباب متعلقة بالأداء أو الميزة يمكن لأي شخص أن يفكر في سبب كونها فكرة سيئة أن يكون لديك حاجز إطار لكل نسيج في المشهد ، بدلاً من مرجع نسيج قياسي؟ لم أتمكن من العثور على أي شيء عن max. التخزين المؤقت للإطارات لكل مشهد ، بقدر ما أستطيع أن أخبرك بمجرد إعداد إطار التخزين المؤقت ، إذا كنت لا تقوم بالعرض عليه ، فسيكون هو نفسه مثل أي مرجع نسيج آخر ، لكن لدي هذا الشعور وكأنني أفتقد شيئًا واضحًا فيما يتعلق لماذا ستكون هذه فكرة سيئة حقًا :)

jbaicoianu re: createImageBitmap من Firefox ، والسبب هو أنها لا تدعم معلمة القاموس ، لذلك فهي لا تدعم اتجاه الصورة أو تحويل مساحة اللون. يجعل معظم تطبيقات API عديمة الفائدة إلى حد كبير. لقد قدمت خطأين متعلقين بالمشكلة: https://bugzilla.mozilla.org/show_bug.cgi؟id=1367251 و https://bugzilla.mozilla.org/show_bug.cgi؟id=1335594

spite هذا ما

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

وهو أمر محير ، لأنني لا أرى أي إصدار من createImageBitmap في المواصفات التي تأخذ ImageBitmapFormat كوسيطة.

هل هناك أي أسباب متعلقة بالأداء أو الميزة يمكن لأي شخص أن يفكر في سبب كونها فكرة سيئة أن يكون لديك حاجز إطار لكل نسيج في المشهد ، بدلاً من مرجع نسيج قياسي؟ لم أتمكن من العثور على أي شيء عن max. التخزين المؤقت للإطارات لكل مشهد ، بقدر ما أستطيع أن أخبرك بمجرد إعداد إطار التخزين المؤقت ، إذا كنت لا تقوم بالعرض عليه ، فسيكون هو نفسه مثل أي مرجع نسيج آخر ، لكن لدي هذا الشعور وكأنني أفتقد شيئًا واضحًا فيما يتعلق لماذا ستكون هذه فكرة سيئة حقًا :)

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 وجميع الأمثلة ( الكود ). كلا اللودرين جاهزين الآن للدمج. نأمل أن يكونوا وفقًا لمخططك في وقت ما من الأسبوع المقبل اعتمادًا على وقت فراغي:
توجيه اختبار 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

لقد قمت باستخراج فئات LoaderSupport (مستقلة عن OBJ) التي تعمل كأدوات مساعدة وأدوات دعم مطلوبة. يمكن إعادة استخدامها للوادر المحتملة الأخرى القائمة على العمال. كل الكود أدناه ، وضعته تحت مساحة الاسم THREE.LoaderSupport لتسليط الضوء على اعتماده من OBJLoader2 :

• Builder : لبناء شبكة عامة
• WorkerDirector : إنشاء لوادر من خلال الانعكاس ، ومعالجة PrepData في قائمة الانتظار مع عدد مكوّن من العمال. تستخدم لأتمتة اللوادر بالكامل (عرض MeshSpray و Parallels)
• WorkerSupport : فئة الأداة المساعدة لإنشاء العمال من الكود الحالي وإنشاء بروتوكول اتصال بسيط
• PrepData + ResourceDescriptor : الوصف المستخدم للأتمتة أو لمجرد الوصف الموحد بين الأمثلة
• Commons : فئة أساسية محتملة للرافعات (حزم المعلمات العامة)
• Callbacks : (onProgress ، onMeshAlter ، onLoad) يُستخدم للأتمتة والتوجيه ويستخدم LoadedMeshUserOverride لتقديم معلومات من onMeshAlter (إضافة عادية في اختبار objloader2 أدناه)
• Validator : شيكات متغيرة خالية / غير محددة

mrdoobjbaicoianu OBJLoader2 يلتف الآن محلل كما اقترح (تم تكوينه مع المعايير المحددة عالميا أو تلقى PrepData للتشغيل). يتلقى Builder كل شبكة خام فردية ويعيد المحلل العقدة الأساسية ، ولكن بصرف النظر عن ذلك ، فإنه يتطابق مع المخطط.
لا يزال هناك بعض الكود المساعد في OBJLoader2 لتسلسل المحلل اللغوي الذي من المحتمل ألا يكون مطلوبًا.
يحتاج المنشئ إلى التنظيف لأن كائن العقد / المعلمة لوظيفة buildMeshes لا يزال متأثرًا بشدة بتحميل OBJ وبالتالي لا يزال يعتبر قيد الإنشاء.

يحتاج الكود إلى بعض التلميع ، ولكنه يصبح جاهزًا بعد ذلك للتغذية الراجعة والمناقشة والنقد ، وما إلى ذلك ... 😄

أمثلة واختبارات

OBJ Loader باستخدام التشغيل والتحميل:
https://kaisalmen.de/proto/test/objloader2/main.src.html
OBJ Loader باستخدام تشغيل غير متزامن و parseAsync:
https://kaisalmen.de/proto/test/wwobjloader2/main.src.html
الاستخدام المباشر للتشغيل غير المتزامن OBJLoader2:
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

تبدو جيدة! هل أنت على علم بهذه التغييرات في OBJLoader ؟ # 11871 565c6fd0f3d9b146b9434e5fccfa2345a90a3842

نعم ، أنا بحاجة إلى نقل هذا. اقترحت بعض قياسات الأداء القابلة لإعادة الإنتاج. سنبدأ العمل على الاثنين في نهاية هذا الأسبوع. متى تخطط لإطلاق r87؟ يمكن أن يجعل دعم N-gon ذلك اعتمادًا على التاريخ.

mrdoob و voila: https://github.com/mrdoob/three.js/pull/11928 دعم n-gon 😄

تحديث الحالة ( كود ):
يمكن للعمال الذين تم إنشاؤهم الآن تكوين أي محلل داخل العامل عبر المعلمات التي تتلقاها الرسالة. WorkerSupport تطبيقًا مرجعيًا ( رمزًا ) يمكن استبداله بالكامل برمز خاص إذا رغبت في ذلك أو إذا أصبح مطلوبًا.
سيقوم العامل بإنشاء وتشغيل المحلل اللغوي بالطريقة run للطريقة WorkerRunnerRefImpl ( Parser متاح داخل نطاق العامل ؛ this.applyProperties واضعو المكالمات أو خصائص المحلل اللغوي):

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 ]
);

كائن الرسالة يعتمد على Loader ، لكن تكوين المحلل اللغوي في العامل عام.
تم تحديث الرمز المستخدم من خلال الأمثلة المرتبطة في المنشور السابق بأحدث رمز.

أعتقد أن تطور OBJLoader2 واستخراج وظائف الدعم قد وصل الآن إلى نقطة تتطلب ملاحظاتك. عندما يتم نقل جميع الأمثلة من الريبو الخاص بها إلى الفرع أعلاه ، سأفتح بيانًا عامًا بملخص كامل ثم أطلب التعليقات

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

لمعلوماتك ، هنا عمل قيد التقدم للحصول على ImageBitmapLoader يستخدم عاملًا كما تمت مناقشته أعلاه. ربما الأكثر إثارة للاهتمام ، بعض الأرقام الصعبة على النتائج: https://github.com/mrdoob/three.js/pull/12456

createImageBitmap من Firefox ، السبب هو أنها لا تدعم معلمة القاموس ، لذلك فهي لا تدعم اتجاه الصورة أو تحويل مساحة اللون. يجعل معظم تطبيقات API عديمة الفائدة إلى حد كبير.

وهذا أمر مؤسف. ☹️

mrdoob هل لديك خطة لتبديل ImageLoader إلى ImageBitmapLoader في TextureLoader لأن ImageBitmap يجب أن يكون أقل حظرًا للتحميل إلى الزخرفة؟ createImageBitmap() يعمل على FireFox حتى الآن إذا مررنا الوسيطة الأولى فقط. (ربما لا نحتاج إلى تمرير الوسيطات الثانية والمزيد من خلال TextureLoader ؟)

return createImageBitmap( blob );

من المهم أن يدعم createImageBitmap () قاموس الخيارات. وإلا لا يمكنك تغيير أشياء مثل اتجاه الصورة (انعكاس Y) أو الإشارة إلى ألفا قبل المضاعفة. الشيء هو أنه لا يمكنك استخدام WebGLRenderingContext.pixelStorei مقابل ImageBitmap . من المواصفات :

_ إذا كانت TexImageSource عبارة عن ImageBitmap ، فسيتم تجاهل هذه المعلمات الثلاثة (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

البق على bugzilla (https://bugzilla.mozilla.org/show_bug.cgi؟id=1367251، https://bugzilla.mozilla.org/show_bug.cgi؟id=1335594) لم يمسها أحد ... اثنان سنوات الآن؟ لم أكن أعتقد أن الأمر سيستغرق كل هذا الوقت الدموي لإصلاحه.

لذا فإن المشكلة تكمن في أن الميزة "تقنيًا" مدعومة على FF ، ولكنها في الواقع غير مجدية. من أجل استخدامه ، يمكن أن يكون لدينا مسار لمتصفح Chrome يستخدمه ، وآخر للمتصفحات الأخرى لا يستخدمه. تكمن المشكلة في أنه نظرًا لأن Firefox يحتوي على الميزة ، فسيتعين علينا القيام باستنشاق UA ، وهو أمر سيء.

الحل العملي هو القيام باكتشاف الميزات: قم ببناء صورة 2 × 2 باستخدام cIB مع علامة الوجه ، ثم اقرأ مرة أخرى وتأكد من صحة القيم.

حول أخطاء FireFox ، سأتصل بهم داخليًا أيضًا. دعونا نرى ما إذا كنا بحاجة إلى حل بديل بعد أن نسمع خطتهم.

البق على bugzilla (https://bugzilla.mozilla.org/show_bug.cgi؟id=1367251، https://bugzilla.mozilla.org/show_bug.cgi؟id=1335594) لم يمسها أحد ... اثنان سنوات الآن؟ لم أكن أعتقد أن الأمر سيستغرق كل هذا الوقت الدموي لإصلاحه.

نعم آسف لذلك لم أتابعها حقًا لفترة -_-

لذا فإن المشكلة تكمن في أن الميزة "تقنيًا" مدعومة على FF ، ولكنها في الواقع غير مجدية. من أجل استخدامه ، يمكن أن يكون لدينا مسار لمتصفح Chrome يستخدمه ، وآخر للمتصفحات الأخرى لا يستخدمه. تكمن المشكلة في أنه نظرًا لأن Firefox يحتوي على الميزة ، فسيتعين علينا القيام باستنشاق UA ، وهو أمر سيء.

الحل العملي هو القيام باكتشاف الميزات: قم ببناء صورة 2 × 2 باستخدام cIB مع علامة الوجه ، ثم اقرأ مرة أخرى وتأكد من صحة القيم.

نعم ، أوافق على أن كلا الحلين سيئان حقًا ويجب أن نحاول تجنبهما قبل البحث في أي من هذه ، دعنا نرى ما إذا كان بإمكاننا إلغاء حظره من جانبنا

لقد أجريت اختبار أداء تحميل ImageBitmap . تحميل مادة في كل 5 ثوان.

يمكنك مقارنة الصورة العادية مقابل ImageBitmap.

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 JPG 4.4 ميجا بايت | 2048 × 2048 PNG 4.5 ميجا بايت |
| ---- | ---- | ---- |
| كروم ايمدج | 500 مللي ثانية | 140 مللي ثانية |
| كروم ImageBitmap | 165 مللي ثانية | 35 مللي ثانية |
| صورة FireFox | 500 مللي ثانية | 40 مللي ثانية |
| FireFox ImageBitmap | 500 مللي ثانية | 60 مللي ثانية |

( texture.generateMipmaps هو true )

افكاري

1. أداء أفضل 3 مرات مع ImageBitmap على Chrome. تحسن جميل جدا.
2. FireFox لديه مشكلة أداء ImageBitmap الآن؟ هل يمكنك تجربة جهاز الكمبيوتر الخاص بك أيضًا؟ المحاولة على الهاتف المحمول هي أيضا موضع ترحيب.
3. حتى مع ImageBitmap ، يبدو أن تحميل الملمس لا يزال يحجب الملمس الكبير. ربما نحتاج إلى تقنية تحميل جزئية تدريجية أو شيء ما لعدم الحظر.

حتى مع ImageBitmap ، يبدو أن تحميل الملمس لا يزال يحجب الملمس الكبير. ربما نحتاج إلى تقنية تحميل جزئية أو شيء ما لعدم الحجب.

أعتقد أن أحد الحلول لهذه المشكلة قد يكون استخدام تنسيق ضغط النسيج وتجنب JPG أو PNG (وبالتالي ImageBitmap ). سيكون من المثير للاهتمام رؤية بعض بيانات الأداء في هذا السياق.

نعم ، موافق. لكن أعتقد أننا ربما لا نزال نرى حظرًا للنسيج الكبير خاصة على الأجهزة منخفضة الطاقة مثل الهاتف المحمول. على أي حال ، قم بتقييم الأداء أولاً.

أو استخدام مجدول / requestIdleCallback texSubImage2D

rIC = requestIdleCallback؟

نعم ، لقد قمت بتحرير النينجا

نعم. نعم وافقت.

راجع للشغل ، لست على دراية بالقوام المضغوط حتى الآن. اسمحوا لي أن أؤكد فهمي. لا يمكننا استخدام نسيج مضغوط مع ImageBitmap لأن compressedTexImage2D لا يقبل ImageBitmap ، صحيح؟

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

عدت مرة أخرى لزيارة تجاربي القديمة على TiledTextureLoader - يبدو أنهم يتسببون الآن في تعطل برنامج تشغيل الفيديو وإعادة تشغيله :(

(تحرير: في الواقع ، يبدو أن تحميل أكبر نسيج (16 كيلو × 16 كيلو - https://baicoianu.com/~bai/three.js/examples/textures/dotamap1_25.jpg) مباشرة في الكروم هو ما يسبب الانهيار. كان هذا يعمل بشكل جيد ، لذلك يبدو أن هناك بعض التراجع في معالجة صور الكروم)

لقد أجريت بعض التجارب باستخدام مولدات requestIdleCallback و ImageBitmap و ES6 لتقسيم نسيج كبير إلى أجزاء متعددة للتحميل إلى وحدة معالجة الرسومات. لقد استخدمت إطارًا مؤقتًا بدلاً من Texture عادي ، لأنه حتى إذا كنت تستخدم texSubimage2D لملء بيانات الصورة ، فلا تزال بحاجة إلى تخصيص الذاكرة مسبقًا ، الأمر الذي يتطلب تحميل مجموعة من البيانات الفارغة إلى وحدة معالجة الرسومات ، بينما يمكن إنشاء مخزن الإطارات وتهيئته بمكالمة GL واحدة.

لا يزال مستودع هذه التغييرات متاحًا هنا https://github.com/jbaicoianu/THREE.TiledTexture/

بعض الملاحظات مما أتذكره من التجارب:

• ساعد requestIdleCallback بالتأكيد في تقليل الرسائل غير المرغوب فيها أثناء تحميل الزخارف ، على حساب زيادة وقت التحميل الإجمالي بشكل كبير
• مع القليل من العمل الإضافي ، يمكن التخفيف من ذلك عن طريق تحميل نسخة مصغرة من النسيج أولاً ، ثم ملء البيانات كاملة الدقة بوتيرة أكثر راحة.
• ساعدت مولدات ES6 في جعل الكود أسهل في الفهم ، وأسهل في الكتابة دون إهدار الذاكرة ، ولكن ربما لا تكون ضرورية حقًا لهذا.

كانت نتائجي متشابهة: كانت هناك مقايضة بين سرعة التحميل والخداع. (راجع للشغل لقد أنشأت هذا https://github.com/spite/THREE.UpdatableTexture).

أعتقد أنه لكي يعمل الخيار الثاني في WebGL 1 ، فإنك ستحتاج في الواقع إلى نسختين ، أو على الأقل معدِّلات لإحداثيات الأشعة فوق البنفسجية. في WebGL 2 ، أعتقد أنه من الأسهل نسخ المصادر ذات الأحجام المختلفة عن النسيج الهدف.

نعم ، مع texSubImage2D ، أعتقد أن هذا النوع من تغيير الحجم لن يكون ممكنًا ، ولكن عند استخدام أداة تخزين الإطارات ، أستخدم OrthographicCamera لتصيير مستوى مع جزء النسيج ، لذا فهي مجرد مسألة تغيير مقياس المستوى لـ التي رسم المكالمة.

حول مشكلة أداء ImageBItmap على FireFox ، فتحت خطأ في bugzilla

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

لقد كنت أتطلع لمحاولة فهم أفضل عندما يتم تحميل البيانات المرتبطة بالنسيج فعليًا في وحدة معالجة الرسومات وتصادف هذا الخيط. في حالة الاستخدام الخاصة بي ، لست قلقًا بشأن تحميل وفك تشفير ملفات jpeg / gif المحلية إلى مواد ، فأنا مهتم فقط بمحاولة تحميل بيانات النسيج مسبقًا على وحدة معالجة الرسومات. بعد قراءة هذا الموضوع يجب أن أعترف أنني لست متأكدًا تمامًا مما إذا كان يعالج كلتا القضيتين أم الأولى فقط؟ بالنظر إلى أنني أهتم فقط بالأخير ، هل أحتاج إلى البحث عن حل مختلف أم أن هناك شيئًا هنا من شأنه أن يساعد في فرض بيانات النسيج ليتم تحميلها في وحدة معالجة الرسومات؟