Three.js: خطأ SkinnedMesh عندما يكون بعيدًا عن جذر المشهد (0،0،0)

تم إنشاؤها على ٩ فبراير ٢٠١٨  ·  113تعليقات  ·  مصدر: mrdoob/three.js

أعتقد أنني وجدت خطأ في SkinnedMesh (تم اختباره على iPhone 6 و 8).

إذا تم الإبلاغ عن هذا بالفعل ، أنا آسف ، لم أجده في قائمة المشكلات :(

يبدو أن مظهر gpu لا يعمل بشكل صحيح ويصبح مجنونًا على الهاتف المحمول.
عندما يتحرك SkinnedMesh أو يتحرك في مواضع عالية القيمة (على سبيل المثال: x: 0 ، y: 0 ، z: 1000) ، لم يعد الجلد دقيقًا ويبدأ رقصة العنكبوت.

حجم الشبكة يؤثر على الخطأ.

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

أجريت العديد من الاختبارات قبل نشر هذا ... بحثًا عن دليل في عمليات تصدير الرسوم المتحركة الخاصة بي ، لكنني اكتشفت أن الخطأ يحدث مع أي نوع من التنسيقات (GLTF و FBX و Collada و JSON ...) ونماذج من ThreeJS repo.

هذا أمر مزعج للغاية لأن هذا يعني أننا غير قادرين على تطوير لعبة عداء بسيطة مع تشغيل الصورة الرمزية (الصورة الرمزية تتزايد بعد ذلك) دون مواجهة هذه المشكلة: ((
ما زلت لا أعرف كيف سأديرها لأن MorphTargets ليست خيارًا :(

أتمنى أن تساعدوا هنا يا رفاق.

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

تظهر فقط على الهاتف المحمول (ض = 10000):
http://cornflex.org/webgl/skinning-bug.html

مع ضبط floatVertexTextures على false (z = 10000):
http://cornflex.org/webgl/skinning-bug2.html

تزداد سوءًا مع المسافة (زيادة z):
http://cornflex.org/webgl/skinning-bug3.html

بعيد جدًا عن المركز (z = 70000000)> يظهر الخطأ أيضًا على سطح المكتب ولكن بالتأكيد بسبب مشكلة دقة التعويم:
http://cornflex.org/webgl/skinning-bug4.html

معاينة الفيديو في بيئة لعبتي:
هذا عالم مقياس واقعي (1.0 م = 1.0 وحدة threejs).
يظهر الخطأ فقط بعد 50-60 مترًا من جذر المشهد ويزداد سوءًا مع المسافة:
http://cornflex.org/webgl/skin-bug.mp4

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

إصدار Three.js
  • [x] ديف
  • [x] r89
  • [x] ...
المستعرض
  • [] كل منهم
  • [ ] كروم
  • [ ] ثعلب النار
  • [ ] متصفح الانترنت
  • [x] سفاري
نظام التشغيل
  • [] كل منهم
  • [ ] شبابيك
  • [] macOS
  • [] لينكس
  • [ ] ذكري المظهر
  • [x] iOS
متطلبات الأجهزة (بطاقة الرسومات ، جهاز VR ، ...)

آيفون 6 و 8

Bug

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

أود إبراز هذا القسم من مستخدم zeoverlord :

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

ال 113 كومينتر

حسنًا ، يبدو العرض التوضيحي جيدًا على جهاز Pixel.

المشكلات المؤكدة على جهاز iPhone SE الخاص بي -

img_6324

ربما تكون مشكلات دقة WebGL في iOS

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

https://www.khronos.org/registry/webgl/conformance-suites/1.0.3/conformance/extensions/oes-texture-float.html

يحتوي iPhone SE على خمسة إخفاقات في تلك الصفحة. 😕

لقد صنعت شاشة صغيرة لعرضها لك في مشروعي:
http://cornflex.org/webgl/skin-bug.mp4

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

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

... لماذا فقط على iPhone إذن: /

أنا عالق تمامًا ... أنا أعيد التوجيه إلى تسلسلات png كخطة احتياطية ... :(

هذا على الأرجح بسبب أن iPhone 6 لا يدعم ما يكفي من العظام.

كان لي نفس المشكلة بالضبط.

تحقق من حد العظام هنا: https://virtulo.us/2/vr/test

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

أبلغ صديق للتو عن نفس الخطأ على iPhone 8

ما النتائج التي تحصل عليها من اختبار المطابقة التالي؟

https://www.khronos.org/registry/webgl/conformance-suites/1.0.1/conformance/misc/shader-precision-format.html

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

img_1411

هممم ... هنا لدي بعض الفشل ، انظر:

img_1412

ربما تكون المشكلة مرتبطة بهذه الإخفاقات. Pixel على سبيل المثال يجتاز جميع الاختبارات.

لنجرب شيئًا ما: انتقل إلى WebGLCapabilities وقم بتعيين قيمة floatVertexTextures إلى false (سيمنع هذا استخدام النسيج الطافي). أنشئ إصدارًا واستخدم هذا الإصدار three.js في تطبيقك. أشعر بالفضول لما يحدث 😊.

https://github.com/mrdoob/three.js/blob/099e4364541502fdf22fc7b1c0f54239d2ba1708/src/renderers/webgl/WebGLCapabilities.js#L105

جربت بالفعل floatVertexTextures = false على العارض.
توقف الجلد عن الشعور بالجنون ولكن لم يعد هناك رسوم متحركة: /
سأدفع عينة.

ها انت:
http://cornflex.org/webgl/skinning-bug2.html

Renderer.capabilities.floatVertexTextures = خطأ ،

=> لم تعد الرسوم المتحركة قيد التشغيل

img_1413

نعم ، نفس الشيء على جهاز Pixel (يعمل سطح المكتب). أعتقد أننا نصل إلى حد موحد.

لقد قمت بعمل عينة أخيرة ، مع ظهور الخطأ بشكل تدريجي:
http://cornflex.org/webgl/skinning-bug3.html

يبدأ من 0،0،0 ويمضي قدمًا ... انتظر بضع ثوان ... تبدأ البشرة بالجنون.

إنه أمر غريب تمامًا ، كل شيء على ما يرام عند 0،0،0. أليس كذلك؟

ض: 1255> لا يزال موافق
ض: 18870> بشرة مجنونة

img_1415

img_1414

كما قلت ، لقد حددت بعمق جميع أوضاع الهيكل العظمي والعظام على جانب وحدة المعالجة المركزية. يبدو أن جميع القيم جيدة تمامًا. الدليل الوحيد الذي أملكه هو أن bonesTextures و BonesMatrixes لا تعمل بشكل صحيح على نظام iOS عندما تكون الشبكة بعيدة عن 0،0،0.

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

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

غريب جدًا لم يقم أحد بتحريك SkinnedMesh داخل مشهد ولم يبلغ عن هذا مطلقًا: /

سؤال آخر: هل لديك نفس المشكلة مع Chrome؟

نفس المشكلة نعم.

img_1416

تبدو مشكلة الدقة. هل حاولت تصغير المشهد؟ (11195 هي 11 كيلومترًا).

هناك خيار آخر يتمثل في تحريك المشهد بدلاً من الشخصية. يميل إلى أن يكون حلاً مشتركًا للمشاهد الكبيرة.

أيضا ، أعتقد أن رمز السلخ موجود في الفضاء العالمي. يمكننا التحقيق في هذا.

أرى أن عدد عظامك هو 67.

يبلغ الحد الأقصى لعظام أجهزة iPhone 6 الخاصة بي 27.

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

لماذا يزداد الأمر سوءًا بمرور الوقت؟ لا يوجد فكرة. ذكر شخص آخر شيئًا مشابهًا ، لست متأكدًا مما إذا كان مرتبطًا: https://discourse.threejs.org/t/updated-with-fiddle-as-animations-go-faster-there-is-increasing-error-in-accuracy/ 1707/6

شيء مزعج آخر وجدته على أجهزة iphones (iphone 6 على الأقل): يجب أن أستخدم دقة عالية في التظليل ، لا تشوه الطبقة المتوسطة والمنخفضة الشبكة بنفس الشكل المخيف (مثل مشكلة العظام الخاصة بي على الهاتف) ، لكن القوام يبدو غريبة ومشوهة / منقطة أثناء الرسوم المتحركة.

ما هو حد عظام جهازك على الجهاز الذي تختبره؟

mrdoob لقد حاولت بالفعل تقليص حجمه ولكن الجلد يصبح أسرع بكثير في الواقع: /
إذا قمت بتقليص حجمها إلى 0.1 ، فإن الخطأ يظهر أسرع 10 مرات.

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

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

نقل كل العالم بدلاً من الصورة الرمزية هو عملي الصغير رقم 2.
يجب أن تعترف أنه اختيار سيء عندما طورت كل روتين لعبة العداء في عالم الفضاء بالفعل مع الفيزياء وكل شيء. و z = 11000 ليس بعيدًا عن لعبة الركض: / ... وهو مجرد رجل يركض ، وليس سفينة.

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

الحل الأول رقم 1: سأقوم بـ 6 تسلسلات بتنسيق png كرسوم متحركة لأوراق الرموز المتحركة. ثم يمكنني الحفاظ على منطق العالم. الموعد النهائي ليس بعيد :(

titansoftime يظهر prob على هاتف iPhone 8 لزوجتي أيضًا. هذا لا يتعلق بـ iPhone 6 فقط.
أيضًا ، إذا كانت لديك مشكلة في العظام القصوى ، فستكون عربات التي تجرها الدواب من البداية. هنا ، يمكنك أن ترى أنها ليست عربات التي تجرها الدواب عند 0،0،0. ثم حد العظام ليس هو المشكلة. حساب العالم للعظام والعظام ماتريكس في تظليل الجلد هو IMO.

ما هو Max Hardware Bones لجهاز iPhone 8؟

لا اعرف. ولست متأكدًا من أنه يعتمد على الجهاز.

ولكن مرة أخرى ... IMO ، لا يتعلق الأمر بقيمة maxbones على الإطلاق.

النموذج يعمل بشكل صحيح على iphone 6، 8، X ... حتى 5 ... فقط عندما يبقى SkinnedMesh عند 0،0،0
https://threejs.org/examples/webgl_loader_fbx.html

إذا كانت maxbones مشكلة ، فلن يكون لدينا مظهر جيد عند 0،0،0 ولا.

أود إبراز هذا القسم من مستخدم zeoverlord :

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

Mmmh ، مثيرة جدا للاهتمام @ Mugen87! يبدو أنك رصدت التسرب.

ض: 1255> لا يزال موافق
ض: 18870> بشرة مجنونة

قد يكون الخطأ من جانبك.
خطأ شائع: لم يتم تطبيق معدل الجلد بشكل صحيح.
الخطأ 1: الرؤوس تتحكم فيها عظام كثيرة
الخطأ 2: رؤوس بدون وزن (أو بوزن صغير جدًا).

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

RemusMar هل نظرت إلى مصدر الصفحة؟
المثال الذي عرضته جاء مباشرة من مصادر ThreeJS.

مذكور جيدًا في وصفي ؛)

أجريت العديد من الاختبارات قبل نشر هذا ... أبحث عن دليل في عمليات تصدير الرسوم المتحركة الخاصة بي ، لكنني اكتشفت أن الخطأ يحدث مع أي نوع من التنسيقات (GLTF ، FBX ، Collada ، JSON ، ...)

لقد قدمت مثالًا واضحًا بمصدر نظيف لفضح المشكلة. من السهل جدًا التحقق من ذلك على هاتف ذكي:

http://cornflex.org/webgl/skinning-bug.html

المثال الذي عرضته جاء مباشرة من مصادر ThreeJS.

وماذا في ذلك؟

كيف يمكن أن يكون الخطأ من جانبي عندما يحدث هذا مع جميع أمثلة Skinnedmesh من ThreeJS :)

أنت قلت:

قد يكون الخطأ من جانبك.
خطأ شائع: لم يتم تطبيق معدل الجلد بشكل صحيح.
الخطأ 1: الرؤوس تتحكم فيها عظام كثيرة
الخطأ 2: رؤوس بدون وزن (أو بوزن صغير جدًا).

FBX من ThreeJS ... ويمكنك المحاولة باستخدام GLTF أو أي تنسيق آخر. المشكلة هي نفسها.

محمل var = جديد THREE.FBXLoader () ؛
Load.load ('https://threejs.org/examples/models/fbx/xsi_man_skinning.fbx'، OnFBXLoaded) ؛

وجد @ Mugen87 دليلاً. دعونا نأمل أن يتمكن الرجل الذي صنع شبكة GPU ذات البشرة من إصلاحها.

كيف يمكن أن يكون الخطأ من جانبي عندما يحدث هذا مع جميع أمثلة skinnedmesh من ThreeJS

قلت "قد يكون الخطأ من جانبك"
الخط السفلي:
استخدم SkinnedMesh بسيطًا مع معدل الجلد المطبق بشكل صحيح:

  • 4 عظام كحد أقصى لكل رأس
  • كل الأوزان = 1.0000

انظر إذا كان يمكنك إعادة إنتاج الخطأ.

هل انت مجنون؟ :)
لا يمكن أن يكون هذا الخطأ في جانبي ... النماذج (fbx ، gltf ، dae ، أيا كان) ومصدر الكود تأتي من ThreeJS.

يرجى قراءة @ Mugen87 المشاركات.

استخدم SkinnedMesh بسيطًا مع معدل الجلد المطبق بشكل صحيح:

  • 4 عظام كحد أقصى لكل رأس
  • كل الأوزان = 1.0000

انظر إذا كان يمكنك إعادة إنتاج الخطأ.

يجب أن أذهب الآن.
في صحتك

هممم. هل تعلم ما الرجال؟ هذا يحدث على سطح المكتب أيضًا :(

نظرًا لأن شبكة نموذج ThreeJS ضخمة (بطول 100 متر) ، فقد وضعتها بعيدًا جدًا: z = 10000000
وانظر ، نفس المشكلة:
http://cornflex.org/webgl/skinning-bug4.html

إنه بالتأكيد شيء متعلق بمواقع عظام الفضاء العالمي وحسابات مصفوفة العظام ، كما هو موضح بواسطة

https://www.opengl.org/discussion_boards/archive/index.php/t-159613.html
https://www.opengl.org/discussion_boards/archive/index.php/t-159364.html

كما أوضح من قبل لـ mrdoob ، لقد حاولت بالفعل المشكلة أسوأ ... حتى على سطح المكتب وتواجه الخطأ ليس بعيدًا عن 0،0،0.

في لعبتي الخاصة (بمقاييس واقعية 1: 1) ، يظهر الخطأ بالفعل في z: 100.

تستمر في استخدام شبكات بشرة سيئة التصميم ...
على أي حال ، لإغلاق هذا الموضوع ، إليك دراسة حالة من 1 إلى 1000000 (مليون !!!):
http://necromanthus.com/Test/html5/Lara_1000000.html
انقر فوق المرحلة للتبديل بين Y = 0 و Y = 1000000
يتوفر تغيير إضاءة شامل صغير لكل مفتاح.
لذلك إذا تم تصميم الشبكة المصقولة بشكل صحيح ، تكون النتيجة (قريبة من) مثالية.
في صحتك

سننظر في الأمر بعد إصدار هذا الشهر.

@ mrdoob شكرا لك.

RemusMar استمر في تجاهل ما قيل هنا. يرجى قراءة الموضوع بأكمله مرة أخرى :)

لقد أعطيتك مثالًا عمليًا ولكنك ما زلت لا تفهم.
http://necromanthus.com/Test/html5/Lara_1000000.html

وتستمر في الحديث عن الممارسات السيئة .
يرجى مراعاة ما يلي:
رقم الفاصلة العائمة أحادية الدقة للأرقام هو 7.
يغطي ذلك 1234،567 و 123456.7
تأتي معظم خرائط الوزن بأربعة أرقام عشرية ، ولكن حتى واحدة واحدة توفر نتائج جيدة.
لهذا السبب ، أوصت جميع المحركات ثلاثية الأبعاد بقيمة قصوى قدرها 10000 بالنسبة للحجم العالمي.
من 0000.001 إلى 9999.999
كلنا نريد عوالم ثلاثية الأبعاد "لانهائية" أو ضخمة ، لكن هذا غير ممكن.
ما تفعله خاطئ تمامًا من وجهات نظر عديدة:
تصميم اللعبة والعروض والرسوم المتحركة والاصطدامات.
أتمنى أن تكون قد حصلت على الصورة الرئيسية الآن.

تضمين التغريدة
لقد فهمت جيدًا ما قلته ولكن للأسف يعاني نموذجك من نفس المشكلة ... بدرجة أقل ولكن لا يزال هناك:
http://cornflex.org/webgl/skin-bug2.mp4

مصدر:
http://cornflex.org/webgl/skinning-bug5.html

وإذا أعطيت مركزًا أعلى من z = 60000 ، فسيزداد سوءًا ... ويصل إلى 100000 فهو غير مرئي تمامًا.

كلنا نريد عوالم ثلاثية الأبعاد "لانهائية" أو ضخمة ، لكن هذا غير ممكن.

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

المشهد الخاص بي: http://cornflex.org/webgl/skin-bug.mp4

إذا كنا غير قادرين على تحريك صورة رمزية تمتد لعدة أمتار ... فما الفائدة ؟؟ (في المقياس الواقعي 1 م = 1 وحدة ثري جي ، يظهر الخطأ بالفعل من 100).

راجع للشغل ، يبلغ ارتفاع نموذجك 150 مترًا ... هذا ليس مقياسًا واقعيًا.
تعديل:
هنا نفس المشهد بمقياس (0.01 ، 0.01 ، 0.01) على نموذجك ، للحصول على حجم واقعي (حوالي 1.5 متر بعد ذلك). كما ترى ، هناك أخطاء بالفعل في z = 300 على الهاتف المحمول:
http://cornflex.org/webgl/skin-bug3.mp4

ما تفعله خاطئ تمامًا من وجهات نظر عديدة:
تصميم اللعبة والعروض والرسوم المتحركة والاصطدامات.

LOL LOL ... أقترح زيارة مواقع الويب الخاصة بي والمدونة حول صنع الألعاب (http://quentinlengele.com ، http://cornflex.org ، http://www.ddrsa.com ، http://br9732.com )

تحرير: مشهدك غير مرئي على نظام iOS ، شاشة فارغة (http://necromanthus.com/Test/html5/Lara_1000000.html).
img_1418

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

دعونا نرى:

vec3 transformed = vec3( position );
...
#ifdef USE_SKINNING
    vec4 skinVertex = bindMatrix * vec4( transformed, 1.0 );
    vec4 skinned = vec4( 0.0 );
    skinned += boneMatX * skinVertex * skinWeight.x;
    skinned += boneMatY * skinVertex * skinWeight.y;
    skinned += boneMatZ * skinVertex * skinWeight.z;
    skinned += boneMatW * skinVertex * skinWeight.w;
    transformed = ( bindMatrixInverse * skinned ).xyz;
#endif

لا يشبه العالم الفضاء بالنسبة لي؟ في شبكة منتظمة، transformed ومن المقرر أن position السمة - وهذا هو، احداثيات المحلية.

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

(تحرير: nvm ، أعتقد أنني أخطأت في هذا)

me

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

كما قلت ، هناك بالتأكيد خطأ ما في حساب مصفوفات العظام أو ربما يكون ترتيب حساب هذه المصفوفات غير صحيح. كما ترون في منتدى OpenGL وكما ذكر @ Mugen87 ، هذا هو الدليل الأكثر إثارة ، على الأقل بالنسبة لي:

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

مرة أخرى ، كما هو موضح ، يؤثر حجم الكائن على الخطأ.
يوضح المثال الخاص بمصادر ThreeJS أن الخطأ فقط عند z = 100000 ولكن هذا يرجع إلى أن حجم الشبكة (يأتي أيضًا من مصدر ThreeJS) ضخم. يبلغ طول الصبي الجري 150 متراً.

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

المشكلة هنا هي عندما تستخدم SkinnedMesh بحجم واقعي: الخطأ يظهر بالفعل عند z = 300.

في أي محرك ، يمكنك إسقاط SkinnedMesh في وضع x: 30000 ، y: 60000 ، z: 140000000 ولا توجد مشكلة في العظام والجلد. لا النرفزة.

بالتأكيد أفهم جيدًا أننا نعمل على نواة جافا سكريبت هنا ... ولكن لا يزال.

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

يجب أن أقول ، هذا الخطأ ممتع. هنا ، يمكنني إعادة إنتاجه على سطح المكتب ، لكن 60 كيلو بايت لم تكن كافية لتنفد الدقة:
needs more zeroes

حسنًا ، عند z = 1e8 ، هذا ما لدينا مع التظليل الحالي:

screen shot 2018-02-14 at 1 15 56

وإليك ما لدينا إذا قمنا بتغيير التظليل إلى هذا (اختلاف طفيف في اختبار خارج رأس رأسي أعلاه الذي قمت بتحريره):

#ifdef USE_SKINNING
    vec4 skinVertex = bindMatrix * vec4( transformed, 1.0 );
    vec4 skinned = vec4( 0.0 );
    skinned += ( bindMatrixInverse * boneMatX ) * skinVertex * skinWeight.x;
    skinned += ( bindMatrixInverse * boneMatY ) * skinVertex * skinWeight.y;
    skinned += ( bindMatrixInverse * boneMatZ ) * skinVertex * skinWeight.z;
    skinned += ( bindMatrixInverse * boneMatW ) * skinVertex * skinWeight.w;
    transformed = skinned.xyz;
#endif

screen shot 2018-02-14 at 1 16 54

لا تزال مهتزة ، لكنها تبدو أفضل :) الآن ، ماذا يعني هذا في سياق هذه القضية؟

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

أوه و

المتصيدون هنا يتظاهرون "كلنا نريد عوالم لا نهائية ولكن هذا مستحيل"

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

makc شكرا جزيلا على وقتك في هذا.
للأسف لقد فات الأوان. لا بد لي من تسليم الجمعة. لقد استخدمت تسلسلات PNG كحل بديل.

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

أنا فضولي للغاية لمعرفة ما إذا كان التصحيح الخاص بك يعمل على نطاق واقعي أيضًا بالطبع :)

أوه و ... هل تجري اختبارك لنظام iOS؟
كما هو موضح في هذا الموضوع ، يحدث هذا بشكل أساسي على أجهزة iOS (6 ، 8).
على سطح المكتب ، فقط القيم الضخمة جدًا هي التي تسبب المشكلة.

شكرا لك مرة أخرى

OrtOfOn يمكنك تجربة makc patch عن طريق إضافة هذا في الجزء العلوي من الكود الخاص بك:

THREE.ShaderChunk.skinning_vertex = `
#ifdef USE_SKINNING
    vec4 skinVertex = bindMatrix * vec4( transformed, 1.0 );
    vec4 skinned = vec4( 0.0 );
    skinned += ( bindMatrixInverse * boneMatX ) * skinVertex * skinWeight.x;
    skinned += ( bindMatrixInverse * boneMatY ) * skinVertex * skinWeight.y;
    skinned += ( bindMatrixInverse * boneMatZ ) * skinVertex * skinWeight.z;
    skinned += ( bindMatrixInverse * boneMatW ) * skinVertex * skinWeight.w;
    transformed = skinned.xyz;
#endif
`;

THREE.WebGLShader: تعذر على Shader الترجمة. : /

patch

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

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

makc CTRL + C / CTRL + V ... فقط من هنا ...: /

لسوء الحظ ، فإن الخطأ أقل قوة من ذي قبل ولكنه لا يزال موجود :(

تم اختباره على iOS (تم تطبيق التصحيح):

شبكة بمقياس 1.0 (صورة رمزية طولها حوالي 20 مترًا بالضبط) ، الموضع z = 10000
http://cornflex.org/webgl/skin-patch1.mp4

شبكة بمقياس 0.1 (صورة رمزية طولها حوالي 2 متر) ، الموضع z = 3000
http://cornflex.org/webgl/skin-patch2.mp4

@ mrdoob سأحاول التكاثر :) ظهر في سطر واحد. كنت أكتب على الصفحة عندما رأيت ردك يظهر ولم يظهر بشكل طبيعي ، أعدك: p ... سأحصل على نقاط المكافأة هذه ، سترى :)

تحرير: راجع للشغل هل قمت بتحرير منشورك؟ :)

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

OrtOfOn في مكانك ، سأحاول التفاف المشهد بأكمله (بكاميرا) في Object3D إضافي وتعيين أسلاك هذا الكائن على -1 * صورة رمزية تغلف كل إطار. هذا من شأنه أن يبقيه في 0،0،0 كورد عالمي إلى الأبد.

markc أنا حقًا لا أحب الغش مثل هذا. لم يتم تصميم طريقة اللعب والمشهد بحيث يتم تعذيبهما بهذه الطريقة ، وباعتبارها أول لعبة محمولة ، يجب أن تكون Perfs مثالية بالطبع.

أيضًا ... ليس حالتي ولكن تخيل هذا مع العديد من الأعداء في SkinnedMesh ، القادمين من كل مكان ...

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

لا نريد "عوالم لا نهائية" ولكننا نريد أن نكون قادرين على استخدام ميزات SkinnedMesh والرسوم المتحركة الرائعة في إحداثيات الفضاء العالمية ، كما نفعل في المحركات الشهيرة :)

