Three.js: انقلبت المعايير على بعض أجزاء الشبكة التي تحتوي على مواد مزدوجة الجوانب

تم إنشاؤها على ٢٣ أكتوبر ٢٠١٩  ·  36تعليقات  ·  مصدر: mrdoob/three.js

وصف المشكلة

بالترقية من 107 إلى 108 ، لاحظت أن أجزاء من نموذجي تبدو الآن وكأنها انقلبت على المعايير. يحدث هذا فقط مع المواد ذات الوجهين.
انظر هنا: https://vaulted-jonquil.glitch.me/

هذا ما يجب أن تبدو عليه ، مع وضع مسافة بادئة للنمط على كلا العجلتين. هكذا كان الأمر في 107
Screen Shot 2019-10-23 at 3 51 35 PM

في 108 ، على الرغم من أن إحدى العجلات لها نمط يبدو وكأنها ظهرت:
Screen Shot 2019-10-23 at 3 51 27 PM

إصدار Three.js
  • [x] r108
المستعرض
  • [x] كل منهم
نظام التشغيل
  • [x] كل منهم
  • [ ] شبابيك
  • [] macOS
  • [] لينكس
  • [ ] ذكري المظهر
  • [] iOS
Bug Regression

التعليق الأكثر فائدة

يصلح ذلك!
Screen Shot 2019-11-21 at 10 02 54 AM

ال 36 كومينتر

pushmatrix هل يمكنك تأكيد ما إذا كان هذا النموذج يوفر أو لا يوفر الظلال الخاصة به؟ أشعر بالفضول لمعرفة ما إذا كان هذا متعلقًا بالرقم 11438.

لا أعتقد أنه يحدد الظل الخاص به

باستخدام حالة اختبار مختلفة ، يشير git bisect إلى # 17586 باعتباره PR الذي بدأ المشكلة إذا كانت الشبكة ذات وجهين ولها مقياس سالب X. كان ذلك في r.109 ، وليس r.108 ، مع ذلك.

لم يتم اختبار هذا على النموذج من هذا العلاقات العامة لأن هذا النموذج غير متوفر.

هنا هو اختبار GLB
عجلات. glb.zip

منذ 3 سنوات: https://github.com/mrdoob/three.js/issues/10331#issue -194807426

في الأساس ، يبدو أن ... gl_FrontFace لا يعمل بشكل صحيح مع المواد ذات الوجهين على وحدات معالجة الرسومات Adreno.

هل هذه _لا تزال مشكلة نحتاج إلى حلها؟

//

يبدو أن هذا النموذج يتم عرضه بشكل صحيح على جهازي إذا أزلنا حل Adreno في normalmap_pars_fragment :

#ifdef DOUBLE_SIDED

    // Workaround for Adreno GPUs gl_FrontFacing bug. See #15850 and #10331

    bool frontFacing = dot( cross( S, T ), N ) > 0.0;

    mapN.xy *= ( float( frontFacing ) * 2.0 - 1.0 );

#else

    mapN.xy *= ( float( gl_FrontFacing ) * 2.0 - 1.0 );

#endif

حسنًا ، أتذكر قراءة هذا التعليق أيضًا ؛ أعتقد أنني صادفته أثناء النظر إلى هذا الخطأ ، والذي تم إصلاحه على ما يبدو في r108 (على الأقل تم إصلاحه من أجلنا): https://github.com/GoogleWebComponents/model-viewer/issues/740

ربما يتعلق الأمر؟ FWIW ، لقد تلقيت بعض التعليقات حول وحدات معالجة الرسومات Adreno القديمة ، لذلك يبدو أنها لا تزال شائعة إلى حد ما.

فقط للتأكيد ، لا يزال هذا يحدث في dev :

Screen Shot 2019-10-25 at 4 06 51 PM

فقط للتأكيد ، لا يزال هذا يحدث في dev:

حق. ولكن ليس إذا قمت بإزالة حل خطأ Adreno.

ولكن ليس إذا قمت بإزالة حل خطأ Adreno.

ماذا عن إزالة الحل الآن ثم البحث عن حل مختلف؟ يؤدي التنفيذ الحالي إلى صور خاطئة بغض النظر عن النظام الأساسي الذي تستخدمه.

@ Mugen87 في هذه الحالة بالذات ، أعتقد أن الأشكال الهندسية هي مرايا لبعضها البعض ، لكنها تشترك في نفس الخريطة العادية.

أنا أتفق معك. لقد استثمرت ساعات عديدة في محاولة إيجاد حل بديل متوافق مع Adreno وصحيح في كل حالة استخدام.

عند فحص نموذج نموذج العجلة ، كل عجلة لها غلاف الأشعة فوق البنفسجية الخاص بها. لا تشترك في واحدة.
وترتيب الرأس معاكس.

