Backend

Backend selects how a source file is materialized: as a visible UMaterial node graph, or as a thin material instance over a hidden base material.

Shader(Name = "<asset-path>")
{
    Settings [=] {
        Backend = { "Graph" | "ThinCustom" | "Instance" };
    }
}

The value is matched case-insensitively after trimming and quote-stripping; quotes are optional. Backend is a special key and never reaches the reflection resolver. Its current form arrived in since 1.5.0.

Accepted values

Precedence

An explicit Backend always wins over the project setting, which is documented on Project Settings.

Backend is resolved before any material object exists and before the rest of Settings is validated, so an unrecognized value fails the compile first and no other settings diagnostic is reported for that file.

What each backend produces

Graph

ThinCustom — the default

UDreamShaderMaterialInstance overrides two engine behaviours:

Both backends log a warning when in-memory generation is shadowed by an already-saved asset:

In-memory material mode: '{Asset}' already exists as a saved asset, which shadows in-memory
regeneration. Delete the saved asset to make it fully in-memory.

See In-memory Materials.

Changing the project default

Changing Default Compiler Backend while the editor is running regenerates every source file in memory and logs DreamShader default compiler backend changed; regenerating all source files in memory. If persisted generated assets exist, a notification points at the cleanup action:

{Count} previously generated asset(s) are still saved on disk and shadow the in-memory materials.
Run Tools > DreamShader > Clean Persisted Generated Assets to remove them.

Notes

• The backend does not change the language surface. Both build a real node graph and accept the identical feature set; they differ only in which object carries the graph and which object is addressable.
• Under ThinCustom, reading BlendMode or the shading model off the generated instance shows the value inherited from the hidden base — that is where the settings were written.
• Neither backend writes a .uasset during ordinary editor work. Assets reach disk at cook time, through the commandlet, or through an explicit Materialize action.
• Backend is honoured only in a Shader block. In a ShaderFunction Settings block it is one of the keys that is silently ignored.

Diagnostics

Informational messages worth recognising in the log:

Example

Shader(Name="Docs/M_ThinCustom", Root="Game")
{
    Properties {
        VectorParameter Tint = float4(0.2, 0.6, 1.0, 1.0) [Group="Look"];
    }

    Settings {
        Backend      = "ThinCustom";
        Domain       = "Surface";
        ShadingModel = "DefaultLit";
        BlendMode    = "Opaque";
        TwoSided     = true;
    }

    Outputs {
        vec3 Color;
        Base.BaseColor = Color;
    }

    Graph {
        Color = Tint.rgb;
    }
}

Generated assets, in persist mode:

package     /Game/Docs/M_ThinCustom
asset       /Game/Docs/M_ThinCustom.M_ThinCustom      UDreamShaderMaterialInstance
subobject   MB_DreamThinBase_M_ThinCustom             UMaterial  (hidden base, same package)

Settings applied to:  MB_DreamThinBase_M_ThinCustom
  BlendMode    = BLEND_Opaque
  ShadingModel = MSM_DefaultLit
  TwoSided     = true

In the editor's ordinary memory-only mode the instance is the same object, but the base is a separate transient-package object named MB_DreamThinBase_Docs_M_ThinCustom — the sanitized Name, not the leaf. The same file with Backend = "Graph"; instead produces a single UMaterial at /Game/Docs/M_ThinCustom carrying the graph and the settings itself.

Next

• Project Settings — Default Compiler Backend and the in-memory visibility toggle
• In-memory Materials — memory-only generation and materializing to disk
• The Pipeline — where backend resolution sits
• Asset Paths — how Name and Root become a package path