هذا وتتطلع جيدة حقا!

بالمناسبة ، نحن نخطط لإزالة THREE.GLTFLoader وإعادة تسمية GLTF2Loader → GLTFLoader وقت قريب *. قد يكون من الجيد إعادة تسمية المُصدر باسم GLTFExporter قبل وصول r87 ، لتجنب أي ارتباك ، وبالتالي لن يكون هناك تغيير في الاسم مطلوب بين الإصدارات. عفوًا ، فاتني أنك سميته بالفعل بهذه الطريقة .. استمر! 😆

* mrdoob ، أي تفضيل متى يجب أن يحدث ذلك؟ IMO يمكننا القيام بذلك الآن ، ما لم نرغب في الاحتفاظ بـ GLTFLoader في r87 مع تحذير الإيقاف فقط ، وإزالته في r88؟

أعتقد أنه كلما كان ذلك أفضل. طالما أن GLTFLoader قادر على اكتشاف 1.0 وتحذير المستخدم من أننا ندعم 2.0+ فقط.

IIRC يمكننا الكشف عن طريق رؤية asset كما ذكرت من قبل.

IIRC يمكننا الكشف عن طريق رؤية الأصول كما ذكرت من قبل.

✅ نعم! https://github.com/mrdoob/three.js/pull/11864

رائع! لكنني وجدت خطأً بسيطًا. أنا أقوم بالعلاقات العامة الآن. دعونا ندمج قبل أن نعيد التسمية.

هل يمكننا تحديد العناصر التي يعمل عليها شخص ما في قائمة التحقق؟

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

الشيء التالي الذي سأعمل عليه هو على الزخارف ، لتحويلها إلى base64 بدلاً من استخدام عنوان url فقط

شكرا! أريد المساعدة في جعل مصدر glTF. أنا أبحث في ما يمكنني المساعدة في قائمة التحقق ...

راجع للشغل هل سمحت عمدا لمتغيرين WEBGL_CONSTANTS و THREE_TO_WEBGL عالمي؟

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

takahirox btw لا تتردد في اقتراح عناصر جديدة على القائمة بالطبع! ؛)

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

أريد العمل على عرض المخزن المؤقت المشترك.

BufferViews: أقوم حاليًا بإنشاء BufferView جديدًا لكل Accessor ، ويجب إصلاح ذلك لاستخدام واحد فقط لهذه السمات التي تشترك في نفس المكون

ما سبب كون أحد السمات التي تشترك في نفس المكون ، وليس واحدًا لجميع السمات ، هو محاذاة البيانات ، أليس كذلك؟

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignment

رائع ، لقد أضفتك للتو إلى القائمة 👍 نعم ، تريد أساسًا مشاركة نفس عرض المخزن المؤقت للمكون من نفس النوع ، على سبيل المثال ، إذا كان لديك موضع وطبيعي ، فسيكون لديك موصّلان VEC3 لكنهما سيشيران إلى نفس المخزن المؤقت. يمكن أن تكون نقطة انطلاق رائعة ؛)

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

أعتقد أنه يمكنك تخزين أنواع مختلفة من المكونات في نفس المخزن المؤقت طالما أنها تحتوي على نفس target ، على سبيل المثال normal (Vec3) ، position (Vec3) و uv (Vec2) يمكن أن يكون في نفس عرض المخزن المؤقت ولكن لا يوجد indices . donmccurdy هل يمكنك تأكيد ذلك؟

نعم ، موافق. وكما تشير مواصفات glTF

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignment

يجب أن يكون إزاحة الموصل في bufferView (أي accessor.byteOffset) وإزاحة الموصل في المخزن المؤقت (على سبيل المثال ، accessor.byteOffset + bufferView.byteOffset) مضاعفًا لحجم نوع مكون الموصل.

إنها فكرة جيدة أن نفصل بين طرق عرض المخزن المؤقت بين نوع المكون المختلف (= نوع البيانات مثل عائم وقصير ، وليس vec2 أو vec3) من أجل البساطة. إذا قمنا بفصلها بين نوع مكون طول البيانات المختلفة ، فسيكون أكثر تحسينًا.

راجع للشغل هناك أي أسباب خاصة تجعل المصدر الحالي يدعم فقط accessor.componentType float و uint و ushort؟ يمكن لـ glTF 2.0 التعامل مع char و uchar و short ، بالإضافة إلى ذلك.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#accessorcomponenttype -white_check_mark

