يمكنني تأكيد glich على جهاز Pixel (1). ومع ذلك ، يبدو أن القطع الأثرية تحدث فقط عند استخدام KHR_materials_pbrSpecularGlossiness .

18042 قدم صقل هندسي. ومع ذلك ، يستبدل GLTFLoader رمز قطعة shader lights_physical_fragment بما يلي:

https://github.com/mrdoob/three.js/blob/3ba0553208cfc9113152f5f39b4036a448cf3f25/examples/js/loaders/GLTFLoader.js#L683 -L688

toji هل يمكنك تعديل نسخة GLTFLoader من تطبيقك باستبدال الكود أعلاه بـ:

var lightPhysicalFragmentChunk = [
    'PhysicalMaterial material;',
    'material.diffuseColor = diffuseColor.rgb;',
    'vec3 dxy = max( abs( dFdx( geometryNormal ) ), abs( dFdy( geometryNormal ) ) );',
    'float geometryRoughness = max( max( dxy.x, dxy.y ), dxy.z );',

    'material.specularRoughness = max( 1.0 - glossinessFactor, 0.0525 );// 0.0525 corresponds to the base mip of a 256 cubemap.',
    'material.specularRoughness += geometryRoughness;',
    'material.specularRoughness = min( material.specularRoughness, 1.0 );',
    'material.specularColor = specularFactor.rgb;',
].join( '\n' );

elalish حتى لو لم يحل هذا التصحيح المشكلة ، يجب أن نضيف هذا إلى GLTFLoader في أي حال ، أليس كذلك؟

@ Mugen87 نعم بالتأكيد. سأرى ما إذا كان بإمكاني إعادة عرض جهاز Pixel 3 أيضًا.

toji لا أعود على Pixel 3 مع Android 10 ، لذلك على الأقل ليس كل Pixels ...

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

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

آه ، السماء السوداء تعني في الواقع فشل جيل PMREM تمامًا ، ويرجع ذلك إلى هذا الخطأ والحل الغريب الذي وجدناه: https://github.com/GoogleWebComponents/model-viewer/pull/920. كنت أقصد الحصول على هذا في r112 ، لكنه تراجع من قبلي. من المحتمل ألا تكون ذات صلة بخلل البروتوكول الاختياري.

لقد قمت بإعادة إنتاج خطأ OP على جهاز OnePlus 5T في كل من Chrome و Firefox.

شكر! تم تطبيق التصحيح على GLTFLoader ولاحظ أنه تم تقليل عنصر النطاقات ، ولكن لم يتم إزالته.

قبل التصحيح:

بعد التصحيح:

في الأساس ، يبدو أنه أصلح أحد النطاقات. :) (تم التقاط لقطات الشاشة على Pixelbook ، ولكن تمت ملاحظتها أيضًا على Pixel 4 XL. ليس لدي أجهزة اختبار أخرى في الوقت الحالي.)

يسعدك تصحيح أي تغييرات أخرى تريد اختبارها ، أو يمكنك التحقق من https://github.com/toji/xr-dinosaurs إذا كنت تريد اختباره محليًا. (لا يتطلب أي مكون خادم.)

أما بالنسبة للكمال: فهو ليس زبدانيًا تمامًا ، لكنه ليس سيئًا.

شكرا لك. 😁 كنت تعمل بجد من أجل الأداء. في هذه الحالة أثناء التحديث إلى r112 ، لاحظت انحدار الأداء وسألت mrdoob عنه. اقترح أنه قد يكون التظليل القياسي الجديد والأكثر دقة واقترح استبدال بعض المواد بـ MeshLambertMaterial للتحقق. نظرًا لأن نموذج البيئة لم يتم تكوين مواد PBR بشكل صحيح على أي حال ، فقد أجبرتها على Lambert وتركتها هناك ، والتي استعادت أي انحدارات للكمال ثم بعضها (نظرًا لأنها تشغل جزءًا كبيرًا من منفذ العرض.) المواد القياسية لأنها مادة العرض "الرئيسية".

ملاحظة جانبية: Scene.environment لا يعمل حاليًا عندما يقوم GLTFLoader بتحميل الشبكات باستخدام مواد براقة / لمعان منذ أن يتحقق العارض من MeshStandardMaterial eg

https://github.com/mrdoob/three.js/blob/dd81aad5513d66e35e51f3a3b42555bc8aef5cbc/src/renderers/WebGLRenderer.js#L1633

ومع ذلك ، ينشئ GLTFLoader ShaderMaterial لكل مادة مرآوية / لمعان. أدركت هذا اليوم عند الاختبار باستخدام نموذج T-Rex ^ ^. حسنًا ، هناك سبب آخر لإكمال # 14099 أخيرًا.

