यह वास्तव में अच्छा लग रहा है!

वैसे, हम THREE.GLTFLoader को हटाने और GLTF2Loader → GLTFLoader नाम बदलने की योजना बना रहे हैं। किसी भी भ्रम से बचने के लिए r87 भूमि से पहले निर्यातक का नाम GLTFExporter के रूप में बदलना एक अच्छा विचार हो सकता है और इसलिए रिलीज़ के बीच नाम परिवर्तन की आवश्यकता नहीं होगी। ओह, मुझे याद आया कि आपने इसे पहले ही इस तरह नाम दिया है.. जारी रखें! मैं

* @mrdoob , ऐसा कब होना चाहिए, इस पर कोई वरीयता? IMO हम इसे अभी कर सकते हैं, जब तक कि हम GLTFLoader को r87 में केवल एक पदावनति चेतावनी के साथ रखना चाहते हैं, और इसे r88 में हटा दें?

मुझे लगता है कि जितनी जल्दी हो उतना अच्छा। जब तक नया GLTFLoader 1.0 का पता लगाने में सक्षम है और उपयोगकर्ता को चेतावनी देता है कि हम केवल 2.0+ का समर्थन करते हैं।

जैसा कि मैंने पहले उल्लेख किया है, आईआईआरसी हम asset देखकर पता लगा सकते हैं।

जैसा कि मैंने पहले उल्लेख किया है, आईआईआरसी हम संपत्ति को देखकर पता लगा सकते हैं।

हाँ! https://github.com/mrdoob/three.js/pull/11864

ठंडा! लेकिन मुझे एक छोटी सी बग मिली है। मैं अभी पीआर बना रहा हूं। नाम बदलने से पहले आइए विलय करें।

क्या हम उन वस्तुओं को निर्दिष्ट कर सकते हैं जिन पर कोई व्यक्ति चेकलिस्ट में काम कर रहा है?

@takahirox यकीन है! लोग यहां केवल टिप्पणियां लिख सकते हैं और मैं सूची को अपडेट कर सकता हूं और पीआर को इंगित कर सकता हूं यदि पहले से ही कुछ चल रहा है

अगली चीज़ जो मैं काम कर रहा हूँ वह बनावट पर है, उन्हें केवल url का उपयोग करने के बजाय बेस 64 में परिवर्तित करना है

धन्यवाद! मैं जीएलटीएफ निर्यातक बनाने में मदद करना चाहता हूं। मैं देख रहा हूँ कि मैं चेकलिस्ट में क्या मदद कर सकता हूँ...

बीटीडब्ल्यू क्या आपने जानबूझकर दो चर WEBGL_CONSTANTS और THREE_TO_WEBGL वैश्विक होने दिया है?

@takahirox कूल!
दो चर के संबंध में, यह कुछ ऐसा है जिसे मैं निम्नलिखित पीआर में संबोधित करने जा रहा हूं ताकि इसे WebGLUtils का हिस्सा बनाया जा सके और इसे आयात किया जा सके। इसका कोई मतलब नहीं है कि इन स्थिरांकों की आवश्यकता वाले प्रत्येक व्यक्ति को हर बार उन्हें फिर से परिभाषित करने की आवश्यकता है।

@takahirox btw पाठ्यक्रम की सूची में नई वस्तुओं का प्रस्ताव करने के लिए स्वतंत्र महसूस करें! ;)

@fernandojsg ज़रूर! चर के बारे में, मैं उन्हें कहीं और स्थानांतरित करने का प्रस्ताव देना चाहता था यदि उन्हें जानबूझकर वैश्विक घोषित किया गया है, इसलिए यह जानना अच्छा है कि आप करते हैं।

मैं साझा बफर व्यू पर काम करना चाहता हूं।

बफर व्यू: वर्तमान में मैं प्रत्येक एक्सेसर के लिए एक नया बफर व्यू बना रहा हूं, इसे इन विशेषताओं के लिए केवल एक का उपयोग करने के लिए तय किया जाना चाहिए जो समान घटक प्रकार साझा करते हैं

एक ही घटक प्रकार साझा करने वाली विशेषताओं के लिए एक कारण, सभी विशेषताओं के लिए एक नहीं, डेटा संरेखण के लिए सही है?

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

