Three.js: Utils: إهمال المصدرين (Blender و 3DS Max و Maya)

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

ملاحظة: مصدر GLTF Blender الرسمي (https://github.com/KhronosGroup/glTF-Blender-Exporter) لا يسمح حاليًا بتصدير الرسوم المتحركة المناسب (يتم دعم رسم متحرك واحد فقط لكل كائن حاليًا).
https://github.com/KhronosGroup/glTF-Blender-Exporter/issues/112

Usnul كيف يمكن مقارنة ذلك

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

حسنًا ، لا أستخدم Blender ، لذا لن أعلق أكثر على ذلك.

ومع ذلك يمكنني القول من التجربة أن محاولة استخدام مُصدِّر 3DS Max ، والذي لم يتم تحديثه منذ عدة سنوات ، يمثل صداعًا لا نهاية له وسأدعم بشدة إزالته من الريبو لصالح تنسيق FBX.
يتم الآن دعم كل شيء تقريبًا يتم تصديره بواسطة مُصدِّر 3DS Max FBX بواسطة FBXLoader وبما أن هذا المصدر يتم صيانته بواسطة AutoDesk ، يمكننا الاعتماد عليه في تحديثه باستمرار.

وبالمثل مع مُصدر Maya FBX ، على الرغم من أن FBXLoader لا يزال بحاجة إلى التحديث لدعم النقاط المحورية بشكل صحيح هناك.

عندما أتذكر بشكل صحيح ، لا يقوم Blender بتصدير الرسوم المتحركة عند تحديد BufferGeometry . هناك بالتأكيد مشكلة في أهداف التحويل ، انظر # 10932. بالإضافة إلى ذلك ، يستخدم المُصدِّر تنسيق التسلسل الهرمي للرسوم المتحركة "القديم" وليس تنسيق نظام الرسوم المتحركة الحالي.

أعتقد أننا يجب أن نزيل برنامج README المُصدِّر Revit أيضًا - فهو يرتبط فقط بمرجع منفصل يبدو أنه بالكاد تم التطرق إليه في العامين الماضيين.

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

يؤدي البحث في Googling عن "three.js revit exporter" إلى أن الريبو جيد على أي حال.

أعتقد أننا يجب أن نزيل برنامج README المُصَدِّر Revit أيضًا - فهو يرتبط فقط بمرجع منفصل يبدو أنه بالكاد تم التطرق إليه في العامين الماضيين.

👍

يعد وجود مصدرين غير محدثين وصيانتين جيدًا في الريبو نقطة ارتباك غير ضرورية للقادمين الجدد

أريد فقط إبراز هذا البيان لأنني أعتقد أنه مهم جدًا لـ three.js . عندما يواجه المستخدمون هؤلاء المصدرين ، فإنهم يتوقعون أدوات تعمل فقط. لكن في معظم الحالات يصابون بالارتباك وربما يكون انطباعًا سيئًا عن المشروع بأكمله. هذا ليس جيدا. 😢

كمستخدم بريء ، هل لي أن أجرؤ على إبداء تعليق ...

بخصوص الخلاط:
إذا كان لدى three.js برنامج استيراد أصلي لتنسيق blend. ،
من الواضح أنه لن تكون هناك حاجة لمصدر.

لا يوجد جهد في التثبيت من جانب الخلاط ،
لا يوجد تجميع من blender API / الهياكل لجافا سكريبت من خلال كود Python ...

كانت هناك جهود جبارة لكتابة مصدر JSON بلغة python ،
أتساءل لماذا لم يختر المتعاونونكم بهذه الطريقة ...؟

تضمين التغريدة
إنه سؤال بسيط إلى حد ما للإجابة عليه. تنسيق المزج ليس قريبًا جدًا من التمثيل الداخلي لـ three.js ، لذلك يلزم إجراء بعض التحويل. تنسيق JSON من three.js قريب جدًا من التمثيل الداخلي ، لذا فإن مهمة التحويل من تمثيل الخلاط إلى three.js موجودة في كلتا الحالتين ، سواء اخترت تسميتها مُصدِّر أو مُحمِّل. ومع ذلك ، فإن. blend ليس تنسيقًا شائعًا للنقل ، ولا شيء يدعمه حقًا باستثناء الخلاط ، لذا فإن وجود محمل له سوف يرضي جمهورًا صغيرًا إلى حد ما ، نظرًا لأن الأشخاص الذين يستخدمون الخلاط بكثرة يميلون إلى استخدام برامج أخرى أيضًا ، و. ليس تنسيقًا مفضلاً كتنسيق تبادل. عادةً ما يكون obj أو fbx أو معيارًا مفتوحًا مثل gltf أو collada.

wolfgangvonludwigsburg إذا كنت _were_ للنظر في بناء محمل ملفات blend. ، فمن المحتمل أن يكون هذا مكانًا جيدًا للبدء:

https://raginggazebo.com/parsing-blender-3d-files-blend-1-of-3/

العديد من THX لتعليقاتكم!

لكن لماذا يتعرض مصدر Blender JSON لمثل هذا الخطأ ...
=> يعتمد ذلك على Blender API ، مكتوب بلغة Python ، يجب أن يفهم هياكل بيانات Blender ،
ويترجم إلى تنسيق JSON ، حيث يتم إعادة تحويل three.js إلى أجزاءها الداخلية ...

هناك الكثير من المهام ، التي يمكن للجميع (ويفعلونها حقًا!) أن تفشل ، بشكل أساسي في تغييرات إصدار Blender.
حسنًا ، أفضل طريقة "تجميع البيانات المباشر" ...

حسنًا ، أفضل طريقة "تجميع البيانات المباشر".

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

حسنًا ، أفضل طريقة "تجميع البيانات المباشر" ...

لسوء الحظ ، هناك مشاكل أعمق في استخدام .blend بهذه الطريقة. يخزن أشياء مثل سجل التحرير والحالة الحالية لواجهة Blender UI وبيانات Blender Add-on. يتغير التنسيق مع ظهور إصدارات Blender الجديدة. ويمكن أن تكون أحجام الملفات كبيرة جدًا ، لذا لن تكون أبدًا خيارًا جيدًا للتطبيقات ثلاثية الأبعاد عالية الجودة. أفضل طريقة للحصول على البيانات مباشرة من Blender هي استخدام واجهات برمجة تطبيقات Blender (كما يفعل مصدرو FBX و glTF) ، بدلاً من محاولة إجراء هندسة عكسية لتنسيق Blender الداخلي .blend .

إلى السؤال الأصلي ، سأتخطى إضافة تصويت بنعم / لا لأنني لا أملك الكثير من الإلمام بسير عمل التأليف ثلاثي الأبعاد.

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

جانباً ، إذا كانت هناك أي مشاكل في النظام البيئي glTF الحالي تمنعه ​​من أن يكون سير عمل جيد بما يكفي لحل هذا النوع من الاحتياجات ، فهذه ملاحظات مفيدة أيضًا. 🙂

لم أجادل في استخدام تنسيق Blender. blend كتنسيق تبادل عام ،
ولكنه قد يبسط التعاون بين Blender و three.js ...

لا يمكنني تقدير الجهود ، مع الاحتفاظ بمصدر Python + GUI ضمن إطار Blender ،
لكن أعتقد أن هذا يمكن أن يصبح رعبًا بسهولة ... ؛-)

