A library is a collection organised so that finding an existing asset is faster than making a new one. Below that bar it is a folder.
What makes it findable
- Consistent naming, so search works.
- Tags — category, style, material, theme. More useful than folders, because an asset belongs to several categories at once.
- Thumbnails. Nobody browses a list of filenames.
- Metadata — polygon count, texture resolution, whether it is rigged, what it was made for.
Consistency is what makes it usable
A library where assets share texel density, naming, scale conventions and material setup can be combined freely. One where each asset was made to its own standard requires inspection before every use, which removes most of the value.
That argues for a defined intake standard: anything entering the library meets the conventions, or it does not enter.
Versioning
Assets improve. A library needs a way to update an asset without breaking projects that use the old one — versioning, or at minimum a clear policy about whether updates are in place.
Licensing metadata
For anything acquired rather than made, the licence has to travel with the asset. An asset in a library with no recorded licence is an asset nobody can safely ship, and that discovery usually happens late.
Generated assets in a library
The temptation is to generate rather than search, because generating is fast. That produces libraries full of near-duplicates and a project with forty similar crates that share nothing.
Two habits help: search before generating, and treat the library as the default source with generation as the fallback. Recording the generation inputs alongside the asset also means a near-match can be varied rather than regenerated from nothing.