The three-layer system

The three-layer system: folders, tags and collections

Updated Aug 10, 2026 · 10 min read

Most STL folder structures fail the same way: they start as a clean tree, then every model that fits two categories forces a judgment call, and within a year the tree is ten levels deep and nobody remembers the rules. The fix is to stop asking folders to do three jobs at once. Folders answer where a file lives, tags answer what it is, and collections answer what it is for. This guide sets up all three layers, with a concrete example and a migration path for a library you already have.

Every organizing scheme for 3D print files eventually runs into the same wall. You build a folder tree, it works for a few hundred models, and then a file arrives that belongs in two places at once. An articulated dragon that came in a Patreon bundle and is also a gift for your nephew: does it go under Creatures, under the creator's name, or under Christmas? Pick one and the other two searches fail forever.

This is not a discipline problem. It is a structural one. A folder tree is a single hierarchy, and a model library has at least three independent axes. The three-layer system separates them so no single layer is asked to carry more than it can.

Why one folder tree is never enough

A folder can only express one relationship: containment. A file is in exactly one folder, and that folder is in exactly one parent. Every question you ask of your library that is not shaped like containment has to be forced through that structure, and the forcing is what produces the ten-level trees.

Look at the questions you actually ask when you sit down to print something:

• "Where did this come from, and do I have the rest of that bundle?" This is a containment question. Folders answer it well.
• "Show me every articulated model I own." This is a property question. It cuts across creators, bundles and dates, and folders answer it badly.
• "What am I printing for the fair next month?" This is a purpose question. It is temporary, it mixes unrelated models, and folders answer it worst of all.

Three questions, three shapes, three layers. Give each one its own tool and none of them has to compromise.

Layer 1: folders give each file one home

The folder layer has exactly one job: every file has one predictable location, and you never have to think about where to put something. That means the folder tree should be shallow, boring, and organized by the one axis that never changes after download.

For almost every library, that axis is origin. Where a model came from is a fact that is true forever. What a model is can be argued about; who published it cannot. A structure that works:

• Library root is one drive or one NAS share. Not five. Everything lives under it.
• One level for source type: Patreon, Thingiverse, Printables, MyMiniFactory, Kickstarter, Purchased, Own designs.
• One level for the creator or the bundle, exactly as it was published. Keep the creator's own naming.
• Stop there. Two levels under the root is enough. If you find yourself wanting a third, that urge is the tag layer asking to exist.

Note what this structure deliberately does not do. It does not sort by subject, by printer, by material, by whether you have printed it, or by project. Those are all real things you want to query, and every one of them belongs in a different layer.

Layer 2: tags say what a model is

Tags carry the properties that cut across folders. A model can hold as many tags as it needs, which is exactly the flexibility folders cannot offer. The risk with tags is the opposite of the folder risk: instead of too much structure, you get a sprawling vocabulary where articulated, articulated-model and flexi all mean the same thing.

Keep the vocabulary small and grouped. Four families cover most libraries:

Two rules keep the vocabulary healthy. Use the singular consistently, and never create a tag that a folder already answers. If everything under the Patreon folder would be tagged patreon, the tag adds nothing and dilutes the rest.

Tagging thousands of models by hand is the step where most systems die, which is why the tag layer is the one worth automating. Meshory generates tags from filename rules and color analysis, and with your own OpenRouter key it can look at each model and write a searchable description of what it actually is, so a file named dragon_v2_final.stl becomes findable as an articulated dragon. You accept or reject what it suggests, and you can add or remove any tag by hand. The details are in collections vs. tags.

Layer 3: collections say what a model is for

The third layer is the one people skip, and it is the one that makes a library feel usable. Collections are hand-built groups tied to intent rather than identity: a print queue, a commission, a gift list, the models going to a maker fair. They are temporary in a way tags are not, and they mix models that have nothing else in common.

The distinction that keeps the two layers from blurring: a tag describes something that is permanently true about a model, and a collection describes something that is currently true about your plans. A dragon is articulated forever. It is in the birthday print queue for three weeks.

• Print queue is the collection almost everyone needs first. What is going on the plate next, in order.
• Per-project collections for a commission, a tabletop campaign, a market stall. Delete them when the project ends.
• Reference collections for the models you keep re-printing: calibration pieces, benchmarks, test prints.

In Meshory a collection can hold individual models or whole folders, and none of it touches the disk: the grouping lives in the index while your files stay exactly where they are.

A worked example

Take a real file: an articulated dragon from a creator's March bundle that you plan to print in resin for a friend's birthday and have already printed once in PLA.

1. 1Folder: Library / Patreon / LoothighCreations / 2026-03-dragons. One location, decided in two seconds, never revisited.
2. 2Tags: dragon, articulated, resin, printed. Four properties, all permanently true, all queryable across every folder in the library.
3. 3Collections: Birthday gifts. Removed once the gift is handed over, without touching the file or its tags.

Now every question resolves in one step. "What came in that March bundle?" is a folder. "Show me every articulated model I can print in resin" is two tags. "What am I printing this month?" is a collection. No single layer had to be twisted to answer a question it was not shaped for.

Migrating a library you already have

If you are starting from ten thousand files across four drives, do not begin by rearranging folders. Reorganizing before deduplicating means moving the same model three or four times, and it is the single most common way these projects stall.

1. 1Index everything where it is. Point a library manager at every location before you move a single file, so you can see the whole picture first. Meshory reads folders in place and never moves, renames or uploads anything.
2. 2Deduplicate first. Years of downloading leave copies that no filename search connects. The duplicate finder groups them by content and geometry so you only file each model once.
3. 3Then flatten the folder layer. Collapse the deep trees down to source and creator. This is a one-time job and it is much smaller after deduplication.
4. 4Tag in bulk, not in one sitting. Let automatic tagging make the first pass, then correct as you browse. Tagging is the only layer that improves gradually without penalty.
5. 5Build collections last, and only for what you are actually printing now. A collection created speculatively is a collection you will never open.

If the pile you are starting from is mostly untouched downloads, the more specific walkthrough is what to do with 1,000+ downloaded STL files. And before you start mass-renaming anything, read naming conventions and version control, because renames done in the wrong order create duplicates rather than order.

Where each layer lives

That last column matters more than it looks. In a folders-only system, renaming a file or reorganizing a directory destroys whatever meaning the old path carried. When the upper two layers live in an index keyed to the file rather than its path, you can rearrange the disk freely and the tags, notes and collections come along. Meshory tracks files through renames and moves for exactly this reason, and its search and filters query all three layers at once. This system is step 2 of the complete guide to organizing an STL library, which covers the deduplication, thumbnail and NAS steps around it.