बढ़िया, मैंने अभी आपको सूची में जोड़ा है हां, मूल रूप से आप एक ही प्रकार के घटक के लिए एक ही बफर दृश्य साझा करना चाहते हैं, उदाहरण के लिए यदि आपके पास स्थिति और सामान्य है तो आपके पास दो वीईसी 3 एक्सेसर्स होंगे लेकिन वे इंगित करेंगे एक ही बफरव्यू के लिए। यह एक महान प्रारंभिक बिंदु हो सकता है;)

मेरा मतलब था, कारण है कि हम अलग-अलग घटकों के बीच बफर व्यू को साझा नहीं करने देते हैं (उदा: फ्लोट और शॉर्ट) अच्छा डेटा संरेखण रखना है, सही है?

मेरा मानना ​​​​है कि आप एक ही बफर व्यू में विभिन्न घटक प्रकारों को तब तक स्टोर कर सकते हैं जब तक उनके पास समान target , उदाहरण के लिए normal (Vec3) , position (Vec3) और uv (Vec2) एक ही बफर दृश्य में हो सकता है लेकिन indices नहीं। @donmccurdy क्या आप इसकी पुष्टि कर सकते हैं?

हाँ, सहमत हुए। और जैसा कि इस glTF विनिर्देश का उल्लेख है

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

एक एक्सेसर का बफ़र व्यू (यानी, एक्सेसर.बाइटऑफ़सेट) में ऑफ़सेट और एक एक्सेसर का बफर में ऑफ़सेट (यानी, एक्सेसर.बाइटऑफ़सेट + बफरव्यू.बाइटऑफ़सेट) एक्सेसर के घटक प्रकार के आकार का एक बहु होना चाहिए।

यह एक अच्छा विचार है कि हम सरलता के लिए अलग-अलग कंपोनेंट टाइप (= डेटा टाइप जैसे फ्लोट और शॉर्ट, न कि vec2 या vec3) के बीच बफर व्यू को अलग करते हैं। यदि हम उन्हें अलग-अलग डेटा लंबाई के घटक प्रकार के बीच अलग करते हैं, तो यह अधिक अनुकूलित होगा।

बीटीडब्ल्यू क्या कोई विशेष कारण है कि वर्तमान निर्यातक केवल accessor.componentType फ्लोट, यूंट और यूशॉर्ट का समर्थन क्यों करता है? glTF 2.0 उनके अलावा char, uchar, और short को भी हैंडल कर सकता है।

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

@takahirox वास्तव में नहीं, मैंने अभी तक इन्हें परिभाषित किया है क्योंकि वे उन विशेषताओं के प्रकार के लिए उपयोग किए जाते हैं जिनका हम अभी समर्थन करते हैं (स्थिति, मानदंड, रंग, यूवी, सूचकांक ..)।
अगला चरण जिस पर मैं काम कर रहा हूं, वह है टेक्सचर्स इसलिए वहां हमें अन्य की आवश्यकता होगी जैसे uchar उदाहरण के लिए

ठीक है, तो मैं पहले accessor.componentType s पर काम करूंगा जब तक कि आप पहले से ही निहित करना शुरू नहीं कर देते।

लगभग तैयार लेकिन मेरे पीआर को #11978 के साथ संघर्ष करना चाहिए।
एक बार #11978 के विलय के बाद मैं अपना भेजता हूं और मैं संघर्ष को ठीक करता हूं।

क्या आप सूची में एनिमेशन जोड़ेंगे?

@takahirox यकीन है, एनीमेशन जोड़ने के लिए यह बहुत अच्छा हो सकता है। मैंने इसे सिर्फ इसलिए नहीं जोड़ा क्योंकि मैं तीन.जेएस पर एनीमेशन सुविधाओं की वर्तमान स्थिति से पर्याप्त परिचित नहीं था, लेकिन अगर आप इसे लेना चाहते हैं, तो यह बहुत अच्छा होगा;)

क्या आप BufferGeometry समूहों का समर्थन करने की योजना बना रहे हैं?
क्या जीएलटीएफ विनिर्देश इसे कवर करते हैं या इसके परिणामस्वरूप प्रत्येक समूह के लिए एक नया जाल तैयार होगा?
यह भी ध्यान रखना चाहिए, मेष की भौतिक संपत्ति सामग्री की एक सरणी है।