تضمين التغريدة
راجع للشغل ، Wavefront .obj ، 3D Studio .3ds هي تنسيقات أصلية أيضًا ، وهي منتشرة على نطاق واسع ...

راجع للشغل ، Wavefront .obj ، 3D Studio .3ds هي تنسيقات أصلية أيضًا ، وهي منتشرة على نطاق واسع ...

نعم ، أعتقد أن OBJ غير مذكور هنا لأن التنسيق لا يدعم بعض الميزات الشائعة مثل الرسوم المتحركة ، ولكن من المؤكد أن three.js ستستمر في دعم OBJ لفترة طويلة جدًا - إنه تنسيق كلاسيكي وموثوق.

3DS Max's .3ds في نفس فئة Blender .blend أو Maya .mlt أو Cinema4D .c4d . كل محرر له تنسيقه الداخلي الخاص به ، وتتغير تلك التنسيقات كما يتغير البرنامج. يعد الحفاظ على أدوات التحميل للتنسيق الداخلي الخاص لكل أداة نمذجة أصعب بكثير وعرضة للأخطاء من استخدام تنسيقات التصدير التي قدمها مطورو المحرر. تجدر الإشارة إلى أن كلاً من 3DS و Blender يأتيان مع تصدير FBX مدمج - يحتفظ به مؤلفوه - وأن Blender سيحتوي أيضًا على تصدير glTF في إصدار مستقبلي أيضًا.