أشعر بخيبة أمل بعض الشيء بطريقة ما ... لأنني صنعت سيناريو Animator رائعًا استنادًا إلى ميزات التلاشي المتقاطع ومستوحى من الميكانيك ... للمشروع التالي بالتأكيد:

markc أنا حقًا لا أحب الغش مثل هذا.

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

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

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

OrtOfOn في الواقع يمكنك استخدام المشهد نفسه. على سبيل المثال في لارا ، افعل هذا:

scene.add(camera);
scene.position.z = -60000;

ولا بأس (تحرير: ومع ذلك ، هناك خطأ ما في الضوء عندما تفعل هذا .... mrdoob ؟)

makc شكرا مرة أخرى لاقتراح التصحيحات.

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

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

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

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

لأن ما هي النقطة التي يجب حصرها في صورة رمزية واحدة ذات بشرة واحدة عند 0،0،0 إذن؟

النقطة المهمة هي أنه من المستبعد جدًا أن تجعل الجلد عند 0،0،0 وجلد آخر عند z = 60000. فقط عدد قليل من الجلود حول 0،0،0 ستظهر على الشاشة ، ولن تكون بعيدة بما يكفي لإثارة الخطأ.

makc مرة أخرى ، التصحيح الخاص بك صالح تحت سطح المكتب ولكنك لا تختبر الحالة على أجهزة iOS ، حيث يظهر الخطأ بالفعل على بعد عدة أمتار من 0،0،0 مع شبكات واقعية متدرجة. لقد صنعت ما يكفي من أشرطة الفيديو لتظهر لها. هذا ، على سبيل المثال ، يعرض الخطأ فقط عند z = 100: /
http://cornflex.org/webgl/skin-bug.mp4

