Three.js: यूटिल्स: डिप्रेसेट एक्सपोर्टर्स (ब्लेंडर, 3डीएस मैक्स और माया)

इसके लिए +1 - रेपो में खराब रखरखाव और पुराने निर्यातकों का अस्तित्व नवागंतुकों के लिए भ्रम का एक अनावश्यक बिंदु है, खासकर जब से @ Mugen87 बताते हैं कि अब बहुत बेहतर विकल्प हैं।

नोट: आधिकारिक GLTF ब्लेंडर निर्यातक (https://github.com/KhrosGroup/glTF-Blender-Exporter) वर्तमान में उचित एनिमेशन निर्यात की अनुमति नहीं देता है (वर्तमान में प्रति ऑब्जेक्ट केवल 1 एनिमेशन समर्थित है)।
https://github.com/KhronasGroup/glTF-Blender-Exporter/issues/112

@Usnul इस रेपो में ब्लेंडर JSON निर्यातक की तुलना कैसे करता है?

@ लूई
ब्लेंडर JSON निर्यातक ठीक एनिमेशन निर्यात करता है। कुछ स्थितियों में यूवी या वर्टेक्स नॉर्म्स के साथ कुछ अजीब गड़बड़ियां हैं जो जीएलटीएफ निर्यातक में मौजूद नहीं हैं, लेकिन यह एक और कहानी है।

ठीक है, मैं ब्लेंडर का उपयोग नहीं करता, इसलिए मैं उस पर आगे कोई टिप्पणी नहीं करूंगा।

हालांकि मैं अनुभव से कह सकता हूं कि 3DS मैक्स निर्यातक का उपयोग करने की कोशिश करना, जिसे कई वर्षों में अपडेट नहीं किया गया है, एक अंतहीन सिरदर्द है और मैं इसे FBX प्रारूप के पक्ष में रेपो से हटाने का पुरजोर समर्थन करूंगा।
3DS Max FBX निर्यातक द्वारा निर्यात की जाने वाली लगभग सभी चीजें अब FBXLoader द्वारा समर्थित हैं और चूंकि उस निर्यातक का रखरखाव AutoDesk द्वारा किया जाता है, इसलिए हम उस पर अद्यतित रहकर भरोसा कर सकते हैं।

इसी तरह माया FBX निर्यातक के साथ, हालांकि FBXLoader को अभी भी वहां पिवोट्स पॉइंट्स को ठीक से समर्थन देने के लिए अपडेट करने की आवश्यकता है।

जब मुझे ठीक से याद है, जब आप BufferGeometry चयन करते हैं तो ब्लेंडर एनिमेशन निर्यात नहीं करता है। निश्चित रूप से रूप लक्ष्य के साथ कोई समस्या है, #10932 देखें। इसके अलावा, निर्यातक "पुराने" एनीमेशन पदानुक्रम प्रारूप का उपयोग करता है, न कि वर्तमान एनीमेशन सिस्टम में से एक का।

मुझे लगता है कि हमें रेविट निर्यातक रीडमे को भी हटा देना चाहिए - यह सिर्फ एक अलग रेपो से जुड़ता है जो ऐसा लगता है कि पिछले कुछ वर्षों में इसे मुश्किल से छुआ गया है।

संभवत: ऐसे सैकड़ों तीन.js टूल हैं जिन्हें हम इस तरह से लिंक कर सकते हैं, लेकिन जब तक हम यह सुनिश्चित करने के लिए तैयार नहीं हैं कि वे सक्रिय रूप से बनाए हुए हैं और सही तरीके से काम कर रहे हैं, मुझे नहीं लगता कि हमें उनके लिंक यहां शामिल करने की आवश्यकता है।

"तीन.जेएस रेविट निर्यातक 'के लिए गुगलिंग रेपो को वैसे भी ठीक पाता है।

मुझे लगता है कि हमें रेविट निर्यातक रीडमी को भी हटा देना चाहिए - यह सिर्फ एक अलग रेपो से जुड़ता है जो ऐसा लगता है कि पिछले कुछ वर्षों में इसे मुश्किल से छुआ गया है।

मैं

रेपो में खराब रखरखाव वाले और पुराने निर्यातकों का अस्तित्व नवागंतुकों के लिए भ्रम का एक अनावश्यक बिंदु है

मैं सिर्फ इस कथन को उजागर करना चाहता हूं क्योंकि मुझे लगता है कि यह three.js लिए बहुत महत्वपूर्ण है। जब उपयोगकर्ता इन निर्यातकों का सामना करते हैं, तो वे ऐसे उपकरणों की अपेक्षा करते हैं जो बस काम करते हैं। लेकिन ज्यादातर मामलों में वे भ्रमित हो जाते हैं और शायद पूरे प्रोजेक्ट का बुरा प्रभाव डालते हैं। यह अच्छा नहीं है। मैं

एक निर्दोष उपयोगकर्ता के रूप में, क्या मैं एक टिप्पणी देने की हिम्मत कर सकता हूं ...

ब्लेंडर के बारे में:
यदि तीन.जेएस में एक देशी .blend
जाहिर तौर पर निर्यातक की कोई जरूरत नहीं होगी।

ब्लेंडर साइड पर कोई इंस्टॉलेशन प्रयास नहीं,
अजगर कोड के माध्यम से ब्लेंडर एपीआई/संरचनाओं से जावास्क्रिप्ट तक कोई संकलन नहीं ...

JSON निर्यातक को अजगर में लिखने के लिए जबरदस्त प्रयास किए गए,
मुझे आश्चर्य है कि आप सहयोगियों ने यह रास्ता क्यों नहीं चुना ...?

@wolfgangvonludwigsburg
इसका उत्तर देना काफी सरल प्रश्न है। ब्लेंड प्रारूप तीन.जेएस आंतरिक प्रतिनिधित्व के बहुत करीब नहीं है, इसलिए कुछ रूपांतरण आवश्यक है। थ्री.जेएस का जेएसओएन प्रारूप आंतरिक प्रतिनिधित्व के बहुत करीब है, इसलिए ब्लेंडर प्रतिनिधित्व से थ्री.जेएस में रूपांतरण का काम किसी भी तरह से है, चाहे आप इसे निर्यातक या लोडर कहते हैं। कहा जा रहा है, .blend एक सामान्य स्थानांतरण प्रारूप नहीं है, ब्लेंडर के अलावा कुछ भी वास्तव में इसका समर्थन नहीं करता है, इसलिए इसके लिए एक लोडर होने से काफी छोटे दर्शकों को संतुष्ट किया जा सकता है, क्योंकि यहां तक ​​​​कि जो लोग ब्लेंडर का उपयोग करते हैं वे अन्य सॉफ़्टवेयर का भी उपयोग करते हैं, और .blend विनिमय प्रारूप के रूप में पसंद का प्रारूप नहीं है। आमतौर पर यह obj, fbx या कुछ खुले मानक जैसे gltf या कोलाडा है।

@wolfgangvonludwigsburg यदि आप _were_ एक .blend फ़ाइल लोडर बनाने के बारे में सोच रहे हैं, तो यह संभवतः शुरू करने के लिए एक अच्छी जगह होगी:

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

आपकी टिप्पणियों के लिए कई THX!

लेकिन ब्लेंडर JSON निर्यातक ऐसी त्रुटि प्रवण क्यों है ...
=> यह ब्लेंडर एपीआई पर निर्भर करता है, जो पायथन में लिखा गया है, ब्लेंडर डेटा स्ट्रक्चर्स को समझेगा,
और एक JSON प्रारूप में संकलित करता है, कि तीन.जेएस अपने आंतरिक में पुन: परिवर्तित हो जाता है ...

बहुत सारे कार्य, जो सभी (और वास्तव में करते हैं!) विफल हो सकते हैं, मुख्य रूप से ब्लेंडर संस्करण में परिवर्तन।
खैर, मैं "प्रत्यक्ष डेटा संकलन" तरीका पसंद करूंगा ...

खैर, मैं "प्रत्यक्ष डेटा संकलन" तरीका पसंद करूंगा।

यह कोई अच्छा तरीका नहीं है। blend फ़ाइलों को सीधे ऐप्स में लोड करना किसी प्रकार का दुरुपयोग है। इसके बजाय, आपको एक फ़ाइल प्रारूप का उपयोग करना चाहिए जो डेटा स्थानांतरण और परिसंपत्ति वितरण के लिए अभिप्रेत है। glTF पहला मानकीकृत प्रारूप है जो एप्लिकेशन के दृष्टिकोण से इस पहलू पर केंद्रित है। यही एक कारण है कि मैं glTF इतनी बार प्रचार करता हूं । यह आने वाले सभी 3D ऐप्स के लिए मानक होना चाहिए।

खैर, मैं "प्रत्यक्ष डेटा संकलन" तरीका पसंद करूंगा ...

दुर्भाग्य से इस तरह से .blend का उपयोग करने में गहरी समस्याएं हैं। यह एडिट हिस्ट्री, ब्लेंडर यूआई की वर्तमान स्थिति, ब्लेंडर ऐड-ऑन डेटा जैसी चीजों को स्टोर करता है। नए ब्लेंडर रिलीज़ के सामने आते ही प्रारूप बदल जाता है। और फ़ाइल का आकार बहुत बड़ा हो सकता है, इसलिए उच्च गुणवत्ता वाले 3D अनुप्रयोगों के लिए यह कभी भी एक अच्छा विकल्प नहीं होगा। ब्लेंडर से सीधे डेटा प्राप्त करने का सबसे अच्छा तरीका ब्लेंडर के आंतरिक .blend प्रारूप को रिवर्स-इंजीनियर करने की कोशिश करने के बजाय ब्लेंडर के एपीआई (जैसा कि FBX और glTF निर्यातक करते हैं) का उपयोग करना है।

मूल प्रश्न के लिए, मैं हां/नहीं वोट जोड़ना छोड़ दूंगा क्योंकि मेरे पास 3D संलेखन वर्कफ़्लोज़ अधिक परिचित नहीं हैं।

लेकिन एक अनुरक्षक और मुख्य रूप से एक JS देव के रूप में, FBX और glTF जैसे प्रारूपों के लिए लोडिंग और समर्थन पर ध्यान केंद्रित करने में सक्षम होने के कारण - जिन्होंने सक्रिय रूप से तृतीय-पक्ष संलेखन उपकरण बनाए रखा है - विश्वसनीय परिणाम देने की अधिक संभावना महसूस करता है।

इसके अलावा, यदि वर्तमान glTF पारिस्थितिकी तंत्र में कोई समस्या है जो इसे इस प्रकार की आवश्यकता को हल करने के लिए पर्याप्त कार्यप्रवाह होने से रोकती है, तो यह सहायक प्रतिक्रिया भी है। मैं

मैंने सामान्य विनिमय प्रारूप के रूप में ब्लेंडर .blend प्रारूप का उपयोग करने का तर्क नहीं दिया,
लेकिन यह ब्लेंडर और तीन.जेएस के बीच सहयोग को आसान बना सकता है ...

मैं ब्लेंडर ढांचे के तहत एक पायथन निर्यातक + जीयूआई बनाए रखने के प्रयासों का अनुमान नहीं लगा सकता,
लेकिन मुझे लगता है, कि यह आसानी से भयावह हो सकता है ... ;-)

