With the amount of software and engines out there, there is no True Way to name things, but if you're in games (mainly Unreal Engine), then there is a common way that you should get used to. Start using it now - start getting your peers to use it - and single and group projects should go smoother.
In this post, I will talk to you about naming something in your modeling software for Substance Painter, exporting tips for Painter to UE, and naming conventions for Unreal. I'll be conforming to Unreal Engine's naming conventions, but if there's another system you want to use, then it should be easy to replace the corresponding conventions with what I cover.
The conventions usually used are prefixes as follows:
- T_ for Textures
- SM_ for Static Meshes
- M_ for Materials
- MI_ for Material Instances
There are others, but these are the ones I will talk about.
In The Modeling Software
Okay. You've modeled something in Maya/3DS Max/Blender. In these programs, the model will have a default material. In Maya -> 'lambert', in 3DS Max -> 'Default,' and in Blender -> 'Material.' If you don't change this in the modeling software, the model will be imported with that name into Substance Painter.
This is important because the 'texture set' name influences the name of the exports from Painter. Then you're pulling these textures into Unreal, and at that point, it could get very convoluted. Suddenly you have lambert5_basecolor, lambert6_basecolor, lamber7_basecolor, etc.
You can rename the texture set name in Painter, but if the model needs some tweaking and is reimported into Painter, the texturing progress is hidden.
It's best to rename the material in your chosen modeling software while you're modeling so that it is already established when you move on to the next phase of the pipeline. This rename should also include the prefix 'T_' to indicate that it is a texture slot name!
*Remember, you should export your fbx with the SM_ prefix! It's a static mesh! Correct naming early in the process prevents you from having to rename things later!
In Substance Painter
When exporting from Painter, we usually go for the Unreal Engine 4 (Packed) template.
*Real quick. What's this Unreal Engine 4 SSS template? Do we use it?? No. Not unless you need to use subsurface scattering and have been using subsurface techniques while you texture. 99% of stuff will not use the SSS template.*
While the UE4 (Packed) template is good, it's a bit much.
Looking under Output Templates > Unreal Engine 4 (Packed), you can see how the export names are generated and what channels are used for which maps. When I say 'a bit much,' I am specifically referring to the name slots.
'$mesh_$textureSet_BaseColor(_$colorSpace)(.$udim)', as an example, is the name generator for the base color map.
- '$mesh' points to your mesh name
- '$texture_set' points to the texture_set name
- 'Basecolor' is the map type
- '$colorspace' refers to the color space you're using. (If you've read my color management post and my Painter to Unreal post, this one is familiar.)
- '$udim' refers to the UV tile used. In usual workflows, this will just be 0001, but if you're using udims, the four digits will point to the UV tile for that export.
For my cube, this export name would be SM_Cube_T_Cube_BaseColor_Ulitity - sRGB - Texture.png
WHY would this name need to be so long? It doesn't! We don't need the mesh name because if we're working right, the texture set should have the same name! Or it should be similar! Also, at this point, we don't need to know what color space we're in. If we've set up our project right (see color management post), then the color space of Painter should be close to the color space of Unreal. Too long and it's gross.
Next Step!! Duplicate(x2)the Unreal Engine 4 (Packed) template and rename it. One duplicate should be called UE TextureName and the other UE TextureName UDIMS. (Or name it to whatever is best identifiable to you. Just make sure one is clearly labeled for UDIMS.)
Then change the name generator - be sure to NOT touch the map channel stuff.
 |
| How it should look |
 |
| How it should look for UDIMS |
For ease of use:
(Non Udim)
$textureSet_BaseColor
$textureSet_OcclusionRoughnessMetallic
$textureSet_Normal
$textureSet_Emissive
(Udim)
$textureSet_BaseColor(.$udim)
$textureSet_OcclusionRoughnessMetallic(.$udim)
$textureSet_Normal(.$udim)
$textureSet_Emissive(.$udim)
Now, these will look concise and correct when you're exporting your textures to your ArtSource. T_Cube_basecolor is better than that monstrosity we saw earlier.
You could even condense the OcclusionRoughtnessMetallic to ORM (I would encourage this), but this is fine for now. Once you get used to knowing that:
- Red = Occlusion
- Green = Roughness
- Blue = Metallic
then you can use $textureSet_ORM and $textureSet_ORM(.$udim)
(I didn't memorize that for way too long. Know it now so your texture names can be short!)
File Type
Small note I want to put here. What file types should we be using? Which file type is the best?
Short answer: PNG for anything real-time. Games, demos, prototypes. PNGs all the way. Larger projects (capstones, gamelabs) should also have a smaller resolution. Most things like props could be 512 or 1K at most. Larger pieces and characters are afforded more resolution: 1K-2K. It really depends on the load your project can handle.
Longer answer: Portfolio pieces and other things that don't need to be real-time (renders of assets) can have higher resolution: 4K - 8K if needed. You could also use the Targa file type. Targa is an uncompressed file type. The color info is nice and fresh, but it's a larger file and takes longer to load. If you have virtual textures enabled in UE, UE might also think targas are virtual textures (even when they're not used like that.)
Using a 1K png for in-game and a 4K targa in the portfolio render is totally okay and is probably the way to go.
---
Look at how neat:
In Unreal Engine!
This is more straightforward. There's just a few things to remember here.
1.) Import Settings
You can combine your mesh into one static mesh. If you've separated your texture sets correctly, they'll all come in on separate material element slots. You don't have to, but just know that you have the option to have all the pieces come in as one or separately.
Also! Do Not Create Material upon import! You should be either using a master material that your group has made or making a new material yourself. It's easier to use things when you know how to edit and control them.
Uncheck sRGB on the ORM Maps!
ORM maps import in with the sRGB box checked. WE DO NOT WANT THE BLUE CHECK! NO CHECK! We want each of the RGB channels to be read independently so that they can be used as our Ambient Occlusion, Roughness, and Metallic maps. If an asset's texture looks too shiny or just a bit off, this is the #1 culprit. It's annoying, but it's gotta be done.
Mapping textures in materials
First of all. NAMING CONVENTIONS! All materials should start with 'M_' and all material instances (materials that use the foundation from their parent materials and can be edited with parameters) use 'MI_' as their prefixes.
Here, I am mapping my cube textures in M_Master.
- BaseColor RBG -> base color
- Normal RBG -> Normal
- ORM Red - > Ambient Occlusion
- ORM Green -> Roughness
- ORM Blue -> Metallic
If this were a larger project, I could use stand-in textures here and convert the Texture Sample nodes to parameters. Then, I could create material instances of the master material and just plug in my cube texture into the drop-down in the instance.
Above you can see that I have MI_Cube as an instance of M_Master. Having a master setup allows you to make materials for your assets quickly.
Last thing! Put materials on the meshes!
Assign your material to your static mesh in the static mesh.
Now, when you pull that mesh into your scene, it already has its material!
 |
| ooh so clean! |
Thanks for reading to the bottom of this post. I do hope that this has helped someone out there! If you already knew this, then great! No reason to not be doing it, then!
Kidding! ha.
No comments:
Post a Comment