STL in GLB umwandeln

Der Slicer exportiert STL, aber der Shop will ein GLB. Wer gedruckte Ersatzteile, Modellbauteile oder Deko-Objekte selbst verkauft — über einen eigenen Shopware- oder WooCommerce-Shop, über Etsy oder über eine Anzeige mit 3D-Vorschau — stößt an genau dieser Stelle an: Das Uploadfeld für die Produktvorschau nennt „glb" und lehnt „stl" ab, weil kein gängiges Vorschau-Widget im Browser eine STL-Datei direkt lädt.

Ein GLB ist die Antwort, weil es Geometrie und Puffer in einer einzigen Datei bündelt. Keine zweite Datei, kein relativer Pfad, der beim Hochladen bricht — genau das, was ein CMS-Uploadfeld erwartet und was eine STL-Datei von sich aus nicht liefert.

Diese Umwandlung überträgt ausschließlich Geometrie: die Positionen der Eckpunkte und die Dreiecke, die sie verbinden. Farbe, Material, Textur, Normalen, Szenengraph — nichts davon ist in einer STL-Datei vorhanden, also kann auch nichts davon in das GLB geschrieben werden. Das GLB enthält am Ende ein einziges Mesh mit einer einzigen Primitive und keiner Materialreferenz.

Was im Vorschau-Widget zu sehen ist, entscheidet also allein dessen eigene Beleuchtung. Ein grauer Klotz ist kein Fehler der Umwandlung, sondern der ehrliche Ausgangszustand — wer ein Produktfoto-Feeling will, braucht Umgebungslicht und einen Schatten im Viewer, nicht eine andere Konvertereinstellung.

Eine STL-Datei speichert jedes Dreieck mit drei eigenständigen Eckpunkten, ganz ohne gemeinsame Nutzung — ein Würfel kommt so mit sechsunddreißig Positionswerten statt der acht, die er eigentlich braucht. Beim Einlesen werden zusammenfallende Punkte auf sechs Nachkommastellen genau erkannt und zu einem gemeinsamen Eckpunkt zusammengeführt, bevor irgendetwas geschrieben wird.

Für eine Datei, die tatsächlich hochgeladen und von einem Kunden geladen wird, ist das kein Nebeneffekt, sondern der Punkt der ganzen Übung: Ein Mesh mit geteilten Kanten braucht vier- bis sechsmal weniger Speicher als die unverschweißte Rohform, und nur geteilte Eckpunkte lassen sich für eine weiche Schattierung überhaupt mitteln.

Slicer und CAD-Programme rechnen Z-up: Die Druckplatte ist die XY-Ebene, die Höhe zeigt nach Z. glTF und damit auch GLB legen Y als „oben" fest, und jeder Web-Viewer folgt dieser Konvention. Die Umwandlung dreht nichts, weil eine geratene Drehung schlimmer wäre als gar keine — welche Konvention die Quelldatei tatsächlich verwendet hat, lässt sich aus den reinen Koordinaten nicht ableiten.

Ein aus Fusion 360, SolidWorks oder einem Slicer exportiertes Bauteil liegt deshalb im Viewer auf der Seite. Das ist kein Fehler in der GLB-Datei, sondern eine Einstellung im Viewer: `<model-viewer>` nimmt ein `orientation`-Attribut mit minus neunzig Grad auf der X-Achse, three.js braucht dieselbe Drehung als eine Zeile Code.

Keines der beiden Formate legt eine Maßeinheit fest, aber die Praxis hat sich eindeutig auseinanderentwickelt: STL wird in der 3D-Druck-Welt durchgehend als Millimeter gelesen, glTF ist dagegen so definiert, dass eine Einheit einem Meter entspricht. Die Zahlen laufen unverändert durch die Umwandlung, ein Bauteil mit sechzig Millimeter Kantenlänge wird also zu einem sechzig Meter großen Objekt, sobald der Viewer es nach seiner eigenen Konvention interpretiert.

Auf einer Produktseite fällt das sofort auf: Das Objekt füllt den Rahmen entweder komplett aus oder ist als winziger Punkt kaum zu erkennen. Der `scale`-Wert von `<model-viewer>` oder ein `object.scale.setScalar(0.001)` in three.js korrigiert das im Viewer, ohne die Datei selbst anzufassen — was auch praktisch ist, wenn dieselbe Geometrie parallel noch an einen Drucker geht.

Ein glTF-Dokument speichert seinen Vertex-Puffer als Base64-codierte Data-URI direkt in der JSON-Datei, und Base64 kostet gegenüber den rohen Bytes rund ein Drittel mehr Platz, dazu kommt eingerückter JSON-Text obendrauf. Ein GLB verpackt dieselben Bytes stattdessen direkt binär in einen eigenen Chunk hinter dem JSON-Kopf.

Für ein internes Prüfwerkzeug oder eine Pipeline mit `gltf-transform` ist das glTF-Format praktischer, weil man es einfach in einem Editor lesen kann. Für die Datei, die tatsächlich an einen Kunden oder in ein Shop-System geht, ist das GLB die richtige Wahl — kleiner, ein einziger Request, kein Sidecar, der beim Verschieben verloren geht.

Weil eine STL-Datei keine Gruppen oder benannten Teile kennt, wird die gesamte Geometrie als ein einziges Mesh mit einer einzigen Primitive geschrieben — das billigste, was ein Renderer darstellen kann, ohne einen einzigen Materialwechsel. Für ein Bauteil auf einer Produktseite ist das genau die richtige Form.

Indizes werden durchgehend als uint32 geschrieben, Positionen als float32. Der Positions-Accessor trägt außerdem die von der Spezifikation geforderten Minimal- und Maximalwerte, ohne die kein Viewer die Kamera sinnvoll auf das Modell ausrichten kann — eine Datei ohne diese Werte öffnet sich hineingezoomt auf nichts.

Eine STL-Datei kostet fünfzig Bytes pro Dreieck, unabhängig davon, wie oft ein Eckpunkt tatsächlich gebraucht wird. Ein GLB speichert jeden Punkt einmal mit zwölf Bytes und jeden Index mit vier — bei einem geschlossenen Mesh, dessen Punkte im Schnitt von fünf oder sechs Dreiecken geteilt werden, liegt das Ergebnis spürbar unter der Ausgangsgröße.

Die freie Obergrenze liegt bei 100 MB, was in etwa zwei Millionen STL-Dreiecken entspricht. Ein Bauteil, das eine Kundin oder ein Kunde auf dem Handy in einer Produktseite dreht, sollte weit darunterbleiben — ein paar hunderttausend Dreiecke sind eine vernünftige Obergrenze, alles Feinere gehört vorher reduziert, nicht erst nach dem Hochladen.

Ein GLB ohne eigenes Material ist kein halbfertiges Produkt, sondern eine bewusst leere Fläche für den Viewer. `<model-viewer>` bringt eine neutrale Umgebungsbeleuchtung und ein `shadow-intensity`-Attribut mit, und beides zusammen macht aus dem grauen Rohling ein Objekt, das plastisch wirkt — zwei Attribute, kein zweiter Konvertierungsschritt.

Wer dem Bauteil eine tatsächliche Farbe geben will, fügt sie nachträglich mit einem Werkzeug wie `gltf-transform` in das fertige GLB ein. Das ist eine kleine Ergänzung an einer bereits vollständigen Datei, kein Neuanfang — die Geometrie, die hier entsteht, bleibt dabei unverändert.

Viele Etsy-Anzeigen und Shop-Einträge zeigen ein Objekt, das eigentlich aus mehreren gedruckten Teilen besteht — ein Deckel und ein Unterteil, ein Sockel und eine Figur. Jedes dieser Teile liegt üblicherweise als eigene STL-Datei vor, und diese Umwandlung verarbeitet jede für sich: Es entsteht ein GLB pro Datei, mit je einem verschweißten Mesh, weil eine STL-Datei selbst keine Beziehung zwischen mehreren Teilen kennt, die sich übertragen ließe.

Für die Produktvorschau bedeutet das meist, entweder das auffälligste Einzelteil zu zeigen oder die Teile im Viewer selbst zu einer Szene zusammenzusetzen — mit Werkzeugen wie `gltf-transform merge`, die mehrere GLB-Dateien zu einer einzigen kombinieren. Die Umwandlung selbst trifft diese Entscheidung nicht, weil das genauso gut die falsche Wahl treffen könnte wie die richtige.

Die Umwandlung läuft als reines JavaScript im Tab: kein WebAssembly-Modul zum Nachladen, kein Upload, kein Konto, keine Warteschlange. Wer das prüfen will, öffnet den Netzwerk-Tab während der Umwandlung und sieht keine Anfrage, die die Datei enthält.

Für ein Bauteil, das noch nicht im Shop steht — ein Prototyp, ein Kundenauftrag unter NDA, ein Design, das erst am Wochenende online geht — ist das der eigentliche Punkt. Eine Umwandlung, die die Geometrie nie überträgt, macht die Frage nach dem Serverstandort überflüssig, statt sie in einer Datenschutzerklärung zu beantworten.