@donmccurdy
BTW, Wavefront .obj, 3D Studio .3ds भी मूल स्वरूप हैं, जो व्यापक रूप से फैले हुए उपयोग में हैं ...

BTW, Wavefront .obj, 3D Studio .3ds भी मूल स्वरूप हैं, जो व्यापक रूप से फैले हुए उपयोग में हैं ...

हाँ, मुझे लगता है कि OBJ का उल्लेख यहाँ नहीं किया गया है क्योंकि प्रारूप एनीमेशन जैसी कुछ लोकप्रिय विशेषताओं का समर्थन नहीं करता है, लेकिन निश्चित रूप से तीन.js बहुत लंबे समय तक OBJ का समर्थन करते रहेंगे - यह एक क्लासिक और विश्वसनीय प्रारूप है।

3DS मैक्स का .3ds ब्लेंडर के .blend या माया के .mlt या Cinema4D के .c4d । प्रत्येक संपादक का अपना आंतरिक प्रारूप होता है, और वे प्रारूप बदलते हैं जैसे सॉफ्टवेयर करता है। प्रत्येक मॉडलिंग टूल के निजी आंतरिक प्रारूप के लिए लोडर को बनाए रखना संपादक के अपने डेवलपर्स द्वारा प्रदान किए गए निर्यात प्रारूपों का उपयोग करने की तुलना में कहीं अधिक कठिन और बग-प्रवण है। ध्यान देने योग्य बात यह है कि 3DS और ब्लेंडर दोनों FBX निर्यात के साथ आते हैं - उनके लेखकों द्वारा बनाए रखा जाता है - और यह कि ब्लेंडर में भविष्य के संस्करण में भी अंतर्निहित glTF निर्यात होगा।