رمية أخيرة ...

لدينا بالفعل أداة نمذجة واحدة مستقلة / مستورد سابق: Collada ،
لكن لأي سبب من الأسباب ، لا يبدو هذا مقبولًا كثيرًا.

من الأفضل أن أفكر في هذا النوع من التنفيذ:
حل تحميل ، يعتمد على مخازن بروتوكول Google

https://developers.google.com/protocol-buffers/

انه

... آلية محايدة اللغة ، ونظام أساسي ، وقابلة للتوسيع لتسلسل البيانات المهيكلة - فكر في XML ، ولكن أصغر وأسرع وأبسط.

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

يوجد في الواقع محلل ملف مزج في جافا سكريبت 😁
https://github.com/Galactrax/js.blend

آه ، أحصل على الدعم ... - شكرًا لك مردوب ؛-))

THE اكبر (من حيث Terrabyte) 3D تطبيق نموذج (خرائط جوجل 3D) يستخدم هذا النوع الفعال (protobufs) من تنفيذ ...

قد لا يكون السير في طريق التحميل. blend عاقلًا جدًا. لكن الأمر لا يختلف حقًا عن تحميل .dae و. fbx ...

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

أوافق على إزالة هؤلاء المصدرين أيضًا. يمكنك حتى نقلها إلى بعض الريبو الأخرى حيث يمكنهم RIP :)

ومع ذلك ، سأنتظر حتى يصبح gltf أكثر نضجًا واختبارًا. صيف 2018؟

الانتظار يبدو معقولا بالنسبة لي. على وجه الخصوص بالنسبة لـ glTF ، سيكون من الجيد وضع بعض الأشياء أولاً:

• [] شحن الخلاط مع تصدير glTF مدمج ، ودعم متعدد للرسوم المتحركة.
• [x] تحسين سير العمل من Maya و 3DS Max إلى glTF ، أو المزيد من اختبار FBX2GLTF .
• [x] تحديثات لمحول COLLADA2GLTF الرسمي لـ glTF 2.0.

يبدو أن إعادة النظر في السؤال في صيف 2018 أمر صحيح.

ومع ذلك ، سأنتظر حتى يصبح gltf أكثر نضجًا واختبارًا. صيف 2018؟

بالنسبة لمصدر الخلاط ، أميل إلى الموافقة. ومع ذلك ، أوصي بإزالة مصدر 3DS Max على الأقل فورًا نظرًا لوجود بديل ناضج وأفضل بكثير في FBX.

ومع ذلك ، أوصي بإزالة مصدر 3DS Max على الأقل فورًا نظرًا لوجود بديل ناضج وأفضل بكثير في FBX.

يبدو جيدا بالنسبة لي 👌

حسنًا ، ذهب مُصدِّر برنامج 3DS Max. دعنا نعيد زيارة المصدرين الآخرين (Blender and Maya) في غضون بضعة أشهر.

لا أعتقد أن الكثير سيتغير فيما يتعلق بمصدر المايا في ذلك الوقت.

ربما ينبغي علينا تقييم ذلك الآن. سأختبرها وأرى ما إذا كان الأمر يستحق الاحتفاظ بها خلال اليومين المقبلين.

اقتراح جيد 👍.

طالما نحن هنا ، ما هي حالة https://github.com/mrdoob/three.js/tree/dev/utils/converters/fbx ؟ يبدو أنه يمكن استبداله ببرنامج نصي node.js مثل محول obj2three ، فقط باستخدام THREE.FBXLoader والتسلسل في النهاية. يحتوي المحول حاليًا على الكثير من المشكلات المفتوحة:

No animation support
Only Lambert and Phong materials are supported
Some camera properties are not converted correctly
Some light properties are not converted correctly
Some material properties are not converted correctly
Textures must be put in asset's folder, and use relative path in the material

أيضًا محولات msgPack و UTF8 و CTM - لم يتم التطرق إليها منذ سنوات.

