Three.js: GLTFExporter GLB متوافق مع عارض Facebook

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

بعد إعلان Facebook عن دعم glTF على الجدول الزمني الخاص بهم ، كنت أحاول استخدام GLTFExporter لإنشاء بعض glTF الثنائي ( glb ) لاختبار هذه الميزة الجديدة.

لكني وجدت بعض المشاكل حتى الآن:

  • [x] يجب محاذاة أجزاء GLB 4 بايت https://github.com/mrdoob/three.js/pull/13395
  • [x] التحقق من الصحة: ​​إصلاح znear و zfar: https://github.com/mrdoob/three.js/pull/13396
  • [x] Vertex Color: يدعم Facebook RGBA فقط وليس RGB. كما هو موضح في رسالة التحقق :
    [msg] => Vertex COLOR_0 attributes of type RGB are (temporarily) notsupported. They must be RGBA. . على الرغم من أن COLOR_0 يمكن أن يكون vec3 أو vec4 ويمكننا تضمين معلمة اختيارية لفرض تحويل السمة color من 3 إلى 4 مكونات ، فأنا لا لا أعتقد أننا يجب أن نقوم بهذا الاختراق لأن تطبيقنا الحالي يتبع المواصفات ولا أرى أي حالة استخدام أخرى لهذا التحويل أكثر من مجرد اختطاف أداة التحقق من facebook أثناء عملهم على إصلاحه. <- تحديث: يجب أن يتم ذلك في الأسابيع التالية ، لذلك لا نحتاج إلى حل بديل
  • [x] الشبكات غير المفهرسة غير مدعومة: `[msg] => العناصر الأساسية للشبكة بدون فهارس هي (مؤقتة) غير مدعومة.
  • [] تصدير الأوضاع الأولية الأخرى (حاليًا يدعم TRIANGLE فقط)

مزيد من المعلومات: https://developers.facebook.com/docs/sharing/3d-posts/glb-tutorials

Enhancement

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

مرحبًا يا رفاق - اعتبارًا من هذا الصباح ، لم يعد Facebook يرفض ألوان رأس RGB (VEC3) باعتبارها "غير صالحة".

تظل متطلبات القوام المكونة من اثنين في الوقت الحالي ، لكنني أعمل على ذلك أيضًا.

ال 56 كومينتر

/ pingzellski

مهلا! نعم ، يجب أن يختفي فحص RGBA في غضون أسبوعين. لا تحل محلها. :)

أحاول تحويل WaltHead.obj إلى glb. أقوم بتحميله في https://threejs.org/editor/ وأصدره إلى GLB من هناك (والذي يجب أن يحتوي على أحدث التصحيحات بالفعل).

إليك WaltHead.glb وهذا ما أحصل عليه في

Your GLB File has the following errors: The 3D model could not be posted: The JSON portion of this model file is invalid.

🤔

إنه JSON صالحًا من الناحية التركيبية ، لكن القيم الخالية في هذا المقتطف من WaltHead.gltf لا تتوافق مع مخطط النوع:

    {
      "bufferView": 2,
      "componentType": 5126,
      "count": 48480,
      "max": [
        null,
        null
      ],
      "min": [
        null,
        null
      ],
      "type": "VEC2"
    }

تسرد أداة المدقق Khronos glTF أيضًا حوالي 10000 مثيل لبعض الأخطاء الأخرى في الملف ، أيضًا ، كلها بترتيب:

        /accessors/2: Accessor element at index 28922 is NaN or Infinity.

لذلك يبدو أنه ربما يتم إنشاء ملحق أثناء تصدير glTF ، ليتم ملؤه بالمؤشرات ، ولكن لا يتلقى أيًا منها في الواقع؟

UVs هي NaN: 🙃

screen shot 2018-02-21 at 9 27 57 pm

تضمين التغريدة https://github.com/mrdoob/three.js/pull/13400
على الرغم من أننا ما زلنا لا نستطيع إظهار هذا المثال بسبب

[msg] => Mesh primitives without indices are (temporary) unsupported.

(أضيف إلى قائمة المهام)

zellski هل لديك أي تقدير حول هذه الميزة؟ ؛)

fernandojsg هذا أصعب قليلاً. سيتم إصلاحه ، لكن قد يستغرق وقتًا أطول قليلاً. TL ؛ الدكتور ربما شهر؟

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

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

أفترض أن الخطأ أعلاه يأتي عندما تحاول شركة Three.js تصدير العناصر الأولية غير المفهرسة بشكل طبيعي في تمثيل وقت التشغيل الخاص بها؟

أفترض أن الخطأ أعلاه يأتي عندما تحاول شركة Three.js تصدير العناصر الأولية غير المفهرسة بشكل طبيعي في تمثيل وقت التشغيل الخاص بها؟

zellski هذا كل شيء! بعض العناصر الأولية أو العناصر التي تم تحميلها على ثلاثة غير مفهرسة. كانت حالة الاستخدام الأولى التي اعتقدت أنها لمحمل facebook glb هي تضمين رسومات من تطبيق A-Painter الخاص بنا (مزيد من المعلومات: https://blog.mozvr.com/tag/a-painter/) ونستخدم هندسة غير مفهرسة هناك أيضًا ، لذلك سيكون من الرائع الحصول على دعم لذلك ؛)
أردت فقط معرفة ما إذا كان ذلك على خريطة الطريق ، لذا فإن معرفة ذلك ويمكننا الحصول عليه في غضون شهر تقريبًا ، يعد أكثر من معقول ؛) شكرًا لمشاركة هذه المعلومات!

قد نضطر إلى إضافة سمة فهرس غبية في هذه الأثناء (كما في 0 ، 1 ، 2 ، 3 ، 4 ، 5 ، 6 ، 7 ، 8 ، ...) 😕

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

نعم أضف إختراق مؤقت في المصدر ...

لا أعرف ، أريد فقط أن تعمل الأشياء ولا يجب أن أخبر الناس ، "أوه؟ نموذجك لا يعمل على facebook؟ هذا لأن ... أنت تعرف ما هي الأشكال الهندسية المفهرسة؟ نعم ، لا يجب عليك ولكن ... "

نعم حصلت عليه! حسنًا ، سألقي نظرة لمعرفة ما إذا كان بإمكاني إضافة بعض الاختراقات غير القذرة :)

zellski للسياق ...

لقد أضفت Export GLB في http://threejs.org/editor/ يستخدم هذا GLTFExporter .

screen shot 2018-02-22 at 11 03 42 am

فيديو: كيفية تصدير النموذج كـ glTF على محرر Three.js: د

https://twitter.com/superhoge/status/966689549803053056

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

هل يمكنك عمل اختراق GLTFExporter في مفترق يستخدم في http://threejs.org/editor/ ولكن ليس في أي مكان آخر؟ أتمنى أن نكون قد أصلحنا هذا الخلل بحلول الوقت الذي يظهر فيه r91 ، لذلك يبدو أنه من غير المجدي بعض الشيء بالنسبة لكم أيها الأشخاص أن تكتبوا تعليمات برمجية دقيقة ومسؤولة عن ذلك.

هل يمكنك عمل اختراق GLTFExporter في مفترق يستخدم في http://threejs.org/editor/ ولكن ليس في أي مكان آخر؟

أجل ، لا تقلق!

آمل أن نكون قد أصلحنا هذا الخلل بحلول وقت ظهور r91

أوه ، أنا أهدف إلى إطلاق سراح ~ الأول من مارس. تم تغيير دورة الإصدار إلى بداية الشهر للحصول على إصدارات شهرية مناسبة.

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

أحدث اختبار ، باستخدام خريطتين منتشرتين ، سحاب أحدهما هو png شفاف:
https://www.facebook.com/fakemrdoob/posts/950266411809572

لست متأكدًا من مصدر alphaTest: 0.5 الظاهر ...

مجرد استخدام الحل البديل للمؤشرات :)
https://www.facebook.com/fernandojsg/posts/10156405595122044

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

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

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

راجع للشغل لقد وجدت للتو هذا الرابط مع بعض المعلومات المفيدة: https://developers.facebook.com/docs/sharing/3d-posts/glb-tutorials

يبدو أن القوام يجب أن تكون بقوة 2 ...
https://twitter.com/drupalati/status/967486854630055936

ألا تقوم Three.js تلقائيًا بتحويل الصورة من غير بقوة اثنين إلى قوة اثنين على الطاير؟

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

takahirox نعم ، سيتم تغيير حجم three.js بسرعة. لكن عملاء Facebook الأصليين لا يستخدمون three.js.

القائمة الكاملة لميزات glTF التي لا يدعمها Facebook بعد ، بترتيب تقريبي لـ ETA:

  • لا توجد ألوان رأس RGB ؛ يجب أن يكون RGBA.
  • لا توجد مواد NPOT لبعض تركيبات لقط / مرشح
  • فقط هندسة المثلث المفهرسة.
  • لا توجد رسوم متحركة (تم تجاهلها بصمت)
  • لا توجد موصّلات متفرقة (فشل التحقق من الصحة)
  • لا توجد أهداف مورف (إذا كان لدى أي شبكة خاصية "هدف" ، يفشل النموذج في التحقق من الصحة)
  • لا توجد كاميرات (تم تجاهلها بصمت) (في الوقت الحالي)

أيضا:

  • الحد الأقصى لحجم الملف 3 ميجا بايت
  • لا يوجد بعد نسيج أكبر من 4096
  • لا توجد امتدادات بخلاف KHR_material_unlit (في الوقت الحالي)

وأعتقد أن كل شيء.

لقد صنعت رقم PR # 13424 لقماش POT لأنني أعتقد أنه لن يكون مفيدًا فقط لـ FB.

عند استخدام GLTFExporter لتصدير شبكة متعددة المواد (مجموعة من المواد) ، تلقيت هذا الخطأ:

GLTFExporter.js:623 Uncaught TypeError: Cannot read property 'toArray' of undefined
    at processMaterial (GLTFExporter.js:623)

@ Ben-Mack هذه مشكلة معروفة وأنا أعمل عليها الآن. (لكن الأمر سيستغرق بعض الوقت).

zellski أي خطط لدعم دراكو على الفيس بوك؟ يمكنني الحصول على شبكاتي من 40 ميغا بايت إلى 5 ميغا بايت ولكن هذا العدد الأخير من ميغا بايت لن ينخفض.

@ webprofusion-chrisc (رجل طويل على لوحة مفاتيح الهاتف) نعم ، Draco هو بالتأكيد على خريطة الطريق. إنها تحتاج إلى قدر لا بأس به من العمل الهندسي ، لذا فقد انقضى شهر على الأقل ، ولكن - من نواح كثيرة قمنا ببناء افتراضاتنا حولها - كما تقول ، بالنسبة للعديد من الطرز ، لا يمكن الدفاع عن حد 3 ميغا بايت. (ما زلت غير متأكد مما يمكننا فعله للمساعدة في القوام.)

(ما زلت غير متأكد مما يمكننا فعله للمساعدة في القوام.)

يحققdonmccurdy بعض التقدم على هذا الصعيد: https://github.com/mrdoob/three.js/pull/12877 😀

يمكننا توقع زخارف أصغر بنسبة 25-30٪ من GLTFExporter مع # 12877.

على المدى الطويل ، تعمل Binomial مع Khronos لإنشاء امتداد للقوام المضغوط عبر النظام الأساسي في glTF: https://www.khronos.org/blog/call-for-participation-gltf-creating-a-compressed-texture-extension .

حسنًا ... بعد # 12877 و # 13451 ، أصبح تصدير GLB الذي كان 3.3 ميجا بايت الآن 480 كيلو بايت

رائع! # 13451 يعني أن حجم ملف الصورة سيكون أكبر إذا قمنا بتحويل jpg إلى png؟

رائع! # 13451 يعني أن حجم ملف الصورة سيكون أكبر إذا قمنا بتحويل jpg إلى png؟

نعم فعلا. يعد # 13451 بمثابة حل بديل نظرًا لحقيقة أن المحرر لا يسمح بتغيير تنسيق النسيج في الوقت الحالي. لكننا نفعل نفس الشيء في المكتبة على أي حال ...

https://github.com/mrdoob/three.js/blob/dev/src/loaders/TextureLoader.js#L34

لكن نعم ، يتم حفظ GLTFExpoter حاليًا بتنسيق jpg عند texture.format === THREE.RGBFormat .

https://github.com/mrdoob/three.js/blob/dev/examples/js/exporters/GLTFExporter.js#L493

أيهما ليس مثاليًا ، لأننا نعيد ضغط jpg ... لكن أفضل من الصادرات كبيرة الحجم على ما أعتقد؟

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

أنا قلق قليلاً بشأن النزف بين القنوات لأشياء مثل نسيج ORM (انسداد / خشونة / معدن) حيث يحمل كل مكون بيانات مستقلة تمامًا عن بيانات المكونات الأخرى ... ولكن من الناحية العملية يبدو أنها تعمل بشكل جيد.

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

zellski for fb's pipeline / viewer أعتقد أنه يمكنك فعل مثل sketchfab وتقديم نسخة منخفضة الدقة ، ثم دفق مواد عالية / كاملة الدقة واستبدلها في النموذج أثناء تحميلها. ليس قطعة صغيرة من العمل ولكن يمكن القيام به.

@ webprofusion-chrisc نعم ، قد ينتهي بنا الأمر بفعل ذلك. في الوقت الحالي ، عملنا جميعًا على .glb باعتباره الكيان المرسل ، والذي يصعب دمجه مع تدفق نوع LOD الانتقائي (نظرًا لوجود ملف تسلسلي واحد فقط بدون وصول عشوائي). لكنني أتوقع أننا سنعيد تقييم الافتراضات الأساسية في كثير من الأحيان ، اعتمادًا على كيفية سير الأمور. :)

يمكن لـ GLTFExporter تصدير BufferGeometry والاستيراد إلى Facebook بشكل جيد. لكن أي تحويل Geometry أو BufferGeometry باستخدام الطريقة fromGeometry لا يعمل على Facebook. أتلقى هذا دائمًا في مدقق FB:

[msg] => سمات Vertex COLOR_0 من النوع RGB (مؤقتًا) غير مدعومة. يجب أن يكونوا RGBA.

خطوة التكاثر:

  • باستخدام misc_exporter_gltf سبيل المثال الاحدث في ديف وتصدير المجال أو Walthead عمل جيدة على FB، ولكن export Scene1 النتيجة لا يمكن استيرادها إلى FB.

هل هذا بعض السلوك المتوقع ويجب أن ننتظر الجانب FB؟

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

@ Ben-Mack هذا شيء يجب إصلاحه في الأسابيع المقبلة وفقًا لـ zellski -> https://github.com/mrdoob/three.js/issues/13397#issuecomment -367534958

اعتبارًا من الإصدار 161 وما فوق (الإصدار الحالي من App Store هو 160) لتطبيق FB الرئيسي ، لن يكون هذا تعطلًا بعد الآن وسنقوم بإزالة هذا التحقق من الصحة. أتوقع أن يحدث هذا في غضون أسبوع.

zellski هذا رائع! شكرا :)

يجعلني أتساءل رغم ذلك ...

السبب "الحقيقي" لعدم قدرة THREE.GLTFExporter تصدير THREE.Geometry هو أنه عندما نقوم بتحويل THREE.Geometry إلى THREE.BufferGeometry فإننا ننشئ color السمة التي تكون ، في معظم الحالات ، مليئة بالأصفار.

لذلك ، سيكون أحد "الحلول" (والتحسين) هو عدم تصدير السمة color إذا تم تعيين material.vertexColors على THREE.NoColors ؟

Ops لم أكن أعلم أن: D هذا أمر مؤكد تحسين لا بد منه: D

fernandojsg شكرًا على التحديثات التي أجريتها ، أقدر ذلك كثيرًا. هناك شيئان آخران يستحقان الإضافة:

  1. دعم تنسجم متعدد المواد. تلك التي تحتوي على مجموعات في الأشكال الهندسية والمصفوفة في Mesh.material - لا يمكن تصديرها حاليًا بشكل صحيح ؛
  2. توافق أفضل بين MeshStandardMaterial المدعومة الوحيدة والنتيجة التي حصلنا عليها على Facebook. حتى الآن تبدو الأسطح المعدنية والمنتشرة مختلفة تمامًا في three.js وعلى Facebook. ربما سيكون لدينا مادة خاصة "فيسبوك" ذات يوم؟

شكرا لك

@ o أعتقد أنه من المحتمل أن يتم إصلاح كلاهما حول r91:

  1. تصدير متعدد المواد https://github.com/mrdoob/three.js/pull/13536
  2. إصلاحات المعادن / الخشونة https://github.com/mrdoob/three.js/pull/13501

من المحتمل أن تكون مواد Facebook ليست صحيحة تمامًا حتى الآن ، لكن glTF محدد جدًا حول الكيفية التي يجب أن تظهر بها الأشياء ، لذا يجب أن نتقارب في النهاية.

أوه ، يجب أن نضيف القدرة على تصدير KHR_materials_unlit أيضًا ...

تحرير: تم فتحه https://github.com/mrdoob/three.js/pull/13566

السبب "الحقيقي" الذي لا يستطيع THREE.GLTFExporter تصدير THREE.Geometry لأنه عندما نقوم بتحويل THREE.Geometry إلى THREE.BufferGeometry ، فإننا ننشئ سمة لونية تكون ، في معظم الحالات ، مليئة بالأصفار.

لذلك ، سيكون أحد "الحلول" (والتحسين) هو عدم تصدير سمة اللون إذا تم تعيين material.vertexColors إلى THREE.NoColors؟

+1 نأمل أن يتم إصلاح هذا قريبًا. لا تزال الكثير من مكتبات Three.js تعمل على أساس THREE.Geometry .

(لا يزال FB يواجه الخطأ ...must be RGBA مع THREE.Geometry )

@ Ben-Mack ، ما المكتبات التي تستخدمها ولا تزال تستخدم Geometry؟ ربما يمكننا العمل مع المالكين لتحديثهم.

looeee يرجى إلقاء نظرة على هذه المكتبة: https://github.com/a-jie/threejs-geometry-modifiers

مرحبًا يا رفاق - اعتبارًا من هذا الصباح ، لم يعد Facebook يرفض ألوان رأس RGB (VEC3) باعتبارها "غير صالحة".

تظل متطلبات القوام المكونة من اثنين في الوقت الحالي ، لكنني أعمل على ذلك أيضًا.

تضمين التغريدة :) أنا قريب جدًا من الحصول على دعم كامل للرسام: D هل هناك أي خطة لتنفيذ بقية الأوضاع البدائية؟ أعتقد الآن أنه يتم دعم TRIANGLE فقط ، قد يكون من الرائع دعم الباقي ، على سبيل المثال في الرسام A ، نستخدم TRIANGLE_STRIP لتوفير بعض المساحة 👼

سيكون من الجنون عدم تنفيذها ، أليس كذلك؟ من الناحية المثالية ، يجب قبول جميع أنواع الـ glTF الصالحة. ومع ذلك ، لا أعرف كيف سيتم تحديد أولويات هذا العمل. نحن فريق صغير ولدينا الكثير من الحوافز القوية. :)

أعتقد أنه يمكن إغلاق هذه القضية الآن؟

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