PLY naar 3MF omzetten

Beide formaten krijgen een scan in een slicer, en 3MF doet dat met meer waarheid erbij. Het declareert zijn eenheid in het model-element, dus de slicer valt niet terug op een huisconventie. Het slaat elk hoekpunt één keer op en verwijst ernaar vanuit elke driehoek, waar een STL drie volledige hoekpunten per driehoek herhaalt.

Niets daarvan verandert de print. Wat het verandert, is het aantal manieren waarop de klus tussen scan en plaat mis kan gaan, en bij gescande geometrie — de minst voorspelbare invoer die een slicer ziet — is dat de moeite waard.

De 3MF hier schrijft altijd unit="millimeter". De coördinaten uit de PLY worden ongeschaald doorgegeven, omdat een PLY geen eenheid declareert en er dus niets is om vanuit om te rekenen. De omzetting stelt dus een feit over het bestand vast dat het bestand nooit bevatte.

Voor een structured-light- of laserscan klopt die bewering meestal wel: het apparaat kent zijn eigen optische geometrie en rapporteert in millimeters. Voor een fotogrammetrische reconstructie is het meestal betekenisloos, want die pijplijn herstelt vorm tot op een onbekende schaalfactor. Zet een liniaal of schaalbalk in de opname, of meet een bekend kenmerk en schaal voordat je omzet.

Dit is het paar waar het verlies het zichtbaarst is, omdat kleur per hoekpunt de hele reden is dat scans PLY-bestanden zijn. De lezer haalt de x-, y- en z-eigenschappen uit elk hoekpunt-element en slaat de rest over — rood, groen, blauw, alfa, normalen, betrouwbaarheid, kwaliteit — zodat de stride correct blijft, en gooit ze dan weg.

3MF kan kleur wel volledig bevatten: het heeft een groep basismaterialen, een kleurgroep en een eigenschapsindex per driehoek, en multimaterialprinters gebruiken die. Hier wordt niets geschreven. Is een kleurenprint het doel, gebruik dan de eigen schildertools van je slicer.

Declareert de PLY hoekpunten en geen vlakken, dan stopt de omzetting en zegt dat. Dat is terecht in plaats van beperkend: een slicer heeft een gesloten oppervlak nodig om een binnen en een buiten te berekenen, en een verzameling punten heeft geen van beide.

Reconstructie is de ontbrekende stap en hoort thuis in een tool met een voorbeeldweergave. MeshLab en CloudCompare bieden allebei Poisson en ball-pivoting; de keuze ertussen verandert het resultaat zichtbaar, en precies daarom moet een converter dat niet voor je kiezen.

Er wordt op dit pad niet gelast. De STL- en OBJ-lezers voegen samenvallende hoekpunten samen omdat die formaten routinematig met duplicaten aankomen; de PLY-lezer neemt de hoekpuntarray en de vlakindices over zoals het bestand ze aangeeft, omdat een meshingstap die keuzes al bewust heeft gemaakt.

Het hoekpuntaantal in de 3MF komt dus overeen met het hoekpuntaantal in de PLY-header, en het driehoeksaantal met het vlakaantal. Dat maakt verifiëren makkelijk en betekent ook dat de omzetting niets opruimt.

Een scan heeft gaten waar de scanner geen zicht had: ondersnijdingen, het vlak waarop het object rustte, donkere of spiegelende oppervlakken die niets terugkaatsten. Meestal draagt hij ook eilandjes achtergrondgeometrie mee en, waar meerdere passages zijn samengevoegd, zelfoversnijdingen.

3MF verwacht dat een printbaar object een gesloten manifoldvolume is, en niets in deze omzetting controleert of dwingt dat af. Het bestand opent in je slicer en de slicer vertelt je wat eraan mankeert. Vooraf herstellen — gaten vullen in MeshLab, de inspector van Meshmixer, Blenders 3D-Print Toolbox — is sneller dan door slicerwaarschuwingen heen ploeteren.

De 3MF bevat één object in zijn resourcessectie en één item in zijn buildsectie, geplaatst zonder transformatie. Een PLY heeft één oppervlak en geen manier om iets anders te zeggen, dus er is niets te verdelen en niets te plaatsen.

Er wordt ook geen naam geschreven, dus de slicer toont een naamloos object. Bevat je scan wel meerdere losse schillen — een gescande assemblage, of een opname met nog vastzittende achtergrondfragmenten — dan vindt Split to Parts na import ze op samenhang.

Een ZIP met drie ingangen: [Content_Types].xml dat de extensies .model en .rels koppelt aan hun content-type, _rels/.rels met één relatie die naar het model wijst, en 3D/3dmodel.model met de geometrie in de 3MF-kernnaamruimte. Die structuur maakt het een OPC-pakket in plaats van een ZIP met een XML-bestand erin.

Het is een modelbestand, geen project. Geen afdrukprofiel, geen filamenttoewijzing, geen platteindeling, geen thumbnail en geen instellingen per object, want dat zijn slicerspecifieke uitbreidingen in plaats van geometrie.

De volgorde die tijd bespaart: mesh de puntenwolk, verwijder de achtergrondeilandjes, vul de gaten, decimeer tot iets dat een slicer aankan, schaal tegen een bekende afmeting, en zet pas dan om. Elk van die stappen is een scanprobleem eerder dan een formaatprobleem, en elk is makkelijker in MeshLab of je scannersoftware dan in een slicer.

De omzetting zelf draait volledig in je browser — geen engine om te downloaden, niets geüpload, een plafond van 100 MB — wat telt wanneer de scan van een persoon is, van een klantobject, of van een onderdeel dat iemand liever niet publiceert.