PLY को 3MF में बदलें

दोनों फ़ॉर्मेट स्कैन को स्लाइसर तक पहुँचा देंगे, पर 3MF ज़्यादा सच्चाई साथ लाता है। यह अपनी यूनिट model तत्व में ही घोषित करता है, इसलिए स्लाइसर किसी घर के रिवाज़ पर नहीं जाता। हर वर्टेक्स एक बार सँभला रहता है और हर त्रिकोण उसका हवाला देता है, जहाँ STL हर त्रिकोण के लिए तीन पूरे वर्टेक्स दोहराता है।

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

यहाँ लिखी गई 3MF हमेशा कहती है unit="millimeter"। PLY के निर्देशांक बिना किसी स्केलिंग के आगे बढ़ा दिए जाते हैं, क्योंकि PLY कोई यूनिट घोषित करता ही नहीं और बदलने को कुछ है ही नहीं। तो यह बदलाव फ़ाइल के बारे में एक ऐसी बात कह रहा है जो फ़ाइल ने कभी कही ही नहीं थी।

स्ट्रक्चर्ड-लाइट या लेज़र स्कैन के लिए यह बात अमूमन सही होती है, क्योंकि डिवाइस अपनी ऑप्टिकल ज्यामिति जानता है और मिलीमीटर में बताता है। फ़ोटो से बनी photogrammetry रीकंस्ट्रक्शन के लिए यह अमूमन बेमानी है, क्योंकि वह प्रक्रिया आकार को एक अनजान स्केल तक ही निकालती है — दो सौ मिलीमीटर की चीज़ इकाई अंकों में भी आ सकती है और हज़ारों में भी। कैप्चर में स्केल बार रखिए, या MeshLab में किसी जाने-पहचाने नाप से स्केल करके ही बदलिए।

यह वह जोड़ी है जहाँ नुक़सान सबसे साफ़ दिखता है, क्योंकि प्रति-वर्टेक्स रंग ही वह वजह है जिसके लिए स्कैन PLY फ़ाइल बनते हैं। यहाँ का रीडर हर वर्टेक्स तत्व से x, y और z प्रॉपर्टी लेता है और बाक़ी सब — लाल, हरा, नीला, अल्फ़ा, नॉर्मल, confidence, quality और कोई भी कस्टम फ़ील्ड — बिना पढ़े छोड़ देता है, ताकि stride सही बना रहे।

3MF रंग रखने में पूरी तरह सक्षम है — इसमें base materials group, colour group और त्रिकोण-स्तर की property index होती है, और मल्टी-मटीरियल प्रिंटर इनका इस्तेमाल भी करते हैं। यहाँ कुछ नहीं लिखा जाता। अगर रंगीन प्रिंट ही मक़सद है, तो रास्ता आपके स्लाइसर के अपने पेंटिंग टूल हैं, यह बदलाव नहीं।

अगर PLY सिर्फ़ वर्टेक्स घोषित करता है और कोई face नहीं, तो बदलाव रुककर यही बताता है। यह सही है, तंग करने वाला नहीं — स्लाइसर को अंदर-बाहर तय करने के लिए एक बंद सतह चाहिए, और बिंदुओं के समूह में दोनों में से कुछ नहीं होता।

यहाँ से आगे बढ़ने का रास्ता किसी प्रीव्यू वाले टूल में है। MeshLab और CloudCompare दोनों Poisson और ball-pivoting reconstruction देते हैं, और उनके बीच का चुनाव नतीजे को साफ़ बदल देता है — इसलिए किसी कन्वर्टर को यह ख़ुद तय नहीं करना चाहिए। पहले मेश बनाइए, जाँच लीजिए, तब बदलिए।

इस रास्ते पर कोई welding नहीं की जाती। STL और OBJ रीडर मिलते-जुलते वर्टेक्स जोड़ देते हैं क्योंकि वे फ़ॉर्मेट अक्सर डुप्लिकेट के साथ आते हैं; PLY रीडर वर्टेक्स सरणी और face indices को वैसे ही लेता है जैसे फ़ाइल में लिखे हैं, क्योंकि मेशिंग का कदम पहले ही जान-बूझकर तय हो चुका होता है।

तो 3MF में वर्टेक्स की गिनती PLY हेडर की element गिनती से मिलती है, और त्रिकोणों की गिनती face गिनती से। इससे जाँचना आसान हो जाता है, पर इसका मतलब यह भी है कि बदलाव कुछ साफ़ नहीं करता। स्कैन की डुप्लिकेट वर्टेक्स, बिना संदर्भ वाले वर्टेक्स और सीम की दरारें जस की तस पहुँचती हैं, और अगर वे manifold की शिक़ायत दे रही थीं तो वैसी ही देती रहेंगी।

