We need implicit default texture assets!

Hi,

I can’t count how many times I’ve ran into issues caused by the fact that Texture Samplers in materials require some sort of default texture assets:

  • Many times, inexperienced artists try to compile their shaders and get the “[SM6] (Node TextureSampleParameter2D) Param2D> Found NULL, requires Texture2D” error. Usually, since they are inexperienced, the will just look around the project and grab any first texture that comes under their hand that matches the selected sampler type. This then creates often confusing and hard to untangle cobwebs of references when they migrate their assets into another project.

  • When using Convert to Virtual Texture batch tool, materials often tend to reference the default texture from the Engine content directory. Convert to Virtual Texture batch tool disregards this, and often just switches even textures in the Engine folder to VT. Since these textures are often used for essential built in editor features, this can lead to corruption of other projects which have virtual texturing disabled, since they all reference the same assets from the Engine directory.

  • Pretty much every 3rd party content creator, even Megascans, need to add bloat to their project in form of placeholder textures to satisfy the requirement for a default texture:

So here’s a wild proposal:
Materials should compile even when the Texture2D asset field is empty. If that is the case, the engine should use implicit, generated placeholder data for the texture based on the sampler type. Just pitch black for most of the sampler types except perhaps Normal sampler types, where it would be the default Z up vector (blue).

It would not even have to be a texture buffer. Literally just a single constant color value. So even if it was generated and stored in the memory on the fly, it would just take couple of bytes of memory at most.

This would save us so many headaches :slight_smile:

+1 here, current implementation demanding 6 garbage textures to keep around (in my material setup with 6 types of different samplers) just to avoid error messages.

Then vote pls! :smiley:

1 Like

As a new Unreal developer (but a senior Unity developer), I can say that I quickly ran into this problem and immediately thought that I was missing something to not have to always set default textures in my materials.
=> In Unity we don’t need to do this: Sampler, depending on their types can have default (color) values.
If you set an sRGB sampler for a diffuse, you can set its default value to white.
If you set a MaskMap, you can set its default value to black.
If you set a normalmap, it already has a flat normalmap value.
Etc.
On top of that, when your default values ​​match the default values ​​of the surface output, the texture sampler is not used when no texture is set.
Ex: when you create a metal map or a smoothing map with black defaults that match the default input value of metal on the surface output.

I really think we have a small but nice optimization for the engine here. It can just improve a lot of things, seriously.

It seems so weird to have to define some (default) textures ourselves, that will not be used later for anything other than to ignore compilation errors, or instead to create errors when these irrelevant default files are missing when the material is used elsewhere… oO

(If only there were some small replacement textures that never change… or better, already defined automatically when creating the Sampler, so that users don’t have to worry about them, and don’t have the chance to create reference problems, every time they create a Sampler…)

I may be wrong, but I also think that the problem here mainly comes from the fact that a material in the UE world, besides being mainly a surface shader, is/maybe also an asset that consumes this shader itself, without explicitly needing to be consumed by a MaterialInstance.
So we can (/should) already define custom textures there, instead of being mainly an abstract model. This is also why these are the default textures that are used for preview in the material editor… (no other solutions for preview)
Because of this, it is almost impossible to work with the preview in the material editor (which is what we want when designing a Surface Shader/Material) without creating unwanted references, if the plan is to reuse this material anywhere. So we have to delete them after editing if we don’t want them… And vice versa when we want to re-edit the material, which is nonsense, kills the workflow and leads to big headaches.

Maybe another good idea to keep the most of the current workflow would be to not throw reference errors (or a way to disable them on the Material itself, like an “abstract/don’t throw reference” errors checkbox), only on materials (while keeping the current behavior on MaterialInstances), and to only include referenced default textures in the build when at least one mesh is used somewhere with that material directly (without using a material instance of that material), or when the user don’t want them and use that checkbox in the material settings.

1 Like