@marcatec glTF स्पेक में "मेष" बनाम "आदिम" भेद होता है जो आपको BufferGeometry समूह बनाने की अनुमति देता है जो प्रत्येक एक अलग सामग्री का संदर्भ दे सकता है। वर्तमान में THREE.GLTFLoader लोडिंग प्रिमिटिव को ऑप्टिमाइज़ नहीं करता है - यह अलग मेश बनाता है - लेकिन इसे लागू किया जा सकता है।

बढ़िया काम, बढ़िया सूची और यह जानकर अच्छा लगा कि प्रारूप पर पहले से ही इतना समर्थन है! साथ ही जीएलटीएफ ब्लेंडर निर्यातक के साथ भी बहुत अच्छी तरह से काम करता है। रोशनी के समर्थन के लिए इंतजार नहीं कर सकता! अच्छा काम करते रहो।

मैं सहमत हूँ, बढ़िया काम!

क्या मानक सामग्री के अलावा अन्य सामग्रियों के लिए समर्थन जोड़ने की योजना है?

धन्यवाद!

@homerjam MeshStandardMaterial के साथ साझा किए map और normalMap का उपयोग करने वाला MeshPhongMaterial उन बनावटों के साथ निर्यात करेगा, लेकिन जब आप इसे वापस तीन में आयात करते हैं। एक MeshStandardMaterial होगा। निर्यातक वर्तमान में इसके लिए पीबीआर में एक सरल रूपांतरण करता है।

राउंड-ट्रिप समर्थन (GLTFExporter से निर्यात फोंग, GLTFLoader से लोड फोंग) को glTF प्रारूप पर प्रगति पर काम करने की आवश्यकता होगी: https://github.com/KhronosGroup/glTF/pull/1150

baseColorTexture : यह समर्थित है (material.map) लेकिन texCoord हमेशा 0 पर सेट होता है

@fernandojsg क्या आप स्पष्ट कर सकते हैं कि यहाँ क्या याद आ रही है? चूँकि .map हमेशा तीन.js में पहला UV सेट होता है, यह glTF में इसका प्रतिनिधित्व करने का सही तरीका लगता है?

इसके अलावा, मैंने सूची में तीन वस्तुओं को पार किया। नीचे तर्क:

• स्पर्शरेखा
  
  
  
  • three.js केवल उनकी गणना GPU पर करता है; केवल निर्यातक के लिए एक कार्यान्वयन जोड़ना आदर्श नहीं लगता।
  
  
• विरल एक्सेसर्स
  
  
  
  • मुझे लगता है कि यह पोस्ट-एक्सपोर्ट ऑप्टिमाइज़ेशन के लिए सबसे अच्छा छोड़ दिया गया है, जैसे mattdesl's script ।
  
  
• जांचें कि क्या सामग्री glTF डिफ़ॉल्ट से मेल खाती है और इसे छोड़ दें
  
  
  
  • एक किनारे के मामले / अव्यवस्था की तरह लगता है, अगर कोई दृढ़ता से महसूस करता है तो इसे लागू करने में संकोच न करें
  
  

संपादक से GLB को निर्यात करके मैंने देखा है कि alphaMap , roughnessMap और metalnessMap निर्यात नहीं होते हैं।

#13397 में मैंने कहा था कि normalMap न तो निर्यात किया जाता है लेकिन ऐसा लगता है कि मैं गलत था।

संपादक से जीएलबी को निर्यात करके मैंने देखा है कि अल्फा मैप, खुरदरापन मैप और मेटलनेस मैप निर्यात नहीं होता है।

मैं आज इस पर काम करूंगा जब तक कि किसी ने पहले ही शुरू नहीं कर दिया हो।

@donmccurdy

विरल एक्सेसर्स
मुझे लगता है कि यह पोस्ट-एक्सपोर्ट ऑप्टिमाइज़ेशन के लिए सबसे अच्छा बचा है, जैसे मैटडेसल की स्क्रिप्ट।

ऐसा महसूस हो रहा है कि निर्यातक को मॉर्फ के लिए विरल एक्सेसर्स का समर्थन करने देना है। मेरी बाद में कोशिश रहेगी।

@takahirox कूल! आगे बढ़ो!

मुझे नहीं लगता कि alphaMap glTF 2.0 में समर्थित है।

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

हाँ, मुझे डर था कि.... metalnessMap और roughnessMap क्या?

मैं अब उन पर काम कर रहा हूँ!

13415

