Extending a complex texture naming convention
Recently I've been revisiting the texture naming convention currently in use, and I'm at a bit of a crossroads. While this has barely any impact on the end user (modding/asset extraction aside), it has a huge impact on UX. Currently used naming scheme allows for quick identification while consisting of only three characters. In addition, textures can be imported, processed, and assigned to corresponding materials automatically.
Where it starts to get funky is when the shader allows for a couple of coexisting standards in the same containers. For this case let's say we store RGB data of albedo in R, G, and B channels of the container. This is what [col] contains, and at a glance one knows that right away. But if we store... idk, La*b, or HSV components in R, G, and B channels, using `col` for all of them becomes confusing, since now we can't determine what kind of data that texture holds. It can take multiple tries to set up the shader to correctly decode the supplied container (i.e. not switching colour sampling to HSV format from straight channel sampling), which is just bad UX.
Naturally, naming HSV contents [hsv] would make sense, but it doesn't scale: if you have layered albedo maps (dirt, splat, decals etc.), all of those also have to follow suit. This also doesn't work well with packed data such as PBR drivers. If there are other containers with multiple standards, it quickly gets out of hand.
One of the ideas was to use suffix-prefixing, but it kinda feels unwieldy: [col] would become [r.col], [l.col], or [h.col] for RGB, La*b, and HSV respectively. It is better than [col]→[hsv] in terms of readability. Still, this seems better than coming up with an entire new abbreviation for effectively the same container that stores different formats of data.
Full names aren't an option because of various packing layouts, as well as just obscenely long filenames. They're somewhat fine for offline rendering, when every single texture is stored separately, but for realtime we want to reduce TSU dispatches. Very rarely is a single-channel texture used. Additionally, 16 bit colours are seldom needed, with a good 99% falling into 5658 (gammatic) or 8888 (scalars) packs. Full names then would expand to something like 1001.Jacket_$uv0_MetalnessDiffusespecularAmbientshadowHeight. A yike right there.
Storing various standards in subfolders is the current workaround for heavy materials (~12 containers, 2 shared samplers), but it also hurts the UX, as instead of a one-level list of all related textures the user is now presented with various broken lists. This is arguably worse than suffix-prefixing. This also doesn't work for asset search, as at a glance one can't tell what standard the `col` contains until one clicks on said texture and views its full path.
What would your approach be to this?
The naming convention in use is pretty straightforward:
<SVT/SDIM/UDIM index>.<MaterialName>_<"$UV"uvsetID>_<container>
This expands to, say, a texture for a jacket with albedo data: `Jacket_$uv0_col` (`1001.Jacket_$uv0_col` for SVT). All well and good.
Where it starts to get funky is when the shader allows for a couple of coexisting standards in the same containers. For this case let's say we store RGB data of albedo in R, G, and B channels of the container. This is what [col] contains, and at a glance one knows that right away. But if we store... idk, La*b, or HSV components in R, G, and B channels, using `col` for all of them becomes confusing, since now we can't determine what kind of data that texture holds. It can take multiple tries to set up the shader to correctly decode the supplied container (i.e. not switching colour sampling to HSV format from straight channel sampling), which is just bad UX.
Naturally, naming HSV contents [hsv] would make sense, but it doesn't scale: if you have layered albedo maps (dirt, splat, decals etc.), all of those also have to follow suit. This also doesn't work well with packed data such as PBR drivers. If there are other containers with multiple standards, it quickly gets out of hand.
One of the ideas was to use suffix-prefixing, but it kinda feels unwieldy: [col] would become [r.col], [l.col], or [h.col] for RGB, La*b, and HSV respectively. It is better than [col]→[hsv] in terms of readability. Still, this seems better than coming up with an entire new abbreviation for effectively the same container that stores different formats of data.
Full names aren't an option because of various packing layouts, as well as just obscenely long filenames. They're somewhat fine for offline rendering, when every single texture is stored separately, but for realtime we want to reduce TSU dispatches. Very rarely is a single-channel texture used. Additionally, 16 bit colours are seldom needed, with a good 99% falling into 5658 (gammatic) or 8888 (scalars) packs. Full names then would expand to something like 1001.Jacket_$uv0_MetalnessDiffusespecularAmbientshadowHeight. A yike right there.
Storing various standards in subfolders is the current workaround for heavy materials (~12 containers, 2 shared samplers), but it also hurts the UX, as instead of a one-level list of all related textures the user is now presented with various broken lists. This is arguably worse than suffix-prefixing. This also doesn't work for asset search, as at a glance one can't tell what standard the `col` contains until one clicks on said texture and views its full path.
Three-letter suffixes seem to be the easiest to read, too: _col, _tbn, _mro, _cdc, _dfv, _wdv, and so on. There's no overlap between single letters, and as such, no guesswork: last letter signifies the type of container: v = vectors, c = scalar storage (container), p = packed masks. Two preceding letters are just the abbreviation: wdv expands into wetness distortion vectors, for example, which under various modes samples from RG or AG. Other, more legacy things, fall into abbreviations or short-hands: col = colour, tbn = tangent-bitangent-normal (t-frame normal map). You get the idea.
This doesn't work with single-letter prefixes, as they overlap with various features: D can stand for diffuse, distortion, displacement. M can stand for metalness, some sort of a mask, mixing driver. R can stand for reflectance, roughness, retroreflectance. That's why it was ditched in the first place, plus it can't really account for 4-channel 4-tile packed maps (16 textures in one).
What would your approach be to this?
Replies
This solves your UX problem since you’re not letting users rename things manually (which always allows a lot of error) and you can present the metadata very cleanly.
We actually do use this approach. Partially through Unity's AssetDB, partially through PAF DB. The main issue is that there's no unified DB that'd be easily integrated into every piece of software, unless I'm missing something relatively new. The only way to provide that metadata along with the files between isolated pieces of software is to either append it in the name, or to use some header/footer sections. Keeping those types in the name is a better one, since that type is instantly made known to the user. Can't really offload this to the user's FS either, unfortunately.
Did you consider bitfields, or number codes or even Ascii?
Ill share you some from my 2003 folder here
Icons are maybe not the most stupid idea there is in combination with some letters
- No naming convention is perfect or future proof
- Every naming convention becomes worthless the moment you allow any flexibility
- Nobody should ever name a file manually - especially artists
Variations on this pattern have served me well enough over the last 15-20 years for every asset type I've encountered
<superset>_<description>_<index>_<usage>
if you need further namespacing/classification the file system comes with folders
It's worth noting that you can save a lot of confusion by not packing your textures manually. Packing them at build/ingestion time based on the material that references them or texture-set files that define the packing/compression allows you to use descriptive usage suffices and standardise on your export processes.