لكن اتجاه الوجه هو نفسه ، على الأقل في Blender.

Screen Shot 2019-11-18 at 11 21 05 AM

لذلك لست متأكدًا مما إذا كان هذا خطأ في r108 ، أو إذا كان r108 يقوم الآن بعمل الأشياء بشكل صحيح. ¯_ (ツ) _ / ¯

pushmatrix هل يمكنك المقارنة مع Unity أو Blender؟

mrdoob

خلاط 2.8

Screen Shot 2019-11-20 at 8 27 27 AM

وحدة

Screen Shot 2019-11-20 at 8 40 30 AM

سكتشفاب

Screen Shot 2019-11-20 at 8 32 48 AM

تضمين التغريدة

من الصعب رؤية الوحدة لأن الضوء في نفس اتجاه الكاميرا ، لكن يبدو أن الوحدة خاطئة أيضًا؟ 🤔

mrdoob

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

ها هو في ضوء آخر ، حيث يبدو صحيحًا
Screen Shot 2019-11-20 at 2 36 16 PM

mrdoob للوجه الأمامي ترتيب لف بعكس اتجاه عقارب الساعة في three.js. عادةً ما يكون للأشعة فوق البنفسجية للرؤوس الثلاثة لكل وجه ترتيب لف عكس اتجاه عقارب الساعة على خريطة الأشعة فوق البنفسجية.

في هذا المثال ، _conjecture_ الخاص بي هو النموذج الموجود على اليسار يحتوي على UVs بعكس اتجاه عقارب الساعة والنموذج الموجود على اليمين يحتوي على _clock في اتجاه عقارب الساعة_ UVs. يتم عرض النموذج الأيمن بشكل غير صحيح في three.js عندما يكون doubleSide هو true .

AFAIK ، إزالة Adreno-workaround يعمل على إصلاح المشكلة لوحدات معالجة الرسومات غير Adreno.

pushmatrix يبدو أن مثال

WestLangley أنا أستخدم نفس خريطة البيئة التي يستخدمها

WestLangley ضوء اتجاه واحد يدور حوله. أشعر وكأنني أنظر إلى الوهم البصري

unity

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

تعد Threejs أيضًا متسقة ، ولكن بالتأكيد يبدو أن المرء يظهر دائمًا:
wheels

أشعر أن هناك شيئًا خاطئًا في الوحدة الأولى ...
مثل ذلك يحتاج إلى شيء مثل. material.normalMapScale.x = -1 .

تضمين التغريدة

mrdoob للوجه الأمامي ترتيب لف بعكس اتجاه عقارب الساعة في three.js. عادةً ما يكون للأشعة فوق البنفسجية للرؤوس الثلاثة لكل وجه ترتيب لف عكس اتجاه عقارب الساعة على خريطة الأشعة فوق البنفسجية.

في هذا المثال ، _conjecture_ الخاص بي هو النموذج الموجود على اليسار يحتوي على UVs بعكس اتجاه عقارب الساعة والنموذج الموجود على اليمين يحتوي على _clock في اتجاه عقارب الساعة_ UVs. يتم عرض النموذج الأيمن بشكل غير صحيح في three.js عندما يكون doubleSide هو true .

AFAIK ، إزالة Adreno-workaround يعمل على إصلاح المشكلة لوحدات معالجة الرسومات غير Adreno.

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

لقد ألقيت نظرة على كود التظليل المعني اليوم ويبدو أنهم لا يستخدمون "Per-Pixel Tangent Space Normal Mapping".

ووفقا لهذا المنصب ، Sketchfab تتوقع تعريفات الظل في الأصول أو هذه البيانات
تولد على أساس إحداثيات الأشعة فوق البنفسجية. هذا يتوافق مع ما رأيته في رمز GLSL.

إذا أضفت الظل إلى النموذج عبر BufferGeometryUtils.computeTangents() وقمت بتعيين Material.vertexTangents إلى true ، فستبدو النتيجة جيدة:

image

راجع للشغل: هل من المقبول مشاركة مقتطفات التعليمات البرمجية من Sketchfab في هذا المنشور ^^؟ بعد كل شيء ، إنه ليس مفتوح المصدر.

من أجل الاتساق ، يوجد هنا Sketchfab مع ضوء اتجاهي واحد يتحرك ذهابًا وإيابًا:

sketchfab

نعم ، هناك شيء واحد يجب أخذه في الاعتبار هو أن Sketchfab يقوم بمعالجة من نهايته عند تحميل نموذج ، لذلك من المحتمل جدًا أن يقوموا بإنشاء أشياء / تغيير الأشياء. ما تشاهده ليس بتنسيق glTF ولكن ملف glTF تم تحويله إلى تنسيقه الخاص.

