Three.js: GLTFLoader: نتيجة نموذج اختبار Normal-Tangent غير صحيحة

شكرا لكتابة هذا @ cx20.

لمزيد من السياق فقط ، إليك بعض المعلومات والمشكلات ذات الصلة:

• لقد أبلغت عن مشكلة مماثلة على عارض ThreeJS glTF @ donmccurdy ، donmccurdy / three-gltf-viewer # 10. لكنني أعتقد الآن أن هذا خطأ في أداة تحميل glTF من ThreeJS ، وليس في العارض. لذا ، فإن هذا الإصدار الجديد في وضع أفضل من مشكلتي القديمة.

• في الإصدار الأقدم أعلاه ، كان النموذج يواجه السماء ، لكنني قمت لاحقًا بتدويره لمواجهة الأفق. هذا يجعل من السهل رؤية عندما تكون الانعكاسات غير صحيحة ، لأن الأفق يدور حول الجنون ، كما هو موضح أعلاه.

• تم تأكيد صحة استخدام النموذج للخريطة العادية من خلال المناقشة في KhronosGroup / glTF # 952.

• تم التشكيك في معالجة ThreeJS للخرائط العادية في # 11315.

• واجهت BabylonJS مؤخرًا مشكلة مماثلة ، تم الإبلاغ عنها هنا ، وتم إصلاحها هنا . إليك عرض توضيحي مباشر لمحمل glTF 2.0 من BabylonJS مع الإصلاح المطبق .

كتابة جيدة ، شكرا!

يبدو أن النموذج يتم عرضه بشكل صحيح مع إضافة هذا السطر:

materialParams.normalScale = new THREE.Vector2(-1, 1);

لكنني لست متأكدًا من أنني أفهم المشكلة جيدًا. قد يساعدك فهم # 11315 هنا.

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

وافق @ cx20 ، تم دمج هذا الإصلاح الآن في THREE.GLTF2Loader.

لقد أكدت أنه يتم إصلاحه.

نتيجة نموذج اختبار Three.js + Normal-Tangent:

لقد تراجع هذا ، في وقت ما بين r101 و r104:

راجع https://github.com/mrdoob/three.js/pull/15749 - الانحدار مقصود ، ويمكن تجنبه من خلال تضمين الظلال في النموذج.

من الناحية المثالية ، سيكون لدينا تطبيق JS لتوليد ظلمات mikktspace ، لحل هذه المشكلة تمامًا ، لكن هذا معقد إلى حد ما.

لم أكن على علم برقم 15749 حتى الآن. لقد فوجئت بهذا ، لقد اعتقدت أننا قمنا بعمل جيد بما يكفي في تحديد الظلال في glTF بحيث يمكن على الأقل تقريبها في وقت التشغيل.

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

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

إعادة فتح 😅

أظن أن هذا التغيير قد يكون قد كسر التعيين العادي لغالبية طرز glTF في ThreeJS.

لا أعتقد أنه شيء بهذه الخطورة - لقد أنشأنا دائمًا الظل الحقيقي في الظل باستخدام المشتقات ، وما زلنا نفعل ذلك. لقد قمنا سابقًا بتضمين اختراق ( normalScale.y *= -1 ) حدث لإصلاح نموذج الاختبار المحدد هذا ، ولكن حدث أيضًا كسر بعض الأمثلة الأخرى. ليس لدي أي تفسير للوقت الذي ساعد فيه ذلك أو لم يساعده ، لذلك أزلنا الاختراق بمجرد دعمنا للظلال المخزنة - وفي هذه الحالة كان من المؤكد أنه كان خطأ. الآن النماذج التي اعتمدت على الاختراق (ولا تشمل الظلال) معطلة ، وتم إصلاح النماذج التي كسرها الاختراق (ولا تتضمن الظلال).

لكنني أعتقد أن مجتمع glTF يجب أن يأخذ في الاعتبار هذه الأولوية العالية للحصول على نماذج بدون الظلال بشكل صحيح مرة أخرى ، حيث أعتقد أن معظم النماذج في هذه الفئة بشكل افتراضي.

أنظر فوق. بشكل عام ، أعتقد أننا نقوم بتصيير النماذج دون الظلال بشكل كافٍ. ومع ذلك ، فإننا لا ننشئ ظلمات mikktspace كما هو مطلوب في مواصفات glTF. على حد علمي ، لا يوجد تطبيق JS لذلك ، وتطبيق التظليل القائم على المشتقات هو ببساطة تقريب "جيد بما فيه الكفاية". نموذج العينة هذا هو حالة متطرفة متعمدة توضح حدود هذا التقريب.

