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

منشور ذو صلة: https://github.com/mrdoob/three.js/issues/3549

عليك استنساخ القوام لكل مادة (إضاعة الكثير من الذاكرة)

بأي معنى تضيع أطنان من الذاكرة؟

احتمالية الحاجة إلى تعويضات / تكرارات مشتركة للأشعة فوق البنفسجية على نسيج "مشترك" منخفضة

ماذا تقصد بذلك؟

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

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

فيما يتعلق بالبيان الثاني:

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

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

صرح mrdoob أنه يجب أن يكون بالشكل التالي كسبب لعدم وجوده لكل مادة ،

خريطة المواد
المواد خريطة الإزاحة
المواد
material.env
material.envOffset
material.env كرر
... إلخ.

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

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

ومع ذلك ، أود أيضًا أن أرى إزاحة / تكرار تم نقلها من Texture إلى المواد.

أعتقد أنه من المعقول افتراض أن الخرائط التالية لها نفس قيم الإزاحة / التكرار:

specularMap
normalMap
bumpMap
alphaMap
aoMap (future)
glossMap (future)
displacementMap (future)

الاستثناء الوحيد هو

هذه هي الطريقة التي يتم تنفيذها الآن. على الرغم من أن كل خريطة لها قيم الإزاحة / التكرار الخاصة بها ، إلا أنه لا يتم تكريمها.

لذلك ، يمكننا إضافة إلى MeshPhongMaterial ، MeshLambertMaterial ، MeshBasicMaterial ، و SpriteMaterial ، نضيف

mapOffset // or mapTranslate
mapRepeat // or mapScale

سنزيل offset و repeat من Texture .

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

IMHO ، هذه واجهة برمجة تطبيقات أكثر طبيعية.

أحاول أن أتذكر لماذا تم تنفيذ API بالطريقة التي كانت عليها. أتوقع أنه كان هناك سبب وجيه.

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

أعتقد أنه من المعقول افتراض أن الخرائط التالية لها نفس قيم الإزاحة / التكرار:
خريطة
...
alphaMap

FWIW ، هذا السلوك (التنفيذ الحالي) يسبب لي إحباطًا كبيرًا في هذه اللحظة بالذات. أحاول تحريك الكشف عن شبكة عن طريق إحداث حركة بينية لإزاحة alphaMap الخاصة بمواد الشبكة بشكل مستقل عن الخريطة المنتشرة (التي تظل ثابتة). بعد بعض الإحباط اكتشفت عبر https://github.com/mrdoob/three.js/pull/4987 وهذا الخطأ أن هذا غير ممكن.

jcarpenter ما هو "الخطأ" الذي تشير إليه؟ ما هو اقتراحك للتحسين؟

تصحيح: عن طريق "علة" قصدت هذه المشكلة. اختلاط بسبب الوقت المفرط في ثقافة بوغزيلا. : p أنا أفهم أن هذا ليس خطأ ، بل هو السلوك المقصود.

WRT إلى تحسن ، بناءً على تجربتي مع تطبيقات إنشاء المحتوى ثلاثي الأبعاد التقليدية مثل Cinema 4D ، أتخيل أن المستخدم قادر على كليهما:

• تحديد الإزاحة / المقياس / التكرار لكل نسيج داخل مادة ، بغض النظر عن القوام الآخر ، _ و_
• تحديد إزاحة / مقياس / تكرار المادة الأصلية

بدلاً من ذلك بالنسبة لحالة الاستخدام التي أعمل عليها ("محاولة تحريك كشف الشبكة") ، سيكون من الرائع أن يكون لديك خيار لـ wrapS و wrapT لا يلتف على الإطلاق. لكل ملف GIF المرفق من Cinema4D ، والذي يحتوي على خيار لتعطيل التبليط بالكامل لرسم خرائط UVW. استنادًا إلى اختبار مكثف إلى حد ما باستخدام أساليب wrapS و wrapT الحالية ، لا شيء من هذا القبيل ممكن. المعنى ، يبدو أن خياراتي لتحريك الكشف عن العناصر في three.js مقصورة على الوضع البيني وشفافية الشبكة بالكامل ... ما لم أفقد شيئًا ما.