هل تستخدم دائمًا الصورة الرمزية التي يبلغ طولها 20 مترًا في ألعابك؟ :)
نظرًا لأن الرقم الذي ركزت عليه (60000) يُستخدم فقط لفضح الخطأ على سطح المكتب (مع عينة لارا ضخمة جدًا أو عينة fbx ضخمة من threejs) ... ليس على الهاتف المحمول. وأنا أفاتار لا يذهب إلى هذا الحد بالطبع ...

أود أن أؤكد أن هذه مشكلة iOS. منذ جيل 6S / 6S + على الأقل ، واجهت iOS مشكلة مع floatVertexTextures. الإصلاح الذي كنا نستخدمه هو تعطيل هذه الميزة على iOS. هذا يحد من العظام التي يمكننا استخدامها ، لكن يتعين علينا تقييدها على أي حال لدعم الهواتف الأكثر روعة.

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

@ daniel - ن أعتقد أنه من المنطقي. ومع ذلك ... كان OrtOfOn يقول أن z = 60K يعيد إنتاج المشكلة على سطح المكتب ... ليس لدي أي مشاكل عند 60

  • تعويم القوام على iOS ،
  • شيء بسرعة 60 كيلوبايت على سطح مكتب
  • ينفد من الدقة عند 1e8 بسبب ترتيب ضرب المصفوفة السيئ في بت تظليل العظام (تلك التي عبثت بها أعلاه) ،
  • ربما شيئًا آخر في تظليل قمة الرأس ، حيث كانت الفتاة لا تزال مهتزة قليلاً بعد التصحيح.