يسعدنا أن يكون لدينا تطبيق جيل ظل من JS mikktspace ؛ سيكون ذلك إضافة جيدة إلى THREE.BufferGeometryUtils. لكن رمز mikktspace الرسمي (الأصلي) طويل إلى حد ما ، ولم أحفر بما فيه الكفاية حتى الآن لمعرفة مقدار ذلك المطلوب لتوليد الظلال.

لقد قمنا سابقًا بتضمين اختراق ( normalScale.y *= -1 ) حدث لإصلاح نموذج الاختبار المحدد هذا ، ولكن حدث أيضًا كسر بعض الأمثلة الأخرى

هل كسرت نماذج glTF الأخرى على وجه التحديد ، أم مجرد أمثلة عامة؟

هناك نوعان مختلفان من الخرائط العادية لمساحة الظل في البرية. يسمي Substance Painter هذه "DirectX Normals" و "OpenGL Normals" ، وهو ليس أعظم اسم لها. الاختلاف هو بالتحديد أن القناة y مقلوبة ، مما يعني أن جميع قيم القناة الخضراء في النسيج معكوسة. يعد ضرب y *= -1 الطريقة الصحيحة لتحويل أحدهما إلى الآخر. يستخدم ما يسمى بـ "DirectX Normals" نظام إحداثيات أعسر ، ويحدد glTF نظام إحداثيات يمنى للعادي / الظل / ظل البت.

ما أظن أنه يحدث هو أنه عندما تقوم ThreeJS تلقائيًا بحساب الظلال ، فإنها تتوقع أن الخريطة العادية قد تم تأليفها بنمط Y (DirectX) المقلوب ، وتعيد هذه القناة إلى الخلف لـ glTF ، لذلك يلزم الرجوع. ومع ذلك ، عندما يتم توفير الظلال ، لا حاجة إلى مثل هذا الوجه.

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

