STL naar GLB omzetten

Drie situaties verklaren bijna deze hele omzetting. Een uploadveld op een advertentie, een documentatieplatform of een contentsysteem dat `.glb` noemt omdat dat is wat zijn viewer-component laadt. Een collega of klant die een onderdeel wil bekijken en geen slicer, geen CAD-pakket en geen zin heeft om iets te installeren. En een augmented-reality- of previewfunctie die om glTF is gebouwd omdat dat de webstandaard is.

In geen van die gevallen bouwt degene die omzet een 3D-toepassing. Ze willen een bestand dat aan de andere kant opent, met de vorm zichtbaar, vanmiddag. Dat is de moeite waard om vast te houden, want de meeste adviezen over glTF zijn geschreven voor mensen die scènes samenstellen en beantwoorden vragen die deze lezer niet heeft.

Een GLB is hetzelfde glTF-document met zijn vertexdata erachter geplakt: een header van twaalf bytes waarvan de eerste vier `glTF` spellen, dan een JSON-blok, dan een binair blok, elk opgevuld tot een grens van vier bytes. Eén bestand, één verzoek, niets ernaast.

Dat doet ertoe tegenover het alternatief op deze site. Een STL naar `.gltf` omzetten geeft ook één bestand, maar het moet de vertexdata als een base64-data-URI in de JSON dragen, wat vier tekens per drie bytes kost — ongeveer drieëndertig procent — met genest opgemaakte JSON erbovenop. De GLB slaat dezelfde bytes rechtstreeks op, dus is hij merkbaar kleiner voor precies dezelfde geometrie. Gaat het bestand ergens naartoe gedownload worden, dan is dit de versie om te sturen.

Een STL heeft geen kleur, geen textuur, geen UV-coördinaten en geen vertexkleuren, en de omzetter schrijft een primitive met een positie-accessor en een index-accessor en geen materiaalverwijzing. Wat op het scherm verschijnt komt volledig uit de standaardwaarden van de viewer.

Daarom kan hetzelfde bestand in de ene viewer als een solide, technisch object ogen en in een andere als een grijze klomp. De oplossing is verlichting, geen omzetting: `<model-viewer>` levert neutrale omgevingsverlichting en een `shadow-intensity`-attribuut, en beide toevoegen verandert het resultaat. In three.js doet een omgevingskaart plus een halve-bol-licht hetzelfde werk. Heeft het onderdeel echt kleur nodig, voeg dan achteraf een materiaal toe aan de glTF met gltf-transform — een kleine wijziging aan een document dat verder compleet is.

Dit is degene waardoor mensen denken dat de omzetting mislukt is. CAD-pakketten en de hele 3D-printwereld werken Z-boven: het bouwplatform is het XY-vlak en hoogte is Z. glTF specificeert Y als boven, en elke viewer volgt dat. Er wordt in de omzetting niets geroteerd, want een rotatie verzinnen zou gissen zijn naar welke conventie de bron volgde.

Een onderdeel geëxporteerd uit Fusion, SolidWorks, FreeCAD of een slicer komt dus negentig graden gekanteld op zijn rug in de viewer aan. Corrigeer het in de scène en niet in het bestand: `<model-viewer>` neemt een `orientation="-90deg 0 0"`-attribuut, en three.js heeft één regel nodig die `object.rotation.x` zet. Dat in de viewer doen houdt de GLB gelijk aan de STL, wat ertoe doet als dezelfde geometrie ook naar een printer gaat.

Geen van beide formaten declareert een eenheid. STL wordt door elke slicer ooit geschreven als millimeters behandeld; glTF wordt zo geschreven alsof één eenheid één meter is. De getallen gaan onaangeraakt over, dus een beugel van 60 mm wordt een object van zestig eenheden, wat een viewer voor meters weergeeft als een beugel van zestig meter, vanaf grote afstand gekaderd.

