STL in GLTF umwandeln

Ein Konstrukteur im Maschinenbau exportiert aus SolidWorks oder Fusion 360 zunächst STL — das ist der übliche Weg zum Drucker, nicht zum Browser. Sobald dieselbe Baugruppe aber in einem internen Ersatzteilkatalog, einer Dokumentation für den Kundendienst oder einer Angebotsseite drehbar dargestellt werden soll, reicht die STL-Datei nicht mehr: Sie trägt keine Bounding Box, und three.js muss sie erst vollständig einlesen, um überhaupt zu wissen, wie groß das Bauteil ist.

glTF wurde für genau diese Übergabe entworfen. Die Datei bringt ihre eigenen Grenzwerte mit, sodass die Kamera sofort weiß, wo sie hinschauen soll, und sie speichert Eckpunkte einmal statt dreifach — ein Unterschied, der bei einem internen Katalog mit hunderten Baugruppen über die Ladezeit der ganzen Seite entscheidet.

Eine binäre STL-Datei ist exakt 84 plus fünfzig mal die Dreieckszahl Bytes groß, unabhängig von der Form. Fünfzig Bytes je Dreieck bedeuten: zwölf für eine Flächennormale, sechsunddreißig für drei vollständige Eckpunkte, zwei ungenutzt — nichts wird geteilt, ein Würfel besteht aus sechsunddreißig Eckpunkt-Datensätzen für acht tatsächliche Ecken.

Beim Einlesen werden Koordinaten auf sechs Nachkommastellen gerundet und zusammenfallende Ecken zu einem Eckpunkt vereint. Bei einer geschlossenen Fläche wird jeder Punkt im Schnitt von fünf bis sechs Dreiecken geteilt, sodass die geschriebene glTF-Geometrie deutlich unter der Ausgangsgröße bleibt — bei einer geschlossenen Baugruppe fast immer kleiner als die STL, aus der sie stammt.

Eine Szene, ein Knoten, ein Mesh, eine Primitive im Dreiecksmodus: eine float32-VEC3-Positions-Accessor und eine uint32-SCALAR-Index-Accessor. Der Puffer wird als Base64-codierte Data-URI eingebettet, sodass keine separate `.bin`-Datei entsteht und kein relativer Pfad brechen kann, wenn die Datei ins Firmennetz oder auf einen anderen Server verschoben wird.

Die POSITION-Accessor trägt Minimal- und Maximalwert, wie es die Spezifikation verlangt — und genau daran orientieren sich three.js und `<model-viewer>` beim Setzen der Anfangs-Kameraentfernung. Fehlen diese Werte, öffnet sich das Modell hineingezoomt auf nichts, was sich vom eigentlichen Ladefehler kaum unterscheiden lässt.

Es wird kein NORMAL-Attribut geschrieben, und die glTF-Spezifikation weist Viewer an, für ein Mesh ohne Normalen flache Facettennormalen selbst zu berechnen. Bei einem organischen Scan wäre das ein Mangel — bei einer STL aus einer CAD-Konstruktion ist es die korrekte Darstellung.

Eine STL-Datei kennt keine gekrümmte Oberfläche, nur die Dreiecke, die der Exporteur bei einer gewählten Sehnentoleranz erzeugt hat. Eine weichgeschattete Darstellung wäre eine geschönte Lüge über die tatsächliche Geometrie, die im Zweifel auch der Drucker so ausgibt. Wer eine glattere Vorschau will, exportiert die STL mit feinerer Toleranz neu, statt Normalen künstlich zu mitteln.

Im deutschen Maschinenbau wird nach DIN durchgehend in Millimetern konstruiert und bemaßt — genau die Einheit, in der auch jede STL-Datei stillschweigend gelesen wird. glTF 2.0 legt dagegen den Meter als lineare Einheit fest, und die Koordinaten werden beim Umwandeln unverändert übernommen, weil eine geratene Umrechnung falscher wäre als gar keine.

Eine Bohrung mit sechzig Millimetern Durchmesser wird dadurch zu sechzig glTF-Metern. Innerhalb der eigenen Szene fällt das oft nicht auf, weil die Kamera anhand der Bounding Box passend positioniert wird — es fällt auf, sobald das Bauteil neben einer zweiten Baugruppe mit korrekt gesetztem Maßstab steht. Ein einmaliger Skalierungsfaktor von 0,001 auf Node-Ebene, per `gltf-transform` oder direkt im Viewer gesetzt, behebt das dauerhaft.

Weil eine STL-Datei keine Baugruppen, Gruppen oder benannten Teile trägt, enthält das glTF genau eine Primitive — die billigste denkbare Form für einen Renderer, ohne einen einzigen Materialwechsel. Ein aus STL erzeugtes Modell verursacht deshalb nie das Draw-Call-Problem, das ein CAD-Export mit dreihundert einzelnen Gruppen mit sich bringt.

Es fehlt genauso Material, Textur, UV-Koordinaten und Vertex-Farbe, weil eine STL-Datei nichts davon enthielt. Der Viewer setzt seinen eigenen Standard, meist ein mittelgraues PBR-Material. Eine Zeile Code in three.js reicht, um stattdessen ein metallisch wirkendes Material mit Environment-Map zuzuweisen — für ein technisches Bauteil im Katalog lohnt sich das fast immer.

Das hier geschriebene glTF bettet seinen Puffer als Base64-Data-URI ein, wodurch keine `.bin`-Datei mitgeliefert werden muss — auf Kosten von rund einem Drittel mehr Bytes gegenüber der binären Form, dazu kommt eingerückter JSON-Text.

Für eine Datei, die inspiziert, mit einem Diff-Werkzeug verglichen oder im Build-Prozess durch `gltf-transform` geschickt wird, ist das glTF die richtige Wahl, weil sie sich lesen lässt. Für die Datei, die tatsächlich an den Browser des Kunden ausgeliefert wird, ist das GLB die bessere Form — gleiche Geometrie, gleiche Bounding Box, aber binär und in einem einzigen Request.

Binäre und ASCII-STL-Dateien teilen sich dieselbe Endung, und die Datei selbst verrät nicht, welche Variante vorliegt. Der verbreitete Test — ob die Datei mit dem Wort „solid" beginnt — ist unzuverlässig, weil der achtzig Byte lange Kopf einer binären STL-Datei beliebigen Text enthalten darf und mehrere Exportprogramme dort tatsächlich „solid" hineinschreiben.

Verlässlich ist stattdessen die Arithmetik: Eine binäre STL-Datei ist exakt 84 plus fünfzig mal Dreieckszahl Bytes lang, entsprechend der im Kopf angegebenen Zahl. Stimmt die Länge nicht überein, wird die Datei als Text gelesen und ihre Vertex-Zeilen ausgewertet. Beide Wege führen zur selben verschweißten Form, bevor das glTF geschrieben wird.

Ein Ersatzteilkatalog wächst selten um eine einzelne Datei — meist steht am Anfang ein ganzer Ordner mit STL-Exporten aus dem CAD-System, oft mehrere Hundert Bauteile aus verschiedenen Baugruppen. Jede Datei lässt sich einzeln ablegen oder der ganze Ordner auf einmal, und beides wird nacheinander im selben Browser-Tab verarbeitet und am Ende als ein ZIP mit allen glTF-Dateien zurückgegeben.

Für einen Katalog, der wöchentlich neue Zeichnungen aufnimmt, ist das der praktische Weg: keine Warteschlange, kein Konto, keine Begrenzung durch eine Tagesquote — nur die Zeit, die der eigene Rechner für die Menge braucht. Die freie Obergrenze von 100 MB gilt dabei je Datei, nicht für den gesamten Ordner.

Ein Zeichnungssatz für eine Baugruppe besteht im Maschinenbau fast immer aus mehreren einzelnen STL-Dateien, eine je Bauteil, jede mit der eigenen Zeichnungsnummer im Dateinamen. Diese Umwandlung arbeitet Datei für Datei: Jede STL wird zu einem eigenen glTF mit genau einem Mesh, weil die Quelldatei selbst keine Baugruppenstruktur, keine Teileliste und keine Beziehungen zwischen Bauteilen kennt, die sich übertragen ließen.

Für einen Katalog, der die Baugruppe als Ganzes zeigen soll, heißt das: Die einzelnen glTF-Dateien werden im Viewer selbst zu einer Szene zusammengesetzt, nicht in dieser Umwandlung. Die Zeichnungsnummer aus dem ursprünglichen Dateinamen ist dabei die einzige verlässliche Verbindung zurück zur Teileliste, und sie überträgt sich nur, wenn sie beim Umbenennen des glTF beibehalten wird — ein zweites Mal zu vergeben, sobald ein Bauteil ausgetauscht wird, lohnt sich mehr als es zunächst wirkt.

Die Umwandlung läuft als reines JavaScript im Browser-Tab, ohne WebAssembly-Modul zum Nachladen und ohne Anfrage, die die Geometrie überträgt. Für ein Bauteil, das unter einer Geheimhaltungsvereinbarung mit einem Kunden steht — bei einem Zulieferer im Maschinenbau eher die Regel als die Ausnahme —, ist das kein Detail, sondern die Voraussetzung dafür, das Werkzeug überhaupt einsetzen zu dürfen.

Die freie Obergrenze liegt bei 100 MB, bei fünfzig Bytes je Dreieck also rund zwei Millionen Dreiecke. Ein Bauteil oberhalb dieser Größe lohnt sich eher vor der Umwandlung zu reduzieren als danach: Das glTF wird sonst proportional groß, und ein Browser im Kundendienst freut sich über keine dieser beiden Dateiformen.