स्कैन में वहाँ छेद होते हैं जहाँ स्कैनर की नज़र नहीं पहुँची — undercut, वह सतह जिस पर ऑब्जेक्ट टिका था, गहरे या चमकदार हिस्से जिनसे कुछ नहीं लौटा। अक्सर पीछे की फ़ालतू ज्यामिति के टुकड़े भी साथ आते हैं, और जहाँ कई पास मिलाए गए वहाँ self-intersection भी।

3MF किसी छापने लायक़ ऑब्जेक्ट से बंद manifold volume की उम्मीद रखता है, और यहाँ कुछ भी इसे जाँचता या लागू नहीं करता। फ़ाइल स्लाइसर में खुल जाएगी और स्लाइसर बता देगा कि क्या ग़लत है। पहले से ठीक करना — MeshLab की hole filling, Meshmixer का inspector, या Blender का 3D-Print Toolbox — स्लाइसर की चेतावनियों में उलझने से तेज़ है, और यही तय करता है कि प्रिंट सफल होगा या नहीं।

3MF अपने resources खंड में एक ही ऑब्जेक्ट रखता है और build खंड में एक ही item, बिना किसी ट्रांसफ़ॉर्म के। PLY में एक ही सतह होती है और उसे बाँटने का कोई रास्ता नहीं, इसलिए बाँटने या रखने को कुछ है ही नहीं।

कोई नाम भी नहीं लिखा जाता, तो स्लाइसर ऑब्जेक्ट को बिना नाम दिखाएगा। अगर स्कैन में कई अलग-अलग टुकड़े हैं — कोई स्कैन की गई असेंबली, या पीछे के टुकड़ों समेत कैप्चर — तो इम्पोर्ट के बाद Split to Parts उन्हें जुड़ाव के हिसाब से ढूँढ लेता है, और यही अवांछित टुकड़े हटाने का सबसे तेज़ रास्ता भी है।

एक ZIP जिसमें तीन एंट्री होती हैं: [Content_Types].xml, जो .model और .rels एक्सटेंशन को उनके content type से जोड़ता है; _rels/.rels, जिसमें model की ओर इशारा करने वाला एक रिलेशनशिप होता है; और 3D/3dmodel.model, जिसमें ज्यामिति 3MF core namespace में रहती है। यही ढाँचा इसे सिर्फ़ XML वाली ZIP नहीं बल्कि एक OPC package बनाता है, और अकेला model पाकर स्लाइसर आर्काइव को ठुकरा देता।

यह एक मॉडल फ़ाइल है, प्रोजेक्ट नहीं। न प्रिंट प्रोफ़ाइल, न फ़िलामेंट असाइनमेंट, न प्लेट का ख़ाका, न थंबनेल, न प्रति-ऑब्जेक्ट सेटिंग — क्योंकि ये सब स्लाइसर की अपनी एक्सटेंशन हैं, ज्यामिति नहीं। आपका स्लाइसर जो भी प्रोफ़ाइल चुनी गई है उसे लगाएगा और बाद में अपना, कहीं बड़ा, प्रोजेक्ट 3MF ख़ुद सहेज सकता है।

वक़्त बचाने वाला क्रम यह है: बिंदुओं के बादल को मेश कीजिए, पीछे के टुकड़े हटाइए, छेद भरिए, किसी स्लाइसर के काबिल तक decimate कीजिए, किसी जाने-पहचाने नाप से स्केल कीजिए, और तभी बदलिए। इनमें से हर कदम फ़ॉर्मेट की नहीं, स्कैन की समस्या है, और हर एक MeshLab या स्कैनर सॉफ़्टवेयर में स्लाइसर से आसान है।

बदलाव ख़ुद आपके ब्राउज़र में पूरी तरह चलता है — कोई इंजन डाउनलोड नहीं, कुछ अपलोड नहीं, 100 MB की सीमा — जो तब मायने रखता है जब स्कैन किसी व्यक्ति का हो, किसी क्लाइंट की चीज़ का हो या कोई पार्ट हो जिसे कोई सार्वजनिक नहीं करना चाहता। स्लाइसर तक पहुँचने वाली फ़ाइल उस मशीन से कभी बाहर नहीं जाती जिस पर स्कैन हुआ था।