[UE5] Asset Management Basics: Folder Structure and Naming Convention Best Practices

Once you have hundreds or thousands of assets, time evaporates just hunting for "that texture — where did I put it?"

An asset is any material or data your project uses: models, images, sounds, Blueprints. A single treasure chest, for example, uses a model for its shape and materials for its surface. Put things you edit together near each other, and make the name reveal the type, and you spend less time searching.

This article organizes how to decide findable folders and names, and the reference relationships to check when you move things. At the end, you move one of your own materials to a new location and confirm it still looks the same.

What You'll Learn

• Why a feature-based folder structure is recommended, with an example layout
• The prefix naming convention using BP_, SM_, T_ and friends
• Redirectors and the Reference Viewer, the safety nets when moving assets
• How hard and soft references differ in when loading happens
• Hands-on: a full sequence for relocating scattered assets without breaking them

---

Project structure fundamentals

Your own assets live mainly under the Content folder. Start by deciding placement on one question: "what do I open together when I want to fix this?"

Split by feature

There are broadly two schools of asset organization.

1. Split by type: group into Materials (surface appearance), Meshes (3D models), Textures (images).
2. Split by subject or feature: group assets used together, such as Characters/Knight or UI/Inventory.

If fixing the knight means bouncing between several type folders, gathering its dedicated assets into Content/MyGame/Characters/Knight/ makes them easier to find. As the count grows, splitting into Meshes and Textures inside that folder is fine. Put anything shared across multiple characters in a common folder rather than copying it per character.

An example layout and three promises

/Content
├── /MyGame          ← every project-specific asset lives under here
│   ├── /Characters
│   ├── /Environments
│   ├── /Weapons
│   ├── /UI
│   └── /Maps        ← level files only
├── /VendorPack      ← example of keeping a third-party pack's shipped folder
└── /Developers      ← personal sandbox (covered below)

• Carve out one root folder named after the project: putting all your own assets under /Content/MyGame/ prevents mixing with third-party assets and lets you manage paths in bulk for future migration or distribution
• Keep third-party and your own assets apart: do not mix your assets into a pack's folder. Some packs have update procedures or fixed paths, so there is no need to relocate everything just for visual consistency.
• Only create the hierarchy you need: you can start with MyGame/Maps plus a folder for the feature you are building now. Rather than pre-creating a pile of empty categories, split where things accumulate.

---

Sticking to naming conventions

If the folder structure is the address, the name is the label telling you what is inside. Adding a prefix for the type at the front makes the purpose easy to judge before you open it. Below are commonly used examples; if the project you are joining has its own rules, follow those.

The basic shape is [prefix]_[subject]_[detail]_[index] (for example SM_Door_Wooden_Old_02).

Asset type	Prefix	Example
Blueprint Class	BP_	BP_PlayerCharacter
Material	M_	M_Ground_Moss
Material Instance	MI_	MI_Ground_Moss_Dry
Texture	T_	T_Ground_Moss_D (_D = color, _N = normal)
Static Mesh	SM_	SM_Tree_Oak_01
Skeletal Mesh	SK_	SK_Player_Base
Animation Blueprint	ABP_	ABP_Player
Animation Sequence	A_	A_Player_Run
Level (map)	L_	L_MainMenu
Widget Blueprint	WBP_	WBP_HealthBar

A prefix is the marker at the front of the name. SM_ says Static Mesh, BP_ says Blueprint Class, so you can guess before opening. Add the detail and index only when you need to tell things apart.

Searching SM_ in the content browser narrows to names containing that string. But renaming does not change an asset's type. When you need to filter by type reliably, use the type filter such as "Static Mesh."

Two more rules alongside it.

• No spaces, no non-ASCII characters: separate words with underscores or camel case (BP_PlayerCharacter). This prevents accidents with characters that are invalid in paths
• Keep capitalization consistent: once you settle on SM_Door, write it the same way in docs and code. Case handling in file names varies by environment, so reducing variation makes verification easier.

---

Three tools that keep assets from breaking

Three standard UE tools show up in everyday organizing. Get familiar with them.

Redirectors: the forwarding note left behind after a move

Move or rename an asset inside the content browser and UE leaves an invisible file called a Redirector at the old location. It works like a postal forwarding request, guiding assets that reference the old path to the new one.

A reference here is a connection where one asset designates and uses another. Once you have finished reorganizing, run "Fix Up Redirectors in Folder" on the original folder and the referencers are updated and saved. Redirectors that were fully updated become unnecessary and are removed. If some remain, check the messages for assets that could not be saved. Deleting a redirector by hand can lose a forwarding target that is still in use.

Reference Viewer: see who uses it before you delete it

Right-click an asset and open "Reference Viewer" to inspect reference relationships centered on your selection. Select a treasure chest's material, for example, and the left shows the models that use that material while the right shows the images that material uses. A material decides surface color and feel, and it may use images as its ingredients.

The diagram is a tidied-up view of the relationship. The arrow means "the asset on the left uses the one on the right," not the order of operations at runtime.

When you are asking "what breaks if I delete this image," trace toward the users. Reference type and depth shown depend on the filters, so an empty display alone does not prove something is unused.

When you want to fix dozens at once

Once a relocation or rename hits a hundred assets, doing it by hand stops working. UE lets you build your own editor tools entirely in Blueprint and run them over the selected assets or Actors (→ Building tools with Editor Utility Widgets).

Migrate: safely exporting to another project

