Source Files

DreamShaderLang lives in plain text files of three kinds. They share one parser and one grammar; the extension decides only two things — what the file is allowed to declare, and whether compiling it produces an asset.

Extensions are compared case-insensitively, so M_Water.DSM is a material file.

Synopsis

// <name>.dsm — Dream Shader Material
[ import "<specifier>" ; ]…
[ Shader( Name = "…" [, Root = "…"] ) { … } ]          // at most one per translation unit
[ <any function, layer, virtual-function or namespace block> ]…

// <name>.dsf — Dream Shader Function
[ import "<specifier>" ; ]…
[ { ShaderFunction | ShaderLayer | ShaderLayerBlend }( Name = "…" [, Root = "…"] ) { … } ]…
[ { VirtualFunction | Namespace | Function | GraphFunction } … ]…

// <name>.dsh — Dream Shader Header
[ import "<specifier>" ; ]…
[ { VirtualFunction | Namespace | Function | GraphFunction } … ]…

What each kind may contain

.dsm has no restriction at all — its column is simply what the grammar accepts. See Top-level Blocks for what each one declares.

How the restriction is enforced

The rule is not part of the parse. After a file's import lines have been stripped and before the declaration parser runs, the loader scans the remaining text for literal substrings, compared case-insensitively.

One needle is enough for .dsf because ShaderFunction( does not contain the substring Shader(; .dsh needs all six for the same reason, and because MaterialLayerBlend( does not contain MaterialLayer(.

One translation unit

A translation unit is one source file plus everything it imports, transitively. import directives are inlined into a single text before parsing, which has one consequence worth memorising:

Everything else — Function name collisions, Namespace re-opening, VirtualFunction visibility — is likewise closure-wide. See Imports and Namespaces.

What each kind generates

A .dsm with no Shader block is still compilable: it produces whatever function assets it does declare.

Where files are found

Files are discovered by recursive scans of the source directory.

A configured relative path is resolved against the project directory, and all three directories are created at module startup. See Project Settings and Packages.

Example

<Project>/DShader/
├── Materials/
│   └── M_Water.dsm
├── Functions/
│   └── F_Tint.dsf
├── Shared/
│   └── Common.dsh
└── Packages/
    └── @typedreammoon/
        └── dream-noise/
            └── Library/
                └── Noise.dsh

// DShader/Shared/Common.dsh — header: helpers only
Namespace(Name="Common")
{
    Function ApplyTint(in vec3 color, in vec3 tint, out vec3 result) {
        result = color * tint;
    }
}

// DShader/Functions/F_Tint.dsf — function file: may declare ShaderFunction
import "Shared/Common.dsh";

ShaderFunction(Name="Functions/F_Tint")
{
    Inputs = {
        vec3 InColor;
        opt float Strength = 1.0;
    }

    Outputs = {
        vec3 OutColor;
    }

    Graph = {
        OutColor = InColor * Strength;
    }
}

// DShader/Materials/M_Water.dsm — material file: may declare Shader
import "Functions/F_Tint.dsf";

Shader(Name="Materials/M_Water")
{
    Outputs = {
        vec3 Color;
        Base.EmissiveColor = Color;
    }

    Graph = {
        Color = vec3(0.1, 0.3, 0.6);
    }
}

Compiling M_Water.dsm produces both assets:

/Game/Materials/M_Water        UMaterial
/Game/Functions/F_Tint         UMaterialFunction

Notes

• A .dsh is the natural home for VirtualFunction declarations. The editor's Create Virtual Function action writes one under DShader/VirtualFunctions.
• Nothing stops a .dsf or .dsh from being imported by any other kind. The extension decides only the default extension of an unsuffixed import specifier and the content rule applied to that file.
• The content check lives in the editor source loader. The runtime parser entry point is extension-agnostic.

Diagnostics

Where to next