एक आखिरी फेंक ...

हमारे पास पहले से ही एक मॉडलिंग उपकरण स्वतंत्र पूर्व/आयातक है: कोलाडा,
लेकिन किन्हीं कारणों से ये इतने स्वीकृत नहीं लगते हैं।

अधिमानतः मेरे पास यह कार्यान्वयन प्रकार दिमाग में था:
Google प्रोटोकॉल बफ़र्स पर आधारित एक लोडिंग समाधान

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

यह है एक

... भाषा-तटस्थ, प्लेटफ़ॉर्म-तटस्थ, संरचित डेटा को क्रमबद्ध करने के लिए एक्स्टेंसिबल तंत्र - एक्सएमएल सोचें, लेकिन छोटा, तेज और सरल।

चूँकि हमें जिस 2D/3D वेक्टर डेटा से निपटना है, वह प्रकृति में इतना जटिल नहीं है, एक ब्लेंडर डेटा फ़ाइल स्कीमा विकसित करना बस संभव होना चाहिए ...

जावास्क्रिप्ट में वास्तव में एक मिश्रण फ़ाइल पार्सर है
https://github.com/Galactrax/js.blend

उह, मुझे समर्थन मिलता है ... - धन्यवाद श्रीदूब ;-))

सबसे बड़ा (टेराबाइट के संदर्भ में) 3D मॉडल एप्लिकेशन (Google मैप्स 3D) कार्यान्वयन के इस कुशल प्रकार (प्रोटोबफ़्स) का उपयोग करता है ...

.ब्लेंड को लोड करने के रास्ते पर जाना शायद बहुत समझदारी भरा न हो। लेकिन वास्तव में .dae और .fbx लोड करने से अलग नहीं है...

वैसे भी, मैं निर्यातकों को पदावनत करने के विचार से सहमत हूं।
हालांकि, मैं तब तक इंतजार करूंगा जब तक कि gltf थोड़ा अधिक परिपक्व और परीक्षण न हो जाए। गर्मी 2018?

मैं उन निर्यातकों को भी हटाने के लिए सहमत हूं। आप उन्हें किसी अन्य रेपो में भी ले जा सकते हैं जहां वे आरआईपी कर सकते हैं :)

हालांकि, मैं तब तक इंतजार करूंगा जब तक कि gltf थोड़ा अधिक परिपक्व और परीक्षण न हो जाए। गर्मी 2018?

इंतज़ार करना मुझे मुनासिब लगता है। विशेष रूप से जीएलटीएफ के लिए पहले कुछ चीजें रखना अच्छा होगा:

• [ ] बिल्ट इन GLTF एक्सपोर्ट के साथ ब्लेंडर शिपिंग और मल्टीपल एनिमेशन सपोर्ट।
• [x] माया और 3DS मैक्स से glTF को बेहतर कार्यप्रवाह, या बस अधिक से परीक्षण FBX2GLTF ।
• [x] glTF 2.0 के लिए आधिकारिक COLLADA2GLTF कनवर्टर में अपडेट।

समर 2018 में प्रश्न पर दोबारा गौर करना सही लगता है।

