Benennung und Versionen

Namenskonventionen und Versionsverwaltung für 3D-Druckdateien

Von Petros, der Meshory entwickelt · Aktualisiert am 10. Aug. 2026 · 9 Min. Lesezeit

In jeder 3D-Druck-Bibliothek entsteht irgendwann eine Datei mit einem Namen wie dragon_v2_supported_final_FINAL.stl. Das ist ein Witz, den jeder kennt, und zugleich ein echtes Versagen: Der Name ist der einzige Ort, an dem die Versionsinformation steht, also wächst er, bis er nutzlos ist. Dieser Leitfaden zeigt eine Namenskonvention, die lesbar bleibt, wie du Versionen ohne Versionsverwaltungssystem nachverfolgst und wie du eine bestehende Bibliothek umbenennst, ohne dass jede Umbenennung zu einem Duplikat wird.

Dateinamen müssen im 3D-Druck zu viel leisten. Eine einzige Zeichenkette soll sagen, was das Modell ist, welche Variante es ist, ob es Stützen hat, für welchen Drucker es gesliced wurde und wie aktuell es ist. Nichts anderes im Workflow hält irgendetwas davon fest, also landet alles im Namen, und der Name bricht unter dem Gewicht zusammen.

Wie Namen zusammenbrechen

Das Muster ist immer dasselbe. Eine Datei beginnt als dragon.stl. Du exportierst eine Version mit Stützen, also gibt es jetzt dragon_supported.stl. Der Designer veröffentlicht eine Korrektur, daraus wird dragon_v2.stl. Du skalierst sie für einen kleineren Drucker und erhältst dragon_v2_small.stl. Irgendwann dazwischen wird eine Datei als final markiert, dann ändert sich etwas, und final_FINAL ist geboren.

Drei konkrete Dinge sind schiefgelaufen, und sie brauchen unterschiedliche Lösungen:

• Die Reihenfolge geht verloren. Nichts an v2, final und FINAL verrät dir, welche Datei zuletzt kam. Das tut nur das Änderungsdatum der Datei, und das Kopieren zwischen Laufwerken zerstört es.
• Varianten und Versionen sind vermischt. Supported und small sind Varianten, die nebeneinander bestehen; v2 ist eine Version, die v1 ersetzt. Stehen beide in derselben Zeichenkette, kannst du nicht erkennen, welche Dateien Alternativen sind und welche veraltet.
• Nichts transportiert Kontext. Warum es v2 gibt, was an v1 falsch war und welche Datei du tatsächlich erfolgreich gedruckt hast, steht nur in deinem Gedächtnis, und auch dort nur kurz.

Eine Namenskonvention, die Bestand hat

Eine gute Konvention ist kurz, sortiert sich korrekt und muss nie nachträglich angepasst werden. Vier Regeln bringen dich dahin:

1. 1Beginne mit dem Modellnamen, unverändert vom Designer. Er ist deine Verbindung zurück zur Shopseite und zu allen Anleitungen, und er macht die Datei unter dem Namen auffindbar, den auch andere dafür verwenden.
2. 2Nutze ISO-Datumsangaben statt Versionsnummern, wenn du eine Reihenfolge brauchst: dragon_2026-03-14.stl sortiert sich in jedem Dateimanager der Welt korrekt und braucht keine Legende zum Verstehen. Versionsnummern funktionieren nur, wenn du nie den Überblick verlierst, und irgendwann verliert jeder den Überblick.
3. 3Setze Varianten an eine feste Stelle, mit festem Vokabular. Entscheide dich für supported oder unsupported, wähle ein Wort für den Maßstab und verwende sie immer in derselben Reihenfolge. dragon_supported_75pct ist lesbar, dragon_75_sup_fix nicht.
4. 4Schreib nie final, new, latest oder fixed. Jedes dieser Wörter stimmt nur in dem Moment, in dem du es tippst, und wird innerhalb einer Woche zur Lüge.

Konsequent angewendet ergibt das Namen wie wyrm_supported_2026-03-14.stl. Der Name sortiert sich chronologisch, sagt, welche Variante es ist, und ergibt auch in zwei Jahren noch Sinn, und das ist der einzige echte Test.

Versionierung ohne Versionsverwaltungssystem

Bei einem gedruckten Modell willst du dir eigentlich nicht die Abfolge der Änderungen merken. Wichtig ist, welche Datei erfolgreich gedruckt wurde, auf welcher Maschine, mit welchen Einstellungen, und was bei denen schiefging, die es nicht wurden. Das ist eine Notiz, keine Commit-Historie.

Genau hier sollte der Dateiname aufhören zu wachsen und eine eigene Ebene übernehmen. Behalte die erfolgreiche Version unter einem stabilen Namen und halte den Kontext an einer durchsuchbaren Stelle fest: was fehlgeschlagen ist, für welchen Drucker sie gedacht war, für welches Material sie gesliced wurde. Meshory speichert Notizen und Filamentzuordnung pro Modell direkt beim Modell, und Tags wie printed, failed oder needs-supports machen den Status zu etwas, nach dem du die ganze Bibliothek filtern kannst, statt ihn im Dateinamen zu kodieren.

Ehrlich gesagt stößt das hier an eine Grenze: Tags halten fest, dass eine Version gedruckt wurde, nicht mit welchen Einstellungen. Werkzeuge, die genau dafür gebaut sind, gehen weiter als Meshory. GyroidVault führt v1, v2 und final unter einem Modelleintrag mit Druckprotokoll, und PrintStash ordnet jede geslicte Datei ihrem Quellmodell zu und liest die Slicer-Einstellungen daraus aus. Wenn du das hier nur liest, weil du einen erfolgreichen Druck sechs Monate später nachvollziehen willst, fang dort an.

Die grundsätzliche Aufteilung (Ordner für den Ort, Tags für Eigenschaften, Sammlungen für den Zweck) beschreibt das Drei-Ebenen-System. Der Versionsstatus gehört klar in die Tag-Ebene.

Solltest du Git für STL-Dateien nutzen?

Für deine eigenen parametrischen Designs manchmal. Für eine Bibliothek heruntergeladener Modelle nicht. Git speichert eine vollständige Kopie jeder Version jeder Binärdatei, also wächst ein Repository mit ein paar hundert STLs unbegrenzt, und jeder Klon schleppt die gesamte Historie mit. Git kann dir außerdem nicht zeigen, was sich zwischen zwei Versionen eines Meshes geändert hat, und genau darin sollte ein Versionsverwaltungssystem eigentlich gut sein.

Es gibt einen engen Anwendungsfall, in dem es funktioniert: Quelldateien für Designs, die du selbst erstellst, vor allem textbasierte Formate wie OpenSCAD, bei denen Diffs aussagekräftig und Dateien klein sind. Leg die Quellen ruhig in Git ab und behandle die exportierten STLs als Build-Artefakte, die in deiner normalen Bibliothek liegen.

Eine bestehende Bibliothek umbenennen

Umbenennungsprojekte scheitern an dem Punkt, an dem eine neue Konvention auf tausende bestehende Dateien trifft, denn der naheliegende Ansatz erzeugt genau das Problem, das er lösen sollte. Kopierst du eine Datei unter ihren neuen Namen und löschst das Original später, hast du eine Zeit lang beide. Vergisst du eine Löschung, hast du ein dauerhaftes Duplikat, das keine Dateinamensuche je mit seinem Zwilling in Verbindung bringt.

1. 1Zuerst Duplikate bereinigen. Benennst du eine Bibliothek um, die noch Kopien enthält, benennst du dasselbe Modell mehrmals um, und die Kopien verstecken sich hinter neuen Namen. Lass vorher einen Inhalts- und Geometrie-Durchlauf mit einem Duplikat-Finder laufen.
2. 2Direkt umbenennen, nie kopieren und dann löschen. Eine echte Umbenennung ist atomar. Eine Kopie ist eine zweite Datei, die existiert, bis du daran denkst, die erste zu entfernen.
3. 3Benenne mit einem Werkzeug um, das deine Metadaten behält. Hängen Tags, Notizen und Vorschaubilder am Pfad, wirft das Umbenennen alles weg, und du fängst von vorn an.
4. 4Lass Dateien von Designern in Ruhe, wenn du keinen Grund hast. Ihre Namen sind deine Verbindung zur Quelle, und eine persönliche Konvention rechtfertigt selten, diese zu verlieren.

Meshory benennt die echte Datei oder den echten Ordner auf der Festplatte um und aktualisiert im selben Schritt den Bibliothekseintrag, sodass Tags, Notizen, Sammlungen und Vorschaubilder erhalten bleiben, auch wenn du einen Ordner samt Inhalt umbenennst. Namen werden gegen die Regeln jeder Plattform geprüft, mit der deine Bibliothek in Berührung kommt, sodass ein Name, der unter Windows oder auf einer NAS-Freigabe Probleme machen würde, schon beim Tippen abgelehnt wird, statt erst später aufzufallen. Außerdem überschreibt Meshory keine vorhandene Datei stillschweigend, sondern verweigert das. Details findest du unter Dateien und Ordner umbenennen.

Was du statt Umbenennen tun kannst

Vor einer Massenumbenennung lohnt sich die Frage: Was willst du eigentlich beheben? Meist lautet die Antwort, dass du Dinge nicht findest und nicht erkennst, was eine Datei ist. Umbenennen löst beides nur indirekt, und teuer obendrein.

Eine Suche über Namen, Pfade, Tags und Beschreibungen löst das Auffinden, ohne eine einzige Datei anzufassen. Gerenderte Vorschaubilder lösen das Erkennen besser als jeder Dateiname, weil du das Modell siehst statt einer Beschreibung davon. Zusammen nehmen sie den meisten Druck zum Umbenennen weg, und die Namenskonvention wird zu etwas, das du künftig auf neue Dateien anwendest, statt zu einem Projekt, das du auf zehntausend alte loslässt. Das Gesamtsystem, zu dem das gehört, beschreibt der vollständige Leitfaden zum Organisieren einer STL-Bibliothek.