The Great Unreal Asset Naming Convention Debate

Technical & Engine Help Unreal Engine Help
1

image

It’s been a long time that I’ve wanted to ask about naming conventions with other FX artists that use Unreal, and I’ve finally decided to spend a few minutes discussing here:

The standard that I keep seeing come out of Epic is to use prefixes (p_, m_, mi_, t_), and I’m curious why?
Examples: p_smokebomb, m_smokebomb, mi_smokebomb, t_smokebomb_norm, etc

Given that the content browser has filters, I prefer to be able to have assets sorted based on their subject, then allow the content browser to provide the highlights of the different types (materials, textures, and FX all have different looking icons, although I wish materials instances were different from materials). So, I typically do a suffix, if anything: smokebomb_fx, smokebomb_mat, smokebomb_mi, smokebomb_norm, etc,

What are the thoughts from my fellow vfx artists out there? Now that my team and I are working as an external vendor for several projects, I keep running into different standards, but I’d love to see if there’s a general preference from everyone.

2 Likes
2

The first versions of the Unreal Editor didn’t really have an asset viewer, just separately windowed lists of textures, meshes, sounds. Once they moved over to a unified “asset viewer” they didn’t have an easy way to sort by type, only name, so artists at Epic started adding the prefix. Sorting by type was added eventually, but by that point it had already become a standard practice, plus if I remember correctly you couldn’t have two assets with the same name even if they were different types. Since all of the assets that came with the engine were using that naming scheme, most studios adopted it (or something similar). Over time some have stuck with it out of familiarity, and others don’t either because new people come in whom don’t have that practice ingrained into them, or for no real reason at all.

Personally speaking, I’m terrible with naming schemes. Nearly every project I’ve ever worked on has used a slightly different naming scheme, with and without prefixes, camel case or underscores, etc. At this point I tend to just dump all of my stuff into one big folder with every other file using a different naming scheme and at some point I might do a pass at unifying it only to completely forget what I’d decided on for the next asset I make. It doesn’t help that every project I’ve been on they’ve changed the coding style guidelines too. :stuck_out_tongue:

2 Likes
3

I just use this. Haven’t looked back since

On the topic of suffixes - one fringe case is that it’s very hard to tell the difference between some assets by thumbnail/colour alone - most obvious case being an MI and M. Prefixes are obv immediately visible when reading.

(However, the editor seems to favour an auto suffix of _inst (which is normally truncated in view))

I’m not evangelical about any of this - tbh I agree with a lot of what you wrote, but the Style guide I linked to has basically pushed all this to the back of my mind. It’s very useful and does really help.

5 Likes
4

MatInstances have a different icon, but its very very identical to materials.

I only use ue4 (and used basically all ue-versions), and been using Par_ and I prefer that since its search function can mess up P_ if there is content named lip_xx, ship_xx, any other xxxp_xx

for materials its M_ for masters, MI_ for mat instances, MII for mat instance…instances.
followed by VFX.
In other words: M_VFX_genericname_version_blendingmode_anythingelseNeeded.
something like MI_VFX_GenericFire_01_M_9x9 for a 9x9 masked flipbook.

The only way-off thing I do is with material functions I make myself, which start with Luos_ because… im weird and it helps imprinting my name in whoever uses it their brains :stuck_out_tongue:
But in the end, I try to use whatever my client uses for naming convention (which can be odd af) unless I am brought in early, then I tell them to look at Allar’s convention guide, (but suggest to use SM_ for static meshes)

Random screenshot of my own stuff: (disabled folder view)

2 Likes
5

I use prefixes, not for assetview. I want it to be superclear in all scenarios, like if I get a log dumped on me I want to quickly see what part of smokebomb is offending. If im looking at a changelist I want it to be super clear if I have the emitter, material and texture and not three versions of the texture. Its all about how much info I can get at a glance.