हालांकि, मैं तब तक इंतजार करूंगा जब तक कि gltf थोड़ा अधिक परिपक्व और परीक्षण न हो जाए। गर्मी 2018?

ब्लेंडर निर्यातक के लिए, मैं सहमत हूं। हालाँकि, मैं कम से कम 3DS मैक्स निर्यातक को तुरंत हटाने की सलाह देता हूँ क्योंकि FBX में पहले से ही एक परिपक्व और बेहतर विकल्प है।

हालाँकि, मैं कम से कम 3DS मैक्स निर्यातक को तुरंत हटाने की सलाह देता हूँ क्योंकि FBX में पहले से ही एक परिपक्व और बेहतर विकल्प है।

मुझे अच्छा लगता है

ठीक है, 3DS मैक्स एक्सपोर्टर चला गया है। आइए कुछ महीनों में अन्य निर्यातकों (ब्लेंडर और माया) पर फिर से गौर करें।

मुझे नहीं लगता कि उस समय में माया निर्यातक के बारे में बहुत कुछ बदलेगा।

हमें शायद अब इसका मूल्यांकन करना चाहिए। मैं इसका परीक्षण करूंगा और देखूंगा कि यह अगले कुछ दिनों में रखने लायक है या नहीं।

अच्छा सुझाव

जब तक हम यहां हैं, https://github.com/mrdoob/three.js/tree/dev/utils/converters/fbx की स्थिति क्या है? ऐसा लगता है कि obj2three कनवर्टर की तरह एक node.js स्क्रिप्ट द्वारा प्रतिस्थापित किया जा सकता है, बस तीन.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 उपयोग नहीं कर सकते क्योंकि आपके पास डोम तक पहुंच नहीं है। TextureLoader का उपयोग करने वाले सभी लोडर की निर्भरता ImageLoader और इसलिए document निर्भर है। हमें ReferenceError: document is not defined जैसी रनटाइम त्रुटियां मिलेंगी। window ऑब्जेक्ट के लिए वही समस्या जो FileLoader से एक्सेस की जाती है।

एक अस्थायी समाधान के रूप में, शायद हम ImageLoader और FileLoader को fbx2three.js फ़ाइल में फिर से परिभाषित कर सकते हैं?

शायद हम fbx2three.js फ़ाइल में ImageLoader और FileLoader को फिर से परिभाषित कर सकते हैं?

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

शायद हम fbx2three.js फ़ाइल में ImageLoader और FileLoader को फिर से परिभाषित कर सकते हैं?

अच्छा विचार: ब्लश:

3DS Max का .3ds उसी श्रेणी में है जैसे Blender का .blend या माया का .mlt या Cinema4D का .c4d।

यह पूरी तरह से सच नहीं हो सकता है, .max एक ही श्रेणी की तरह अधिक है, .3ds बहुत नीचे छीन लिया गया है।

मुझे एक निर्यातक को कैसे लिखना है, और मैक्सस्क्रिप्ट पर भी एक उदाहरण के रूप में 3ds अधिकतम निर्यातक को पसंद आया। मुझे नहीं लगता कि मैं कभी भी 3ds मैक्स से fbx के माध्यम से सही स्पर्शरेखा स्थान निर्यात करने में सक्षम था, मैक्सस्क्रिप्ट के साथ प्रयोग करना और आपकी ज़रूरत के सामान को पकड़ना आसान है।

उपयुक्त अस्वीकरण के साथ, एक नया रेपो डालने के लायक? एक निर्यातक को कैसे लिखना है, इसके उदाहरणों के लिए सभी, लेकिन अगर यह रखरखाव नहीं है और FBXLoader अब अधिक विश्वसनीय है, तो हम नहीं चाहते कि लोग यह मान लें कि यह 3DS Max से संपत्ति को तीन.js में लाने का अनुशंसित तरीका है।

हाँ, अगर कुछ भी हो तो मैं एक नए रेपो के लिए वोट करता हूं।

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

@pjoe मुझे उम्मीद है कि JSON प्रारूप और ब्लेंडर निर्यातक इस धागे में उल्लिखित अन्य चीजों (जैसे 3DS मैक्स + माया निर्यातक) की तुलना में निकट अवधि में इधर-उधर रहने की अधिक संभावना है।

लेकिन फिर भी, glTF और Blender Exporter पर आपकी प्रतिक्रिया प्राप्त करना अच्छा होगा। आपने जो कुछ भी उल्लेख किया है वह समर्थित है:

• कैमरा सेट करें
• दृश्य पदानुक्रम
• एनिमेशन (एकाधिक ब्लेंडर क्रियाओं के लिए आपको एक अलग निर्यातक की आवश्यकता होगी)
• कस्टम गुण (विकल्पों में "अतिरिक्त निर्यात करें" चुनें)
• सामग्री, मेटाडेटा, आदि के लिए "सिर्फ JSON"। मेष डेटा को अलग बाइनरी पेलोड के रूप में अनुकूलित किया गया है

@donmccurdy को स्वीकार करना होगा कि मेरे पास glTF (कम से कम अभी तक) के साथ बहुत अनुभव नहीं है - हालांकि मैंने कल्पना को पढ़ने की कोशिश की :)

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

ब्लेंडर जीएलटीएफ निर्यातक के साथ बिताए संक्षिप्त समय से यह भी उस समय (लगभग दो महीने पहले) काफी अपरिपक्व लग रहा था। इसे सुधारने में मदद करके इसे स्पष्ट रूप से ठीक किया जा सकता है :)

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

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