छवि प्रारूपों के संबंध में। glTF 2.0 बाहरी छवि फ़ाइलों के रूप में केवल .png और .jpg का समर्थन करता है। मैं गैर embedImages मोड पर गैर समर्थित छवि प्रारूप फ़ाइलों (जैसे: .bmp) को संभालने के तरीके पर विचार कर रहा हूं।

1. .png या .jpg में कनवर्ट करें और एम्बेड करें
2. परवाह मत करो। मूल छवि फ़ाइलों के रूप में निर्यात करें
3. निर्यात न करें

मुझे पसंद है 1. कोई विचार?

वाह, वास्तव में आप लोगों के कार्यों की सराहना करते हैं।

आशा है कि Multi-material meshes को यथाशीघ्र लागू किया जाएगा क्योंकि अधिकांश 3D मॉडल बहु-सामग्री का उपयोग कर रहे हैं।

1. .png या .jpg में कनवर्ट करें और एम्बेड करें
2. परवाह मत करो। मूल छवि फ़ाइलों के रूप में निर्यात करें
3. निर्यात न करें

मैं 3 के लिए वोट करता हूं और कंसोल में एक चेतावनी लॉग करता हूं।

आशा है कि मल्टी-मटेरियल मेश को यथाशीघ्र लागू किया जाएगा क्योंकि अधिकांश 3D मॉडल मल्टी-मैटेरियल्स का उपयोग कर रहे हैं।

सहमत हूं, मेरे लिए यह निर्यातक के उपयोग को रोकने वाला नंबर एक मुद्दा है।

आशा है कि मल्टी-मटेरियल मेश को यथाशीघ्र लागू किया जाएगा क्योंकि अधिकांश 3D मॉडल मल्टी-मैटेरियल्स का उपयोग कर रहे हैं।

जैसा कि मैंने दूसरे सूत्र में कहा, मैं इस पर काम कर रहा हूं।

1. .png या .jpg में कनवर्ट करें और एम्बेड करें
2. परवाह मत करो। मूल छवि फ़ाइलों के रूप में निर्यात करें
3. निर्यात न करें

मैं 3 के लिए वोट करता हूं और कंसोल में चेतावनी दर्ज करता हूं

हाँ, मुझे लगा कि 3. सरल होगा और उपयोगकर्ताओं को भ्रमित नहीं करेगा। गैर emedImages मोड पर एम्बेडेड छवि प्राप्त करना थोड़ा भ्रमित करने वाला होगा।

कारण है कि मैं 1 पसंद करता हूं। अन्य प्रारूपों से जीएलटीएफ में कनवर्ट करना था। अन्य प्रारूपों में से कुछ (या कई) में छवि प्रारूप की सीमा नहीं है।

निर्यातक embedImages मोड पर कनवर्ट करता है। तो कंसोल चेतावनी में "यदि आप कनवर्ट करना चाहते हैं तो एम्बेड इमेज विकल्प का उपयोग करें" जोड़ना अच्छा होगा, मैं सोच रहा हूं।

मैं भी 3 के लिए जाऊंगा। चूंकि अन्य प्रारूपों से परिवर्तित करना कठिन हो सकता है, और आपको कुछ प्रारूपों को दूसरों के मुकाबले प्राथमिकता देने की आवश्यकता होगी। शायद यह अभी 3 करने लायक है और यह देखने के लिए प्रतीक्षा करें कि क्या gltf ktx या तो नए बनावट प्रारूपों में समर्थन जोड़ता है और हम कार्यान्वयन पर फिर से जा सकते हैं।

जैसा कि https://github.com/mrdoob/three.js/pull/13415#issuecomment -369022383 में चर्चा की गई है, यह अच्छा होगा यदि निर्यातक उपयोगकर्ता के लिए ambientRoughnessMetalness बनावट बनाने में सक्षम हो। हालांकि उस कोड को ImageUtils में रखना बेहतर होगा।

मैंने नवीनतम परिवर्तनों के साथ चेकलिस्ट को अपडेट किया है। मैंने multimaterial आइटम में @takahirox जोड़ा है, और मैं छवियों को लिखने का कार्य स्वयं लूंगा।
मैंने material_unlit एक्सटेंशन भी जोड़ा है, हालांकि अभी भी मसौदे में है, मेरा मानना ​​​​है कि यह रिलीज के काफी करीब है और इतना नहीं बदलेगा (/cc @donmccurdy)

आशा है कि मल्टी-मटेरियल मेश को यथाशीघ्र लागू किया जाएगा क्योंकि अधिकांश 3D मॉडल मल्टी-मैटेरियल्स का उपयोग कर रहे हैं।

