STL को PLY में बदलें

इस सेट की हर और जोड़ी कुछ न कुछ छोड़ती है। glTF मैटीरियल खो देता है, OBJ MTL खो देता है, 3MF रंग खो देता है। STL to PLY face normal खोता है, और वे हर उस reader से दोबारा बन जाते हैं जिसे उनकी ज़रूरत है, winding order से।

बाक़ी सब बचता है क्योंकि और कुछ था ही नहीं। STL बिना रंग, इकाई, नाम, हिस्से या attribute के ट्रायंगल की सूची है। x, y और z तथा face सूची के साथ लिखी PLY ठीक वही रखती है। दोनों फ़ॉर्मेट इस पर सहमत हैं कि मॉडल क्या है, जो इस श्रेणी में दुर्लभ बात है।

CloudCompare, MeshLab, Open3D और trimesh सब PLY को पहले-दर्जे का इनपुट मानते हैं, क्योंकि Stanford ने 1994 में इसे ठीक इसी तरह के काम के लिए डिज़ाइन किया: एक ख़ुद-को-बताने वाला हेडर जो जो भी प्रति-vertex और प्रति-face गुण किसी शोध टूल को चाहिए वे सूचीबद्ध करता है।

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

STL हर ट्रायंगल के लिए तीन स्वतंत्र vertex रखता है। एक क्यूब आठ पोज़िशन के लिए छत्तीस vertex रिकॉर्ड है। इसे किसी मेश टूल में लोड करके पूछिए क्या सतह बंद है और वह कहेगा हर एक किनारा boundary edge है, क्योंकि कोई दो ट्रायंगल vertex साझा नहीं करते।

बदलाव निर्देशांक छह दशमलव अंक तक गोल करता है, उसे कुंजी के तौर पर इस्तेमाल करता है, और एक ही जगह हर कोने को एक साझा vertex में समेट देता है जिसे उसके सभी ट्रायंगल इशारा करते हैं। इसके बाद manifold जाँच, normal अंदाज़ा, curvature, decimation, smoothing और hole filling सब असली adjacency पर काम करते हैं।

हेडर सादा है: ply, format ascii 1.0, writer का नाम बताती टिप्पणी, x, y और z के लिए तीन property float लाइन वाली एक element vertex घोषणा, एक property list uchar int vertex_indices लाइन वाली एक element face घोषणा, और end_header। फिर प्रति vertex एक लाइन और प्रति ट्रायंगल एक लाइन।

और कुछ घोषित नहीं होता — कोई normal, रंग, विश्वास, गुणवत्ता या कस्टम property नहीं। यह जान-बूझकर है: ऐसा हेडर जो कोई गुण देने का वादा करता है जो फ़ाइल भर नहीं सकती वह छोटे हेडर से बुरा है, और PLY संभालने वाला हर reader इस प्रकार को संभालता है।

बाइनरी STL के हर पचास-बाइट ट्रायंगल रिकॉर्ड की शुरुआत में बारह बाइट का face normal होता है। वे बारह बाइट छोड़ दिए जाते हैं। उनकी जानकारी तीनों vertex के क्रम से पूरी तरह तय होती है, तो उसे दोबारा हिसाब लगाना अनुमान नहीं, सटीक है।

यह सुविधा के लिए लिया शॉर्टकट नहीं। सहेजे गए STL normal winding से इतनी बार असहमत होते हैं कि कई slicer और मेश टूल उन्हें नीति के तौर पर छोड़ देते हैं। Winding से दोबारा हिसाब लगाना एक जैसा जवाब देता है, और असंगत winding वाला मेश एक ख़राबी है जिसे आप देखना चाहते हैं।

हर निर्देशांक दशमलव टेक्स्ट के तौर पर लिखा जाता है, प्रति vertex एक लाइन, और हर ट्रायंगल शुरुआती 3 के बाद तीन इंडेक्स के तौर पर। जो vertex बाइनरी में बारह बाइट था वह बीस से साठ अक्षर बन जाता है। इसके ख़िलाफ़, वेल्डिंग पहले ही STL के लगभग पाँच-छठे vertex रिकॉर्ड हटा चुकी होती है।

दोनों असर आंशिक रूप से एक-दूसरे को काटते हैं और नतीजा मॉडल पर निर्भर करता है। STL पक्ष अनुमानित है: n ट्रायंगल के लिए ठीक 84 + 50n बाइट, तो बीस-लाख-ट्रायंगल वाला स्कैन-आधारित मेश बदलने से पहले 100 MB का है और पहले decimate करने लायक़ है।

इस बदलाव की सबसे आम वजह deviation विश्लेषण है: STL से कोई पार्ट प्रिंट या मशीन से बना, फिर स्कैन हुआ, और किसी को फ़र्क़ चाहिए। CloudCompare का cloud-to-mesh distance रेफ़रेंस को face वाले मेश के तौर पर चाहता है, जो यह बनाता है।

दो व्यावहारिक बातें। दोनों डेटासेट पहले एक साथ align होने चाहिए — मोटा point-pair चुनाव फिर ICP सामान्य रास्ता है — और उन्हें एक जैसा scale साझा करना चाहिए, जो कोई फ़ॉर्मेट घोषित नहीं करता। स्कैन मिलीमीटर में हो और STL इंच में एक्सपोर्ट हुई हो, तो alignment किसी संभावित पर मिल जाएगा, ग़लत।

PLY वह फ़ॉर्मेट है जिसमें 3D स्कैन आते हैं क्योंकि यह प्रति-vertex रंग रखता है, और यही किसी photogrammetry मेश को असली वस्तु जैसा दिखाता है। यहाँ इनमें से कुछ नहीं आता, क्योंकि STL के पास देने को रंग था ही नहीं।

ग़ैर-आधिकारिक अपवाद जानने लायक़ है: मुट्ठी भर टूल हर STL ट्रायंगल रिकॉर्ड के आख़िर के दो attribute बाइट में पंद्रह-बिट रंग एनकोड करते हैं, दो असंगत रिवाज़ में। वे बाइट यहाँ नहीं पढ़े जाते। किस रिवाज़ का इस्तेमाल हुआ यह बताने का कोई तरीक़ा नहीं, और अंदाज़ा लगाना ग़लत रंग किसी नापी जा रही मेश पर डाल देगा।

अगर गंतव्य कोई slicer या प्रिंट ब्यूरो है, न बदलें — वे STL या 3MF चाहते हैं, और उस दुनिया में PLY का सहारा असमान है। अगर गंतव्य कोई ब्राउज़र व्यूअर है, glTF सही लक्ष्य है, PLY ग़लत।

तब बदलिए जब अगला क़दम कोई एल्गोरिदम हो: दूरी का हिसाब, decimation, remesh, hole fill, आयतन या सतह क्षेत्र, स्कैन डेटा के ख़िलाफ़ alignment। इस क़दम की पूरी क़ीमत वेल्डिंग और टूल की चाही टाइप है, और यह पूरी तरह आपके ब्राउज़र में बिना अपलोड के चलता है।