اهلا ياجماعة،
أولاً ، شكرًا لك على العودة إلى هذا الخطأ. ما زلت لا أجد الوقت للحفر فيه :(

@ daniel-nth حجم الكائن يؤثر على الخطأ:

على نظام iOS ، مع هذا الكائن الضخم "Lara" (الارتفاع = 120 ، المقياس = 1) ، يظهر الخطأ عند z = 60000 بالفعل. ولكن ، إذا أخذت شبكة ذات حجم واقعي (الارتفاع = 1.8 ، المقياس = 1) ، فإنها تظهر بالفعل فقط عند z = 100.

أكبر شبكة الجلد ، يجب أن تكون الترجمة كذلك لرؤية الخطأ.

كما تم اختباره بالفعل والإبلاغ عنه في هذا الخيط ، فإن تعطيل floatTextures على نظام التشغيل iOS يؤدي إلى عدم وجود جلد على الإطلاق.

أشك أيضًا في وجود ضرب مصفوفة سيئ أو ترتيب شريطي لضرب مصفوفة العظام.

على نظام التشغيل iOS ، مع هذا الكائن الضخم "Lara" (الارتفاع = 120 ، المقياس = 1) ، يظهر الخطأ عند z = 60000

OrtOfOn انتظر ،

الرقم الذي ركزت عليه (60000) يُستخدم فقط لفضح الخطأ على سطح المكتب (مع عينة لارا ضخمة جدًا أو عينة fbx ضخمة من threejs) ... ليس على الهاتف المحمول.

على نظام iOS ، مع هذا الكائن الضخم "Lara" (الارتفاع = 120 ، المقياس = 1) ، يظهر الخطأ عند z = 60000 بالفعل.

إنها ليست ضخمة على الإطلاق.
وما زلت لا تفهم العلاقة بين حجم النموذج والمقياس العالمي.
للمرة الاخيرة:
http://necromanthus.com/Test/html5/Lara_1000000.html
ارتفاع موديل تقريبا = 75 والمقياس العالمي = 9999999.
من Z = 0 إلى Z = 1،000،000 (مليون !!!)
نظرًا لأن عدد الفاصلة العائمة أحادية الدقة للأرقام هو 7 ، فلا توجد فواصل عشرية على الإطلاق !!!
إنه يعمل بشكل مثالي على جميع أجهزة الكمبيوتر المحمولة وأجهزة الكمبيوتر المكتبية لدي.
أكثر من ذلك:
يعمل بشكل مثالي على Android 6 و 7 والعديد من هواتف Samsung المحمولة.

lara_1000000

RemusMar في

camera.position.z += 1e8;
scene.children[2].position.z += 1e8;

سترى شيئًا كهذا:
screen shot 2018-03-03 at 15 48 53

screen shot 2018-03-03 at 15 51 41
إنه ثلاثي

سأعطيكم أن z = 1e6 لا يبدو سيئًا أيضًا. حول 1e7 إنه ملحوظ بالفعل ، و 1e8 مجنون

OrtOfOn إعداد القدرات.

سأعطيكم أن z = 1e6 لا يبدو سيئًا أيضًا. حول 1e7 إنه ملحوظ بالفعل ، و 1e8 مجنون

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

makc في الواقع ، حصلت على أرقام خاطئة لسطح المكتب. يجب أن تكون ضخمة جدًا ، أنت على حق وقد ذكرت في الموضوع مسبقًا في الحقيقة: / https://github.com/mrdoob/three.js/issues/13288#issuecomment -364650679

@ daniel-nth جيد أن تعرف ولكن هل أنت متأكد؟ هذا هو الاختبار الذي قمت به هنا في هذا الموضوع ، مع نموذج ثلاثي الأبعاد من مصادر threejs. لا يزال بإمكانك إلقاء نظرة على الكود. قدم @ Mugen87 نفس الملاحظات أيضًا ، لا توجد رسوم متحركة مع هذا النموذج. https://github.com/mrdoob/three.js/issues/13288#issuecomment -364572653

أوه ، أرى أن النموذج لم يعد موجودًا بعد الآن. 404 في https://threejs.org/examples/models/fbx/xsi_man_skinning.fbx

@ daniel-nth إذا كنت تستخدم نموذجًا جديدًا به عظام أقل ، فأنا أصدقك ؛)

