glTF को GLB में कैसे बदलें (सिंगल-फ़ाइल 3D मॉडल)
glTF बनाम GLB: इन दो प्रारूपों के बीच असल में क्या अंतर है
मूल रूप से, glTF और GLB एक ही चीज़ हैं। वे एक ही Khronos Group स्पेसिफिकेशन द्वारा परिभाषित हैं और समान डेटा संरचनाओं को साझा करते हैं, जो समान PBR मटीरियल, एनिमेशन और सीन हायरार्की का समर्थन करते हैं। एकमात्र वास्तविक अंतर पैकेजिंग का है। एक मानक glTF एसेट फ़ाइलों का एक पूरा संग्रह होता है जिन्हें एक साथ रहना पड़ता है। आपको एक मानव-पठनीय .gltf JSON फ़ाइल मिलती है जो सीन, मटीरियल और मेश टोपोलॉजी का वर्णन करती है। इसके साथ, आपको एक या अधिक .bin फ़ाइलें मिलेंगी जिनमें कच्चा ज्यामिति डेटा होता है—वर्टेक्स पोजीशन, नॉर्मल्स, UVs, और इसी तरह। फिर टेक्सचर इमेज का एक फ़ोल्डर होता है, जो आमतौर पर PNG या JPEG होते हैं। एक मध्यम रूप से जटिल कैरेक्टर मॉडल character.gltf, character0.bin, और दस इमेज वाले textures/ फ़ोल्डर के रूप में आ सकता है। यदि आप इनमें से एक भी फ़ाइल खो देते हैं, तो मॉडल बस लोड नहीं होगा। दूसरी ओर, GLB बाइनरी कंटेनर संस्करण है। यह JSON, बाइनरी डेटा और सभी टेक्सचर को एक ही .glb फ़ाइल में बड़े करीने से पैक करता है। यह सब एक छोटे 12-बाइट हेडर द्वारा एक साथ रखा जाता है जिसमें एक मैजिक नंबर (0x46546C67, जो ASCII में 'glTF' है), एक संस्करण फ़ील्ड (वर्तमान में 2), और कुल फ़ाइल लंबाई होती है। फ़ाइल का बाकी हिस्सा सिर्फ डेटा चंक्स का एक क्रम है। यह एक GLB फ़ाइल को पूरी तरह से आत्मनिर्भर बनाता है। आप इसे ईमेल कर सकते हैं, इसे वेब-आधारित उत्पाद कॉन्फ़िगरेटर में डाल सकते हैं, या इसे किसी क्लाइंट को टूटे हुए पाथ या गायब टेक्सचर की चिंता किए बिना दे सकते हैं। फ़ाइल का आकार लगभग हमेशा मूल बंडल के 1-3% के भीतर होता है, इसलिए आप इस अपार सुविधा के लिए कोई वास्तविक स्टोरेज पेनल्टी नहीं देते हैं।
आपको glTF को GLB में कब बदलना चाहिए (और कब नहीं)
अंतिम डिलीवरी और डिप्लॉयमेंट के लिए, मेरा डिफ़ॉल्ट हमेशा GLB होता है। एक अकेली, आत्मनिर्भर फ़ाइल की सादगी को नज़रअंदाज़ करना बहुत मुश्किल है। लेकिन सक्रिय विकास के दौरान, मल्टी-फ़ाइल glTF प्रारूप के साथ बने रहना वास्तव में एक समझदारी भरा विकल्प हो सकता है। GLB का मामला सबसे मजबूत तब होता है जब आप किसी मॉडल को model-viewer, Babylon.js, या Three.js जैसे वेब व्यूअर पर डिप्लॉय कर रहे हों। एक सिंगल फेच रिक्वेस्ट हमेशा प्रत्येक बाइनरी फ़ाइल और टेक्सचर के लिए नेटवर्क कॉल्स के एक झरने से बेहतर होती है। एक 4 MB की GLB फ़ाइल मोबाइल कनेक्शन पर उसी मॉडल की तुलना में काफ़ी तेज़ी से लोड होगी जो 120 KB .gltf, 2.1 MB .bin, और कुल 1.8 MB के छह टेक्सचर में विभाजित है। क्यों? क्योंकि प्रत्येक अलग फ़ाइल को अपने स्वयं के HTTP राउंड-ट्रिप की आवश्यकता होती है। आपको क्लाइंट या मार्केटप्लेस में वितरित करते समय भी GLB में कनवर्ट करना चाहिए; Unity Asset Store, Sketchfab, और Apple के AR Quick Look पाइपलाइन जैसे प्लेटफ़ॉर्म इसके साथ सहजता से काम करते हैं। तो मल्टी-फ़ाइल glTF कहाँ बेहतर है? कंटेंट निर्माण के दौरान। यदि कोई टेक्सचर आर्टिस्ट 2K रफ़नेस मैप पर काम कर रहा है, तो वे बस एक नया PNG टेक्सचर फ़ोल्डर में डाल सकते हैं और रिफ्रेश कर सकते हैं। यह हर बार पूरे एसेट को फिर से पैक करने की तुलना में बहुत तेज़ है। यही तर्क स्वचालित बिल्ड सिस्टम पर भी लागू होता है। यदि आपकी पाइपलाइन KTX2 या Basis Universal वेरिएंट उत्पन्न करने के लिए टेक्सचर कम्प्रेशन चलाती है, तो हर बिल्ड पर GLB को अनपैक और रीपैक करने की तुलना में अलग-अलग फ़ाइलों पर काम करना कहीं ज़्यादा सरल है। और यहाँ एक मुख्य सीमा याद रखनी है: GLB डिज़ाइन के अनुसार बाहरी टेक्सचर को संदर्भित नहीं कर सकता है। यदि आपका मूल glTF होशियारी से CDN पर टेक्सचर से लिंक करने के लिए सेट किया गया था—एक पैटर्न जो मॉडलों के बीच टेक्सचर एटलस साझा करने के लिए होता है—तो GLB में कनवर्ट करने से स्थानीय प्रतियां एम्बेड हो जाएंगी और वह साझा-संसाधन पैटर्न टूट जाएगा।
CocoConvert का उपयोग करके glTF को GLB में कैसे बदलें
CocoConvert के ब्राउज़र-आधारित टूल का उपयोग करना GLB प्राप्त करने का सबसे सरल तरीका है, क्योंकि इसमें किसी सॉफ़्टवेयर इंस्टॉलेशन की आवश्यकता नहीं होती है। 100 MB से कम की फ़ाइलों के लिए यह पूरी प्रक्रिया क्लाइंट-साइड काम करती है, जिसका अर्थ है कि आपका मूल्यवान ज्यामिति और टेक्सचर डेटा आपकी मशीन को कभी नहीं छोड़ता है। चरण 1 — अपनी फ़ाइलें तैयार करें। एक glTF एसेट एक पैकेज डील है, इसलिए आपको सब कुछ एक साथ अपलोड करने की आवश्यकता है। ऐसा करने का एकमात्र तरीका है कि आप अपनी .gltf फ़ाइल, उससे जुड़ी सभी .bin फ़ाइलें, और पूरे टेक्सचर फ़ोल्डर को एक ही आर्काइव में ज़िप करें। आंतरिक फ़ोल्डर संरचना को बनाए रखना महत्वपूर्ण है। .gltf फ़ाइल ./textures/baseColor.png जैसे रिलेटिव पाथ पर निर्भर करती है, और कनवर्टर को उन पाथ्स का ज़िप के अंदर सही होना आवश्यक है। चरण 2 — कनवर्टर खोलें। /convert/gltf-to-glb पर जाएं और या तो अपलोड क्षेत्र पर क्लिक करें या बस अपनी .zip फ़ाइल को पेज पर खींचकर छोड़ दें। टूल इतना स्मार्ट है कि glTF एंट्री पॉइंट को स्वचालित रूप से ढूंढ लेता है। यदि किसी कारण से आपके ज़िप में कई .gltf फ़ाइलें हैं (जैसे LOD वेरिएंट), तो एक ड्रॉपडाउन दिखाई देगा ताकि आप रूट के रूप में उपयोग करने के लिए सही फ़ाइल चुन सकें। चरण 3 — रूपांतरण विकल्पों की समीक्षा करें। CocoConvert आपको कुछ सेटिंग्स देता है। 'Embed textures' डिफ़ॉल्ट रूप से चालू है, जो कि आप एक वास्तविक, सिंगल-फ़ाइल GLB के लिए चाहते हैं। यदि आप इसे बंद कर देते हैं, तो आउटपुट बाहरी टेक्सचर URI को संदर्भित करेगा, जो रूपांतरण के पूरे उद्देश्य को विफल कर देगा। दूसरा विकल्प 'Flatten buffer' है। मेरी सलाह? इसे सक्षम रहने दें। यह कई .bin फ़ाइलों को एक ही बाइनरी चंक में मिला देता है, जो मानक GLB व्यवहार है। चरण 4 — डाउनलोड करें। बस इतना ही। रूपांतरण में आमतौर पर 5 से 20 सेकंड लगते हैं, यह इस बात पर निर्भर करता है कि आपके पास कितने टेक्सचर हैं और कुल फ़ाइल का आकार क्या है। आपको एक सिंगल .glb फ़ाइल मिलेगी, जो डिप्लॉयमेंट के लिए तैयार है।
कमांड-लाइन विकल्प: स्वचालित वर्कफ़्लो के लिए gltf-pipeline का उपयोग करना
जब आप एक बिल्ड पाइपलाइन के हिस्से के रूप में दर्जनों मॉडलों को परिवर्तित कर रहे हों, तो एक-एक करके वेब UI का उपयोग करना व्यावहारिक नहीं है। किसी भी प्रकार के स्वचालित वर्कफ़्लो के लिए, Cesium टीम का gltf-pipeline Node.js टूल सबसे विश्वसनीय ओपन-सोर्स विकल्प है। सबसे पहले, इसे npm के साथ विश्व स्तर पर इंस्टॉल करें: `npm install -g gltf-pipeline`। फिर एक एकल एसेट को परिवर्तित करना सीधा है: `gltf-pipeline -i scene.gltf -o scene.glb`। -i फ्लैग आपकी इनपुट .gltf फ़ाइल को इंगित करता है। वेब टूल के विपरीत, gltf-pipeline स्वचालित रूप से संबंधित .bin फ़ाइलों और टेक्सचर को उसी डायरेक्टरी में ढूंढ लेता है, इसलिए कुछ भी ज़िप करने की आवश्यकता नहीं है। -b फ्लैग (--binary के लिए) तब निहित होता है जब आपका आउटपुट फ़ाइल नाम .glb में समाप्त होता है, जो एक अच्छी सुविधा है। पूरी डायरेक्टरी को बैच प्रोसेस करने के लिए, एक साधारण शेल लूप आपका मित्र है: `for f in models/*.gltf; do gltf-pipeline -i "$f" -o "${f%.gltf}.glb"; done`। विंडोज पावरशेल के लिए समकक्ष कमांड है `Get-ChildItem -Filter *.gltf | ForEach-Object { gltf-pipeline -i $_.FullName -o ($_.FullName -replace '.gltf','.glb') }`। gltf-pipeline --draco.compressionLevel फ्लैग के साथ Draco मेश कम्प्रेशन का भी समर्थन करता है (मान 0-10, डिफ़ॉल्ट 7)। किसी भी घने मेश वाले मॉडल के लिए, आपको इसे बिल्कुल सक्षम करना चाहिए। यह ज्यामिति के आकार को 60-80% तक कम कर सकता है। एक 500,000-पॉलीगॉन स्कैन जो बिना कम्प्रेशन के 18 MB का है, Draco लेवल 7 के साथ लगभग 4 MB तक सिकुड़ सकता है। ब्राउज़र में थोड़ा लंबा डीकोड समय लगभग हमेशा इसके लायक होता है। टूल की एक बड़ी सीमा यह है कि यह टेक्सचर कम्प्रेशन (KTX2/Basis) को हैंडल नहीं करता है। उसके लिए, आपको अपनी पाइपलाइन में toktx या basisu जैसे टूल का उपयोग करके एक अलग चरण की आवश्यकता होगी, या तो GLB को पैकेज करने से पहले या बाद में।
डिप्लॉयमेंट से पहले अपने GLB आउटपुट को मान्य करना
इस चरण को नज़रअंदाज़ न करें। एक GLB जो एक व्यूअर में पूरी तरह से खुलता है, वह दूसरे में चुपचाप विफल हो सकता है यदि उसमें गैर-अनुरूप डेटा हो। किसी भी परिवर्तित एसेट को शिप करने से पहले सत्यापन को अपनी प्रक्रिया का एक मानक हिस्सा बनाएं। Khronos glTF Validator सत्य का एकमात्र स्रोत है। आप इसे validator.khronos.org पर ऑनलाइन उपयोग कर सकते हैं—बस अपनी .glb को पेज पर खींचें। यह त्रुटियों, चेतावनियों और अन्य जानकारी का विवरण देते हुए एक संरचित JSON रिपोर्ट देता है। त्रुटियाँ डील-ब्रेकर होती हैं। एक्सेसरी componentType का बेमेल होना या बफर व्यू का घोषित बफर लंबाई से अधिक होना जैसी चीजें अधिकांश लोडर्स को फ़ाइल को तुरंत अस्वीकार करने का कारण बनेंगी। चेतावनियाँ कम गंभीर होती हैं लेकिन फिर भी पढ़ने लायक होती हैं; 'MESH_PRIMITIVE_UNUSED_TEXCOORD' जैसी एक आम चेतावनी का मतलब सिर्फ यह है कि आपके पास एक UV सेट है जिसका कोई मटीरियल उपयोग नहीं कर रहा है। स्वचालित पाइपलाइनों के लिए, आप वैलिडेटर को Node पैकेज के रूप में इंस्टॉल कर सकते हैं: `npm install -g gltf-validator`। फिर `gltf-validator scene.glb --stdout > report.json` चलाएं और उस रिपोर्ट को CI चेक में पाइप करें। यदि त्रुटियों की संख्या शून्य से अधिक है तो बिल्ड को निश्चित रूप से विफल होना चाहिए। सख्त स्पेक अनुपालन से परे, हमेशा कम से कम दो अलग-अलग रेंडरर्स में एक विज़ुअल जांच करें। मैं model-viewer (modelviewer.dev) और Babylon.js Sandbox (sandbox.babylonjs.com) की सलाह देता हूँ। वे अलग-अलग WebGL कार्यान्वयन का उपयोग करते हैं और सूक्ष्म मटीरियल समस्याओं को उजागर करने में बहुत अच्छे हैं। कोई भी जिसने एक नॉर्मल मैप के साथ संघर्ष किया है जो उनके DCC टूल में ठीक दिखता था लेकिन वेब पर रहस्यमय तरीके से उलटा हो गया था, वह इस दर्द को जानता है। glTF स्पेक के लिए OpenGL-शैली के नॉर्मल्स (Y-up) की आवश्यकता होती है, लेकिन कई टूल डिफ़ॉल्ट रूप से DirectX-शैली (Y-down) निर्यात करते हैं। यदि आपकी लाइटिंग उल्टे उभार की तरह दिखती है, तो अपने नॉर्मल मैप के ग्रीन चैनल को पलटें और फिर से कनवर्ट करें।
सामान्य रूपांतरण त्रुटियाँ और उन्हें कैसे ठीक करें
अधिकांश glTF से GLB रूपांतरण त्रुटियाँ निराशाजनक होती हैं, लेकिन शुक्र है कि उनके सीधे समाधान होते हैं। यहाँ वे मुद्दे हैं जो बार-बार सामने आते हैं। आउटपुट में टेक्सचर का गायब होना: यह नंबर एक मुद्दा है। इसका अपराधी लगभग हमेशा यह होता है कि .gltf फ़ाइल के टेक्सचर URI पाथ रूपांतरण के दौरान हल नहीं हुए। इसे डीबग करने के लिए, अपनी .gltf को एक टेक्स्ट एडिटर में खोलें और images ऐरे ढूंढें। आपको `"uri": "textures/Material_baseColor.png"` जैसी प्रविष्टियाँ दिखाई देंगी। आपको यह सुनिश्चित करना होगा कि वे फ़ाइलें आपके ज़िप आर्काइव या वर्किंग डायरेक्टरी के अंदर ठीक उसी रिलेटिव पाथ पर मौजूद हों। याद रखें कि सर्वर पर पाथ सेपरेटर और कैपिटलाइज़ेशन मायने रखता है: `Textures/BaseColor.png` और `textures/baseColor.png` एक समान नहीं हैं। आउटपुट फ़ाइल का बड़ा आकार: यदि आपका GLB अप्रत्याशित रूप से बड़ा है, तो इसका कारण लगभग निश्चित रूप से आपके टेक्सचर हैं। एक सिंगल 4096×4096 RGBA PNG मेमोरी में बिना कम्प्रेशन के 64 MB का हो सकता है। जबकि PNG खुद लॉसलेस कम्प्रेशन का उपयोग करता है, एक GLB बस कच्चे PNG फ़ाइल बाइट्स को एम्बेड करता है। इसका मतलब है कि आपका 12 MB का PNG टेक्सचर GLB में 12 MB जोड़ता है। वेब उपयोग के लिए, आपको गंभीरता से टेक्सचर को 2048×2048 तक डाउनसैंपल करने (दृश्य अंतर अक्सर नगण्य होता है) या GLB पैक करने से पहले KTX2 कम्प्रेशन लागू करने पर विचार करना चाहिए। एनिमेशन का न चलना: यदि आपके स्रोत glTF में स्केलेटल एनिमेशन थे लेकिन वे GLB में गायब हैं, तो इसका मतलब यह है कि एनिमेशन डेटा कभी शामिल ही नहीं किया गया था। कुछ 3D एक्सपोर्टर एनिमेशन डेटा को एक अलग .bin फ़ाइल में लिखते हैं। यदि वह फ़ाइल आपके रूपांतरण इनपुट से गायब थी, तो एनिमेशन डेटा बस चला गया है। इसका समाधान यह है कि आप अपने 3D टूल से फिर से एक्सपोर्ट करें, यह सुनिश्चित करते हुए कि सभी बाइनरी डेटा एक ही .bin फ़ाइल में लिखा गया है, और फिर रूपांतरण फिर से चलाएं। CocoConvert अपने लॉग में एक चेतावनी रिपोर्ट करेगा यदि उसे संदर्भित फ़ाइलें मिलती हैं जो उसे आपके आर्काइव में नहीं मिलीं। डाउनलोड करने से पहले हमेशा लॉग की जाँच करें।
फ़ाइल का आकार, प्रदर्शन, और वास्तविक परियोजनाओं में क्या उम्मीद करें
चलिए सिद्धांत से आगे बढ़ते हैं। ठोस उम्मीदें अस्पष्ट वादों से बेहतर होती हैं, इसलिए यहाँ कुछ विशिष्ट एसेट्स के लिए रूपांतरण प्रक्रिया वास्तव में कैसी दिखती है। एक साधारण फर्नीचर मॉडल—एक मेश, दो मटीरियल, चार 1K टेक्सचर—एक 3.2 MB के मल्टी-फ़ाइल glTF बंडल के रूप में शुरू हो सकता है। रूपांतरण के बाद, यह 3.1 MB का GLB बन जाता है। आकार में यह थोड़ी कमी JSON व्हाइटस्पेस को हटाने और बफर हेडर्स को मर्ज करने से आती है। तेज़ कनेक्शन वाले डेस्कटॉप पर, आपको लोड समय में कोई अंतर महसूस नहीं होगा। लेकिन 4G मोबाइल कनेक्शन पर, वह सिंगल-फ़ाइल GLB कई HTTP अनुरोधों के ओवरहेड से बचकर 300-500 ms पहले रेंडर करना शुरू कर देगा। अब स्केलेटल एनिमेशन, 12 मटीरियल और 2K टेक्सचर वाले एक जटिल कैरेक्टर पर विचार करें। यह 28 MB का glTF बंडल हो सकता है। एक सादे GLB के रूप में, यह लगभग 27.4 MB का है। यदि आप ज्यामिति के लिए Draco कम्प्रेशन जोड़ते हैं, तो यह लगभग 22 MB तक गिर सकता है। लेकिन यदि आप पहले KTX2 Basis Universal टेक्सचर कम्प्रेशन लागू करते हैं, तो अंतिम GLB 9-11 MB जितना छोटा हो सकता है। CocoConvert बुनियादी glTF-से-GLB पैकेजिंग को पूरी तरह से संभालता है, लेकिन यह वर्तमान में Draco या KTX2 लागू नहीं करता है। उन उन्नत अनुकूलन के लिए, आपको gltf-pipeline और toktx जैसे टूल का उपयोग एक अलग चरण में करना होगा। AR परियोजनाओं के लिए, फ़ाइल का आकार महत्वपूर्ण है। Apple के AR Quick Look और Google के Scene Viewer दोनों की प्रलेखित सीमाएँ हैं। Apple मोबाइल नेटवर्क पर विश्वसनीय लोडिंग के लिए GLB को 20 MB से कम रखने का सुझाव देता है। Google की हार्ड लिमिट 200 MB है, लेकिन वे अच्छे प्रदर्शन के लिए 15 MB से कम रहने की सलाह देते हैं। यदि आपका परिवर्तित GLB इन सीमाओं से अधिक है, तो तुरंत ज्यामिति सरलीकरण टूल की ओर न बढ़ें। आपका पहला और सबसे अधिक प्रभाव वाला कदम लगभग हमेशा टेक्सचर कम्प्रेशन होता है। /convert/gltf-to-glb पर रूपांतरण स्वयं 3D डेटा के संबंध में दोषरहित है — ज्यामिति, मटीरियल, एनिमेशन और सीन हायरार्की बिल्कुल संरक्षित हैं। आप जो डालते हैं, वही आपको मिलता है, बस अधिकतम पोर्टेबिलिटी के लिए फिर से पैक किया गया है।