जैसा कि मैंने दूसरे सूत्र में कहा, मैं इस पर काम कर रहा हूं।

WIP... (Miku में बहु-सामग्री है)

गैर-समर्थित छवि प्रारूपों के बारे में, ठीक है, आइए 3 पर चलते हैं।

@takahirox अच्छा लग रहा है! मैं

BTW, क्या आप लोग ज़िप संग्रह समर्थन में रुचि रखते हैं? .glTF + बाहरी .bin और बनावट अन्य संलेखन उपकरण (शायद) के लिए उपयुक्त होंगे, लेकिन गैर-संग्रह के साथ करना कठिन होगा। तो ज़िप संग्रह आवश्यक होगा। और हम निर्यात की गई फ़ाइल का आकार कम कर सकते हैं।

मुझे यह चाहिए और मैंने पहले अपनी स्थानीय शाखा में कोशिश की, यदि आप रुचि रखते हैं तो मैं बाद में साझा कर सकता हूं।

क्या यह काफी हद तक ग्लोब को gzipping करने जैसा नहीं है?

.glTF + बाहरी .bin और बनावट अन्य संलेखन उपकरण (शायद) के लिए उपयुक्त होंगे

मुझे आशा है कि संलेखन उपकरण के लिए अलग फाइलों की आवश्यकता नहीं होगी; हम सभी को डिफ़ॉल्ट रूप से GLB का उपयोग करने के लिए प्रोत्साहित कर रहे हैं। लेकिन अगर छवि एम्बेड नहीं की गई है, तो निश्चित रूप से किसी छवि को हाथ से संपादित करना आसान है।

