DreamShaderLang
Plugin reference

Settings

Settings

Settings

DreamShader » Settings

The section that carries <key> = <value>; pairs from a source block to the asset it generates.

Declared in.dsm, .dsf, .dsh — inside Shader, ShaderFunction, ShaderLayer, ShaderLayerBlend or VirtualFunction
Kindsection
Generatesnothing directly — it writes properties on the asset the enclosing block generates

Synopsis

Settings [=] { <setting-statement> … }

<setting-statement> := <name> = <value> ;
<name>              := <identifier>
<value>             := <tokens up to the next ;> | "<text>"

The = between the section name and its { … } block is optional sugar (since 1.5.0). The ; after the last statement is optional.

(since 2.0.0) A name is one identifier. 1.x also read a nested path (Lightmass.DiffuseBoost) and a fixed-array index (PhysicalMaterialMap[2]) as a key of a Shader block; the legacy front end stops at the . or the [ and reports DSH3261.

A Shader's Settings is the 2.0 #pragma material(…) — see The 2.0 language.

Where a Settings block is accepted

BlockSection keywordsKey handlingReference
ShaderSettingsBackend and Substrate are read by the compiler; BlendMode / RenderType, ShadingModel, MaterialDomain / Domain are hand-handled; every other key is written onto UMaterial by reflection — an unknown key fails the build (DSH8215)Shader settings
ShaderFunctionSettings4 recognized keys; every other key is a DSH3263 warning and is ignoredFunction settings
ShaderLayerSettingssame 4 keysFunction settings
ShaderLayerBlendSettingssame 4 keysFunction settings
MaterialLayer / MaterialLayerBlend (deprecated in 1.3.0; DSH2251)Settingssame 4 keysShaderLayer
VirtualFunctionSettings or OptionsAsset (required, DSH6312) and Description; any other key is ignoredOptions
Function / GraphFunction—no Settings section exists; only Inputs/Properties, Outputs/Results and Code/GraphFunction

A block may contain more than one Settings section. They merge into one list; a key written twice keeps the last value, regardless of which section it came from, and the repeat is a DSH3262 warning (since 2.0.0).

How a statement is parsed

(since 2.0.0) The legacy front end reads a Settings section from the same tokens as the rest of the file:

#StepConsequence
1// and /* … */ comments are triviacomments may stand between any two tokens, including mid-statement
2A statement is a name, =, and a value; the value runs to the next ; at depth zero of ( ), [ ] and { }, or to the } that closes the sectionColor = (R=1,G=0,B=0); is one statement; empty statements are skipped, so a trailing ; is optional
3The name is one identifierFoo.Bar = 1; and Foo[2] = 1; are DSH3261, as are a statement with no = and an = with no value
4A value that is one string literal gives its contents, its escapes read by the lexer; any other value is its text as writtenquotes are optional on every setting
5A name written twice, compared ignoring case, keeps the later valueDSH3262

Because of step 4, TwoSided = true; and TwoSided = "true"; are identical, and Domain = Surface; behaves exactly like Domain = "Surface";.

Key normalization

Several normalizations act on Settings data. Confusing them is the source of most surprises on this page.

StageOperations, in orderApplied to
Duplicate check, Backend, Substratecase-insensitive comparisonevery key of the block
Key storage and direct lookuptrim, lowercaseevery key that reaches the material; every direct key probe (BlendMode, ShadingModel, Domain, …)
Reflection lookuptrim, lowercase, delete every space, _ and -property names, the alias table, and the special-key test
Value lookup for enumstrim, lowercase, delete every space, _ and -ShadingModel, BlendMode, Domain values and every reflected enum-typed value (which additionally deletes :, . and /)

Nothing else is stripped. A key spelled Two_Sided is stored as two_sided and only matches later because the reflection lookup strips the underscore.

[!WARNING] The special Shader keys are matched by direct lookup (trim + lowercase) but skipped from the reflection pass by the reflection normalization (which also strips _). A spelling that differs from the canonical name only by underscores therefore matches neither and is applied nowhere, with no diagnostic: Blend_Mode, Render_Type, Shading_Model, Material_Domain, Back_end. Write BlendMode, RenderType, ShadingModel, MaterialDomain, Domain and Backend without separators. (A space or a hyphen cannot stand in a name at all since 2.0.0.) See Shader settings.

This is not a fixed key list

Settings in a Shader block is not a catalogue of supported keys. A handful of keys are hand-handled; every other key is resolved against the generated UMaterial by Unreal reflection.

Settings key
   ├── Backend, Substrate
   │      └── read by the compiler when the source is bound; never reach the material
   ├── blendmode rendertype shadingmodel materialdomain domain
   │      └── hand-handled: value parsed through the project's alias maps
   └── anything else
          └── alias table  →  UMaterial / UMaterialInterface / UObject property lookup
                                 (name, b-stripped name, or DisplayName)
                              →  value parsed per the property's C++ type

Two consequences a reference reader must internalise:

  • Any UPROPERTY on UMaterial or one of its bases is reachable by its name. Nested struct members and fixed-array elements are not reachable from a 1.x key (since 2.0.0); a fixed-size array named without an index is DSH7121. No table in this manual can be complete for that surface, because it is the engine's property set, not the plugin's.
  • Which enum values are accepted likewise comes from engine reflection, so a modified engine build contributes its own spellings automatically. See Material enums.

Material-function blocks are the opposite: exactly four keys are read and every other key is a DSH3263 warning. See Function settings.

Pages

PageCovers
Shader settingsthe special keys, the alias table, the reflection resolver, value grammar per property type, and what every generated material is reset to
Material enumsevery accepted ShadingModel, BlendMode and Domain spelling
BackendGraph vs ThinCustom, the old Instance spelling, precedence against the project default
Function settingsSettings inside ShaderFunction / ShaderLayer / ShaderLayerBlend
Project settingsProject Settings ▸ DreamPlugin ▸ Dream Shader — all seventeen config properties, including Preprocessor Defines

Diagnostics

Parse time

CodeRaised when
DSH3261no { after Settings; a statement that does not start with a name; a name with no = after it (which is what a . or [ in a key gives); an = with no value
DSH3262a name written twice in the block, compared ignoring case (warning; the later value wins)
DSH3263a function block's key it does not read (warning; ignored)
DSH2245a section name inside Shader, a function block or a VirtualFunction that the block does not have
DSH2246a Code section in a Shader or function block, which takes Graph

Diagnostics raised while applying the settings are listed on Shader settings, Backend and Function settings.

Example

Shader(Name="Docs/M_SettingsGrammar")
{
    Properties { vec3 Tint = vec3(1.0, 0.5, 0.25); }

    // Two Settings sections merge into one list.
    Settings {
        Domain       = Surface;        // quotes are optional
        ShadingModel = "Unlit";
        BlendMode    = "Opaque";
    }

    Settings = {
        BlendMode           = "Translucent";   // last write wins over "Opaque" (DSH3262)
        TwoSided            = true;            // reflected onto UMaterial::TwoSided
        OpacityMaskClipValue = 0.5;            // reflected, float-typed
    }

    Outputs {
        vec3  Color;
        float Alpha;
        Base.EmissiveColor = Color;
        Base.Opacity       = Alpha;
    }

    Graph {
        Color = Tint;
        Alpha = 0.5;
    }
}

Effective settings, keys as the emitter stores them:

domain                  -> Surface
shadingmodel            -> Unlit
blendmode               -> Translucent
twosided                -> true
opacitymaskclipvalue    -> 0.5

See also

On this page