هل ما زالت مفيدة لأي شخص؟

donmccurdy أخشى أنه لا يمكنك استخدام FBXLoader داخل البرنامج النصي node.js نظرًا لأنه لا يمكنك الوصول إلى DOM. جميع اللوادر التي تستخدم TextureLoader لها تبعية لـ ImageLoader وبالتالي إلى document . سنحصل على أخطاء وقت تشغيل مثل ReferenceError: document is not defined . نفس المشكلة بالنسبة للكائن window الذي يتم الوصول إليه من FileLoader .

كحل مؤقت ، ربما يمكننا إعادة تعريف ImageLoader و FileLoader في الملف fbx2three.js ؟

ربما يمكننا إعادة تعريف ImageLoader و FileLoader في ملف fbx2three.js؟

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

ربما يمكننا إعادة تعريف ImageLoader و FileLoader في ملف fbx2three.js؟

فكرة جيدة: أحمر الخدود:

3DS Max's .3ds في نفس فئة Blender's. blend أو Maya .mlt أو Cinema4D's .c4d.

قد لا يكون هذا صحيحًا تمامًا ، فإن .max يشبه إلى حد كبير نفس الفئة ، حيث يتم تجريد .3ds إلى حد كبير.

أحببت وجود مصدر 3ds max كمثال على كيفية كتابة مصدر ، وعلى maxscript أيضًا. لا أعتقد أنني كنت قادرًا على تصدير مساحة الظل الصحيحة من 3ds max عبر fbx ، باستخدام maxscript ، من السهل التجربة والاستيلاء على الأشياء التي تحتاجها.

هل يستحق وضع اتفاقية إعادة شراء جديدة ، مع إخلاء المسؤولية المناسبة؟ كل ذلك للحصول على أمثلة حول كيفية كتابة مصدر ، ولكن إذا لم تتم المحافظة عليه وأصبح FBXLoader الآن أكثر موثوقية ، فنحن لا نريد أن يفترض الناس أنها الطريقة الموصى بها لجلب الأصول من 3DS Max إلى three.js.

نعم ، إذا كان هناك أي شيء ، فأنا أصوت على الريبو الجديد.

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

pjoe أتوقع أن

ولكن على الرغم من ذلك ، سيكون من الجيد الحصول على ملاحظاتك حول glTF ومصدر Blender . كل ما ذكرته مدعوم:

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

donmccurdy يجب أن أعترف أنه ليس لدي الكثير من الخبرة مع glTF (على الأقل حتى الآن) - على الرغم من أنني حاولت قراءة المواصفات :)

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

من الوقت القصير الذي أمضيته مع الخلاط مصدر glTF بدا أيضًا غير ناضج تمامًا في ذلك الوقت (منذ حوالي شهرين). من الواضح أنه يمكن تصحيح ذلك من خلال المساعدة في تحسينه :)

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

نعم ، إنه غير مصمم للتحرير اليدوي بهذا المعنى ، وكتنسيق وقت التشغيل / الإرسال ، ربما لن يكون كذلك أبدًا. هناك العديد من المكتبات للعمل معها والتي يمكن أن تساعد.

بشكل عام ، وجدت أن مصدر glTF Blender يعطي نتائج أفضل من أي إخراج آخر للخلاط ، ولكن يرجى تسجيل الأخطاء إذا وجدت مشكلات معينة. :)

اتفق donmccurdy على أن تظل glTF وفية لكونها للنقل / وقت التشغيل ... أحد الأشياء الرائعة في ذلك ، هو بالضبط أنها لا تحاول أن تكون مناسبة لجميع التنسيقات (مثل collada - لا تجعلني أبدأ).

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

كملاحظة جانبية ، نستخدم أيضًا أداة تحميل webpack json لتضمين ملف المشهد في الحزمة الرئيسية - مما يجعل التعامل معها أسهل.

لا أعتقد أن الكثير سيتغير فيما يتعلق بمصدر المايا في ذلك الوقت. ربما ينبغي علينا تقييم ذلك الآن. سأختبرها وأرى ما إذا كان الأمر يستحق الاحتفاظ بها خلال اليومين المقبلين.