As to the specifics of the prefix, I use whatever the project wants. There is always someone who cares more about these things than I. If I get to decide I use FX_ MAT_ or others that look unique. Having M_ and MI_ defeats the purpose as I can easily mix them up when working fast. This is even more important if you read the names in a bad font, like when doing some total commander editing or if you are merging files in p4.

As long as I dont ever have to read the path or read a name to figure out what it is, Im happy.

1 Like
6

I’ve started to use m_fx and mi_fx for material specific to vfx, they are easier to find in giant projects. especially when you don’t want to constantly rely on click and drag :smiley:

1 Like
7

That makes sense - I definitely use some sort of convention, always, specifically for this purpose as well. Would suffixes still achieve the same visibility for you? Prefixes prevent me from seeing at a glance all of the individual assets pertaining to an effect in whole, which I suppose is the root of my reluctance for them.

@alex.underhill That’s an awesome looking tool - downloading it now - might change my entire philosophy on all of this.

8

@Luos_83 Hey, you’re that guy from the UE4 Marketplace! lol

I have a suffix for mine. _tex, _mat, _matInst, _FX, etc. They’re also in my own special folder that is clearly marked and has more folders.

9

Potentially. I’m just a lot more used to prefixes. I’m hesitant to go with suffixes for similar reasons as you are with prefixes. If I’m looking at a CL with long filenames I’m not going to see the suffix until I change my window or scroll.

But this is all just personal preference and you’ll always have to make a judgement call on where the info is most useful to you.

10

I have a little more time to go into it a bit deeper. (using my own pov)

I think --especially in an environment that has a lot of freelancers-- its extremely important that the project uses the most generic naming conventions used in the engine of choice, that way anybody joining the project on a later date will have a much easier time to find and work with the content that is available. but not only naming conventions matter, folder structure and its naming as well.
Im gonna pick two random projects from two clients I have worked with/am working with.
Also mind you-- especially when it comes to ue4, my ocd can be off the charts.

Project 1: While the team is talented, almost none --especially the artists-- had any experience with UE4 and its folder structure wasnt perfect but managable. I am also in the middle of moving and sorting all the effects into proper named folders but bear with me.

Folder/naming

but when it came to actually naming the files we see something like this:


PS_, Par_, FX_ though after I’m done moving everything I can easily change the naming with Linter which is made by the same person who did the naming convention guide.

Scan your content for potential issues and inconsistent style. Also includes a batch asset rename tool. Enforces ue4.style . https://www.unrealengine.com/marketplace/linter

Its naming convention for materials and textures is near non-existent. and non-consistent.

And this hurts in many ways.
I often need to open i.e. a mesh/skelmesh to find its material to then find the textures used in that material.
It wastes my time and therefore the clients.
Sadly the people handling the code/blueprints are too worried about renaming and replacing the now near thousands of master materials into one master material and use instances properly. So worried that one claims he noticed a performance reduction when moving more stuff over to instances.
That said, when I am tasked to touch one of the levels I tend to properly name the materials, meshes, move everything over to instances where possible etc.
for my own sanity (ocd can be a b…) and eventually for theirs as well.
But sadly I often still need to move within some very strange naming conventions.
Its especially hard when they make content all using WW_ and prefix for an environment named “WW” and later on use the same content for an environment named “Vanisir” for instances. (with Vanisir_ as prefix).
It also happened that people working with code/blueprint pick the wrong file for their work.

This makes it so darn important that we should all advocate to at least try and use the most generic used naming conventions. sure you can deviate from it, but always keep others and their sanity in mind. (and to some extend, the time and money you might be wasting in the long run)

Project 2
First of, I love this team to bits. I enjoy working with them, and I love the game they made.
but when it came to the folder structure… (and I was brought in rather late into the production cycle) has been some of the most confusing ones I have come across.