متفق. تتمثل الخطة في تبسيط كل هذا (باستخدام مصفوفة واحدة 3 في التظليل) والحصول على إزاحة / تكرار (أو ترجمة / مقياس) لكل نسيج.

أي شخص يريد المساعدة في هذا سيكون موضع تقدير كبير!

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

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

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

تتمثل الخطة في تبسيط كل هذا (باستخدام مصفوفة واحدة 3 في التظليل) والحصول على إزاحة / تكرار (أو ترجمة / مقياس) لكل نسيج.

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

1. هل تقصد _per material.map_ بحيث يكون تحويل النسيج في المادة؟ لسوء الحظ ، هناك الكثير من الخرائط المادية. يمكننا الاستمرار في افتراض أن جميع تحويلات النسيج هي نفسها ، باستثناء Lightmap.
2. هل تريد دعم التناوب أيضًا؟ إذا كان الأمر كذلك ، فيجب عليك أيضًا إضافة مركز الدوران - إلا إذا كنت تريد توصيل مركز الدوران بمركز النسيج.

سيكون هذا التغيير محل تقدير كبير. إن الاضطرار إلى استنساخ القوام فقط لوضعها في قيم تكرار فريدة أمر مرهق للغاية. هل هذه هي الطريقة التي تقوم بها المكتبات الأخرى؟

1. هل تقصد _per material.map_ بحيث يكون تحويل النسيج في المادة؟ لسوء الحظ ، هناك الكثير من الخرائط المادية. يمكننا الاستمرار في افتراض أن جميع تحويلات النسيج هي نفسها ، باستثناء Lightmap.

أعتقد أنه يجب أن يكون لدينا mat3 لكل خريطة ويجب أن يتكون من خصائص Texture .

1. هل تريد دعم التناوب أيضًا؟ إذا كان الأمر كذلك ، فيجب عليك أيضًا إضافة مركز الدوران - إلا إذا كنت تريد توصيل مركز الدوران بمركز النسيج.

التناوب نعم. مركز أم لا ... لست متأكدًا ، ولكن بقدر ما أفهم ، يمكن ترميز كل هذا في mat3 للتظليل (لكل خريطة).

هنا هو عرض النموذج كيف يمكن ل Matrix3 يمكن أن تنتقل إلى تظليل وتمثل تحويل يحددها offsetX ، offsetY ، repeatX ، repeatY ، rotation ، rotationCenterX ، و rotationCenterY .

إذا كان center غير مسموح به كخيار ، فيجب أن يكون مثبتًا على ( 0.5, 0.5 ) .

نرحب بالتعليقات.

تحرير: تم تحديث العرض

هذا عظيم! : +1:: +1:

أعتقد أنني سأختار translation و scale (بدلاً من offset و repeat ).

ماذا يجب أن تكون بالضبط خصائص المواد الجديدة؟ هناك الكثير من الخرائط المادية.

ما الذي يجب إزالته من خصائص النسيج؟

أفترض أن wrapS/T يجب أن يظل على النسيج.

أعتقد أنه يجب إزالة texture.offset و texture.repeat .

أعتقد أن الخصائص الجديدة يجب أن تكون ... texture.translation ، texture.rotation ، texture.scale ، texture.center و texture.matrix . ربما نحتاج أيضًا إلى طريقة texture.updateMatrix() والتي سيتم استدعاؤها في وقت العرض. وهذا بالطبع يمثل تحديًا يتمثل في التأكد من أننا نقوم بذلك مرة واحدة فقط حتى إذا تم إعادة استخدام النسيج.

بالإشارة إلى عنوان هذا المنشور ، وإلى الحجج الموجودة في https://github.com/mrdoob/three.js/issues/5876#issuecomment -69483293 ، اعتقدت أن النقطة هي نقل هذه الخصائص إلى المادة.

/ pingbhouston للتعليقات.

أفكاري هي أن النسيج / التكرار يجب أن يتم تحميصه في الأشعة فوق البنفسجية قدر الإمكان. إنها أسهل. هذه هي الطريقة التي يقوم بها UE4 / Unity 5 في الغالب.

