How to Set Up a 3D Asset Library: 8 Steps

Last updated: August 2026

Quick answer: You can set up a 3D asset library without migrating everything, switching version control, or asking artists to learn a new workflow. Define how assets are organised, tagged, previewed and approved on top of the storage you already run, and connect a library layer to it.

The goal is not perfection. It is a library where anyone on the team can find the current approved model in under a minute and hand it to the right person without asking for a fresh export.

TL;DR

• Audit what you have, where it lives and who needs access before you build anything.
• Set one folder structure and one naming convention. Do it before you touch metadata.
• Keep files in place and connect the library to Perforce, Git, Diversion or your cloud drives.
• Add the metadata fields people will use weekly, browser previews for your working formats, and a four-stage approval flow.
• Onboard each group separately. Artists, producers and downstream users need different things from the same library.

Contents

• 1. Audit your current asset mess
• 2. Set folder rules and naming conventions
• 3. Which storage layer should a 3D asset library sit on?
• 4. Do I need to migrate my files first?
• 5. Define the metadata you actually need
• 6. Set up 3D previews for your working formats
• 7. Build a clear approval workflow
• 8. Onboard the team and lock in the process
• Launch checklist
• FAQ

1. Audit your current asset mess

Before you build anything, map the reality. List the formats in use, the storage systems they live in, the teams that touch them and the problems that keep resurfacing.

The same failures show up in almost every studio:

• duplicate exports with no clear version history
• files sitting on personal drives and local folders
• three naming patterns, none of them agreed
• artists, producers and marketers hunting for the same asset in different places
• approvals happening in chat threads nobody can find a month later

That last one is usually the expensive problem. An asset that was approved in a DM is, for practical purposes, not approved at all — the next person to need it will either ask again or guess.

Time the search. Pick five assets your team shipped last quarter and ask someone who did not make them to find the approved final. If that takes more than a minute, you have your first priority, and it is findability rather than storage.

2. Set folder rules and naming conventions

Keep the tree simple enough that an artist joining on Monday understands it by lunchtime. A workable starting point is project, then category, then asset type, status, source files and exports.

For naming, pick one pattern and hold the line:

project_assettype_assetname_version_status

So a hero character rig becomes nova_character_hero_v03_approved.

Resist the urge to encode everything. If people need a cheat sheet to name a file, the convention is too complex and they will quietly stop following it. Two or three segments that everyone actually types beat six that only the technical artist remembers.

If you are still settling the fundamentals here, it is worth reading what 3D asset management involves before you commit to a structure.

3. Which storage layer should a 3D asset library sit on?

The one you already trust. Introducing a library is not a reason to rebuild storage, and a studio that changes habits twice in one quarter usually abandons both changes.

Our view, plainly: if you are shipping in Unreal at any real scale, use Perforce. If your repo workflow is already healthy and your binaries are under control, stay on Git LFS. If you want Perforce-grade versioning and nobody on staff wants to own a server, Diversion is the better trade. Cloud drives are fine as the access layer for finished work and poor as the working layer for source files, and most studios end up running two of these rather than one.

Artstash connects to all of them, which means the choice above is a pipeline decision rather than a library decision.

4. Do I need to migrate my files first?

No, and in most rollouts you should not. Keep the files where they are and connect the library layer to the existing storage.

Leaving files in place buys you four things:

• less risk during rollout, because nothing moves
• no duplicate copies to keep in sync
• faster adoption, because artists stay in the tools they already use
• one searchable surface across storage systems that otherwise never talk to each other

We built Artstash because our own library was the pile. Everything above comes out of that: the reason the product connects to storage rather than replacing it is that we had already lived the version where a migration is the first thing you ask a busy team to do.

A library layer gives you search, preview, tags and permissions without a storage re-architecture. For a studio mid-production, that matters more than having a tidy backend on paper.

5. Define the metadata you actually need

