STL naar GLTF omzetten

Geen browser rendert een STL en geen browser rendert een glTF rechtstreeks — beide hebben een runtime nodig. Wat verschilt, is de kwaliteit van het pad. three.js levert een STL-loader mee, dus het naïeve antwoord is de STL rechtstreeks te serveren, en voor een eenmalig intern hulpmiddel is dat een redelijk antwoord.

Het houdt op redelijk te zijn zodra de pagina publiek is en het model de inhoud is. Een STL is de minst efficiënte manier om een mesh over een verbinding te sturen die er is, hij draagt geen grenzen dus de camera moet ze na het parsen berekenen, en elk driehoekje komt met zijn eigen drie vertices die de GPU al dan niet moet ontdubbelen. glTF is voor precies deze overdracht ontworpen en lost alle drie op.

Een binaire STL is precies 84 + 50n bytes voor n driehoeken, ongeacht de vorm. Vijftig van die bytes zijn twaalf voor een vlaknormaal, zesendertig voor drie volledige vertices, en twee ongebruikt. Er wordt niets gedeeld: een kubus is zesendertig vertex-records voor acht afzonderlijke hoeken.

De omzetting rondt coördinaten af tot zes decimalen om een sleutel te bouwen en laat elke hoek op dezelfde positie samenvallen in één vertex. Op een gesloten oppervlak bedient elke vertex doorgaans vijf of zes driehoeken, dus de vertexdata daalt met ongeveer die factor voordat hij als float32 wordt weggeschreven.

Eén scène, één node, één mesh, één primitive in driehoeksmodus, een float32 VEC3-positieaccessor en een uint32 SCALAR-indexaccessor. Het asset-blok declareert versie 2.0. De buffer wordt ingesloten als base64-data-URI, dus het bestand is op zichzelf staand.

De POSITION-accessor draagt min en max, wat de specificatie vereist en het praktische verschil is tussen een model dat verschijnt en een dat dat niet doet. model-viewer en three.js leiden hun beginnende cameraafstand allebei af uit die zes getallen; een bestand zonder ze geschreven opent uitgezoomd naar niets.

Er wordt geen NORMAL-attribuut geschreven, en de glTF-specificatie draagt viewers op om vlakke vlaknormalen te berekenen wanneer een mesh er geen heeft. Op een organisch model uit een sculptprogramma is dat een gebrek en vragen mensen hoe ze het verhelpen. Op een onderdeel dat als STL uit CAD kwam, is het de waarheid.

Een STL heeft geen gebogen oppervlakken. Hij heeft de driehoeken die de exporter produceerde bij welke koordetolerantie dan ook, en een vloeiend geschaduwde render daarvan is een vleiende leugen over de geometrie die een printer echt zal reproduceren. Wil je de preview vloeiender laten ogen, is de eerlijke oplossing stroomopwaarts.

STL declareert geen eenheid en de techniek- en printwereld leest zijn getallen als millimeters. glTF 2.0 definieert zijn lineaire eenheid als de meter. De omzetting kopieert de coördinaten ongewijzigd over, omdat herschalen met een factor die de bron nooit noemde, gokken zou zijn.

Een beugel van 60 mm wordt dus een beugel van 60 meter in glTF-termen. Niets oogt fout in isolatie, maar het gaat fout zodra het naast iets anders in een scène staat. Zet een uniforme schaal van 0,001 op de node in je viewer, of pas het toe in gltf-transform tijdens de build.

Omdat een STL geen onderdelen, groepen of objecten heeft, bevat de glTF precies één primitive. Dat is het goedkoopste dat te renderen valt, en het betekent dat een uit STL afgeleid model nooit het draw-call-probleem krijgt dat een CAD-export met driehonderd groepen veroorzaakt.

Het heeft ook geen materiaal, geen textuur, geen UV-coördinaten en geen vertexkleuren, omdat een STL daar geen van bevatte. Je viewer past zijn standaard toe, meestal een middengrijs physically-based materiaal. Iets beters toewijzen in three.js is één regel, en de moeite waard.

De .gltf hier ingesloten buffer als base64-data-URI, dus er is geen .bin om ernaast te serveren en geen relatief pad dat kan breken. Base64 kost vier tekens per drie bytes, dus dat gemak is ongeveer 33 procent meer bytes, bovenop mooi opgemaakte JSON.

Voor een bestand dat je gaat inspecteren, diffen of tijdens de build aan gltf-transform voeren, neem je de glTF. Voor het bestand dat de bezoeker daadwerkelijk downloadt, neem je de GLB: dezelfde geometrie, dezelfde grenzen, binaire buffer, één verzoek.

Binaire en ASCII-STL delen een extensie en het bestand zegt niet welke van de twee het is. De gangbare test — controleren of het bestand begint met het woord "solid" — is onbetrouwbaar, want de tachtig-byte header van een binaire STL kan willekeurige tekst bevatten en meerdere schrijvers zetten daar "solid" neer.

De betrouwbare test is rekenkundig: een binaire STL is precies 84 + 50n bytes voor het driehoekaantal in zijn header, en verder niets. Klopt de lengte niet, dan wordt het bestand als tekst gedecodeerd en worden de vertexregels gelezen.

Nergens. Het paar draait als gewone JavaScript in de pagina — geen WebAssembly-engine om te downloaden, geen verzoek dat het model draagt, geen wachtrij. Dat doet er meer toe dan gewoonlijk bij dit paar, want de STL’s die mensen voor een webpreview omzetten, zijn vaak het onderdeel van een klant of een onuitgebracht product.

Het gratis plafond is 100 MB, wat bij vijftig bytes per driehoek een model van twee miljoen driehoeken is. Bestanden van die omvang zijn het waard om vooraf te decimeren in plaats van erna: de glTF wordt evenredig enorm.