There are many “Character” folders, some with directly related content, and some… well… I just dont know.
Some are just with meshes, others with textures, and sometimes there are other folders like “world 1” where more characters are stored, sometimes the enemies are characters, and sometimes the characters are enemies.
By now I am too afraid to ask and often needed to use not only quick search, but again had to go from blueprint to character to mat instance, to master mat, to texture to find what I needed.
Not to mention that they started out with trying to use just a few master materials for everything, resulting in a material instance mess filled with more switches than the Philips lightbulb testing facility has.

Just like most clients, they use a lot of made-up naming conventions which in some cases are totally obvious when you are with the project from begin to end, but if you just joined and are asked to clean up shaders, add effects to materials for characters, or improve upon existing effects… its going to get frustrated really fast.
So again I often had to go from blueprint to skelmesh/mesh to mat instance (to mat instance, to mat instance, etc) to master material (and sometimes to texture) because weird prefixes, weird naming conventions, and in addition weird folder structures.

And well… the textures had the same issue, besides being all over the place and more than often had duplicates because of it it was hard to find what I needed.


Again I am wasting a lot of time trying to find the right files, and if I am wasting time, I am wasting my clients money.
Time I rather spend making cool stuff, money they rather spend on more cool stuff instead of trying to find the content I need.
In about a weeks time I will be tasked to optimise and redo almost 1500 of their materials and their instances.
dear god!

Then there is the marketplace!
When you sell on the ue4 marketplace… again: Please use generic naming conventions and try to have a proper folder structure. you arent the only one using the package, in fact your package is probably going to be used alongside a bleepload of others, so if they all use different folder structures and their own naming conventions, for any developer using it it will be getting more and more annoying to go trough the files.

This is just a few of the low poly packs --which arent the worst offenders out there–


(and yes, the Lcave stuff was my doing, and I am ashamed of it)

Granted though, over the course of time you get a better understanding of naming conventions, folder structure, and workflow, and these all greatly affect eachother. when looking back at some of my old content I cannot phantom why I named certain things the way I did, or why my folder structures are such a joke. but at least keeping a generic naming convention and preferable a more standardized folder structure can save a lot of headaches.

My big point here being:
If you are working on a project solo and know that at one point you will add more people, please use generic naming conventions and try to use a folder structure that makes sense. If you and your team start on a project and know you will occasionally hire freelancers or add more members to your team… please use generic naming conventions and again proper folder structures. if you make stuff for the marketplace… well you get the point by now.
For the love of workflow, sanity, time, and money… please use generic naming conventions and folder structures that make sense.

Also, clean up your redirectors please <_<

3 Likes
11

I see it primarily as a way to make programmers happy. They want to have all that stuff sort together in name space. I’ve never seen a programmer willingly open an asset browser in ANY of the engines in which I’ve worked.

Also, a thumbnail alone doesn’t always explain what kind of “thing” an object is. So having the P_ there is a wonderful arm rest for your brain. Let’s be honest, color is a TERRIBLE delineating factor between material and instance.
Your brain is set up to recognize motion, silhouette, color. So color is at the end of that pipeline.

I’m actually quite happy with adding a single letter or pair to the beginning of names, but if you do anything more than one tag in your name…you’re in trouble. Names are going to get crazy.

12

Excellent point. ++1

13

We are starting to use the UE default naming convention, but before we would use Mat_, P_, MatFun_, and T_. For master materials we would put ‘MASTER’ in them and just know anything with ‘Mat_’ is a material instance. All our environment peeps would use M_ for materials, and I personally liked that ours were a different prefix than theirs. If we had leaves for fx, the Mat_ vs M_ would help me more quickly sort what belonged to who. We usually try to add in the name where it was being used, or what creature it was for, since maybe it’s almost an identical material, but maybe _Smoke_Explosion has a different soft particle fade value than _Smoke_Fire. I use all the quick filter options as well to help narrow stuff down.

1 Like
14

Thanks everyone for hopping into this conversation so thoroughly with me. I’ve been debating this with myself for way too long as I’ve been setting up our internal pipelines here at Beyond-FX - picking whatever standard is the most widely used is only going to help, so I really appreciate that prefixes are the clear winner in this group :wink:

Also Linter is a massive winner in my book… I just wish it supported older engine versions, as many of clients haven’t moved into the modern world quite yet…

1 Like
15

My style is prefix_category_description_number_suffix, like:

SM_FX_Rubble_00
M_FX_Rubble_00 (instance or not, haven’t found a reason to specify yet)
T_FX_Rubble_00_BC (basecolor)
T_FX_Rubble_00_N (normal)
T_FX_Rubble_00_ORM (ao-rough-metal)
P_FX_Rubble_Explosion_00
P_FX_Rubble_Drop_00
BP_FX_Rubble_Ceiling_00

And folders go like:

Effects

  • /Blueprints
  • /Materials
  • /Meshes
  • /Particles
  • /Shaders
  • /Textures

And I only make subfolders inside those mentioned above if a project has a significant number of assets that justify that. My master materials go in that folder called shaders and they’re named like MM_FX_Ubershader_DepthTestOff or MM_Standard or MM_Env_TriplanarGrid etc. I call it shaders and set it aside to make it clearer that I don’t want people touching those without my knowledge, since I’m currently the only tech/fx artist on the team.
It makes sense for my brain and I haven’t found much opposition to this method yet!

16

Adding my two pence,
The thing with prefixes is that a list like this:

SM_FX_Rubble_00
M_FX_Rubble_00 (instance or not, haven’t found a reason to specify yet)
T_FX_Rubble_00_BC (basecolor)
T_FX_Rubble_00_N (normal)
T_FX_Rubble_00_ORM (ao-rough-metal)
P_FX_Rubble_Explosion_00
P_FX_Rubble_Drop_00
BP_FX_Rubble_Ceiling_00

In practice due to the prefixes you will rarely see it alphabetically listed like presented above unless the Rubble is encapsulated in its own dedicated folder with no other assets, otherwise the assets Rubble and all its related assets will be scattered among a larger list sorted on prefixes.

You are more likely to see a list using prefixes like this:

SM_FX_Rubble_00
SM_FX_Rock_00
SM_FX_RedRock_00
SM_FX_Debris_00
SM_FX_Dirt_00
SM_FX_StoneWall_00
SM_FX_etc_00

M_FX_Rubble_00 (instance or not, haven’t found a reason to specify yet)
M_FX_Rock_00
M_FX_RedRock_00
M_FX_Debris_00
M_FX_Dirt_00 M_FX_Rubble_00
M_FX_StoneWall_00
M_FX_etc_00

And this pattern is obviously repeated for each type of asset (Materials, Textures, Particles, Static meshes). Preventing an asset (Rubble) consisting of many different type of assets that belong together , from being listed together.

Because there are filters to sort and isolate based on type of assets (material, texture, particle, etc) , but there is no filter to sort assets on their basename (Rubble, RedChair, Dirt, UniqueDirt,…). (Other than the search query). I rather use the alphabetical sorting for the basename than waste it on prefixes, for which filters offer the functionality.

So if you really want to see all containg Rubble together, then you either need to encapsulate in unique folders or use suffixes.

Which is why we tend to veer to suffixes. It keeps assets that belong together nicely lexicographic sorted. Using suffix, the same name base assets will indeed be batched together even when in a directory with other assets.

Example:
Rubble_M
Rubble_P
Rubble_M_Inst
Rubble_SM
Rubble_MX
etc

Otherwise by large we follow the style guide linked by Alex U. earlier in this topic. Which is a really solid great style guide!
Allar/ue4-style-guide

Kind Regards,
Ingmar

1 Like
17

That makes sense! It just so happens that the way I work I share a lot of resources between different effects and assets, most of them are called T_FX_Noise_01 and so on, most textures are sitting on the same folder, same for meshes. So I guess using ‘rubble’ as an example wasn’t such a good idea.