Metadata is the difference between a folder system and a library. Start with the fields the team will fill in every week, not the schema that looks complete in a planning doc and sits empty six weeks later.

Required fields worth setting:

• asset name
• project
• asset type
• owner
• status and approval state
• version
• engine or use case
• file format

Optional fields can cover characters, environment, material set, campaign or lore tags where your studio has a real use for them. Add auto-tag rules wherever they save typing.

Every required field is a small tax on the person uploading. Charge it only where retrieval improves.

6. Set up 3D previews for your working formats

If people have to download a file to know what it is, the library is too slow to win against the old habit of asking in chat.

Artstash renders previews for 58 formats in the browser, including FBX, OBJ, GLTF, .blend and Unreal .uasset files, so most studios can cover their working set without an export step. Whatever tool you use, previews need to answer four questions at a glance: is the shape and scale right, are the textures attached, are there obvious material issues, and is this the correct export for the job.

The payoff shows up downstream. A producer who can see the asset stops pinging the artist, and a marketer who can see the asset stops requesting a render that already exists.

7. Build a clear approval workflow

Assets need a visible path from draft to approved. Four stages is enough:

1. Draft
2. In review
3. Approved
4. Archived

Each stage answers a different question. Is this ready for feedback? Is it safe to use in production? Is it out of date but still worth keeping?

Feedback belongs against the version it refers to. Artstash pins comments to a specific version, so "the hands need work" stays attached to v03 and does not follow the asset around after v04 fixed it. That single detail removes most of the confusion that makes chat-based review expensive.

If your team still approves assets in Slack, move that decision into the library first and worry about the rest of the workflow afterwards.

8. Onboard the team and lock in the process

Adoption is the step that decides whether any of this survives contact with a deadline. A library that makes sense to one technical artist fails the week everyone gets busy.

Show each group what changes for them:

• artists need to know where to upload, how to name files and which fields are required
• producers need to know how to check status and find the latest approved version
• technical directors take on formats, previews and storage connections
• marketers and outsourcers just need search and download rights, without asking for a fresh export

Invite all of them. Artstash puts no cap on users on any plan, so there is no per-seat reason to leave the marketing team outside the system and then handle their requests by hand.

Then write the process down on one page and put it where people already look. If the engine-specific considerations for Unreal or Unity change how your team exports, document that on the same page rather than in a separate doc.

Launch checklist

If those eight are in place, the library is usable. If not, it is still a pile of folders with better branding.

FAQ

Do I need to migrate all my files first?

No. Keep files where they are and add a library layer on top. That cuts rollout risk, avoids duplicate copies, and gets people using the system in days instead of after a migration project.

What is the most important part of the setup?

The naming convention and the metadata schema. If people cannot search their way to the right file quickly, previews and approval flows will not rescue the library.

Which storage system is best for a 3D asset library?

Perforce Helix Core if you are shipping in Unreal at scale, Git LFS if your repo workflow already works and your binaries are modest, Diversion if you want that level of versioning without running a server. Cloud drives such as Google Drive, Dropbox, Box and OneDrive work well as the access layer for approved work and poorly as the working layer for source files.

How detailed should the metadata be?

Keep it tight. Start with the fields that help people find, identify and approve an asset, then add more only when a real retrieval problem justifies the extra typing.

How do I get artists to use it?

Make it faster than the old way. Artists adopt a library when finding the latest file through it beats asking in chat, and they abandon it the first time a required field costs them five minutes.

How long does setup take?

A small studio can complete steps one to four in a week, because nothing moves. Metadata, previews and approval flow usually settle over the following two or three weeks as real assets pass through the system.

Conclusion

A 3D asset library works when it removes friction rather than adding a process layer on top of the one you already have. Get the structure right, leave storage alone, and make search, preview and approval the three things the team can rely on daily.

Once you have that running, the next decision is tooling — and which tool to use depends more on your storage and engine than on any feature grid.