الاستثناء هو أن Unity 5 لديها القدرة على تحديد إزاحة / تكرار عالمي واحد لكل مادة يتم مشاركتها عبر جميع القوام - ولكنها لا تؤثر على ما يعتبر خرائط مخبوزة مثل lightMap أو ambientOcclusion Maps (تلك لا معنى للتعديل.)

السبب الذي يجعلني لا أدافع عن قدر كبير من المرونة هنا هو أن النماذج التي تم إنشاؤها بشكل احترافي تحتوي على UVs المناسب الذي يجعل هذا غير ضروري بشكل عام - أدوات إنشاء المحتوى لها طرق لتحميص ذلك. المشكلة الأخرى هي أن WebGL لديه حد أدنى منخفض بشكل يبعث على السخرية للأزياء الموحدة - 16 Vec4. إذا كان يجب أن يكون لديك تكرار / إزاحة لكل خريطة ، وسوف نحصل على الكثير من الخرائط قريبًا ، فإننا نهدر Fragment Uniforms مقابل القليل جدًا من القيمة.

لقد أضفت في الواقع تكرارًا / إزاحة ثم عناصر تحكم في السطوع / اكتساب لكل نسيج في Clara.io مؤخرًا وسأقوم بالتراجع عن هذه التغييرات لأنها تؤدي إلى تجاوز Fragment Uniforms على الأجهزة المنخفضة النهاية - مثل كل جهاز Apple iOS. على الرغم من أن التكرار / الإزاحة والسطوع / الكسب يعمل بشكل رائع على أجهزة الكمبيوتر المكتبية مع NVIDIA 980s ، إلا أنه يتعين علينا التصميم للجميع ، وليس للأجهزة المتطورة. ؛)

يجب أن نتعامل مع الزي الرسمي المتقطع باحترام ولا نستخدمه إلا عند الضرورة. أعتقد أن هذه ليست واحدة من تلك الحالات.

الاستثناء هو أن الوحدة 5 لديها القدرة على تحديد إزاحة / تكرار عالمي واحد لكل مادة

هذا هو ما تفعله شركة Three.js الآن - على الرغم من أنها تحصل على الإزاحة / التكرار من خريطة الانتشار ، وجميع مواد النسيج الأخرى تستخدم الإعداد من تلك الخريطة.

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

لسوء الحظ ، لم نحصل على الكثير من الإجماع حول هذا الموضوع.

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

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

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

التغيير الوحيد المقترح للتظليل هو استبداله

vUv = uv * offsetRepeat.zw + offsetRepeat.xy;

مع

vUv = ( uvTransform * vec3( uv, 1 ) ).xy;

نعم. ماذا عن هذا ... نضيف texture.dynamic ( false افتراضيًا) والذي ينتج:

vUV = uv;

إذا عيّن المستخدم texture.dynamic إلى true فسنحسب texture.matrix من texture.translation و texture.rotation و texture.scale و texture.center ، نمررها إلى البرنامج وننتج:

vUv = ( uvTransform * vec3( uv, 1 ) ).xy;

بالطبع ، إذا تغير texture.dynamic فسنحتاج إلى إعادة تجميع البرنامج.

بهذه الطريقة نحصل على أفضل ما في العالمين؟

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

1. من وجهة نظرك ، هل scale خاصية للملمس أم أن texture.scale خاصية للمادة؟ آمل أن يكون هذا هو الأخير ، لأن هذا هو كل ما يدور حوله هذا الموضوع.
2. لا نحتاج إلى خاصية .matrix . Matrix3 هو زي يحل محل الزي المادي offsetRepeat . يتم حسابها من المعلمات الأخرى في العارض وتمريرها إلى وحدة معالجة الرسومات تمامًا مثل أي زي موحد آخر.

1. من وجهة نظرك ، هل scale خاصية للملمس أم أن texture.scale خاصية للمادة؟ آمل أن يكون هذا هو الأخير ، لأن هذا هو كل ما يدور حوله هذا الموضوع.