looeee أنا فضولي ، هل لديك أي أخبار عن هذا؟ هل تعتقد أنه يمكننا إزالة المصدر الآن والرجوع إلى FBX بدلاً من ذلك؟

هل تعتقد أنه يمكننا إزالة المصدر الآن والرجوع إلى FBX بدلاً من ذلك؟

لقد أجريت قدرًا صغيرًا من الاختبارات فقط ، وخططت للقيام بالمزيد ولكن لم يكن لدي الوقت. لكنني أقول نعم ، يجب أن نزيله ونعمل على جعل FBXLoader يدعم Maya بشكل كامل.

التناغم كمستخدم لمصدر Blender هنا: ميزة واحدة لامتلاك JSON هي أنه من السهل للغاية تعديله بعد التصدير. يعتبر Blender جزءًا فقط من سلسلة الأدوات الآلية الخاصة بنا ، ونقوم بالكثير من المعالجة على JSON المُصدَّر ، قبل أن يصبح جاهزًا للانتقال إلى عارض الويب الخاص بنا. يعد وجود تنسيق نقل قريب جدًا من تنسيق threejs الداخلي مكافأة كبيرة لنا.

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

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

أطلقت Soft8Soft للتو برنامج تصدير قائم على glTF لـ 3ds Max . لذلك قد يكون بديلاً جيدًا لمصدر JSON الذي تمت إزالته.

شكرًا alexkowel ، من الرائع رؤية ذلك (ومبروك!). إذا كان بإمكانك إضافة رابط في هذا الموضوع ، فسنقوم بإدراجه مع موارد glTF الأخرى. 🙂

dherben نقاط جيدة ، شكرًا -

حول سرعة التحليل ، أتوقع أن تجد glTF أسرع. يكمن الاختلاف الأساسي في أن البيانات الوصفية لا تزال "مجرد JSON" في حين أن الأجزاء الكبيرة من الحمولة (مواضع الرأس ، وبيانات الرسوم المتحركة) موجودة في مجموعة ArrayBuffer يمكن استخدامها لإنشاء مصفوفة مكتوبة لمُنشئي THREE.BufferAttribute . في أداة تحميل مُحسّنة بالكامل (لا أعرف ما إذا كان برنامج THREE.GLTFLoader موجودًا بالفعل) ، لن تضطر أبدًا إلى قراءة هذه البيانات أو نسخها في JS.

ولكن بالنسبة للتعديلات التي يتم إجراؤها على البيانات كجزء من خط الأنابيب ، فأنا أوافق على أن التعامل مع JSON العادي أسهل ، كما قلت. توجد مكتبات بلغات مختلفة للعمل مع glTF ، لكن الأدوات لم تنضج بعد.

الوضع الحالي لهذه المشكلة:

المصدرين:

• [X] مايا مصدر
• [X] مصدر 3DS Max
• [X] مصدر الخلاط
  
  
  
  • لن أذهب إلى أي مكان الآن ، قد يعيد النظر في المستقبل.
  
  
  • تمت إزالته في مايو 2018.
  
  

المحولات:

• [] FBX
  
  
  
  • تم اقتراح استبدال مبسط كـ https://github.com/mrdoob/three.js/pull/13013 ؛ يحتاج إلى اختبار
  
  
• [] CTM (لم تتم مناقشته)
• [] utf8 (لم تتم مناقشته)
• [] obj2three (لم تتم مناقشته)

EDIT: تم التحديث في مايو 2018.

donmccurdy أردت فقط العودة بعد تجربة المزيد مع مصدر glTF Blender ومحمل Three.js. تبين أنه يعمل بالفعل بشكل جيد مثل تنسيق المشهد لحالة الاستخدام الخاصة بنا حتى الآن. ما أفعله الآن هو تحميل ملف glTF المُصدَّر إلى مشهد Three.js ثم معالجة التسلسل الهرمي للمشهد Three.js (تبديل العناصر النائبة بعناصر محملة ديناميكية) قبل إجراء التصيير الأول.

ربما لا تزال هناك بعض الميزات التي أود رؤيتها في مُصدِّر glTF ، سأحاول التعليق أو إجراء علاقات عامة هناك :)

ربما لا تزال هناك بعض الميزات التي أود رؤيتها في مُصدِّر glTF ، سأحاول التعليق أو إجراء علاقات عامة هناك :)

