Texture Suffix

[wilberolive]

I'd like to propose updating the texture suffix convention as follows, which includes:

1. Adding the missing Height/Displacement map. This should actually really by _D (as UE4 calls it Displacement), however that conflicts with the Diffuse/Albedo/Base Color map, which should really be _A (since it is an Albedo map in PBR), but that is already taken too, so _H seems like a good compromise. Unless the Diffuse/Albedo/Base Color map is changed to _BC (since UE4 calls it Base Color).
2. Swapping the Alpha/Opacity and Ambient Occlusion suffix's as the engine refers to Alpha/Opacity simply as Opacity so it makes more sense for it to be _O.

Texture	T_
Texture (Diffuse/Albedo/Base Color)	T_	_D
Texture (Normal)	T_	_N
Texture (Roughness)	T_	_R
Texture (Alpha/Opacity)	T_	_O
Texture (Ambient Occlusion)	T_	_A
Texture (Height/Displacement)	T_	_H
Texture (Bump)	T_	_B
Texture (Emissive)	T_	_E
Texture (Mask)	T_	_M
Texture (Specular)	T_	_S
Texture (Packed)	T_	_*	See notes below about packing.
Texture Cube	TC_
Media Texture	MT_
Render Target	RT_
Cube Render Target	RTC_

[Allar]

1. I would definitely accept a pull request merge for adding this as _H. _D/_A/_BC is definitely something of a hot debate between legacy and newer unreal users, and in this case I'm opting for the legacy. This issue highlights a struggle of this guide, as I did not plan for my style guide to become a de facto standard, but a standard that I use that others can modify. This guide's increased visibility beckons the question of should the guide evolve and be a progressive force, or should it be a reliable fixed data point for others to build on...

2. I feel like referring to alphas as _O is a cardinal sin to me, but I have no real basis for this.

[wilberolive]

1. _H/_D makes sense to me. Just depends what it conflicts with and how to handle that conflict. Sorry that your guide has essentially become the standard. Pretty much everyone refers to it now, but I think it is a great idea to have a global standard. Imagine if every UE4 developer followed this. How much easier it would be for example to grab an asset from the marketplace and drop it into your project.

2. Guess it depends on how you think about it. You are thinking about it as "alpha" where as UE4 thinks about it as "opacity" which makes more sense from a PBR perspective. Surfaces in the real world have an opacity value, not an alpha value.

[nlongchamps]

Hi! Awesome initiative by the way. Congratulations for creating a standard. Thought i would chip in..

1 - Should be _H. The suffix should describe what the texture data represents, not what to do with it. Displacement is not really a texture type but rather a material effect which uses height or vector data to displace pixels or vertices. The scalar texture itself represents height data. Height maps are not always used solely for displacement. Substance also refers to height.

I would tend to use _BC or _C for base color and discourage the use of _D as the term "diffuse" is somewhat obsolete and does not make sense in a PBR context. Diffuse is a lighting term and not a surface property. _A for Albedo is okay but i cant help but think "alpha" when i see A. Channel packing should be considered. The Alpha channel is mostly used for alpha but can be packed with other scalar data: _C - rgb color only _CA - rgba color and alpha/opacity _CR -rgba color + roughness

2 - I would use _O for "Occlusion". I'm not really sure a suffix for Alpha/Opacity is necessary. When would you use a standalone alpha texture instead of putting it in the alpha channel of the associated texture? A standalone alpha to me seems redundant with _M (Mask), which seems more useful as a descriptor. They would essentially represent the same type of data. Could use _A for "Alpha Mask" and keep _M for "Metalness"?

3 - _B Bump? As in Bump Offset or the old surface bump technique? Bump offset uses height data so is redundant with _H. The texture suffix should describe what the data represents, not where/how to use it.

4 - Id like to suggest _V (Vector) and _D (Data) suffixes. Working with shaders and VFX i've often had to generate textures holding vector information (flow maps, vector displacement, directions in tangent space, etc) or random/general purpose "data" (object positions, vertex animation textures, baked rigid bodies, etc).

[zaha]

To throw my opinion in here as well:

• I prefer _BC for albedo/base color map
• I agree with @nlongchamps reasoning for using _H

In general, I don't think it's wise to overforce a single letter to identify the texture type for the sake of brevity. In my experience, clarity always trumps brevity, therefore I personally use AO for ambient occlusion, BC for base color and MT for metallic. With that I know at a glance what kind of texture it is and I do not have to wonder whether M stands for Metallic or Mask.

[lucastucious]

As we overly used texture packing in our game, we use only one letter to identify the nature, but we don't find a way to handle alpha properly.

We use _A, as O is for occlusion.

My last word would be : don't focus on how unreal choose to name it, but on how artist and 3D software name it, because it's what they understand. Industry standard are Substance Painter, and the name are Diffuse (D) Roughness (R), Occlusion(O), Metallic (M), Normal (N). For Opacity, O is already used. So use _A instead

[shaunrandall]

I'd argue that since its a style guide primarily for Unreal naming should help convey for people working on the engine with the UAssets what the point of the texture is.

The question of whether or not it should evolve or remain fixed is definitely the hardest question.

For new options I'd argue matching Unreal and eating an extra character (ex: _AO for ambient occlusion) will help both artists become more familiar working in the engine and performance developers instantly grasp suffixes without having to refer directly to the style guide. TBF I haven't been working with Materials long enough to see it shift in the engine over time if that is a thing.

Just my two cents though as the style guide enforcer on the team,