GLTF को OBJ में बदलें

दोनों फ़ॉर्मेट टेक्स्ट हैं, और यह समानता भ्रामक है। एक .gltf खोलिए तो एक JSON document मिलता है जिसमें vertex डेटा एक base64 string है, buffer views से byte offsets से काटा हुआ, accessors से पढ़ा हुआ। एक coordinate तक पहुँचने के लिए चार indirection हैं।

OBJ में इनमें से कुछ नहीं। v से शुरू होने वाली line एक vertex है और उसके बाद के तीन नंबर उसके coordinate हैं। यही पूरी grammar है, और यही वजह है OBJ हर उस फ़ॉर्मेट से ज़्यादा टिका रहा जिसने इसकी जगह लेनी चाही जब काम निरीक्षण का था।

ऊपर एक comment line लेखक बताती है, फिर हर mesh के लिए — glTF से नाम लाती एक o line, v lines की एक लड़ी, और f lines की एक लड़ी। कुछ और नहीं दिखता — कोई vt नहीं, कोई vn नहीं, कोई mtllib नहीं।

इसका मतलब है इसके लिए parser लगभग छह लाइन का होगा, और wc, grep व awk जैसे टूल सीधे काम आते हैं। f lines गिनना triangle count देता है; v lines गिनना vertex count।

OBJ face indices एक से शुरू होते हैं। वे पूरी फ़ाइल में लगातार भी चलते हैं, हर o group पर दोबारा शुरू नहीं होते — यही वह विवरण है जिसे ज़्यादातर हाथ से लिखे parser ग़लत पकड़ते हैं।

अगर आप फ़ाइल वापस पढ़ रहे हैं, नियम है — अब तक देखी v lines की गिनती जोड़िए और zero-based index पाने के लिए एक घटाइए।

glTF node tree किसी mesh को matrix की एक श्रृंखला से कहीं भी रख सकता है, और एक ही mesh को कई जगह भी। OBJ के पास न scene graph है, न instancing, इसलिए रूपांतरण tree को resolve करता है।

जो नतीजा नापने वाले के लिए अच्छा है — जो संख्या आप पढ़ रहे हैं वह वहीं है जहाँ ज्यामिति असल में है, transform से पहले नहीं। फ़ाइल के आकार के लिए नतीजा है कि दोहराई गई instances दोहराया gadhaव vertex data बन जाती हैं।

Materials, textures, images, samplers, UV coordinates, normals, tangents, vertex colours, morph targets, skins, animation channels, cameras, lights और कोई भी extension। इनमें से कुछ भी न पढ़ा जाता है न लिखा।

OBJ सैद्धांतिक रूप से UV और normals रख सकता है, और एक अलग MTL material बता सकती। यह converter दोनों नहीं लिखता, क्योंकि यह छह फ़ॉर्मेट के बीच ज्यामिति ले जाता है और जो डेटा कभी निकाला ही नहीं गया उससे material file गढ़ना ग़लत होगा।

glTF primitives एक mode घोषित करते हैं। Mode 4 triangle list है और यही पढ़ी जाती है; points, lines, triangle strips और fans छोड़ दी जाती हैं। सिर्फ़ line geometry वाली फ़ाइल एक संदेश के साथ रुकती है, जो ख़ाली OBJ से ज़्यादा उपयोगी है।

Draco-compressed geometry नाम बताते हुए रुकती है, क्योंकि KHR_draco_mesh_compression का decoder यहाँ नहीं है। अगर आपकी glTF size-optimised export pipeline से आई, यही सबसे बड़ी वजह होगी।

बिल्कुल, हर mesh के लिए। इस रास्ते पर कुछ नहीं मिलाया जाता — POSITION accessor element-दर-element v lines में डिकोड होता है उसी क्रम में, और index accessor f entries बनती है।

यह गिनती एक इस्तेमाल लायक़ जाँच बनाती है — अगर आपके टूल ने 48,213 vertices बताए और OBJ में 48,213 v lines हैं, कुछ छूटा नहीं। इसका यह भी मतलब है coincident vertices बचे रहते हैं।

glTF buffer में float32 coordinate चार बाइट का है। वही संख्या दशमलव पाठ के रूप में लिखी जाना आम तौर पर आठ से अठारह अक्षर लेती है, इसलिए OBJ glTF के geometry हिस्से से कहीं बड़ी होती है।

सटीकता truncate नहीं होती — values उतनी सटीकता पर छापे जाते हैं जितनी JavaScript को float round-trip करने के लिए चाहिए, इसलिए बाहर जाते वक़्त चुपचाप कुछ round नहीं होता।

अगर model को render करना है, glTF रखिए। जो इसे देखने लायक़ बनाता है — materials, textures, animation — सब कुछ इस रूपांतरण द्वारा फेंके गए हिस्से में है, और हर आधुनिक viewer इसे सीधे पढ़ता है।

बदलिए जब model asset की बजाय डेटा है — जब आपको भरोसेमंद triangle count चाहिए, ख़ुद नापा bounding box, दो exports के बीच diff, या अपने लिखे code का इनपुट।