आम तौर पर मैंने किसी भी अन्य ब्लेंडर आउटपुट की तुलना में बेहतर परिणाम देने के लिए glTF ब्लेंडर निर्यातक को पाया है, लेकिन यदि आपको विशेष समस्याएँ मिली हैं तो कृपया बग दर्ज करें। :)

@donmccurdy परिवहन/रनटाइम के लिए सही रहने के लिए जीएलटीएफ पर सहमत हुए ... इसके बारे में महान चीजों में से एक यह है कि यह सभी प्रारूपों में फिट होने की कोशिश नहीं कर रहा है (जैसे कोलाडा - मुझे शुरू न करें)।

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

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

मुझे नहीं लगता कि उस समय में माया निर्यातक के बारे में बहुत कुछ बदलेगा। हमें शायद अब इसका मूल्यांकन करना चाहिए। मैं इसका परीक्षण करूंगा और देखूंगा कि यह अगले कुछ दिनों में रखने लायक है या नहीं।

@looeee मैं उत्सुक हूँ, क्या आपके पास इस पर कोई खबर है ? क्या आपको लगता है कि हम अब निर्यातक को हटा सकते हैं और इसके बजाय FBX संदर्भ ले सकते हैं?

क्या आपको लगता है कि हम अभी निर्यातक को हटा सकते हैं और इसके बजाय FBX का संदर्भ ले सकते हैं?

मैंने केवल थोड़ी मात्रा में परीक्षण किया, और अधिक करने की योजना बनाई लेकिन मेरे पास समय नहीं था। लेकिन मैं कहूंगा कि हां, हमें इसे हटा देना चाहिए और FBXLoader को माया को पूरी तरह से सपोर्ट करने के लिए काम करना चाहिए।

यहां ब्लेंडर निर्यातक के उपयोगकर्ता के रूप में बात करना: JSON होने का एक फायदा यह है कि निर्यात के बाद इसे संशोधित करना बेहद सरल है। ब्लेंडर हमारे स्वचालित टूलचेन का केवल एक हिस्सा है, और हमारे वेब व्यूअर के पास जाने के लिए तैयार होने से पहले हम निर्यात किए गए JSON पर बहुत सारी प्रोसेसिंग करते हैं। एक स्थानांतरण प्रारूप होना जो आंतरिक तीनj प्रारूप के बहुत करीब है, हमारे लिए एक प्रमुख बोनस है।

इसके अलावा, हमने अन्य निर्यात प्रारूपों के साथ कुछ परीक्षण किए हैं, और पाया है कि जेएसओएन प्रारूप हस्तांतरण आकार के मामले में इतना खराब नहीं है, उदाहरण के लिए, कोलाडा या एफबीएक्स से काफी बेहतर है। हमने एक त्वरित प्रोटोबफ़र्स-आधारित परीक्षण किया, और उस तरह से थोड़ा छोटा हो सकता है, लेकिन ऐसा कुछ भी नहीं जो हमारे लिए परेशानी के लायक हो।

बड़े दृश्यों और धीमे ग्राहकों के लिए, आंतरिक थ्रीजेएस मॉडल को पार्स करने और परिवर्तित करने की गति भी महत्वपूर्ण हो जाती है। चूंकि JSON पार्सिंग ब्राउज़र में अत्यधिक अनुकूलित है, और चूंकि मॉडल संरचना बहुत समान है, इसलिए हमने मान लिया है कि JSON प्रारूप इस संबंध में काफी अच्छा करेगा। वास्तव में इसका परीक्षण नहीं किया है।

Soft8Soft ने अभी- अभी

धन्यवाद @alexkowel , यह देखकर बहुत अच्छा लगा (और बधाई!) यदि आप इस थ्रेड पर एक लिंक जोड़ सकते हैं तो हम इसे अन्य glTF संसाधनों के साथ सूचीबद्ध करेंगे। मैं

@dherben अच्छे अंक, धन्यवाद -

पार्सिंग की गति के बारे में, मुझे उम्मीद है कि आप glTF को और भी तेज़ पाएंगे। अंतर अनिवार्य रूप से यह है कि मेटाडेटा अभी भी "सिर्फ JSON" है, जबकि पेलोड के बड़े हिस्से (वर्टेक्स पोजीशन, एनीमेशन डेटा) एक ArrayBuffer खंड में हैं जो THREE.BufferAttribute कंस्ट्रक्टर्स के लिए एक टाइप की गई सरणी बनाने के लिए उपयोग किया जा सकता है। पूरी तरह से अनुकूलित लोडर में (मुझे नहीं पता कि THREE.GLTFLoader अभी तक काफी है) आपको कभी भी उस डेटा को JS में पढ़ने या कॉपी करने की आवश्यकता नहीं है।

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

इस मुद्दे की वर्तमान स्थिति:

निर्यातक:

• [एक्स] माया निर्यातक
• [एक्स] 3डीएस मैक्स निर्यातक
• [एक्स] ब्लेंडर निर्यातक
  
  
  
  • अभी कहीं नहीं जा रहे हैं, भविष्य में फिर से आ सकते हैं।
  
  
  • मई 2018 को हटा दिया गया।
  
  

कन्वर्टर्स:

• [ ] एफबीएक्स
  
  
  
  • सरलीकृत प्रतिस्थापन https://github.com/mrdoob/three.js/pull/13013 के रूप में प्रस्तावित
  
  