أنا لا أتفق مع هذا الموضوع. لا أعتقد أنه يجب علينا تلويث المواد بـ mapMatrix ، envMapMatrix ، ... ولا mapTranslation ، mapRotation ، mapScale . أعتقد أنه أكثر نظافة إذا كان THREE.Texture يحتوي على translation و rotation و scale و ربما center .

1. لا نحتاج إلى خاصية .matrix . Matrix3 هو زي يحل محل الزي المادي offsetRepeat . يتم حسابها من المعلمات الأخرى في العارض وتمريرها إلى وحدة معالجة الرسومات تمامًا مثل أي زي موحد آخر.

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

أنا لا أتفق مع هذا الموضوع. لا أعتقد أننا يجب أن نلوث المواد باستخدام mapMatrix ، envMapMatrix ، ... ولا ترجمة الخرائط ، mapRotation ، mapScale. أعتقد أنه من الأنظف إذا كان ثلاثة ، يحتوي النسيج على ترجمة ، وتناوب ، ومقياس ، وربما توسيط.

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

يجب فصلtitansoftime image عن THREE.Texture . مثالي واحد واحد THREE.Image يمكن استخدامها من قبل مختلف THREE.Texture كل واحد مع اختلاف translation ، rotation ، ... تكوينات.

يجب أن يكون منفصلا صورةtitansoftime من THREE.Texture. من الناحية المثالية ، يمكن استخدام صورة واحدة من ثلاث صور مختلفة.

منطقي. هل يعمل الملمس. clone () بهذه الطريقة بالفعل ، أم يجب إعداده يدويًا؟

texture.clone() بهذه الطريقة ، لكن WebGLRenderer غير قادر على معرفة أن الصورة هي نفسها ، لذا فإن تحميل النسيج غير ضروري ...

أنا لا أتفق مع هذا الموضوع. لا أعتقد أننا يجب أن نلوث المواد باستخدام mapMatrix ، envMapMatrix ، ... ولا ترجمة الخرائط ، mapRotation ، mapScale. أعتقد أنه من الأنظف إذا كان ثلاثة ، يحتوي النسيج على ترجمة ، وتناوب ، ومقياس ، وربما توسيط.

هذا هو أساسا ما نفعله الآن. كل مادة لها خاصية offset الخاصة بها ، ولا يتم تكريم الإزاحات الفردية - يستخدم العارض نفس الإزاحة لكل خريطة للمادة.

FWIW ، أعتقد أننا يجب أن نفعل ما قلته في https://github.com/mrdoob/three.js/issues/5876#issuecomment -69483293.

لا أفهم سبب عدم سماح واجهة برمجة التطبيقات بما يريد jcarpenter القيام به (تحريك إزاحة alphaMap ، بينما يبقى map كما هو). يمكن للمرء أن يفعل ذلك في لوحة الرسم ، لكنني أعتقد أن هذه مهمة لوحدة معالجة الرسومات بدلاً من ذلك.

هناك الكثير من الأشياء التي يمكن للمرء القيام بها من خلال اللعب بإزاحات من خرائط مختلفة ... موازنة alphaMap فقط ، توسيع نطاق normalMap ، إلخ.

يبدو أن الحصول على uvTransform واحد فقط

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

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

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

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

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

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

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

تخيل ورقة سبرايت و 20 نقشًا. حاليًا ، نحتاج إلى 20 مادة مستنسخة و 20 مادة مستنسخة - تمامًا كما هو الحال في http://threejs.org/examples/misc_ubiquity_test2.html. (راجع للشغل ، لاحظ أن لدينا بالفعل SpriteMaterial.rotation .)

عند الانتقال إلى المادة ، سنحتاج إلى 20 مادة مستنسخة ونسيج واحد.

في الواقع ، عند نقل الإزاحة إلى العفريت ، سنحتاج إلى مادة واحدة ونسيج واحد.

تخيل ورقة سبرايت و 20 نقشًا. حاليًا ، نحتاج إلى 20 مادة مستنسخة و 20 مادة مستنسخة

أوم ، لم أكن أفكر في حالة الاستخدام هذه. شكرا!