RemusMar تمامًا معك حول المسافات التي تم استحضارها في أحدث المشاركات. الأرقام (1e6 ، 1e8 ، 1e9 ، ...) ستنتج بالتأكيد بدقة سيئة. لا شك في ذلك. لكن من فضلك توقف عن التصيد لي. توقف عن التظاهر بأنني لا أفهم أي شيء واسأل نفسك ما إذا كانت الشبكة الرمزية بارتفاع 120 ليست ضخمة. بالنسبة لي ، إنه ضخم جدًا وغير قابل للاستخدام في لعبة gamedev مع أشياء أخرى واقعية الحجم صنعها فنانين ، وبث الأشعة ، والفيزياء ، والإضاءة ... وسيتم تسليمها في غضون 3 أسابيع.

أنا أصر على أن الحفاظ على الأصول على نطاق واقعي باستخدام الوحدات المترية هو أمر إلزامي لبناء لعبة قائمة على الفيزياء بشكل صحيح :)

من المؤسف أنه على نظام iOS ، لا يمكنني تشغيل الصورة الرمزية الخاصة بي على مسافة تزيد عن 100 متر في ظروف المقياس الواقعية هذه: /

تحديث: على أي حال ، يبدو أن @ daniel-nth يخبرنا أنه يعمل الآن مع إزالة القوام العائم وعدد محدود للغاية من العظام.

