Functions

Function and GraphFunction move reusable logic out of raw Graph statements. Both take a C-style signature and an HLSL body; the difference is what happens to that body.

Namespace groups either kind under an Ns:: prefix.

Synopsis

Function      [ { Inline | SelfContained } ] [ <return-type> ] <name> ( [ <parameter-list> ] ) { <hlsl> }
GraphFunction                                [ <return-type> ] <name> ( [ <parameter-list> ] ) { <hlsl> }

<parameter-list> := <parameter> [ , <parameter> ] …
<parameter>      := [ { in | out } ] <type-token> <parameter-name>

There is no (Key = Value) header, no Settings, and no sections of any kind. The { … } after the parameter list is raw HLSL, extracted by balanced-brace scanning that is aware of //, /* */ and "…".

The keywords Function and GraphFunction are matched case-sensitively; the modifier, the in / out qualifiers and every type token are not.

Declaration order

The parser reads identifiers left to right and disambiguates by one character of lookahead: after reading an identifier it skips whitespace and comments, and if the next character is not (, the identifier just read was the return type.

The modifier is therefore fixed in first position, immediately after the keyword.

Parameters

Parameters are split on top-level , and each one is then split on any run of whitespace. Two or three tokens are accepted:

At least one output

A function must produce something: after parsing, the result list must be non-empty. That means the declaration carries either at least one out parameter or a return type. Neither gives Function '{Name}' must declare at least one out parameter.

Return type

A return type implies exactly one output and forbids every explicit out. Multiple outputs require out parameters and no return type.

return lowering

When a return type is declared, the body is rewritten before codegen: every return at brace depth 0, bounded by non-identifier characters, becomes the literal text __return =. The trailing expression and its ; are preserved verbatim, and the scan skips comments, "…" and '…', so returnValue and my_return are untouched.

A bare return; at depth 0 is a hard error: A function with a return type cannot use a bare 'return;'. Return a value, e.g. 'return expr;'.

Accepted parameter types

After the 15 GLSL aliases are normalised, the resolver accepts:

An unknown token is not validated at parse time — it is passed through and only fails when the function is called. Matrices reach that path: DreamShader Function 'Rotate' input 'basis' uses unsupported type 'float3x3'.

Texture parameters and samplers

Five tokens are treated as texture function parameters: Texture2D, TextureCube, Texture2DArray, Texture3D, VolumeTexture. For each one the generated HLSL signature gains an extra SamplerState <ParamName>Sampler parameter immediately after it, and every generated call site passes the matching <argument>Sampler. Use that name inside the body to sample the texture.

SamplerState is not in that list: a parameter declared SamplerState S resolves as an ordinary Texture2D object and receives no companion parameter.

Function SampleTinted(in Texture2D tex, in vec2 uv, in vec3 tint, out vec3 rgb, out float alpha)
{
    float4 texel = Texture2DSample(tex, texSampler, uv);
    rgb   = texel.rgb * tint;
    alpha = texel.a;
}

Body normalisation

Every Function and GraphFunction body — and nothing else in the language — is passed through an identifier-level rewrite before it is stored. The scan is comment- and string-aware, and does two things: it substitutes the 18 aliases (15 GLSL type spellings plus mix → lerp, fract → frac, mod → fmod), and it flattens A::B into the sanitised identifier A_B.

Generated HLSL

Each Function is emitted into the generated include as:

<ResultType0> DreamShaderFn_<SanitizedName>(<params>)
{
	<ResultType0> <Result0Name> = (<ResultType0>)0;
	<Result1Name> = (<ResultType1>)0;
	<body, indented>
	return <Result0Name>;
}

Every Function in a parse unit goes into the include — including SelfContained ones. GraphFunction declarations never do. See The Pipeline.

Inline / SelfContained

Inline is an exact synonym of SelfContained — the same parser branch, the same flag, no behavioural difference whatsoever. Neither is accepted on GraphFunction.

Without the modifier, a call site emits a Custom node whose code calls the include. With it, the function and the transitive closure of the plain Functions it calls are embedded into the calling node's own code, wrapped in a struct.

GraphFunction and UE.* hoisting

Before the Custom node's code is assembled, the body is scanned and every UE.* call is replaced by the name of a generated input pin carrying the value that call evaluates to.

A call is hoisted only when all of these hold, in order:

If steps 1–4 fail, the text is copied through verbatim and silently. If step 5 fails, generation stops with DreamShader GraphFunction '{Name}' contains an unterminated UE.* call. The scan skips comments and string literals, so a UE.Time() inside a comment is not hoisted.

The extracted text is re-parsed as a Graph expression and evaluated against a scope containing the enclosing Graph block's variables plus this call's arguments, so any UE.* builtin — including UE.Expression — is available.

The generated pin name

So a GraphFunction WindPulse whose body contains one UE.Time() call produces a pin literally named:

_ds_WindPulse_UE0

and a namespaced Common::Pulse produces _ds_Common_Pulse_UE0. These names are user-visible on the generated node and in any shader-compiler error that mentions them.

A hoisted expression must produce a plain numeric value. A texture object, a MaterialAttributes value or a Substrate material fails with DreamShader GraphFunction '{Name}' UE input '{CallText}' cannot be passed into a Custom node input.

GraphFunction WindPulse(in float2 uv, out float pulse)
{
    float t = UE.Time();
    pulse = sin(uv.x * 8.0 + t);
}

generates, for one call:

UMaterialExpressionTime                →  Custom pin "_ds_WindPulse_UE0"
UMaterialExpressionTextureCoordinate   →  Custom pin "uv"
UMaterialExpressionCustom  Description="WindPulse"  OutputType=CMOT_Float1

float pulse = (float)0;
float t = _ds_WindPulse_UE0;
pulse = sin(uv.x * 8.0 + t);
return pulse;

Namespace

A Namespace prefixes the names of the Function and GraphFunction declarations it contains. It is not an entity: no object is stored for it and it creates no scope. Its only effect is on the member's recorded name.

Namespace(Name = "Common") { Function ApplyTint(…) }   →   name "Common::ApplyTint"

Namespace(Name="Common")
{
    Function ApplyTint(in vec3 color, in vec3 tint, out vec3 result) {
        result = color * tint;
    }

    Function float Remap01(in float value) {
        return saturate(value * 0.5 + 0.5);
    }

    GraphFunction Pulse(in float speed, out float value) {
        value = sin(UE.Time() * speed);
    }
}

Graph = {
    vec3 Tinted;
    Common::ApplyTint(BaseColor, Tint, Tinted);   // statement call
    float K = Common::Remap01(Tinted.r);          // value call
}

Calling

Both call forms live in a Graph block.

Named arguments are not supported on Function or GraphFunction in either form — a Key = Value argument fails with … currently uses positional arguments only. Out targets must be bare names, non-empty, and distinct within one call. Because lookup also accepts the mangled spelling, DreamShaderFn_Luma(c) is a legal call.

Full argument rules, default, output selectors and cross-kind ambiguity are on Calls.

Notes

• No overload resolution. Names are not scoped by arity or parameter type; the first declaration whose name matches, ignoring case, wins.
• Case-insensitive collisions are real collisions. Luma and luma are "declared more than once", and so are A::B and A_B.
• The parse unit is the whole import closure, so a name clash across imported headers is a clash. See Imports and Namespaces.
• A .dsm or .dsf containing only Function blocks compiles successfully and produces no asset: Generated DreamShader helper include '{Path}' from {File}.
• If a Function and a GraphFunction share a name, every call is ambiguous.
• On UE 5.3 generated Custom nodes display their code in the material graph; from UE 5.4 onward ShowCode is set to false.
• The legacy section-style body Function Name { Inputs = { … } Code = { … } } is not a supported form.

Example

// DShader/Lib/Color.dsh

Function float Luma(in vec3 color)
{
    return dot(color, float3(0.299, 0.587, 0.114));
}

Function SelfContained Remap01(in float value, out float result)
{
    result = saturate(value * 0.5 + 0.5);
}

import "Lib/Color.dsh";

Shader(Name="Materials/M_Tinted")
{
    Properties = {
        TextureSampleParameter2D BaseTex = Path(Game, "Textures/T_Base");
        vec3                     Tint    = vec3(1.0, 0.6, 0.2);
    }
    Outputs = {
        vec3 Color;
        Base.EmissiveColor = Color;
    }
    Graph = {
        vec2 UV  = UE.TexCoord(Index = 0);
        vec4 Tex = BaseTex(Coordinates = UV);

        float Key;
        Remap01(Luma(Tex.rgb), Key);      // statement call, nested value call

        Color = Tex.rgb * Key;
    }
}

Diagnostics

Choosing a form

Where to next