سأفكر في هذا ...

أنا أؤيد عدم تحولات الأشعة فوق البنفسجية في النسيج.

لسببين: (1) أنها مربكة ، (2) هناك المزيد من الأحداث التي يجب نشرها ، و (2) إنها تبذير.

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

المزيد من انتشار الحدث: المشكلة الأخرى التي واجهتها في Clara.io هي انتشار الحدث عند محاولة تحريك معلمات النسيج. يحتاج المرء إلى كل نسيج لتتبع كل مادة تستخدمه ، ثم يخبر تلك المواد بأنها متسخة وتحتاج إلى إعادة حسابها. ليس من المستحيل القيام بذلك ، فقط المزيد من العمل.

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

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

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

Having only one uvTransform per material seems very very limiting.

أوافق تماما هنا. عدم وجود هذه الوظيفة محدود للغاية. هناك تأثيرات رائعة يمكن توفيرها هنا وهي ليست فقط لأن كل إزاحة مقفلة معًا.

ولكن كيف يمكن توفير هذه الوظيفة دون الاختناق على الحيوانات المستنسخة؟

أعتقد أن وجود القيم على المادة بدلاً من الملمس أمر منطقي لحالة الاستخدام الشائعة حيث سيتم مطابقة جميع القوام.

أوافق تماما هنا. عدم وجود هذه الوظيفة محدود للغاية. هناك تأثيرات رائعة يمكن توفيرها هنا وهي ليست فقط لأن كل إزاحة مقفلة معًا.

ولكن كيف يمكن توفير هذه الوظيفة دون الاختناق على الحيوانات المستنسخة؟

يمنحك THREE.ShaderMaterial أو THREE.RawShaderMaterial هذه القدرة ، ونظرًا لأنه لا يعمل حاليًا مع المواد العادية ، فهذا هو المسار الذي يجب عليك استخدامه على أي حال.

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

+1 لهذا يا رفاق.

سيكون مفيدًا جدًا عندما يكون لديك ورقة نقوش عملاقة (تعرف أيضًا باسم أطلس) وترغب في إعادة استخدام نسيجها في العديد من مثيلات THREE.Sprite .

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

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

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

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

الحل لهذا هو sunag 's NodeMaterial راجع للشغل.

إضافة +1 لهذا! سيجعل العمل مع أوراق الرموز المتحركة أجمل بكثير.

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

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

الحل لهذا هو sunag 's NodeMaterial راجع للشغل.

bhouston ، هل يمكنك تقديم ارتباط؟ لا يوجد مستودع عام تحت حساب sunag بهذا الاسم.

@ rhys-vdw يوجد هنا في فرع dev فقط:

https://github.com/mrdoob/three.js/tree/dev/examples/js/nodes

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

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

bhouston يمكنني إنشاء مثال باستخدام Node ، يبدو هذا جيدًا.

حول THREE.SpriteMaterial يمكنك الوصول إلى الإزاحة / المقياس لإنشاء spritesheet باستخدام هذا على سبيل المثال:

var offsetX = frameX / mapWidth;
var scaleX = mapWidth / frameWidth;

sprite.material.map.offset.x = offsetX;
sprite.material.map.repeat.x = scaleX;

https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/plugins/SpritePlugin.js#L53

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

... لذلك سوف يمنحك المرونة لتعديل الوصول إلى النسيج بشكل تعسفي.

tbh لا أعرف ماذا يعني ذلك. لتحريك مجموعة فردية من الزي الرسمي للتظليل من أجل "الإزاحة" و "التكرار" على أساس كل مادة.

حول THREE.SpriteMaterial ، يمكنك الوصول إلى الإزاحة / المقياس لإنشاء ورقة الرموز المتحركة باستخدام هذا على سبيل المثال ...

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

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

QuaziKb هل هناك لمشروعي ؟

على الرغم من أن هذا الأمر برمته لن يكون مشكلة ، كما قال WestLangley ، فإن ما يلي كان صحيحًا:

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

هل هذا صحيح؟

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

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

https://github.com/mrdoob/three.js/issues/7522