لكن من فضلك توقف عن التصيد لي
أنا أصر على أن الحفاظ على الأصول على نطاق واقعي باستخدام الوحدات المترية هو أمر إلزامي لبناء لعبة قائمة على الفيزياء بشكل صحيح :)

أنا لا أتصيدك.
لكن 1.5 وحدة لا تعني 1.5 متر
في صحتك

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

أنا أصر على أن الحفاظ على الأصول على نطاق واقعي باستخدام الوحدات المترية هو أمر إلزامي لبناء لعبة قائمة على الفيزياء بشكل صحيح :)

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

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

بالطبع ، يعتمد ذلك على مستوى الدقة الذي تحتاج إلى تحقيقه والقيم مثل 1e6 ، 1e7 ، ... هي طريقة كبيرة جدًا وستعرض مشكلات تتعلق بالدقة. ولن تحتاج أبدًا إلى تحريك شبكة بشرة إلى هذا الحد. اتفقنا على ذلك. ولكن ، في نظام iOS ، يجب أن نكون قادرين على تحريك شبكة gpu skinnedmesh (بطول 1.5 وحدة) في نطاق من عدة مئات من الوحدات ، على الأقل.

لكن محرك الفيزياء / ليبس يتوقع منك استخدام القيم المترية.

هذا ليس صحيحا.
الأمتار والسنتيمتر والبوصة وما إلى ذلك غير ذات صلة.
كما قلت (عدة مرات) من قبل ، كل ما يهم هو الحجم العالمي (المقياس) والدقة.
ضع في اعتبارك ما يلي:
إذا كان لديك شبكة ذات ارتفاع = 1.5 وحدة ، فأنت مجبر من خلال خريطة أوزان الرأس على استخدام 2-3 أرقام عشرية على الأقل.
بالنسبة لمحرك الفيزياء (إن وجد) ، قد تحتاج إلى 3-4 أرقام عشرية للحصول على نتائج مقبولة.
إذا كانت الدقة العامة تتطلب 4 أرقام عشرية ، فإن الحد الأقصى لحجم العالم هو 999 (لأن رقم الفاصلة العائمة أحادية الدقة للأرقام هو 7).
بمعنى آخر ، يمكنك استخدام مسافات تصل إلى بضع مئات إذا كنت تريد رسومًا متحركة جيدة وفيزياء جيدة.
أتمنى أن تكون قد حصلت على الصورة كاملة هذه المرة.
في صحتك