To take an asset to a different project, use "Asset Actions → Migrate." The list shows the asset you selected plus the dependent assets needed for it to behave and look correct. Review the list and specify the destination project's Content folder. Removing needed images from the list means the look cannot be reproduced on the other side.

If an asset with the same name exists at the destination, you get an overwrite confirmation. Decide which to keep before overwriting. Plugins and C++ code will not necessarily come along with this operation, so open and verify on the destination too. Migrating only what you need out of a test project is also covered in the Fab article.

---

Asset management on a team

With multiple people, the rules matter even more. Source control (Git LFS or Perforce) is a prerequisite. For a concrete procedure managing a UE project with Git LFS, see Project management with Git LFS; for getting Git started right after project creation, see the initial settings article.

• Do not edit the same asset simultaneously: UE assets are binary files whose changes cannot be merged automatically the way text can. Divide ownership and share what is being edited using whatever your setup provides, such as Perforce checkout or Git LFS locks. Committing in Git does not stop anyone else from editing.
• The Developers folder is for experiments: do not let production assets reference prototypes in this folder. Move anything you adopt to a proper location and verify it there. If you also want to keep experiments safe, record them in history according to your team's policy.
• Share moves as one unit: record the moved files together with the files whose references were updated and saved, as a single change. For folders someone else is editing, sync up on a stopping point before moving anything.

---

Hard references and soft references

The last piece of asset management is how Blueprint and C++ reference assets. This is what drives memory usage and load time.

Loading means reading saved data into memory so it can be used at runtime. How you hold a reference changes when that loading becomes necessary.

• Hard reference: loading the referencer makes its target necessary too. This is the basic way to bind things used at the same time, like a chest's model and the material on its surface.
• Soft reference: it holds the asset's location, and loading happens in a separate step. Think of loading a gallery's large images when the page opens.

The "always used / occasionally used" split in the diagram is a rule of thumb. What matters is which referencer being loaded makes what else necessary. A hard reference does not mean everything loads at game startup.

Switching to a soft reference does not make the image appear on its own. You request a load, and use it for display once it completes. Waiting for that load while other work continues is called asynchronous loading. A hands-on exercise using Blueprint's Soft Object Reference and Async Load Asset is covered in the async loading and soft references article. For now, there is no need to replace every reference just for tidiness.

---

Hands-On: safely relocating scattered assets

Here we move one of your own materials that a level is using. For example, take NewMaterial assigned to a floor and file it under MyGame/Environments/Floor. If you do not have many assets yet, a test project where you can run the same steps is fine. Commit or back up the pre-move state before you begin.

If you have not made a material yet, create one that applies a color in Material Basics and try with that. There is no need to use an entire content pack for your first practice run.

1. Check where it is used: open the target material in the Reference Viewer and see which models and levels use it. Open that level and check the current appearance too.
2. Create the destination and move it: create MyGame/Environments/Floor in the content browser. Drag the asset into that folder and choose "Move Here." "Copy Here" duplicates instead, so we do not use it.
3. Rename at the same time: change NewMaterial to M_Floor_Stone. Using the prefix table, fix the name so it tells you what the asset is
4. Update references and save: run "Fix Up Redirectors in Folder" on the source folder and save the changes. If any save-failure message appears, deal with that asset first.
5. Confirm it looks the same: reopen the level that uses it and check the floor's color and pattern against before the move. Also check that the material slot now points to the asset's new location.
6. Record the change: if you use source control, commit the move, the rename, and the files whose references were updated together.

If reopening the level shows the same appearance and the slot points to the new location, the move is done. If the appearance changed, check which material or image assignment came loose. A broken reference does not always show up as a specific color. If the Output Log lists a missing file name, cross-reference it against where things are saved (→ Reading the Output Log).

There are two key points.

• Pair the move with a check: move inside the editor, update references and save, then reopen the level that uses it.
• Relocate in small batches: rather than doing everything in one night, splitting it as "today, just the UI folder" makes it far easier to isolate a problem when one appears

Bonus: Good to Know Up Front

Common mistake	What happens	What to do instead
Moving or renaming assets in Explorer	References break and Fix Up Redirectors cannot fix them	Always work inside the content browser
Names that don't reveal type or purpose	Hard to judge the contents without opening it	Add a prefix such as T_ plus a name that states the purpose
Mixing your assets into a third-party pack's folder	Hard to tell what to update or delete	Keep your work under MyGame and handle the pack's layout as shipped

If the appearance does not come back, stop making further moves or deletions and compare against the pre-move state. If the original file is gone, restoring from history or backup may be necessary. Fix Up tidies up remaining forwarding information; it is not a feature for restoring a lost asset itself.

Summary: an asset management checklist

Check	How often
Are assets you edit together gathered somewhere findable?	When adding a feature
Does every asset carry the correct prefix?	Every time you create an asset
Did you run Fix Up Redirectors after moving or renaming?	Every time, before committing
Do large assets need their load timing reconsidered?	When load time or memory becomes a problem
Are any production assets still in the Developers folder?	At each milestone

Rather than building a perfect taxonomy up front, pick one asset you are using right now and make yourself able to explain its name, its location, and who uses it. Even as assets multiply, you can keep organizing one unit at a time.

Next, confirm content browser operations in Editor UI Basics, then pick up the ability to investigate when things do not work in Debugging with Print String.

How many assets are sitting "at no fixed address" directly under your project's Content right now? Decide on just one destination folder and start moving.

Further Reading

Epic's official docs cover each mechanism: Reference Viewer, Redirectors, Migrating Assets, and Referencing Assets.