رائع ، من فضلك! 🙂

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

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

إذا لم يفعل ذلك أحد قبلي ... أود ، على الأقل ، محاولة حل مشكلات التناوب. # 13130

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

لم أقرأ المناقشة بأكملها ، بل قرأت سنتي.

طُلب مني الأسبوع الماضي مساعدة شركة لديها حل يستخدم Three.js في توصيل المحتوى ضمن معرض دائم. لافتات مع نماذج ثلاثية الأبعاد يمكن للمستخدمين استكشافها والتفاعل معها. استخدم مطورو البرامج الأصليون منذ فترة طويلة

يجب IMHO Three.js التركيز على دعم إنشاء ومن الأشكال كذلك سريعة النمو مثل FBX وglTF. الأولوية لتلك التنسيقات التي يمكن أن تحتوي على العديد من صناديق بيانات الأشعة فوق البنفسجية (وبالتالي لا ينبغي تشجيع OBJ المحبوب). ثم الرسوم المتحركة. أعلم أن ملحق تصدير Blender يدعم كليهما من المفترض ، لكن كذلك يدعم FBX.

تخيل سير العمل حيث تخرج أشياء Blender'ed إليه

1) WebGL
من الواضح أن Three.js 😃

2) برنامج OpenGL 3.3+
خام / جمرة

3) برنامج OpenGL ES 2.0 على RISC
من الهاتف الذكي إلى RaspberryPi

4) محركات اللعبة

5) تطبيقات رسومات في الوقت الفعلي مدمجة مع خوادم الوسائط (Hippo ، D3 تمويه)
تلك المرحلة التي يستخدمها شباب المؤثرات البصرية.

بدلاً من الاضطرار إلى استخدام العديد من المصدرين المختلفين لمخرجات مختلفة ، سيكون الهدف هو استخدام تنسيق 1 ، كحد أقصى 2. عند كتابة OGL في الحالات الثلاث الأولى ... يجب استخدام نفس تنسيق النموذج ، هذا كل شيء. بالنسبة للنقطتين الأخيرتين ، فإن FBX هو الملك (تطبيقات مختلفة لـ COLLADA عبر الحزم تجعل من الصعب العمل بها) وهناك في الواقع النموذج غير "مكشوف".
أنا لا أقوم بتقسيم تنسيق Three.js JSON أو mrdoob 🙇 🙏) ، فقد تم استخدامه (كان؟) وربما تم اختراعه لحل المشكلات التي لم تتمكن التنسيقات الأخرى من حلها في ذلك الوقت في المقام الأول (وأنا أفعل ذلك) لديهم أيضًا متلازمة NIHS).
أريد فقط أن أشارك ذلك من منظور حيث يتعين على المرء أن يقدم باستمرار لمخرجات مختلفة داخل الصناعة لا يتناسب تنسيق Three.js JSON مع المشهد ، فهو غير ضروري.

kroko أوافق بالتأكيد 👍

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

بصفتي مبتدئًا ، كان مصدر Three.js JSON تعليميًا للغاية لأنه سمح لي برؤية البيانات الأولية والهيكل الأساسي لهندسات الإخراج. المصدرون الآخرون ، على الرغم من كفاءتهم ، لا يسمحون لك برؤية البيانات لأنهم في الغالب بتنسيق ثنائي.

أوافق على أن إزالته من هذا الريبو سيكون الخيار الأفضل اليوم ، ولكن كما قال hccampos ، ربما يمكن وضعه في الريبو الخاص به ليبقى للأغراض التعليمية.

أوافق على أن إزالته من هذا الريبو سيكون الخيار الأفضل اليوم ، ولكن كما قال hccampos ، ربما يمكن وضعه في الريبو الخاص به ليبقى للأغراض التعليمية.

سيكون هناك دائمًا خيار التصدير بتنسيق JSON من http://threejs.org/editor/

مغلق في https://github.com/mrdoob/three.js/pull/14117.

أقترح أن نغلق الآن جميع المشكلات المفتوحة المتعلقة بمصدر Blender. متفق؟

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

stmaccarelli ، هناك بعض الوثائق الجديدة هنا: https://threejs.org/docs/#manual/introduction/Loading -3D-Models ، لكن نعم ، يرجى إخبارنا بما سيكون مفيدًا أيضًا!

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

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