Deel door 1000 in de scène, en controleer tegen een afmeting die je kunt verifiëren in plaats van op het oog. `<model-viewer>` heeft een `scale`-attribuut; three.js heeft `object.scale.setScalar(0.001)`. Oogt de viewer correct zonder schalen, dan was de STL waarschijnlijk niet in millimeters, wat de moeite waard is om te weten voor hij naar een printer gaat.

Een STL slaat elke driehoek op als drie onafhankelijke vertices zonder enige deling, dus een kubus komt binnen als zesendertig posities waar acht zouden volstaan. De lezer voegt eerst samenvallende vertices samen, vergeleken op zes decimalen, want twee driehoeken die elkaar bij een rand raken zijn het regelmatig oneens in de laatste bit van een float.

Voor een leveringsbestand is dat geen bijzaak. De ongelaste vorm zou vier tot zes keer zoveel vertices in de buffer plaatsen en dus in de download, en het zou ook zachte schaduw breken, want een viewer die normalen middelt heeft gedeelde vertices nodig om over te middelen. Het resultaat is een GLB waarvan de geometrie zowel kleiner is als zich beter gedraagt dan een naïeve herschrijving zou opleveren.

Alles wat in de STL gevonden wordt, wordt geschreven als één mesh met één primitive, want een STL heeft geen groepen om te bewaren. Dat is het goedkoopste model dat mogelijk is voor een renderer — één draw call, geen materiaalwissels — wat de juiste vorm is voor een onderdeel op een productpagina of in een previewvenster.

De primitive gebruikt overal uint32-indices en float32-posities. Smallere indextypes bestaan en zouden op een klein model wat besparen, maar een mesh boven 65.535 vertices heeft dan stilzwijgend een ander type nodig, wat een makkelijk te verprutsen voorwaarde is voor een paar kilobyte. De positie-accessor draagt `min` en `max` zoals de specificatie vereist, wat een viewer in staat stelt het model bij het laden te kaderen in plaats van ingezoomd op niets te openen.

Dit is het stilletjes nuttige geval. Een collega, een klant of een klant moet een onderdeel zien en heeft er geen software voor — een STL sturen betekent uitleggen wat er geïnstalleerd moet worden, en een schermafbeelding sturen betekent dat ze het niet kunnen draaien. Een GLB opent in een browsergebaseerde viewer zonder installatie, en elke huidige telefoon en desktop kan er een renderen via een pagina.

Wat mee te sturen: de echte afmetingen, in een zin, want het bestand draagt ze niet en de viewer toont welke schaal je ook instelt. En een opmerking over oriëntatie als die ertoe doet. Twee regels context maken van een grijs object dat in een viewer zweeft een onderdeel waar iemand op kan reageren.

Meestal aanzienlijk kleiner. De STL is vijftig bytes per driehoek zonder deling; de GLB slaat elke vertex eenmaal op als twaalf bytes en elke index als vier, dus een mesh waarvan de vertices elk door vijf of zes driehoeken gebruikt worden, comprimeert al aanzienlijk in geometrische zin voor er compressie wordt toegepast.

De gratis grens is 100 MB, wat ongeveer twee miljoen STL-driehoeken is. Ruim daarvoor wordt een model al ongemakkelijk om in een browser te laden — een paar honderdduizend driehoeken is een verstandige bovengrens voor iets dat een bezoeker op een telefoon opent. Is de STL dichter dan dat, decimeer dan voor het omzetten; gltf-transform kan ook Draco-compressie op de resulterende GLB toepassen, al kan een Draco-gecomprimeerd bestand op deze site niet worden teruggezet.

Niets. De omzetting is gewoon JavaScript in dit tabblad, zonder WebAssembly-module om te downloaden, geen upload, geen account en geen dagelijkse limiet. Het netwerktabblad tijdens een omzetting is de controle.

Dat is het relevante punt voor een onderdeel dat voor een advertentie of klantbeoordeling wordt voorbereid, want het model is vaak nog onuitgebracht en vaak van iemand anders. Een omzetting die de geometrie nooit verzendt, haalt de vraag helemaal weg in plaats van hem met een privacyverklaring te beantwoorden.