• [ ] सीटीएम (चर्चा नहीं की गई)
• [ ] utf8 (चर्चा नहीं की गई)
• [] obj2three (चर्चा नहीं की गई)

संपादित करें: मई 2018 को अपडेट किया गया।

@donmccurdy बस glTF ब्लेंडर निर्यातक और थ्री.जेएस लोडर के साथ और अधिक प्रयोग करने के बाद वापस आना चाहता था। यह पता चला है कि यह वास्तव में अब तक हमारे उपयोग के मामले में दृश्य प्रारूप के रूप में काफी अच्छी तरह से काम कर रहा है। अब मैं जो कर रहा हूं वह निर्यात की गई glTF फ़ाइल को तीन.जेएस दृश्य में लोड करना है और फिर पहले रेंडर करने से पहले थ्री.जेएस दृश्य पदानुक्रम (डायनेमिक लोडेड सामान के साथ प्लेसहोल्डर को स्वैप करना) में हेरफेर करना है।

शायद अभी भी कुछ विशेषताएं हैं जिन्हें मैं ग्लोटीएफ निर्यातक में देखना चाहता हूं, वहां टिप्पणी करने या पीआर करने का प्रयास करूंगा :)

शायद अभी भी कुछ विशेषताएं हैं जिन्हें मैं ग्लोटीएफ निर्यातक में देखना चाहता हूं, वहां टिप्पणी करने या पीआर करने का प्रयास करूंगा :)

बढ़िया, कृपया करें! मैं

ब्लेंडर निर्यातक अभी कहीं नहीं जा रहा है, भविष्य में फिर से आ सकता है।

तो क्या कोई मौजूदा ब्लेंडर निर्यातक बग पर काम करने जा रहा है? मुझे उम्मीद है कि उत्तर नहीं है। ऐसे में हमें ऐसा कहना चाहिए।

अगर मेरे सामने कोई और नहीं करता है ... मैं कम से कम, रोटेशन के मुद्दों को हल करने का प्रयास करना चाहता हूं। #13130

तो क्या कोई मौजूदा ब्लेंडर निर्यातक बग पर काम करने जा रहा है? मुझे उम्मीद है कि उत्तर नहीं है।

मैंने पूरी चर्चा नहीं पढ़ी, लेकिन मेरे दो सेंट।

पिछले हफ्ते मुझे एक ऐसी कंपनी की मदद करने के लिए कहा गया जिसके पास एक समाधान है जो स्थायी प्रदर्शनी के भीतर सामग्री वितरण में तीन.जेएस का उपयोग करता है। 3D मॉडल वाले साइनेज जिन्हें उपयोगकर्ता एक्सप्लोर कर सकते हैं और उनके साथ इंटरैक्ट कर सकते हैं। लंबे समय से चले आ रहे मूल देवों ने

IMHO Three.js को FBX और glTF जैसे स्थापित और साथ ही तेजी से बढ़ते प्रारूपों का समर्थन करने पर ध्यान देना चाहिए। उन प्रारूपों पर प्राथमिकता जो कई यूवी डेटा डिब्बे रख सकते हैं (इस प्रकार प्रिय ओबीजे को प्रोत्साहित नहीं किया जाना चाहिए)। फिर एनिमेशन। मुझे पता है कि ब्लेंडर एक्सपोर्ट एडऑन माना जाता है कि दोनों का समर्थन करता है, लेकिन ऐसा FBX करता है।

वर्कफ़्लो की कल्पना करें जहाँ Blender'ed सामान बाहर जाता है

1) वेबजीएल
तीन.जेएस स्पष्ट रूप से

2) ओपनजीएल 3.3+
कच्चा / सिंडर

3) आरआईएससी पर ओपनजीएल ईएस 2.0
स्मार्टफोन से रास्पबेरी पाई तक

4) गेम इंजन

5) रीयल-टाइम ग्राफिक्स ऐप्स जो मीडिया सर्वर (हिप्पो, डी 3 छिपाने) के साथ एकीकृत हैं
वे स्टेज वीएफएक्स लोग इस्तेमाल करते हैं।

विभिन्न आउटपुट के लिए कई अलग-अलग निर्यातकों का उपयोग करने के बजाय लक्ष्य 1, अधिकतम 2 प्रारूपों का उपयोग करना होगा। पहले 3 मामलों में OGL लिखते समय... समान मॉडल प्रारूप का उपयोग किया जाना चाहिए, बस। पिछले दो बिंदुओं के लिए एफबीएक्स राजा है (पैकेजों में कोलाडा के लिए अलग-अलग कार्यान्वयन के साथ काम करना मुश्किल हो जाता है) और वास्तव में मॉडल "उजागर" नहीं होता है।
मैं थ्री.जेएस JSON फॉर्मेट या ब्लेंडर एडऑन ( @mrdoob 🙏 ) को
मैं इसे केवल उस परिप्रेक्ष्य से साझा करना चाहता हूं जहां किसी को उद्योग के भीतर विभिन्न आउटपुट को लगातार वितरित करना पड़ता है। थ्री.जेएस जेएसओएन प्रारूप परिदृश्य में फिट नहीं होता है, यह अनावश्यक है।

@kroko निश्चित रूप से सहमत हैं

मुझे लगता है कि प्रारूप परिदृश्य अधिक स्पष्ट होने लगा है। three.js json फॉर्मेट इसलिए किया गया क्योंकि उस समय कोई json फॉर्मेट नहीं था। एक फ़ाइल प्रारूप को परिभाषित करना आखिरी चीज थी जो मैं करना चाहता था जब मैं पहले से ही एक रेंडरिंग इंजन और एक एपीआई कर रहा था

एक नौसिखिया के रूप में, Three.js JSON निर्यातक बहुत शैक्षिक था क्योंकि इसने मुझे आउटपुट ज्यामिति के कच्चे डेटा और अंतर्निहित संरचना को देखने की अनुमति दी थी। अन्य निर्यातक, जितने कुशल हैं, आपको डेटा देखने नहीं देते क्योंकि वे ज्यादातर बाइनरी प्रारूप में होते हैं।

मैं मानता हूं कि इस रेपो से इसे हटाना आज सबसे अच्छा विकल्प होगा, लेकिन जैसा कि @hcampos ने कहा, शायद इसे शैक्षिक उद्देश्यों के लिए रहने के लिए अपने स्वयं के रेपो में रखा जा सकता है।

मैं मानता हूं कि इस रेपो से इसे हटाना आज सबसे अच्छा विकल्प होगा, लेकिन जैसा कि @hcampos ने कहा, शायद इसे शैक्षिक उद्देश्यों के लिए रहने के लिए अपने स्वयं के रेपो में रखा जा सकता है।

http://threejs.org/editor/ से हमेशा JSON के रूप में निर्यात करने का विकल्प होगा

https://github.com/mrdoob/three.js/pull/14117 में बंद

मेरा सुझाव है कि अब हम सभी खुले मुद्दों को बंद कर दें जो ब्लेंडर निर्यातक से संबंधित हैं। माना?

मुझे लगता है कि कोई व्यक्ति 3D मॉडल निर्यात/आयात (बुनियादी और विशेष सुविधाओं के लिए), सामान्य समस्या निवारण के लिए कुछ "आधिकारिक" दस्तावेज़/पाइपलाइन लिख सकता है, और सभी पुराने दस्तावेज़ों और उदाहरणों को काट या अपडेट कर सकता है। ईजी नाइट उदाहरण बहुत भ्रमित करने वाला है, यह देखते हुए कि आपके पास अब ब्लेंडर जेसन निर्यातक नहीं है। हो सकता है कि 3D मॉडल के लिए JSONLoader को केवल रेट्रोकम्पैटिबिलिटी के लिए रखा जाना चाहिए, लेकिन हमें इसे पढ़ना होगा, आदि।

@stmaccarelli यहाँ कुछ नए दस्तावेज़ हैं: https://threejs.org/docs/#manual/introduction/Loading -3D-models, लेकिन हाँ कृपया हमें बताएं कि और क्या मददगार होगा!

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

मास्टर एनिमेशन सिस्टम डॉक्टर ठीक रहेगा यदि एकल वस्तुओं के रेफरी सही होंगे।
आइए एनिमेशनक्लिप संदर्भ लें। मुझे यकीन नहीं है कि मैं सही तरीके से morphTargets निर्यात कर रहा हूं, लेकिन यहां मैंने पढ़ा है:

_.CreateClipsFromMorphTargetSequences (नाम: स्ट्रिंग, morphTargetSequence: ऐरे, एफपीएस: नंबर, नोलूप: बूलियन): ऐरे
"Walk_001, Walk_002, Run_001, Run_002 ..."_ जैसे एनीमेशन-समूह-आधारित पैटर्न में मॉर्फ लक्ष्य नामों को सॉर्ट करने का प्रयास करते हुए, ज्यामिति के मॉर्फ लक्ष्य अनुक्रमों से बनाए गए नए एनिमेशनक्लिप्स की एक सरणी देता है।

समस्या यह है कि अगर मैं एक glTF फ़ाइल आयात करता हूं, तो कोई morphTargetSequence सरणी नहीं है... कुछ morphTargetSomething वस्तुएं यहां और वहां संग्रहीत हैं, लेकिन मुझे नहीं पता कि क्या और कैसे उपयोग करना है।

मुझे लगता है कि हमारे पास बहुत ही सरल उदाहरणों के साथ 3D मॉडल प्रबंधन/वर्कफ़्लो का वर्णन करने वाले कुछ दस्तावेज़ होने चाहिए।
और 3D लोडर संदर्भों को सभी समान टेम्पलेट का सम्मान करना चाहिए।
हम कहते हैं
1- साधारण 3D मॉडल आयात
2- सामग्री (ओं) का आयात (सभी घंटियों और सीटी के साथ जैसे विभिन्न मानचित्र, मानचित्र परम, बहु-सामग्री प्रबंधन, आदि)
3- संपूर्ण दृश्य आयात (जैसे आयातित दृश्यों को कैसे पार/प्रबंधित करना है जैसे कि glTF से)
4- कंकाल एनीमेशन (ओं) आयात और प्रबंधन
5- मॉर्फ एनीमेशन (ओं) आयात और प्रबंधन

हमें यह भी जांचना चाहिए कि 3D मॉडल लोडिंग वाले सभी उदाहरण समान पैटर्न का सम्मान करते हैं।

हमें उदाहरणों को अपडेट करना चाहिए, और संभव नहीं होने पर हमें स्पष्ट रूप से लिखना चाहिए कि कुछ हिस्सों को हटा दिया गया है और क्या (जैसे नाइट उदाहरण में ...)