ولكن في الوقت الحالي حاول شخص ما إنشاء مثيل uuid مثل هذا :؟

THREE.Texture.prototype.createInstance = function() {

    var inst = this.clone();

    inst.uuid = this.uuid;
    inst.version = this.version;

    return inst;

}

إذا كنت تستخدم needsUpdate فقم بتحديث جميع الحالات version أيضًا.

مثال:

var uniqueTextureOffset = map.createInstance();
var material = new THREE.SpriteMaterial( { map: uniqueTextureOffset } );

الاحتفاظ بنفس uuid و version سيشارك texture على وحدة معالجة الرسومات.

https://github.com/mrdoob/three.js/blob/master/src/renderers/WebGLRenderer.js#L2832
https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProperties.js#L11

على الرغم من أنه حل مؤقت بالنسبة لي. أنا أؤمن بـ NodeMaterial للمستقبل.

هل يمكننا من فضلك نقل الأشعة فوق البنفسجية إلى مادة؟

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

(على الرغم من أنني أؤيد حقًا استخدام NodeMaterial لكل شيء في المستقبل ، إلا أنه من المؤلم التحول إليه.)

ما زلت أعتقد أن الحل لذلك هو إنشاء THREE.Image . https://github.com/mrdoob/three.js/issues/5876#issuecomment -81189892

THREE.Image

mrdoob ، هل يعني ذلك أنه سيتم استنساخ كلٍّ من Texture مع Material ؟

mrdoob كتب:

ما زلت أعتقد أن الحل لهذا هو إنشاء ثلاثة

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

أعتقد أن هذا الحل سيتطلب ضعف الكائنات الجديدة لمجموعة من العفاريت - نسيج واحد لكل كائن ومادة واحدة؟ أين هي الطريقة الأخرى التي تتطلب مادة جديدة لكل كائن؟

أعلم أن Unity تدعم التكرار / الإزاحة لكل مادة ، لكن أدوات VFX المتطورة مثل 3DS Max و Maya و Softimage لا تدعمها - فهي تحتوي فقط على عقدة Bitmap وعقدة Texture (التي تحتوي على كلٍ من عقدة Bitmap بالإضافة إلى رسم خرائط للأشعة فوق البنفسجية nod) ، وهو مشابه لتصميمmrdoob .

يشبه UE4 أيضًا ما يقترحهmrdoob ،

تقوم الأدوات المتقدمة بفصل الصورة / الصورة النقطية عن الملمس وتقوم أيضًا بفصل عقدة تعيين الأشعة فوق البنفسجية ، في هذا النموذج:

 -> Bitmap
 -> UVMapping

نحن لا نسمح بالكثير من خيارات UVMapping في StandardMaterial الرئيسية في الوقت الحالي. لكن الأنواع المختلفة من خرائط الأشعة فوق البنفسجية المستخدمة في UE4 ، و Maya ، و Softimage ، و 3DS Max ، ستكون هي القناة التي يجب استخدامها ، أو التحويل لتطبيقها ، أو استخدام الإحداثيات العالمية كمصدر ، أو إذا كان ينبغي على المرء القيام بإسقاط كروي ، أو مكعب ، أو مستو بناءً على المعلمات المطلوبة لتلك الإسقاطات.

يحتوي UE4 على مادة sprite التي تسمح بالتكرار / الإزاحة داخل المادة:

https://docs.unrealengine.com/latest/INT/Engine/Paper2D/Sprites/index.html

تتمتع Maya و Softimage و 3DS Max و UE4 بفصل الصورة النقطية / الصورة عن الملمس (ومن جيل الأشعة فوق البنفسجية) كما يقترحmrdoob ، ولكنها تستخدم أيضًا الرسوم البيانية

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

بالضبط 😊