इस बारे में कोई ठोस राय नहीं है कि क्या हम उस कार्यक्षमता को सीधे THREE.GLTFExporter में रखना चाहते हैं... लेकिन मुझे लगभग लगता है कि हमारे पास बहुत अधिक विकल्प नहीं होने चाहिए जो इसके बजाय glTF पर पोस्ट-ऑप्टिमाइज़ेशन हो सकते हैं। एक और उदाहरण, ड्रेको जटिल है और इसके लिए कई बाहरी फाइलों की आवश्यकता होती है, इसलिए शायद यह बेहतर होगा कि विशेष glTF-to-glTF टूल को वह ऑप्टिमाइज़ेशन करने दें? और इसी तरह हम लोगों को GLB से ZIP तक फ़ाइलों को अनपैक करने में मदद करने के लिए एक glb-unpacker (http://glb-packer.glitch.me/ के विपरीत) बना सकते हैं यदि हमें पता चलता है कि लोगों को इसकी आवश्यकता है।

https://github.com/KhronasGroup/glTF/issues/1256 से —

... gltf-पाइपलाइन का मूल उद्देश्य - और वास्तव में सामान्य रूप से glTF - निर्यातकों को यथासंभव सरल बनाते हैं और ऑप्टिमाइज़ेशन को एक सामान्य टूल पर धकेलते हैं। यह, निश्चित रूप से, विखंडन में भी मदद करेगा।

उस ने कहा, कोई भी ग्लोब-अनपैकर अभी तक मौजूद नहीं है जिसके बारे में मुझे पता है ...

@mrdoob

मैं चाहता था कि बनावट छवियां .glTF बनाम .glb के बजाय बाहरी हों।

@donmccurdy

मैंने https://github.com/KhronasGroup/glTF/issues/1117 चर्चा का अनुसरण किया और अब .glb + एम्बेडेड फ़ाइलों और पाइपलाइन दृष्टिकोण को प्रोत्साहित करने के लिए सहमत हूं। एक .glb विशेष रूप से वेब के लिए डेटा ट्रांसमिशन के लिए अच्छा है और पाइपलाइन दृष्टिकोण निर्यातकों और उपकरणों को सरल और पुन: प्रयोज्य रख सकता है। (मुझे यूनिक्स/लिनक्स कमांड पाइपलाइन दृष्टिकोण भी पसंद है!)

इसलिए मुझे नहीं लगता कि निर्यातक को अब जिप आर्काइव सपोर्ट की जरूरत है। और शायद इसी कारण से इसे स्पैस एक्सेसर और ड्रेको सपोर्ट की भी आवश्यकता नहीं है।

Glb-unpacker के संबंध में, मैं इसे अपने खाली समय में बनाने जा रहा हूँ। मुझे लगता है कि कुछ कलाकार .glTF + बाहरी फ़ाइलें पसंद करते हैं क्योंकि वे बिना किसी glTF विशिष्ट टूल के पठनीय हैं। और कभी-कभी बाहरी फाइलें समानांतर लोडिंग फ़ाइल के कारण लोडिंग समय को कम कर सकती हैं, इसलिए इसका उपयोग अनुकूलन उद्देश्य के लिए किया जा सकता है।

पाइपलाइन/अनुकूलन उपकरण के संबंध में, मैं यह नोट करना चाहता हूं कि हम नेटवर्क पर विशाल डेटा स्थानांतरित नहीं करना चाहते हैं। उपयोगकर्ता ~ ट्रांसफ़ॉर्मिंग ~ डेटा ट्रांसफ़र करने से पहले ऑप्टिमाइज़/संपीड़ित करना चाहते हैं। इसलिए glTF ऑप्टिमाइज़ेशन वेब सेवा कभी-कभी विशाल डेटा के लिए अच्छी तरह से काम नहीं करती है क्योंकि उपयोगकर्ता को सर्वर पर बड़ी फ़ाइल भेजने की आवश्यकता होती है।

साथ ही, Three.js और अन्य JavaScript ब्राउज़र आधारित इंजनों के लिए, हमें खुशी होगी यदि हमारे पास ब्राउज़र पर चलने वाले glTF अनुकूलन उपकरण हैं। उपयोगकर्ताओं को डेटा पास करने से पहले हम अनुकूलित/संपीड़ित कर सकते हैं। उनके बिना उपयोगकर्ताओं को निर्यात किए गए डेटा को मैन्युअल रूप से डाउनलोड करने और फिर ब्राउज़र सीमाओं के कारण इसे पाइपलाइन टूल में पास करने की आवश्यकता होती है।

इस दृष्टिकोण से, मैं चाहता हूं कि एक उपकरण कहीं भी, ब्राउज़र पर, सर्वर पर, सीयूआई, और इसी तरह चलाने में सक्षम हो, ताकि इसे अधिक सामान्य और पुन: प्रयोज्य बनाया जा सके। हम अलग-अलग प्लेटफॉर्म के लिए एक ही उद्देश्य वाले टूल को दो बार या अधिक नहीं बनाना चाहते हैं। तो नोड.जेएस आधारित उपकरण अच्छा होगा? क्या glTF (पाइपलाइन) टीम के पास कोई सुझाव है? (हो सकता है कि यह चर्चा glTF में की जानी चाहिए, यहां नहीं।)

बस मामले में, GLTFLoader बाइनरी सपोर्ट को एक्सटेंशन के रूप में लागू किया गया है, लेकिन .glb, glTF 2.0 के कोर स्पेस में है, सही है?

बस के मामले में, जीएलटीएफलोडर में बाइनरी समर्थन को विस्तार के रूप में लागू किया गया है, लेकिन .glb, glTF 2.0 के मूल विनिर्देश में है, सही है?

हाँ, यह glTF 1.0 में एक विस्तार था और कोर glTF 2.0 युक्ति का हिस्सा बनने के बाद मैंने कभी भी उस कोड को स्थानांतरित या उसका नाम नहीं बदला।

इस दृष्टिकोण से, मैं चाहता हूं कि एक [अनुकूलन उपकरण] कहीं भी, ब्राउज़र पर, सर्वर पर, सीयूआई, और इसी तरह चलाने में सक्षम हो, ताकि इसे और अधिक सामान्य और पुन: प्रयोज्य बनाया जा सके। तो नोड.जेएस आधारित उपकरण अच्छा होगा? क्या glTF (पाइपलाइन) टीम के पास कोई सुझाव है? (हो सकता है कि यह चर्चा glTF में की जानी चाहिए, यहां नहीं।)

यह glTF-पाइपलाइन रोडमैप के बारे glTF-Toolkit प्रासंगिक दिखता है, लेकिन (वर्तमान में) केवल विंडोज़ पर चलता है। मुझे व्यक्तिगत रूप से Node.js पसंद है लेकिन WASM के संकलन के साथ C++ या Rust उचित विकल्प हो सकते हैं।

ओह, मैं WASM के संकलन को याद कर रहा था। कुछ अनुशंसित देव प्लेटफार्मों को निर्दिष्ट करना अनुकूलन देवों के लिए अच्छा होगा। तो मैं एक उपयुक्त सूत्र का प्रस्ताव रखूंगा।

मैं @donmccurdy से सहमत
मैं यह भी मानता हूं कि जब तक हमारे पास WASM होगा, तब तक यह वास्तव में स्रोत भाषा से कोई फर्क नहीं पड़ेगा, लेकिन यह भी सच है कि अगर यह नोड.जेएस में लिखा गया है तो शायद 3 डी वेब इंजन के आसपास के कई समुदाय उन्हें बेहतर बनाने में मदद कर सकते हैं। वैसे भी इस फ़ाइल स्वरूप के लिए अभी मुख्य लक्ष्य हैं।

मुझे यकीन नहीं है कि मैं "रूपांतरण से पहले अनुकूलन" के बारे में समझता हूं ... एक पाइपलाइन मॉडल पर कई प्रकार के परिवर्तन कर सकती है, और अनुकूलन शायद सबसे आम प्रकार का परिवर्तन है?

उससे परे सहमत हुए। निम्न स्तर, केंद्रित उपकरण होना अच्छा है जिसका उपयोग अन्य उपकरण बनाने के लिए किया जा सकता है या अधिक उपयोगकर्ता के अनुकूल जीयूआई में प्लग किया जा सकता है।

ओह, यह टाइपो है। रूपान्तरण नहीं बल्कि स्थानान्तरण। मेरा मतलब था, अधिकांश उपयोगकर्ता नेटवर्क पर डेटा भेजने से पहले अनुकूलित/संपीड़ित करना चाहते हैं। मैंने पोस्ट को स्पष्ट करने के लिए अपडेट किया है।

हाय दोस्तों

मैं एक संपूर्ण aframe दृश्य को एक gltf ऑब्जेक्ट के रूप में निर्यात करने के लिए THREE.js GLTF निर्यातक का उपयोग कर रहा हूं।
मैं कैसे ए-एनीमेशन टैग को एफ़्रेम पर परिभाषित कर सकता हूँ ताकि वह GLTF ऑब्जेक्ट में एनिमेशन का हिस्सा बन सके?

@donmccurdy @fernandojsg @mrdoob

हाय @सिद्धार्थपाई - THREE.GLTFExporter केवल THREE.AnimationClip ऑब्जेक्ट्स को glTF एनिमेशन में कनवर्ट करता है, जबकि A-Frame का एनिमेशन सिस्टम TweenJS का उपयोग करता है। इसलिए फिलहाल यह संभव नहीं है। आप ए-फ़्रेम या ए-फ़्रेम इंस्पेक्टर पर एक समस्या खोलना चाह सकते हैं, जो भविष्य की सुविधा के रूप में अनुरोध करने के लिए GLTFExporter का भी उपयोग करता है।

बहु-सामग्री समर्थन #13536

मैंने अभी देखा है कि सत्यापनकर्ता प्रत्येक सामान्य तत्व पर एक बफरव्यू पर एक त्रुटि फेंकता है जो सामान्यीकृत नहीं होता है। उदाहरण के लिए यदि मैंने [0,0,0] जैसे अनियमित मानों को संग्रहीत किया है तो यह उस त्रुटि को फेंक देगा।
चूंकि यह एक त्रुटि है और चेतावनी/नोटिस नहीं है, मुझे लगता है कि इसे ठीक करना संवेदनशील है। यह सुनिश्चित करने के बारे में आप क्या सोचते हैं कि सामान्य बफ़रव्यू तत्व सामान्यीकृत हैं? फिर भी, उन मानों के लिए जिन्हें सामान्यीकृत नहीं किया जा सकता है जैसे [0,0,0], क्या हमें एक वैध इकाई वेक्टर का उपयोग करना चाहिए? /सीसी @donmccurdy

ऐसा लगता है कि NORMAL सामान्यीकृत किया जाना चाहिए।

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

सामान्य | "वीईसी3" | 5126 (फ्लोट) | सामान्यीकृत XYZ वर्टेक्स नॉर्म्स

सुनिश्चित करने के लिए सहमत हैं क्योंकि तीन.जेएस सामान्य में ऐसी कोई सीमा नहीं है।

हां, लेकिन क्या करें जब आपके पास वास्तविक सामान्य न हो, जैसे कि [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 कूल, धन्यवाद! लेकिन कोई जल्दी नहीं मैं सिर्फ निर्यातक की स्थिति की समीक्षा कर रहा था ^_^

ठीक है, तो मैं इस सप्ताह ~कल~ करूँगा।

ठीक है, जीएलटीएफ विशेष शिखर पर मानदंडों को छोड़ने की अनुमति नहीं देता है, लेकिन दूसरों को एक ही आदिम में नहीं। हमें किसी प्रकार का मान प्रदान करना होगा, इन शीर्षों को अलग करना होगा, या एक त्रुटि फेंकनी होगी।

मैं उपयोगकर्ता के लिए चीजों को आसान बनाना पसंद करूंगा, इसलिए मेरा वोट उन्हें सामान्य बनाने और खाली लोगों के लिए (0,1,0) मान जोड़ने के लिए एक नया मानदंड बनाने के लिए है।

अच्छा लगना। यदि यह बड़े मॉडलों के लिए धीमा है, तो हम checkNormals विकल्प या ऐसा ही कुछ चाहते हैं, इसलिए जिन उपयोगकर्ताओं को इसकी आवश्यकता नहीं है, वे प्रत्येक शीर्ष को स्कैन करने के बजाय ऑप्ट आउट कर सकते हैं।

हाँ, मैं वही लिखने वाला था! :डी

यदि यह बड़े मॉडलों के लिए धीमा है, तो हम एक checkNormals विकल्प या ऐसा कुछ चाहते हैं, इसलिए जिन उपयोगकर्ताओं को इसकी आवश्यकता नहीं है, वे प्रत्येक शीर्ष को स्कैन करने के बजाय ऑप्ट आउट कर सकते हैं।

मैं पहले उस विकल्प के बिना पीआर बनाने वाला हूं। आइए जोड़ते हैं जब/यदि आवश्यक हो। व्यक्तिगत रूप से मुझे लगता है कि यह चेक ज्यादा धीमा नहीं है।

मैं पहले उस विकल्प के बिना पीआर बनाने वाला हूं। आइए जोड़ते हैं जब/यदि आवश्यक हो। व्यक्तिगत रूप से मुझे लगता है कि यह चेक ज्यादा धीमा नहीं है।

पेंटर पर प्रत्येक स्ट्रोक लोड करते समय मैं पूरे बफर को सामान्य कर रहा था और यह काफी धीमा था

भले ही वे जाँच कर रहे हों कि क्या वे सामान्यीकृत हैं?

@takahirox आपको वैसे भी लंबाई की गणना करने की आवश्यकता होगी, इसलिए मुझे लगता है कि यह इतना नहीं बदलेगा

एचएम ठीक है। मैं पीआर के साथ मूल्यांकन करूंगा।

यह पहली GLTFExporter सुविधा है जिसे हमने पेश किया है जो प्रत्येक शीर्ष के साथ कोई गणना करता है (सापेक्ष/पूर्ण मॉर्फ लक्ष्य रूपांतरण को छोड़कर) तो हाँ संभावित रूप से धीमा .. हालांकि किसी भी तरह से।

महान काम! IMHO को "उदाहरण" के बजाय कोर तीन.js में मिला दिया जाना चाहिए।
KHR_lights_punctual समर्थन देखना पसंद करेंगे!

पीआर https://github.com/mrdoob/three.js/pull/15519 KHR_lights_punctual जोड़ता है। :)

मुझे लगता है कि इस मुद्दे को शायद बंद किया जा सकता है - शेष आइटम कम महत्वपूर्ण सुविधा या अनुकूलन हैं, और कहीं और ट्रैक किए जा सकते हैं:

• [] बफ़रव्यू का पुन: उपयोग करें
• [] स्वचालित रूप से धातु / खुरदरी / एओ बनावट को मर्ज करें

हे दोस्तों, क्या किसी को पता है कि मैं मॉर्फ को लागू करके और इसे अंतिम ऑब्जेक्ट से हटाकर मॉर्फ परिवर्तनों द्वारा कस्टम आकार के जाल को कैसे निर्यात कर सकता हूं?
इस सवाल की तरह https://stackoverflow.com/questions/57423471/how-to-export-morph-changed-meshes-from-threejs-application
अग्रिम में धन्यवाद!

@ vini-guerrero कृपया GitHub मुद्दों के बजाय फ़ोरम (https://discourse.threejs.org/) या स्टैक ओवरफ़्लो का उपयोग करें।