takahirox ليس حقًا ، لقد حددت هذه
الخطوة التالية التي أعمل عليها هي الأنسجة ، لذا سنحتاج إلى أشياء أخرى مثل uchar على سبيل المثال

حسنًا ، سأعمل أولاً على accessor.componentType s ما لم تكن قد بدأت بالفعل في الضم.

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

هل تضيف الرسوم المتحركة إلى القائمة؟

takahirox بالتأكيد ، قد يكون من الرائع إضافة الرسوم المتحركة. لم أقم بإضافته لأنني لم أكن على دراية كافية بالحالة الحالية لميزات الرسوم المتحركة على three.js ، ولكن إذا كنت ترغب في توليها ، فسيكون ذلك رائعًا ؛)

هل تخطط لدعم مجموعات BufferGeometry؟
هل تغطي مواصفات GLTF ذلك أم أنها ستؤدي إلى إنشاء شبكة جديدة لكل مجموعة؟
يجب أن يهتم هذا أيضًا بكون الخاصية المادية للشبكة عبارة عن مجموعة من المواد.

marcatec تحتوي مواصفات glTF على تمييز "شبكة" مقابل "بدائي" يسمح لك بإنشاء مجموعات BufferGeometry يمكن أن تشير كل منها إلى مادة مختلفة. حاليًا ، لا يعمل برنامج THREE.GLTFLoader على تحسين التحميلات الأولية - فهو ينشئ شبكات منفصلة - ولكن يمكن تنفيذ ذلك.

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

أنا أتفق ، عمل عظيم!

هل هناك خطط لإضافة دعم للمواد الأخرى بخلاف StandardMaterial؟

شكرا!

homerjam ، سيتم الاحتفاظ بأي خصائص مادية مشتركة مع MeshStandardMaterial - على سبيل المثال ، سيتم تصدير MeshPhongMaterial باستخدام map و normalMap مع هذه الأنسجة سليمة ، ولكن عند استيرادها مرة أخرى إلى three.js سيكون MeshStandardMaterial. يقوم المصدر حاليًا بتحويل ساذج إلى PBR لهذا الغرض.

سيتطلب دعم رحلة الذهاب والإياب (تصدير Phong من GLTFExporter ، وتحميل Phong من GLTFLoader) عملاً قيد التنفيذ على تنسيق glTF: https://github.com/KhronosGroup/glTF/pull/1150

baseColorTexture : إنه مدعوم (خريطة المواد) لكن texCoord مضبوط دائمًا على 0

fernandojsg هل يمكنك توضيح ما هو مفقود هنا؟ نظرًا لأن .map هو دائمًا أول عنصر UV يتم تعيينه في three.js ، يبدو أن هذا هو الطريقة الصحيحة لتمثيل ذلك في glTF؟

أيضًا تنبيه ، شطبت ثلاثة عناصر في القائمة. التفكير أدناه:

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

من خلال التصدير إلى GLB من المحرر ، لاحظت أنه لم يتم تصدير alphaMap و roughnessMap و metalnessMap .

في 13397 normalMap لم يتم تصدير أي منهما ولكن يبدو أنني كنت مخطئا.

من خلال التصدير إلى GLB من المحرر ، لاحظت أن alphaMap و roughnessMap و metalnessMap لا يتم تصديرها.

سأعمل على هذا اليوم ما لم يبدأ أحد بالفعل.

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

ملحقات متفرقة
أعتقد أنه من الأفضل ترك هذا لتحسين ما بعد التصدير ، مثل نص مات ديزل.

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

تضمين التغريدة إنطلق!

لا أعتقد أن alphaMap مدعوم في glTF 2.0.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#material

نعم ، كنت أخشى أن .... ماذا عن metalnessMap و roughnessMap ؟

أنا أعمل عليها الآن!

13415

بخصوص تنسيقات الصور. يدعم الإصدار 2.0 من glTF فقط .png و. jpg كملفات صور خارجية. أفكر في كيفية التعامل مع ملفات تنسيق الصور غير المدعومة (على سبيل المثال: .bmp) في الوضع غير embedImages .

1. تحويل إلى .png أو .jpg وتضمين
2. لا تهتم. تصدير كملفات صور أصلية
3. لا تصدر

أنا أفضل 1. أي أفكار؟

واو ، حقا أقدر أعمالكم يا رفاق.

آمل أن يتم تنفيذ Multi-material meshes أسرع وقت ممكن لأن معظم النماذج ثلاثية الأبعاد تستخدم مواد متعددة.

1. تحويل إلى .png أو .jpg وتضمين
2. لا تهتم. تصدير كملفات صور أصلية
3. لا تصدر

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