pushmatrix هل يمكنك _please_ إثبات أن # 17958 يعمل مع نموذجك؟

three.js يحسب الظلال في تظليل الأجزاء. أعتقد أنه يعمل بشكل صحيح إذا تمت إزالة اختراق لاستيعاب بعض وحدات معالجة الرسومات Adreno التي عربات التي تجرها الدواب. انظر # 17958.

//

يحسب Sketchfab الظلال على وحدة المعالجة المركزية عندما تكون الظلال مطلوبة ولا يوفرها النموذج. ( donmccurdy هذا ما تتطلبه مواصفات glTF.)

يمكن لـ three.js القيام بذلك أيضًا ، ولكن هذا يعني إضافة الظلال الصحيحة إلى جميع الأشكال الهندسية المضمنة. سيتعين على three.js أيضًا تنفيذ خوارزمية MIKKTSpace لاستبدال ComputeTangents() . نظرًا لأن three.js تدعم كل من الأشكال الهندسية المفهرسة وغير المفهرسة ، أتوقع أن يتطلب ذلك جهدًا كبيرًا.

يصلح ذلك!
Screen Shot 2019-11-21 at 10 02 54 AM

حسنًا ، يبدو أن الحل هنا هو التراجع عن حل Adreno (# 17958) والتوصية على الأشخاص باستخدام BufferGeometryUtils.computeTangents() عندما لا يحتوي النموذج على الظل ويهدفون إلى دعم Adreno GPU (# 15850) .

يبدو جيدا؟

حل آخر هو استدعاء BufferGeometryUtils.computeTangents() في المحرك تلقائيًا عندما لا يتم توفيره وإزالة كل الكود الذي يحسب الظلال في تظليل الجزء ... 🤔

يتطلب BufferGeometryUtils.computeTangents() حاليًا فهرسًا لذلك لا يمكن استخدامه في النواة. ومع ذلك ، أعتقد أنه سيكون من الأفضل أن يقوم three.js بتوليد الظل وفقًا لـ MIKKTSpace في مرحلة ما ثم إزالة perturbNormal2Arb() .

كتب WestLangley :

سيعني إضافة الظلال الصحيحة لجميع الأشكال الهندسية المضمنة.

غيرت رأيي ... الظلال ليست مطلوبة بالضرورة. بدلاً من ذلك ، سأستعيد الطريقة BufferGeometry.computeTangents() و "تجاوز" هذه الطريقة لجميع الأشكال الهندسية المضمنة التي يمكننا من أجلها تحديد الظلال الدقيقة بشكل تحليلي.

//

حل آخر هو استدعاء BufferGeometryUtils.computeTangents () في المحرك تلقائيًا عندما لا يتم توفيره وإزالة جميع الكود الذي يحسب الظلال في تظليل الجزء ...

يبدو هذا صحيحا بالنسبة لي.

يتطلب BufferGeometryUtils.computeTangents () حاليًا فهرسًا لذلك لا يمكن استخدامه في النواة.

أعتقد أنه تم إصلاحه بسهولة. وسيتعين إصلاحه لدعم https://github.com/mrdoob/three.js/issues/17804#issuecomment -557135610.

سيكون من الأفضل إذا تمكنت three.js من توليد الظل وفقًا لـ MIKKTSpace في مرحلة ما ثم إزالة الاضطراب Normal2Arb () ...

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

سيكون من الرائع أن يقوم BufferGeometryUtils.computeTangents بتنفيذ نهج MikkTSpace - فهذه هي أفضل خوارزمية ، إذا كان يجب عليك حسابها مسبقًا. ولكن ربما يكون من الأسهل وضع MikkTSpace في أدوات مثل glTF-Pipeline أو gltfpack ، والتي يمكنها استخدام التنفيذ الأصلي الحالي ، والقيام بالحساب مقدمًا ، دون اتصال بالإنترنت.

تضمين التغريدة

ولكن ، لنقل ... في حالة الاستخدام <model-viewer> ، لا أعتقد أن هناك طريقة موثوقة لمعرفة ما إذا كان المستخدم لديه وحدة معالجة رسومات Adreno ولكننا نريد أن ننظر بشكل صحيح (https: // github. com / GoogleWebComponents / model-viewer / issues / 740).

هل يجب على <model-viewer> (والمشروعات الأخرى التي تريد دعم x-gpu) الاتصال بـ BufferGeometryUtils.computeTangents عندما لا يتم توفير الظل ، أم يجب على ثلاثة؟

تضمين التغريدة

هاها ، لقد أدركت للتو من أين تأتي هذه العجلات

https://bumbleride.com/products/era؟variant=20719969599599

Screen Shot 2019-11-22 at 3 52 19 PM

mrdoob 🕵

حسنًا ، دعنا نعود إلى الحل الآن.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات