Automatically tag and organize 3D model library

Automatic tagging and organizing get as far as the facts a file already carries, then stop at what the model is for. A library reads the slicer’s settings out of each G-code file, creates the printer and filament profiles those settings name, turns an indexed folder tree into a collection tree, and recognizes a file whose bytes it already holds. What it will not infer is meaning: that a bracket needs supports, or that a model was a gift.

The dividing line is whether the data exists somewhere already: inside the G-code your slicer wrote, in the folder names the files sit under, or in the bytes themselves. Where it does, a library can read it and fill the field in. Where it does not, someone has to decide, and no parser is going to decide on their behalf. Knowing which side a thing falls on saves you from the two expensive mistakes: hand-tagging fields the parser already filled, and waiting for an automatic categorization that is never going to arrive.

What gets filled in on ingest

Slicers write their settings into the file. PrintStash parses them on upload, so a G-code or BGCODE file arrives carrying the slicer name, printer profile and nozzle, layer height, wall count, infill, supports, material, hotend and bed temperatures, estimated print time, and estimated filament use, depending on which of those the slicer recorded. OrcaSlicer, PrusaSlicer, Bambu Studio, and Cura output all parse, but not to the same depth: Cura keeps most of its settings in an encoded block the parser does not read, so a Cura file arrives with a handful of fields where an Orca file arrives with nearly all of them.

Two side effects of that parse are easy to miss. A filament profile is created from the material the file names, and a printer profile from the machine preset, so Ender-3 V3 SE 0.4 nozzle becomes a profile with the model and nozzle diameter filled in the first time a file mentions it. When the slicer wrote both a total filament cost and a filament weight, the cost per kilogram is inferred from them and stored on the filament profile. Neither is something you asked for, and both mean the dropdowns are already populated when you go looking for them.

The other automatic step is identity. Every file is hashed on the way in, and identical bytes resolve to the entry that already holds them rather than starting a second one. That is what makes a re-download of the same STL under a different name land in the right place, and it is how duplicate detection works later. Finding duplicate STL files goes into what to do with the results.

What structure comes from where the files already are

Most libraries already carry organization in their folder names, and importing them is the cheapest structure you will ever get.

A shared volume points at a local or NAS folder and indexes it in place. In mirror mode the directory tree becomes the collection tree, so props/helmets/mando.stl lands under props, then helmets, with the file left exactly where it was. Single-collection mode drops everything into one collection instead, which is the right choice when the existing tree is accidental download structure rather than a decision anyone made. The shared volume guide covers scan scheduling and what happens when the mount disappears.

ZIP uploads behave the same way. The archive becomes a collection named after it, nested under whatever parent you pick, and folders inside the archive become sub-collections. For the multi-part packs that come off model sites, that alone is usually enough structure.

Which tags still have to be written by hand

Nothing infers tags, whether from filenames, geometry, or the description on the site you downloaded the model from. Tags come from whoever uploaded the file, or from a bulk edit later. An import from a model site does not carry the listing’s description across either, and files indexed from a NAS folder arrive with no tags at all.

This is less of a gap than it sounds, because the useful tags are the ones no parser could produce anyway. needs-supports, calibration, gift, print-in-place, resin-only: each is a judgment about what you will do with the model. Material, layer height, nozzle, and printer are already structured fields, so tagging them again gives you two sources of truth that disagree the moment you reslice. Keep the list short enough to remember the spelling, since print-in-place and print_in_place are two filters and one intention. Collections and tags has more on designing that vocabulary.

Making the parsed fields do the work

Filters are where the automatic half pays off. A library filtered by artifact type, material, slicer, printer model, revision status, print outcome, storage location, or upload date answers most of the questions people reach for tags to answer. Save the combinations you repeat as views, so “PETG parts that printed clean on the 0.6 machine” is a click rather than a query you rebuild each time.

For a library that predates any of this, the retro-fit is mechanical. Let the first scan finish so every file is hashed and parsed. Filter by something the parser knows, such as a material or a slicer, and bulk edit the results, up to 500 models at a time, to set the collection or add a tag to the whole group. Repeat until the filters stop finding coherent groups, then stop. Past that point you are inventing categories rather than recording them, and the next person cannot predict them either.

A large existing archive has its own failure modes, mostly around the first scan. Organizing thousands of STL files is the longer version of that migration.

What to expect after a week

The realistic outcome is a library where structured search works and the tag list is under twenty entries. Models arrive with their settings attached, collections match a tree someone already thought about, and the manual work is a few seconds of tagging when something genuinely needs a label.

The unrealistic outcome, worth naming because people plan for it, is a library that sorts itself semantically: knowing that this is a Voron part and that one is a toy. Nothing here does that, and the tools that promise it are guessing from filenames.

Questions that come up

Can a 3D model library tag and organize itself automatically?

Partly, and the line between the halves is sharp. The organizing half and the physical facts arrive on their own, because the slicer wrote its settings into the file and the folder tree already encodes a hierarchy, both of which a library can read on the way in. Tags describing what a model is for do not arrive at all, since that judgment exists only in your head until you type it. Run a library this way and you end up with a full set of structured fields to filter on, plus a tag list of maybe a dozen entries written once.

Does anything tag models with AI, or from the geometry or the download page?

No. PrintStash reads what the slicer embedded in the file and looks at neither the mesh nor the listing you downloaded the model from, so no tag appears saying that one file is a printer upgrade and another is a costume prop. The closest thing to automatic recognition is content hashing, which establishes that two files are byte identical rather than working out what either one depicts, and finding duplicate 3D models covers where that stops. Where another tool does claim semantic tagging, the input is almost always the filename or the text scraped from a model page, so the tags inherit whatever noise those carry.

Can a library tag models automatically from their filenames?

PrintStash does not, and filenames are a weak signal to build on: bracket_v2_FINAL.stl says nothing reliable about material, purpose, or status, and the conventions vary per person and per download. What does get read automatically is the metadata slicers embed in G-code, which is structured and machine-written rather than inferred. If your filenames genuinely encode a scheme, the practical path is to filter and bulk edit in groups rather than hope for a parser that matches your convention.

If slicer metadata is parsed, do I still need tags?

Yes, but far fewer of them. Parsed fields cover the physical facts: material, nozzle, layer height, temperatures, printer, estimated time and filament. Tags are for the judgments that never appear in a file, like whether a part needs supports, whether it is a gift, or whether it belongs to a calibration routine. A tag that duplicates a parsed field is worse than no tag, because it goes stale the first time you reslice with different settings and nothing updates it.

What happens to my existing folder structure?

You choose. A shared volume in mirror mode turns subfolders into nested collections and leaves every file at its current path, so your slicer keeps opening the same locations it always did. Single-collection mode ignores the tree and puts everything in one place, which suits folders that grew out of downloads rather than intent. Uploading a ZIP behaves like mirror mode for the contents of that archive. Nothing moves or renames your source files.

Can I organize a library that is already thousands of files deep?

Yes, and the order matters. Index first without moving anything, let the initial scan hash and parse everything, and only then decide on structure, because the index usually shows the library is not shaped the way you remember. From there, filter by a parsed field and bulk edit up to 500 models per pass. Test on a representative subfolder before adding the full root: the first scan is the expensive one, and dense meshes are where memory limits show up.

Does any of this need a printer connected?

No. Metadata parsing, profile detection, collections, tags, filters, and saved views all work with no printer configured. A connected printer adds job history, and how much of that history is measured rather than estimated depends on the provider: measured filament use comes from Moonraker only, measured duration also comes from OctoPrint, PrusaLink, and Elegoo Centauri, and Bambu LAN in local mode reports neither. Anything missing falls back to the slicer’s estimate, so this improves cost figures rather than organization.

Sources

• PrintStash user guide for the ingest and metadata loop, shared volumes for mirror versus single-collection mode and scan behavior, and capabilities for the current filter, saved view, and bulk edit limits.
• Slicer coverage and parsed fields follow what OrcaSlicer, PrusaSlicer, Bambu Studio, and Cura write into their output, so the available fields vary with slicer and profile.

If the library is mostly G-code rather than meshes, tracking G-code revisions covers the version side of the same problem, and automatic uploads from OrcaSlicer removes the step where files get into the library at all.