آمل أن يتم تنفيذ شبكات متعددة المواد في أسرع وقت ممكن لأن معظم النماذج ثلاثية الأبعاد تستخدم مواد متعددة.

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

آمل أن يتم تنفيذ شبكات متعددة المواد في أسرع وقت ممكن لأن معظم النماذج ثلاثية الأبعاد تستخدم مواد متعددة.

كما قلت في الموضوع الآخر ، أنا أعمل عليه.

1. تحويل إلى .png أو .jpg وتضمين
2. لا تهتم. تصدير كملفات صور أصلية
3. لا تصدر

أنا أصوت لـ 3 وأقوم بتسجيل تحذير في وحدة التحكم

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

السبب الذي جعلني أفضل 1. هو التحويل من تنسيقات أخرى إلى تنسيق glTF. بعض (أو العديد) من التنسيقات الأخرى ليس لها قيود على تنسيق الصورة.

يقوم المُصدّر بالتحويل في الوضع embedImages . لذا فإن إضافة "خيار استخدام embedImages إذا كنت تريد التحويل" إلى تحذير وحدة التحكم سيكون أمرًا جيدًا ، على ما أعتقد.

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

كما تمت مناقشته في https://github.com/mrdoob/three.js/pull/13415#issuecomment -369022383 ، سيكون من الجيد أن يتمكن المصدر من تكوين نسيج ambientRoughnessMetalness للمستخدم. ربما من الأفضل وضع هذا الرمز في ImageUtils رغم ذلك.

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

آمل أن يتم تنفيذ شبكات متعددة المواد في أسرع وقت ممكن لأن معظم النماذج ثلاثية الأبعاد تستخدم مواد متعددة.

كما قلت في الموضوع الآخر ، أنا أعمل عليه.

WIP ... (لدى Miku مواد متعددة)

حول تنسيقات الصور غير المدعومة ، حسنًا ، دعنا ننتقل إلى 3.

takahirox تبدو جيدة! 👍

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

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

أليس هذا يشبه إلى حد كبير gzipping a glb؟

.glTF + خارجي .bin والقوام سيكون مناسبًا لأدوات التأليف الأخرى (ربما)

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

لا يوجد رأي قوي حول ما إذا كنا نريد وضع هذه الوظيفة في THREE.GLTFExporter مباشرة ... لكنني أعتقد أنه لا ينبغي أن يكون لدينا الكثير من الخيارات التي يمكن بدلاً من ذلك أن تكون تحسينات لاحقة على glTF. مثال آخر ، Draco معقد نوعًا ما ويتطلب العديد من الملفات الخارجية ، لذلك ربما يكون من الأفضل السماح لأدوات glTF-to-glTF المتخصصة بإجراء هذا التحسين؟ وبالمثل ، يمكننا إنشاء برنامج glb-unpacker (مقابل http://glb-packer.glitch.me/) لمساعدة الأشخاص في فك ضغط الملفات من GLB إلى ZIP إذا اكتشفنا أن الناس بحاجة إليها.

من https://github.com/KhronosGroup/glTF/issues/1256 -

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

ومع ذلك ، لا يوجد برنامج glb-unpacker حتى الآن الذي أعرفه ...

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

أردت أن تكون صور النسيج خارجية ، بدلاً من .glTF مقابل glb.

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

لقد تابعت https://github.com/KhronosGroup/glTF/issues/1117 المناقشة وأوافق على تشجيع الملفات المضمنة glb + ونهج خط الأنابيب الآن. واحد .glb مفيد لنقل البيانات خاصة لشبكة الويب ونهج خطوط الأنابيب الذي يمكن أن يبقي المصدرين والأدوات بسيطة وقابلة لإعادة الاستخدام. (أنا أحب نهج خط أنابيب أوامر UNIX / Linux ، أيضًا!)

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

فيما يتعلق بـ glb-unpacker ، قد أقوم بعمله في وقت فراغي. أعتقد أن بعض الفنانين يحبون ملفات .glTF + الخارجية لأنها قابلة للقراءة بدون أي أدوات خاصة بـ glTF. وأحيانًا يمكن أن تقلل الملفات الخارجية من وقت التحميل بسبب ملف التحميل المتوازي بحيث يمكن استخدامه لغرض التحسين.

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

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

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

فقط في حالة ، في GLTFLoader يتم تنفيذ الدعم الثنائي كامتداد ولكن glb في المواصفات الأساسية لـ glTF 2.0 ، أليس كذلك؟

فقط في حالة ، في GLTFLoader يتم تنفيذ الدعم الثنائي كامتداد ولكن glb في المواصفات الأساسية لـ glTF 2.0 ، أليس كذلك؟

نعم ، لقد كان امتدادًا في glTF 1.0 ولم أقم مطلقًا بتغيير موقع هذا الرمز أو إعادة تسميته بعد أن أصبح جزءًا من مواصفات glTF 2.0 الأساسية.

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

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

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

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

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

متفق عليه بعد ذلك. من الجيد أن يكون لديك أدوات مركزة منخفضة المستوى يمكن استخدامها لبناء أدوات أخرى أو توصيلها بواجهة مستخدم رسومية أكثر سهولة في الاستخدام.

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

اهلا ياجماعة

أنا أستخدم THREE.js GLTF Exporter لتصدير مشهد أفريم كامل ككائن gltf.
كيف يمكنني الحصول على علامات الرسوم المتحركة المحددة على aframe لتكون جزءًا من الرسوم المتحركة في كائن gltf؟

donmccurdyfernandojsgmrdoob

Hisiddhartpai - THREE.GLTFExporter يحول فقط THREE.AnimationClip كائنات إلى رسوم متحركة glTF ، بينما يستخدم نظام الرسوم المتحركة A-Frame TweenJS. لذلك هذا غير ممكن حاليا. قد ترغب في فتح مشكلة على A-Frame أو A-Frame Inspector ، والتي تستخدم أيضًا GLTFExporter ، لطلبها كميزة مستقبلية.

دعم متعدد المواد # 13536

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

يبدو أنه يجب تطبيع NORMAL .

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes

عادي | "VEC3" | 5126 (عائم) | معايير قمة XYZ الطبيعية

تمت الموافقة على ضمان لأن Three.js normal لا يوجد به مثل هذا القيد.

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

ماذا تفعل عندما لا يكون لديك قيمة طبيعية فعلية ، مثل القيمة غير المستخدمة [0،0،0]

جلالة .... استبدالها بواحد صحيح وتحذير؟

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

أفضل القيام بذلك processMesh() لأنه سيكون أبسط ، مثل

var originalNormal = geometry.attributes.normal;

if ( hasNonNormalizedValues( originalNormal ) ) {

    geometry.attributes.normal = createNormalizedAttribute( originalNormal );

}

processAccessorHere();

geometry.attributes.normal = originalNormal;

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

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

حسنا سأفعل. (هل أنت في عجلة من أمرنا لإصلاح ذلك؟)

takahirox رائع ، شكرا! لكن دون استعجال ، كنت أراجع حالة المُصدر ^ _ ^

حسنًا ، سأفعل غدًا ~ هذا الأسبوع.

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

أفضل أن أجعل الأمور أسهل على المستخدم ، لذا فإن تصويتي هو لإنشاء مجموعة قياسية جديدة لتطبيعها وإضافة قيمة (0،1،0) إلى القيم الفارغة.

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

نعم كنت على وشك كتابة نفس الشيء! :د

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

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

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

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

حتى لو كان مجرد التحقق مما إذا كانت تطبيع؟

takahirox ، ستحتاج إلى حساب الطول على أي حال ، لذا أعتقد أنه لن يتغير كثيرًا

حسنًا. سأقيم مع العلاقات العامة.

إنها أول ميزة GLTFExporter قدمناها والتي تقوم بأي حساب مع كل قمة (باستثناء تحويل الهدف النسبي / المطلق) لذا من المحتمل أن يكون أبطأ .. في كلتا الحالتين.

عمل عظيم! يجب دمج IMHO في العناصر الأساسية three.js ، وليس في "الأمثلة".
أحب أن أرى الدعم KHR_lights_punctual !

يضيف PR https://github.com/mrdoob/three.js/pull/15519 KHR_lights_punctual. :)

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

• [] إعادة استخدام Bufferviews
• [] دمج القوام المعدني / الخام / ao تلقائيًا

مرحبًا يا رفاق ، هل يعرف أي شخص كيف يمكنني تصدير شبكة ذات شكل مخصص عن طريق تغييرات التحويل بتطبيق الأشكال وإزالتها من الكائن النهائي؟
مثل هذا السؤال https://stackoverflow.com/questions/57423471/how-to-export-morph-changed-meshes-from-threejs-application
شكرا لك مقدما!

@ vini-guerrero الرجاء استخدام المنتديات (https://discourse.threejs.org/) أو Stack Overflow للحصول على المساعدة ، بدلاً من مشكلات GitHub.