ربما يكون في غير محله قليلًا لذكره ولكن أود أن أوصي بدمج PTEX في أقرب وقت ممكن.
http://ptex.us/PtexFile.html
إذا كانت هناك طريقة لعمل إسقاطات نموذجية إلخ / تحويلها إلى NodeTexture (؟) أو خيار يمثل نظامًا جديدًا أكثر قوة وشمولاً لرسم خرائط نسيج المستوى الأساسي؟ ... حسنًا ، ربما هذا شيء يجب مراعاته مسبقًا.
[بالإضافة إلى نفس النقطة:]
المفهوم مع ptex ليس في الحقيقة صورة ثنائية الأبعاد ولكن علاقة الأشعة فوق البنفسجية حتى تتمكن من الرسم / الختم / المشروع حول سطح معقد دون المفهوم / التحدي الخاص بكيفية الترجمة ثنائية الأبعاد إلى ثلاثية الأبعاد ، وهو أمر رياضي في أفضل الأحوال في المقارنة ( دائمًا تكافح تقنيًا مع التقويض).
لقد أوضحت للتو أن ptex كان يجب أن يكون أكثر منطقية وأن يكون أولوية منذ أكثر من 20 عامًا ولا ينبغي اعتباره امتدادًا أو مؤديًا من الدرجة الثانية ، ولكن بالنسبة لي حقًا العكس. يجب أن تكون هذه هي الطريقة الأصلية القديمة للقول بشكل صريح لكيفية عرض / ختم صورة ثنائية الأبعاد في نظام المستوى الأساسي الحقيقي الذي يعمل دائمًا من ptex. على أي حال ، مجرد فرض الفكرة يجب أن تكون متكاملة إن لم يكن من الأفضل أن تأخذ لفة مركزية أكثر.
شكرا لإتاحة الفرصة لي لتقديم اقتراحات نبيلة. كنت سعيدًا جدًا لأن ptex تم إجراؤه وفقًا للمواصفات. فكرت في الأمر بنفسي قبل أكثر من 10 سنوات ، لكن عندما كنت طفلاً لم يكن لديه القدرة على تحديد المواصفات الجديدة وما إلى ذلك. في الإدراك المتأخر ، كان يجب أن أرى أنه ربما كان بإمكاني أن أحاول إحداث فرق بدلاً من قائمة المراقب التي ما زلت أحافظ عليها. إذن فهذه محاولة للتراجع عن خطأ طويل الأمد.

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

MasterJames نوع من خارج الموضوع ... إنشاء موضوع جديد من فضلك؟

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

تضمين التغريدة هذا ما يتعامل معه NodeMaterial .

أليس الأمر كذلك أن Texture يستخدم نفس مثيل نسيج OpenGL لكل .clone() ، أم أنني أفتقد شيئًا ما. هل هو في الواقع يعيد تحميله لكل نسخة؟ إذا كان الأمر كذلك ، فهذه مشكلة خطيرة للغاية.

evrimoztamur ، أعتقد أنه ينسخ النسيج في كل مرة. يمكنك التحقق مما يحدث باستخدام WebGL Inspector .

حاولت حاولت كل نهج ما كنت أفكر فيه، بما في ذلكsunag الصورة الحل ، ولكن لا شيء يعمل. بناءً على تجربتي التي لم تسفر عن نتائج ، والمناقشة أعلاه ، فقد ألقيت نظرة حول كيفية تعامل المكتبات الأخرى مع الرسوم المتحركة للرموز المتحركة. لقد وجدت Sprite و SpriteManager API من

@ rhys-vdw: بالنسبة لمشروع حالي ، انتهى بي الأمر بنسخة مخطئة من MeshBasicMaterial:
https://gist.github.com/karimbeyrouti/790d2e1a8c0137b16bae

عند تعيين الخريطة ، يقوم هذا تلقائيًا بتعيين الزي الرسمي / التكرار (الموجود في مادة مخفية). يمكنك بسهولة تعيينها بشكل منفصل - سيوقفك ذلك عن الحاجة إلى استنساخ الزخارف في الوقت الحالي. (العمل مع r73)

لقد أرسلت للتو بيانًا عامًا يجب أن يعالج هذه المشكلة ، PR # 8278

كتب WestLangley :

أعتقد أنه من المعقول افتراض أن الخرائط التالية لها نفس قيم الإزاحة / التكرار:

خريطة
خريطة المرآة
خريطة عادية
نتوء خريطة
alphaMap
aoMap (المستقبل)
glossMap (المستقبل)
خريطة الإزاحة (المستقبل)

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

تحرير: حسنًا ، هذا على الأقل ما اعتقدت أنني قمت به. ربما تم تجاهل الحيلة. ويمكنني تحقيق نتائج مماثلة عن طريق إضافة ضوضاء في الظل أو شيء من هذا القبيل. عرض The WestLangley's Matrix3 رائع.

أعتقد أن هذا يحل مشكلة الحالات ذات الأشعة فوق البنفسجية المختلفة في Sprite. من الممكن تعديل vertex و pixel shader الحفاظ على نفس النسيج.

https://threejs.org/examples/#webgl_sprites_nodes

يستخدم SpriteNodeMaterial و Mesh مع PlaneBufferGeometry . الواجهة غير مناسبة لـ Sprite لكنها تعمل. ربما يمكن أن يتطور إلى SpriteMesh لجعل الواجهة أكثر ملاءمة

هذا الموضوع هو TL ؛ DR بالنسبة لي. لكنني اكتشفت للتو هذا الرمز في R68 (مشروع قديم ، نعم):

        // uv repeat and offset setting priorities
        //  1. color map
        //  2. specular map
        //  3. normal map
        //  4. bump map
        //  5. alpha map

        var uvScaleMap;

        if ( material.map ) {

            uvScaleMap = material.map;

        } else if ( material.specularMap ) {

            uvScaleMap = material.specularMap;

        } else if ( material.normalMap ) {

            uvScaleMap = material.normalMap;

        } else if ( material.bumpMap ) {

            uvScaleMap = material.bumpMap;

        } else if ( material.alphaMap ) {

            uvScaleMap = material.alphaMap;

        }

        if ( uvScaleMap !== undefined ) {

            var offset = uvScaleMap.offset;
            var repeat = uvScaleMap.repeat;

            uniforms.offsetRepeat.value.set( offset.x, offset.y, repeat.x, repeat.y );

        }

إذن أجل...

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

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

إذا كنت لن تنقل هذا المكان الذي ينتمي إليه ، على الأقل قل أنه ليس له تأثير في المستندات؟

sunag للعلاقات العامة:
https://github.com/mrdoob/three.js/pull/11531

واجهت مشكلة واحدة:
https://jsfiddle.net/f0j2v3s8/

يبدو أنه تم فقد الشفافية SpriteNodeMaterial ، ولا يوجد مزيج من المزج يمكنني استخدامه لتشغيل هذا المثال.

أيه أفكار؟

كتب karimbeyrouti :

عند تعيين الخريطة ، يقوم هذا تلقائيًا بتعيين الزي الرسمي / التكرار (الموجود في مادة مخفية). يمكنك بسهولة تعيينها بشكل منفصل - سيوقفك ذلك عن الحاجة إلى استنساخ الزخارف في الوقت الحالي. (العمل مع r73)

أعتقد أن هذا قد عفا عليه الزمن حيث تم تغيير uniforms.offsetRepeat إلى uniforms.uvTransform (r88).

فيما يتعلق بـ "إعادة استخدام أطلس نسيج مع حالات استخدام متعددة لـ Object3D" ، أقترح تجول بسيط:

1. تخزين بيانات UVs (الإزاحة ، التكرار) في كائن atlas json ؛
2. ربط زوج الوظيفة onBeforeRender\onAfterRender من Object3D ؛
3. في رد الاتصال قبل التصيير ، قم بتحميل بيانات UVs من كائن atlas json وضبطها على material.map ؛
4. في رد الاتصال بعد تقديمه ، أعد تعيينه مرة أخرى ؛

سينتج عنه:

1. نسيج واحد ومادة واحدة تتقاسمها كائنات متعددة ، لا يلزم استنساخ ولن يزيد عداد info.memory.textures ؛
2. ولكن لا تزال جميع الخرائط الأخرى (عادي ، ao ، إزاحة ...) يجب أن تتوافق مع نفس ترجمة الأشعة فوق البنفسجية ؛