_EG- अगर हम तय करते हैं कि 3D मॉडल के लिए JSON फ़ाइल प्रारूप को - - कहते हैं - glTF के पक्ष में बहिष्कृत किया जाना चाहिए, तो इसका कोई मतलब नहीं है कि कंकाल एनीमेशन और मॉर्फटारगेट दोनों को प्रदर्शित करने वाला एकमात्र एनीमेशन उदाहरण पुराना नाइट है, जो एक का उपयोग करता है 10 संस्करण पहले का JSON मॉडल, जो एक डेटा संरचना संग्रहीत करता है जिसका अब उपयोग नहीं किया जाता है।_

@stmaccarelli कोई एकल अनुशंसित एंड-टू-एंड वर्कफ़्लो नहीं है; मुझे लगता है कि हमें अलग-अलग कौशल स्तर, मुफ्त बनाम सशुल्क मॉडलिंग टूल और विशेष जरूरतों के लिए प्राथमिकताएं प्रदान करने के लिए कड़ी मेहनत की जाएगी।

मुझे नहीं लगता कि आपको आमतौर पर उस CreateClipsFromMorphTargetSequences विधि की आवश्यकता होगी। उपरोक्त दस्तावेज़ किसी विशेष लोडर का उपयोग करने के विवरण में नहीं जाता है (जैसा कि आप उल्लेख करते हैं, वे असंगत हैं), लेकिन जीएलटीएफलोडर दस्तावेज़ करते हैं -

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

इस मामले में इससे कोई फर्क नहीं पड़ता कि क्लिप टीआरएस हैं, चमड़ी वाले, या मॉर्फ लक्ष्य हैं - आप एनिमेशन को समान रूप से चला सकते हैं। मैंने मिक्सामो और ब्लेंडर का उपयोग करके एक संभावित वर्कफ़्लो लिखा है। यहाँ माया का उपयोग करने वाला

हमें यह भी जांचना चाहिए कि 3D मॉडल लोडिंग वाले सभी उदाहरण समान पैटर्न का सम्मान करते हैं।

और 3D लोडर संदर्भों को सभी समान टेम्पलेट का सम्मान करना चाहिए।

यह एक उचित बिंदु है, और हमारे पास यहां सुधार करने के लिए कुछ जगह है।

इसका कोई मतलब नहीं है कि कंकाल एनीमेशन और मॉर्फटारगेट दोनों को प्रदर्शित करने वाला एकमात्र एनीमेशन उदाहरण पुराना नाइट है, जो 10 संस्करणों से पहले के JSON मॉडल का उपयोग करता है, जो एक डेटा संरचना को संग्रहीत करता है जिसका अब उपयोग नहीं किया जाता है।

कड़ाई से बोलते हुए JSON प्रारूप और डेटा संरचना को बहिष्कृत नहीं किया गया है, और यह अभी भी एक दृश्य को क्रमबद्ध करने के लिए एक पूरी तरह से उचित तरीका है, लेकिन बिंदु लिया गया है। @mrdoob हमारे द्वारा कुछ एनीमेशन उदाहरणों को बदलने के बारे में आप क्या सोचते हैं? जैसे कि:

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

हमारे द्वारा कुछ एनिमेशन उदाहरणों को बदलने के बारे में आप क्या सोचते हैं?

इसके लिए +1। मैं कम से कम सैनिक को animation / skinning / blending a से मिक्सामो के अधिक आधुनिक मॉडल के साथ बदलने के लिए वोट देता हूं, जैसे कि यह एक:

हम निष्क्रिय/चलने/चलाने के बीच मिश्रण कर सकते हैं, और यदि यह पसंद किया जाता है तो मॉडल को glTF में परिवर्तित करना संभव होगा।

मॉडल का आकार 9mb के आसपास होगा, जबकि सभी संबंधित फाइलों के साथ वर्तमान मॉडल 71mb है !!

animation / skinning / morph हम उस मॉडल का उपयोग कर सकते हैं जिसके साथ मैं एफबीएक्स मॉर्फ लक्ष्यों का परीक्षण कर रहा हूं:

यह वर्तमान नाइट मॉडल के समान आकार के बारे में है, लेकिन चूंकि चेहरे के भावों के लिए मॉर्फ लक्ष्य अधिक सामान्यतः उपयोग किए जाते हैं, इसलिए मैं कहूंगा कि यह अधिक समझ में आता है। दोबारा, यह वर्तमान में एफबीएक्स प्रारूप में है लेकिन अगर इसे पसंद किया जाता है तो इसे जीएलटीएफ में परिवर्तित किया जा सकता है।

विचार करने के लिए यहां कुछ उदाहरण दिए गए हैं:

| स्क्रीनशॉट | लिंक | आकार |
|---|---|--|
| | लिंक | 6 एमबी |
| | लिंक | 3 एमबी |
| | लिंक | 5 एमबी |
| | लिंक | 12 एमबी |

वे सभी एनिमेटेड हैं, तीन.जेएस में सही ढंग से काम करते हैं, और संभवतः स्केचफैब डाउनलोड संस्करण की तुलना में थोड़ा अधिक संकुचित या अनुकूलित किया जा सकता है। मेरे पास अच्छे रन/वॉक साइकिल के साथ एक कठोर चरित्र नहीं है, लेकिन मिक्सामो-> जीएलटीएफ वर्कफ़्लो बहुत खराब नहीं है।