_.CreateClipsFromMorphTargetSequences (الاسم: String، morphTargetSequence: Array، fps: Number، noLoop: Boolean): صفيف
تُرجع مصفوفة من AnimationClips الجديدة التي تم إنشاؤها من تسلسل هدف التحويل في الشكل الهندسي ، في محاولة لفرز أسماء الأهداف المحولة إلى أنماط قائمة على مجموعة الرسوم المتحركة مثل "Walk_001 ، Walk_002 ، Run_001 ، Run_002 ..." _

المشكلة هي أنه إذا قمت باستيراد ملف glTF ، فلا توجد مصفوفة morphTargetSequence ... هناك بعض كائنات morphTargetSomething مخزنة هنا وهناك ، لكنني لا أعرف ماذا وكيف أستخدم.

أعتقد أنه يجب أن يكون لدينا بعض المستندات التي تصف إدارة / سير العمل النماذج ثلاثية الأبعاد بأمثلة بسيطة للغاية.
ويجب أن تحترم جميع مراجع برامج التحميل ثلاثية الأبعاد نفس القالب.
دعنا نقول
1- استيراد نموذج ثلاثي الأبعاد بسيط
2- استيراد المواد (مع جميع الأجراس والصفارات مثل الخرائط المختلفة ، معلمات الخرائط ، إدارة المواد المتعددة ، إلخ)
3- استيراد المشهد بالكامل (مثل كيفية اجتياز / إدارة المشاهد المستوردة مثل تلك من glTF)
4- استيراد وإدارة الرسوم المتحركة الهيكلية
5- استيراد وإدارة الرسوم المتحركة

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

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

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

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

لا أعتقد أنك ستحتاج عادةً إلى طريقة CreateClipsFromMorphTargetSequences . لا يدخل المستند أعلاه في تفاصيل استخدام أي أداة تحميل معينة (كما ذكرت ، فهي غير متسقة) ، لكن مستندات GLTFLoader تفعل -

loader.load('foo.glb', function(gltf) {
  const clips = gltf.clips;  // Array<THREE.AnimationClip>
  const model = gltf.scene; // THREE.Scene
  ...
});

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

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

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

هذه نقطة عادلة ، ولدينا مجال للتحسين هنا.

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

بالمعنى الدقيق للكلمة ، لم يتم إهمال تنسيق JSON وهيكل البيانات ، ولا تزال طريقة معقولة تمامًا [لإزالة] تسلسل مشهد ، ولكن تم أخذ النقطة. mrdoob ما رأيك في استبدال بعض أمثلة الرسوم المتحركة؟ مثل:

animation / keyframes / json
animation / scene
animation / skinning / blending
animation / skinning / morph

ما رأيك في استبدال بعض أمثلة الرسوم المتحركة؟

+1 لهذا. أنا أصوت لاستبدال ما لا يقل عن الجندي من animation / skinning / blending a بنموذج أكثر حداثة من Mixamo ، مثل هذا:

يمكننا المزج بين الخمول / المشي / الجري ، وربما يكون من الممكن تحويل النموذج إلى glTF إذا كان ذلك مفضلاً.

سيكون حجم النموذج حوالي 9 ميغا بايت ، بينما النموذج الحالي مع جميع الملفات المرتبطة به هو 71 ميغا بايت !!

بالنسبة إلى animation / skinning / morph يمكننا استخدام النموذج الذي كنت أختبر أهداف تحويل FBX به:

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

فيما يلي بعض الأمثلة التي يجب وضعها في الاعتبار:

| لقطة شاشة | ارتباط | الحجم |
| --- | --- | - |
| | ارتباط | 6 ميجا بايت |
| | ارتباط | 3 ميجا بايت |
| | ارتباط | 5 ميغا بايت |
| | ارتباط | 12 ميغا بايت |

جميعها متحركة ، وتعمل بشكل صحيح في three.js ، ومن المحتمل أن تكون مضغوطة أو محسّنة أكثر قليلاً من إصدار Sketchfab الذي تم تنزيله. ليس لدي شخصية مزورة مع دورات تشغيل / سير لطيفة ، لكن سير عمل Mixamo-> glTF ليس سيئًا للغاية.