لا يمكنني إعادة إنتاج عناصر النطاقات عند عدم استخدام خريطة بيئة. كل شيء يبدو جيدًا على Pixel (1) مع إعداد إضاءة بسيط مثل الإضاءة المحيطة والنقطة.

يبدو أن هناك المزيد من المشكلات المتعلقة بالمواد المادية باستخدام خريطة البيئة. اكتشف كيف تبدو الأمثلة التالية على هاتف Pixel 1 ، Android 10.

https://threejs.org/examples/webgl_materials_envmaps_exr

https://threejs.org/examples/webgl_materials_physical_clearcoat

https://threejs.org/examples/webgl_materials_envmaps_hdr

لا يمكنني إعادة إنتاج هذه القطع الأثرية على iMac.

يحدث شيء غريب جدًا على جهازي ، فأنا قادر على إعادة إنتاج هذه القطع الأثرية في جميع الأمثلة التي تستخدم PMREMGenerator . ولكن فقط عند تشغيلها محليًا ؛ عند مشاهدتها عبر الإنترنت (من صفحة threejs.org) تبدو جميعها صحيحة.

لم أواجه مثل هذه المشكلة مطلقًا وفقدت تمامًا أسبابها.

أنا أقوم بتشغيل Windows 10 مع GeForce GTX 750 TI ، لذلك لا أعتقد أن هذه مشكلة خاصة بالجهاز.

ولكن فقط عند تشغيلها محليًا ؛ عند مشاهدتها عبر الإنترنت (من صفحة threejs.org) تبدو جميعها صحيحة.

انتبه إلى أن إصدار dev به تغييرات غير موجودة في prod حتى الآن. هل يمكنك مراجعة الفرع الحالي master ثم إجراء اختبار محلي؟

هل يمكنك مراجعة الفرع الرئيسي الحالي ثم إجراء اختبار محلي؟

أول شيء جربته بعد ملاحظة هذا السلوك ، نفس النتائج. فضولي حقا.

هل يمكنك من فضلك الاختبار باستخدام نوافذ التصفح المتخفي؟ في بعض الأحيان ، قد يتم تخزين الأشياء مؤقتًا أو تتداخل ملحقات المستعرض مما قد يكون مربكًا حقًا

تمت المحاولة مع وضع التخفي ، نفس النتائج :(

أعتقد أنني أعرف سبب حدوث هذا النطاقات.
أثناء إنشاء mip ، يقوم الإصدار المحلي (غير الصحيح) بإنشاء نطاق أسود غير موجود في الإصدار المباشر.

يتم نسخ هذا أيضًا إلى مستويات منخفضة من mip.

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

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

على الأجهزة ذات النقطة العائمة الاسمية pixelRatio نحصل على إحداثيات mipmap "سيئة" على النسيج الذي تم إنشاؤه. لذلك هناك فجوات صغيرة ومناطق متداخلة. اكتشفت أيضًا أن جهازي يحتوي على devicePixelRatios مختلفًا اعتمادًا على ما إذا كنت أشاهد المثال محليًا (0.899 ..) أو عبر الإنترنت (1) ولهذا السبب كنت أعاني من هذه القطع الأثرية محليًا فقط.

لقد قمت بإعداد اختبار بسيط عن طريق تعطيل setPixelRatio ويبدو أنه يحل المشكلة ، إذا كان هذا هو الحال بالنسبة للآخرين ، فمن الأفضل إعادة بناء الطريقة التي يتعامل بها PMREMGenerator مع المشكلة.

toji @ plut0nist عقل فحص الأمثلة التالية على الأجهزة التي قدمت هذه القطع الأثرية؟

مثال DEV
مثال اختبار

@ sciecode شكرًا جزيلاً لك على اكتشاف السبب الجذري! سأرى ما إذا كان بإمكاني التوصل إلى حل.

sciecode : تم التحقق منه على

كنت أشعر بالفضول الشديد لماذا يحتاج PMREMGenerator لحساب devicePixelRatio على الإطلاق ، لذلك ذهبت للحفر. اتضح أن السبب في ذلك هو أن renderer.setViewport() يعامل DPR تلقائيًا في أي قيم ترسلها ، الأمر الذي يبدو أنه سلوك خاطئ لأهداف العرض بخلاف الإطارات الاحتياطية الافتراضية ، والتي يتم تخصيصها بقيم بكسل دقيقة لا حساب نسبة البكسل على الإطلاق. أقترح أن السلوك "الصحيح" هنا هو أن rendere.setViewport() داخليًا يجب أن يستخدم getTargetPixelRatio() ، والذي يُرجع 1 عندما يكون هدف العرض النشط هو أي شيء آخر غير الافتراضي. يمكنني بالتأكيد أن أرى كيف يمكن أن يؤدي ذلك إلى ظهور مشكلات التوافق المتخلفة.