RemusMar سأتوقف هنا. يبدو أنك لا أو لا ترغب في اختبار حالتك على جهاز iOS. لا يمكنك استخدام "مسافة بضع مئات" على هذه الأجهزة مع شبكات gpu skinnedmeshes. الشبكة تصبح مجنونة بسرعة كبيرة. هذا هو الهدف من هذا الموضوع وأردت فقط الإبلاغ عن ذلك في البداية. هذا كل شيء.

آمل أن تكون قد حصلت على حقيقة أن جميع مقترحاتك وعيناتك لا تعمل على أجهزة iOS ، كما أفاد أشخاص آخرون هنا ومن خلال لقطات الشاشة الخاصة بي: /

لا يمكنك استخدام "مسافة بضع مئات" على هذه الأجهزة مع شبكات gpu skinnedmeshes.

أنت مخطئ مرة أخرى.
انظر لقطة الشاشة أعلاه (Android 7 - هاتف Samsung المحمول).
ارتفاع النموذج = 75 (نصف قطر الكرة المحيطية 38 تقريبًا) والمسافة 1،000،000 (مليون !!!)
أو ارتفاع الموديل = 1.5 والمسافة 20000.

ملاحظة
ليست مشكلتي أن iOS كان دائمًا عبارة عن مجموعة من الأخطاء.

RemusMar لست مخطئا أيها القزم. أنا أتحدث عن iOS وأنت تتحدث عن جهاز آخر ... هل أنت مجنون ؟؟

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

نهاية الإرسال هنا ... لا يمكنني متابعة هذا بعد الآن.

OrtOfOn نعم ، النموذج الذي استخدمته يحتوي على 19 عظمة ، و 404 fbx به 67.

https://github.com/mrdoob/three.js/issues/13288#issuecomment -364550036 يحتوي على رابط لصفحة تُظهر حد العظام الموحد. الصيغة التي تستخدمها الصفحة هي Math.floor((data.webgl.params.MAX_VERTEX_UNIFORM_VECTORS - 20) / 4); لست متأكدًا مما إذا كان هذا دقيقًا بنسبة 100٪ لـ three.js ، لكنها تشير إلى 27 حتى على iPhone X ، وهو للأسف أقل من نصف حتى Galaxy S3 ، لكنه لا يزال كثيرًا لعبة WebGL المحمولة. استوعبت بسرعة مجلد عملي وفي 26 مشروع WebGL ، واحد فقط لديه نموذج به المزيد من العظام ، وهذا النموذج يبقى عند 0،0،0.

OrtOfOn : أواجه مشكلات مماثلة مع مشهد ثابت وتحريك شخصية بشرة في المشهد. توتر الشخصية بشكل رهيب على iOS. عدد العظام 22. أبعاد المشهد معقولة. أعتقد أن المشكلة تكمن في أن استخدام القوام الرأسي يحدك من عوامات 32 بت ، إلى جانب التأكيد أعلاه على أن Threejs تحسب الجلد في الفضاء العالمي!

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

سأعيد النشر عندما يكون لدي حل.

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

vec2 encodeFloatRG( float v )
{
    vec2 kEncodeMul = vec2(1.0, 255.0);
    float kEncodeBit = 1.0/255.0;
    vec2 enc = kEncodeMul * v;
    enc = fract (enc);
    enc.x -= enc.y * kEncodeBit;
    return enc;
}

float decodeRGFloat( vec2 enc )
{
    vec2 kDecodeDot = vec2(1.0, 1.0/255.0);
    return dot( enc, kDecodeDot );
}

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

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

تم إصلاح المشكلات المذكورة أعلاه تمامًا للسلخ على نظام iOS. يجب أن أشير أيضًا إلى أن هذا الحل عالمي - يعمل بشكل لا تشوبه شائبة على جميع متصفحات سطح المكتب بالإضافة إلى أجهزة Android التي اختبرتها. يعد تقشير الفضاء المحلي IMHO هو الطريقة الصحيحة للذهاب في جميع الحالات تقريبًا ، ويجب أن تكون هذه الطريقة هي الطريقة الافتراضية لـ ThreeJS. mrdoob : ما هو رأيك في هذا؟

mesh = new THREE.SkinnedMesh(geo.geometry, mat);
mesh.bindMode = 'detached';
var skel = new THREE.Skeleton(bones, boneInvs);
var bsm = new THREE.Matrix4().fromArray(geoPrims.bsm);
mesh.bind(skel, bsm);

// make bsmInv identity for models that have multiple skins
mesh.bindMatrixInverse = new THREE.Matrix4();

// patch SkinnedMesh's updateMtxWorld:
// we're using local skinning, so don't keep resetting binMatrixInverse (leave identity)
// the reason we're using .bind here is for models that have more than one skin
mesh.updateMatrixWorld = PatchSkinnedMeshUpdateMW.bind(mesh);

// re-normalize since input data has been compressed
mesh.normalizeSkinWeights();