(هناك أيضًا بعض النقاش حول هذا من العام الماضي في KhronosGroup / glTF-Sample-Models # 174)

أود أن أستدعي جملة واحدة من

تستخدم المتجهات العادية اتفاقيات OpenGL حيث يكون + X صحيحًا و + Y للأعلى. + يشير Z تجاه العارض.

هذه الجملة هي التي تسمح بشحن النماذج بدون نواقل مماسة ، مما يوفر مساحة.

دعونا نختبرها. لقد صنعت هنا خريطة ارتفاع رديئة (خريطة نتوء) من بقعة في برنامج طلاء:

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

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

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

لذلك أعتقد أن المحول عبر الإنترنت قام بما طلبته glTF ، على الأقل بعد تكوينه بشكل صحيح. في الصورة الحمراء (X) ، يمكننا أن نرى المنحدر على اليمين به بكسلات بيضاء (+1.0) ، مشيرًا إلى متجه X على الحافة اليمنى للصورة. على الجانب الأيسر من الصورة الحمراء ، تشير وحدات البكسل السوداء (-1.0) إلى متجه X في الجانب الأيسر من الصورة. في الصورة الخضراء (Y) ، البيكسلات البيضاء على طول المنحدر العلوي من نقطة التضاريس ، تشير إلى متجه Y في أعلى الصورة. تعتبر قيم Z هي الأقل بديهية ، ولكن تذكر أن طرف النتوء واللوحة الخلفية نفسها تشير إلى العارض ، وأن المنحدرات على جميع الجوانب تشير بعيدًا ، لذلك تكون جميعها أغمق بالتساوي.

ماذا لو قمنا بتحميل هذا في Blender Eevee ، والذي (تمامًا مثل glTF) يقبل خرائط OpenGL العادية؟ ماذا يحدث إذا تم تدوير خريطة الأشعة فوق البنفسجية أو حتى تحجيمها لعكسها؟

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

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

إذا قمت بتحميل إحدى هذه الخرائط العادية على غرار DirectX في Blender Eevee ، فهل ما زلت أتوقع أن تعمل؟

رقم الخلاط كان يتوقع + Y up. الرياضيات خاطئة ، وخط الأفق المنعكس يدور في كل مكان.
يحدث نفس الشيء إذا قمت بتحميل خريطة عادية بنمط OpenGL في محرك كان يتوقع + Y أسفل.

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

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

ما أفعله حاليًا هو إصدار TangentW المعكوس من MikkTSpace ليتوافق مع هذه العينة المعينة ، ولكن هذا ما حدث للعمل.

هل كسرت نماذج glTF الأخرى على وجه التحديد ، أم مجرد أمثلة عامة؟

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

الاختلاف هو بالتحديد أن قناة y معكوسة ، مما يعني أن جميع قيم القناة الخضراء في النسيج معكوسة. يعد ضرب y * = -1 الطريقة الصحيحة لتحويل أحدهما إلى الآخر.

شكرًا ، هذا تبرير أفضل بكثير لـ "الاختراق" مما كان لدينا عندما طبقناه. 😇

من المؤسف أن المواصفات تستدعي mikktspace ومعظم التطبيقات تقترب من ذلك مع مشتقات مساحة الشاشة.

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

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

لست متأكدًا من أن خوارزمية MikkTSpace سهلة التمثيل كصيغة منفصلة ... هل تطلب بديلاً عن كود MikkTSpace الأساسي؟ أو بعض المعلومات الإضافية بخلاف تعليمات استخدام MikkTSpace؟ تضمين التغريدة

بالنسبة إلى المشكلة الأصلية ، يبدو أنه يجب علينا استعادة المضاعف normal.y *= -1 مكان ما. هناك ثلاثة أماكن محتملة للقيام بذلك:

• (أ) في GLTFLoader ، للشبكات التي لا تحتوي على مماسات
• (ب) في GLTFLoader ، لجميع الشبكات
• (ج) في WebGLRenderer ، لجميع الشبكات

إذا كانت threejs تستخدم بالفعل اصطلاح DirectX وعلى سبيل المثال Blender لا تستخدم ، يمكنني رؤية حالة لـ (c). من أجل حل سريع وآمن ، فإنني أميل إلى الذهاب مع (أ).

ما أظن أنه يحدث هو أنه عندما تقوم ThreeJS تلقائيًا بحساب الظلال ، فإنها تتوقع أن الخريطة العادية قد تم تأليفها بنمط Y (DirectX) المقلوب.

لا ، لا تفترض شركة Three.js أن ...

يفترض three.js أن + Y هو "up" لمساحة الظل ، وأن زيادة V هي "up" لمساحة الأشعة فوق البنفسجية.

وهذا يعني أن three.js تفترض أن uv (0 ، 0) موجود في الزاوية اليسرى السفلية من النسيج ، بينما تفترض مواصفات glTF أعلى اليسار. هذا هو سبب تعيين GLTFLoader texture.flipY إلى false . (يعين three.js texture.flipY إلى true افتراضيًا.)

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

بالنسبة لنماذج glTF المؤلفة بشكل صحيح ، فإن هذا الافتراض غير صحيح. ومع ذلك ، يجب أن تكون قادرًا على التعويض عن طريق تعيين normalScale.y = - 1 لأي نموذج _ يتقيد بشكل صحيح بمواصفات glTF_.

يبدو لي أيضًا أنه يمكننا إصلاح هذا تلقائيًا من خلال تكريم علامة flipY في التظليل.

إذا كان إعداد normalScale.y لا يعمل ، فهذا يعني أن شيئًا آخر يحدث.

شكرا على هذا التوضيح. أعتقد أن لدينا طريق إلى الأمام هنا.

يبدو لي أيضًا أنه يمكننا إصلاح هذا تلقائيًا من خلال تكريم علامة flipY في التظليل.

نعم ، باستثناء الحالات التي توفر فيها glTF ناقلات المماس الخاصة بها ، أليس كذلك؟ أتوقع أن الظلال المحسوبة تلقائيًا فقط هي التي تحتاج إلى اختبار flipY والنفي المقابل لـ y .

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

تحرير: أعتقد أنني تأكدت من صحة متجهات الظل المصدرة ، ولا تحتاج إلى أي تقليب على شكل Y. يمكنني نشر مزيد من التفاصيل حول ذلك إذا لزم الأمر.

ولكن يبدو أن الإجراء الصحيح هو قلب normalScale.y فقط عندما يتم استخدام الظلال المُنشأة تلقائيًا (غير المظللة) مع العلم flipY . أفكار؟

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

اقترحت أيضًا أننا قد نتمكن من إصلاح هذا تلقائيًا من خلال تكريم علامة flipY في التظليل. لم أقل أننا سنصلح هذا تلقائيًا ، ولكننا نقلب normalScale.y . لا أعتقد أنه يجب علينا تغيير إعدادات المستخدم.

على أي حال ، قبل أن نسير في هذا المسار ، أعتقد أنه من الضروري أن نتحقق من هذه الفرضية:

[Y] يجب أن تكون قادرًا على التعويض عن طريق تعيين normalScale.y = - 1 لأي ​​نموذج يلتزم بشكل صحيح بمواصفات glTF.

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

لا أعتقد أنه يجب علينا تغيير إعدادات المستخدم.

نعم ، معذرةً ، لم أكن أنوي إملاء هذا النوع من تفاصيل التنفيذ. أحاول فقط التأكد من عدم وجود سوء فهم لما يعنيه تكريم flipY flag_ رياضيًا ، لغرض إنشاء ظل مساحة الشاشة.

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

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

أفترض أن هذا وثيق الصلة بهذه المسألة؟ https://github.com/KhronosGroup/glTF-Sample-Models/issues/174

WestLangley هذا ما وجدته حتى الآن. بشكل افتراضي ، يبدو khronos-NormalTangentTest (لا يتضمن الظلال) خاطئًا:

إذا قمت بتعيين normalScale.y = -1 ، فلا يزال الخطأ:

إذا قمت بدلاً من ذلك بتعيين normalScale.x = -1 ، فإنه يبدو صحيحًا:

مع استثناء محتمل أن العرض يبدو منقسمًا بعض الشيء ، خاصة على عاكس الذهب. هل هذا متوقع مع تقريب مساحة الشاشة ، أم مؤشر لخلل آخر؟

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

elalish هذا

هذا المثال هو IMHO مبهم جدا. نحتاج إلى حالة اختبار متماسكة توفر مرئيات كافية لفهم ما يحدث.

راجع للشغل ، اعتدنا أن يكون لدينا VertexTangentHelper (# 3511) ، والذي يمكن إحياؤه لدعم هندسة المخزن المؤقت.

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

على الرغم من دوران الأشعة فوق البنفسجية ، فإن صورة الخريطة العادية متسقة تمامًا حول الاتجاه الذي يشير إليه المتجهات ، عندما يتم عرض الخريطة العادية كصورة ثنائية الأبعاد. في العرض ثنائي الأبعاد للصورة ، تحتوي الجوانب اليمنى لجميع نصفي الكرة الأرضية على قيم قناة حمراء عالية ، والحواف العلوية لجميع نصفي الكرة لها قيم قناة خضراء عالية ، بغض النظر عن إحداثيات الأشعة فوق البنفسجية. يتبع ذلك مواصفات glTF التي تشير إلى أن اللون الأحمر (+ X) يشير إلى الجانب الأيمن من النسيج في مساحة الأشعة فوق البنفسجية ، والنقاط الخضراء (+ Y) عند الحافة العلوية للنسيج في مساحة الأشعة فوق البنفسجية. لا يحتاج المرء إلى متجهات الظل الموردة لإنجاز هذا العمل: تقدير بسيط لمساحة الشاشة عمومًا للاتجاه الذي يكون فيه محور + U لمثلث معين كافٍ للعمل على متجهات المماس وثنائية الظل ، كما يفعل BabylonJS و CesiumJS ، وبالطبع ThreeJS يعمل كذلك ولكن مع بعض قلب المحور العادي غير المبرر حتى الآن.

هناك نقطة ارتباك معروفة مع استخدام glTF لعلم flipY ، عكس إحداثيات V في مساحة الأشعة فوق البنفسجية ، والتي أعتقد أنك تدركها جيدًا بالفعل. لطالما اشتبهت في أن هذا يلعب دورًا في الانقلاب العادي غير المبرر.

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

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

WestLangley أحب هذا الاختبار فقط لأنه أفضل ما رأيته ، ويعرف أيضًا باسم الوحيد. سأكون سعيدًا باستخدام أي نموذج اختبار آخر أشرت إليه.

أيضا ، الحبكة كثيفة: الاختبار الأصلي عبارة عن مادة ذات وجهين. بسبب # 17804 ، قررت أن أجربها من جانب واحد. لا يزال الأمر خاطئًا بشكل افتراضي ، لكنني الآن أحصل على الإجابة الصحيحة عند تعيين normalScale.y = -1:

على الأقل أتمنى أن نتفق على أن تغيير الوجهين لا يجب أن يؤثر على تصيير الجانب الأمامي؟

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

emackey شكرا لك على كل ما تبذلونه من العمل على هذا. أنا أقدر ذلك كثيرا جدا. أفهم جميع القضايا المختلفة التي يمكن أن تنشأ مع الفنانين - والقضايا التي يجب التغلب عليها.

ربما تكون على استعداد للعمل مع elalish وتقديم أي نماذج

elalish لقد تناولنا هذه المشكلات سابقًا. في وقت من الأوقات كان لدي انطباع بأن كل شيء يعمل. إذا كانت هناك حالة اختبار بسيطة ، فيمكنني استخدام bisect لتحديد مكان تعطل الأشياء.

مكعب لامع مع عوارض ملحومة وخريطة عادية مقابلة مصممة لجعله على شكل مكعب بدلاً من دائري.

تم: normal_map_flat.zip . أخذت مثال الظل ، الذي كتبه فريق دراكو ، وأنشأت نسخة إضافية بدون سمة الظل.

في وقت من الأوقات كان لدي انطباع بأن كل شيء يعمل.

أعتقد أننا وصلنا إلى حالة يعمل فيها كل شيء _إذا_ يشتمل النموذج على الظلال. إذا لم يكن الأمر كذلك ، فعادة ما تكون الأمور على ما يرام ، ولكن هناك بعض حالات الحافة المحتملة خاصة حول طبقات الأشعة فوق البنفسجية. في هذه الحالة ، ننصح المستخدمين بإضافة الظل. أو ، كما ورد emackey في https://github.com/mrdoob/three.js/issues/11438#issuecomment -507027586 ، ربما يجب علينا استعادة normalScale.y *= -1 flip في GLTFLoader ، فقط في الحالات التي تكون فيها الشبكة يحذف ظل الرأس.

donmccurdy شكرا. لقد نفد الوقت لهذه المشكلة اليوم لكنني ما زلت أعاني من جوانب المكعب المسطح. إذا قمت بتحرير النموذج الخاص بك للحصول على سطح لامع ( metallicFactor: 1, roughnessFactor: 0.1 ) ، فسترى الانعكاسات في جوانب المكعب تسبح حولها قليلاً.

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

أعتقد أنني أرى اختلافًا طفيفًا في الطريقة التي يتم بها استيفاء المتجهات العادية (أو مساحة TBN) بين الرؤوس عبر وجه المثلث ، في SP مقابل Blender مقابل محركات WebGL المختلفة. لقد استخدمت Gimp لتشغيل "اختلاف" بين مخبز SP مقابل Blender bake ، وظهر باللون الأسود (قيم RGB متطابقة) في كل رأس ، لكن المسافة بين القمم تظهر اختلافات دوامة ذات شدة خافتة للغاية.

أتوقع تأثيرات منزل مرح خفية ، ولكن ليس ما أحصل عليه حاليًا (إصدار no tangents):

الإصدار with tangents ليس أفضل حقًا ، مما يقودني إلى التساؤل عما إذا كان هذا حقًا glTF صالحًا:

emackey هل تشعر أنك مؤهل لإخبارنا ما إذا كان أحد هذين الطرازين @ donmccurdy المقدمين أو كلاهما هو في الواقع صالح glTF؟ إذا كانوا كذلك ، أعتقد أن لدينا مشكلة كبيرة.

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

تبدو الانعكاسات جامحة في BabylonJS أيضًا:

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

ما زلت موافقًا على استعادة المضاعف normalScale.y *= -1 ، لكن الافتقار إلى أمثلة للمشكلة يبدو وكأنه مؤشر على أن المشكلة بسيطة ، وليس إشارة إلى أننا بحاجة إلى إنشاء مثل هذه الأمثلة المتطرفة.

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

تصحيح: https://github.com/mrdoob/three.js/issues/17804 يشير إلى أن شيئًا ما ربما يكون قد تراجعت بالفعل مع المواد ذات الوجهين. يبدو أن هذا يستحق المزيد من البحث ، على الرغم من أنه من أجل البساطة والعقل ، ربما ينبغي علينا ترك المكعب الملعون وحده في الوقت الحالي. 😇