// remove bone roots and add to bone root list
for (var bi = 0, bl = bones.length ; bi < bl ; bi++) {
    if (bones[bi].parent && !bones[bi].parent.isBone) {
        bones[bi].parent.remove(bones[bi]);
        boneRoots.push(bones[bi]);
    }
}

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

وإليك التصحيح لاستبدال تنفيذ ThreeJS 'SkinnedMesh (لاحظ أن هذا ضروري فقط نظرًا لأن موقع threejs' updatematrixworld clobbers the bindMatrixInverse الذي نريد الاحتفاظ به كهوية) بدلاً من ذلك ، يمكنك الارتباط بـ THREE.Mesh..prototype.UpdateMatrixWorld مباشرة بدلاً من استخدام وظيفة التصحيح.

function PatchSkinnedMeshUpdateMW( force ) {
    THREE.Mesh.prototype.updateMatrixWorld.call( this, force );
}

@ denbo-ft أعتقد أن هذا يبدو جيدًا بالنسبة لي. هل ترغب في إنشاء علاقات عامة لها؟

@ denbo-ft شكرا جزيلا على جهودك. آسف على الرد المتأخر ، لم أعد أتابع هذا الموضوع بعد الآن.

لدينا هذه المشكلة في منتجنا أيضًا - أي متصفح (إذا كنت بعيدًا بما يكفي عن 0،0،0) ولكن أكثر وضوحًا على نظام التشغيل iOS كما يحدث بمجرد أن تكون على بعد 2-3 وحدات حاسمة بالنسبة لنا ولكن على الأقل لدينا الضحك عندما نرى ذلك
image

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

كذلك هنا. تبدو My SkinnedMesh وكأنها حلقة من دكتور كاتز ، معالج محترف على أجهزة iPhone.

لمعلوماتك ، منشوري من 21 مايو لديه الحل الكامل. ليس هناك الكثير من الإصلاحات لمصادر ThreeJS - معظم الإصلاح ينتمي إلى اللودر و / أو رمز إعداد المشهد لمشاريعك الفردية.

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

تعديل:
لدينا تنسيق ملف ومحمل مخصصان تمامًا لـ TJS ، لذلك لسوء الحظ من أجل إنشاء علاقات عامة كاملة مع مثال على الحل ، يجب أن أقوم بإصلاح أحد اللوادر المجهزة (مثل Collada). سأفعل هذا الآن

شكرًا ، كنت سأخصص بعض الوقت لمحاولة فهم وتطبيق حلك أيضًا بطريقة أكثر عمومية (يبدو أن حلك خاص بمشروعك). هل يمكنك مشاركة سياق أكثر قليلاً لشفرتك؟

دكتور كاتز ، معالج محترف

أنا لست مدمن مخدرات أو أي شيء ، ولكن اللعنة .

تعديل:

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

المنشور الأصلي:

لدي فرع محلي مع التغييرات ، لكن لا يبدو أنه يمكنني الدفع نحو الأصل. حتى تقديم أرصدة github الخاصة بي ، أتلقى هذا الخطأ:

الدفع إلى https://github.com/mrdoob/three.js.git
بعيد: تم رفض إذن mrdoob / three.js.git إلى denbo-ft.
فادح: غير قادر على الوصول إلى " https://github.com/mrdoob/three.js.git/ ": أرجع عنوان URL المطلوب الخطأ: 403

سأحب بعض النصائح لأن هذه هي أول مساهمة لي في جيثب. شكر!

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

All binMode = "local" لا يغير bindMatrixInverse أثناء التحديث ، على عكس "منفصل" ، الذي يعيد تعيينه إلى معكوس bindMatrix ، بدلاً من تركه عند الهوية.

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

تم استخدام العرض التوضيحي لمحمل Stormtrooper DAE لاختبار هذا الإصلاح. تم نقل الشخصية 2000 وحدة بعيدا عن أصل هذه الاختبارات. لقطات أدناه.

اللقطات أدناه مأخوذة من iPhone X / Safari 11

قبل هذا التغيير (2000 ، 2000 ، 2000):
img_0658

بعد هذا التغيير:
img_0659

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

لديك خياران:

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

2) اترك Bones في مساحة الأفاتار كما هي واحصل على الالتواء على نظام iOS

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

مزيد من المعلومات:

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

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

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

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

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

حظا طيبا وفقك الله!

ستختفي مشكلة الجلد على نظام iOS تمامًا إذا قمت بإجراء السلخ في الفضاء المحلي

كما قلت منذ البداية ، هذا حل بديل لقيود iOS (خطأ) وعليك إهدار قوة المعالجة لذلك.
هذا ليس حلا!
الحل الحقيقي هو رفع دقة النقطة العائمة على نظام iOS (إلى القيمة العادية المكونة من 7 أرقام).
http://davenewson.com/posts/2013/unity-coordinates-and-scales.html

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

قضيت وقتًا في التفكير في المشكلة ولكني لم أتوصل إلى حل أفضل. (ما زلت أحاول)

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

الحل الحقيقي هو رفع دقة النقطة العائمة على نظام iOS

ربما يجب على شخص ما أن يسأل grorg وشركاه أولاً عن الصفقة مع الزخارف العائمة هناك ، وكيف يحدث ذلك؟ لأن لدي شعور بأنه ليس مجرد خلل ولكن "حل" أبل لبعض المشاكل الأخرى

لدي شعور بأنه ليس مجرد خلل ولكن "حل" أبل لبعض المشاكل الأخرى

غالبا صحيح.
مشابه للمشكلة على Firefox Android: تم الإبلاغ عن خطأ ، تم التحقق منه بواسطة المطورين ، ولكن لم يتم إصلاحه في الأشهر الخمسة الماضية (إصداران)!؟!

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

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

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

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

يبدو أنني سأضطر إلى استخدام العظام عند 0،0،0 وإجراء بعض حسابات المصفوفة الإضافية للأشياء الأخرى. شكر!

@ denbo-ft هو الصحيح. هذه مشكلة three.js سببها الجلد في الفضاء العالمي.

للإشارة ، هذا هو المكان الذي تم فيه التغيير في عالم الفضاء: https://github.com/mrdoob/three.js/pull/4812.

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