About DreamShader
What the plugin is, the four modules it ships, which engines it supports, and where the related repositories live.
DreamShader is an Unreal Engine plugin that compiles DreamShaderLang source files into standard material assets. DreamShaderLang is the language; the plugin owns parsing, generation, caching, diagnostics, decompilation and the editor integration.
| Version | 2.0.0 — descriptor Version 200, IsBetaVersion false |
| Engines | Unreal Engine 5.3 – 5.8, Win64 — what 2.0.0 was built against is under Engine support |
| Modules | DreamShaderLang (Runtime), DreamShader (Runtime), DreamShaderCompiler (Editor), DreamShaderEditor (Editor) |
| Plugin dependencies | WebSocketNetworking, SQLiteCore |
| Descriptor flags | EnabledByDefault, CanContainContent |
| License | MIT |
| Repository | TypeDreamMoon/DreamShader |
What it is for
Unreal material graphs are hard to review, diff, reuse and migrate once they grow. DreamShader moves the repeatable parts into text:
| Pain point | The answer |
|---|---|
| Large graphs are hard to review and diff | graph structure lives in .dsm / .dsf files |
| Shared logic gets duplicated | .dsh headers, .dsf function assets, Function / GraphFunction helpers, packages |
| Regenerating a material function breaks its callers | FunctionInput / FunctionOutput pin identities are preserved by name |
| Substrate graphs need text authoring | the Substrate type, Base.FrontMaterial, and the Substrate.* builtins since UE 5.4 |
| Existing graphs need migrating | the decompiler exports UMaterial / UMaterialFunction back to .dsm / .dsf |
| Generated assets lose their provenance | DreamShader.SourceFile and DreamShader.SourceHash are stamped into package metadata |
| A rebuild silently overwrote a hand-edited asset | the DreamShader.OutputDigest fingerprint stops that rebuild and offers Revert / Adopt / Detach since 1.8.0 |
| A plugin wants to ship its own material sources | every enabled plugin with a DShader folder contributes a source root since 1.6.0 |
| A graph wants real expressions and control flow | .dss: HLSL with declarations, one asset per export since 2.0.0 |
| Material instances are edited one checkbox at a time | .dsi: a parent and its overrides, as text since 2.0.0 |
It is not a replacement for the material editor, and not a shader pipeline. Graph is a node-graph
builder with four operators and if / else; anything genuinely imperative belongs in a Function,
whose body is real HLSL compiled into a Custom node. A one-off, highly visual graph is still faster
to build in Unreal — and can be exported later if it stabilizes.
The four modules
| Module | Type | Public headers | Responsibility |
|---|---|---|---|
DreamShaderLang since 2.0.0 | Runtime | 27 | The language, depending on Core alone: the lexer, both parsers (2.0 and the 1.x front end), the preprocessor, the binder, the engine-free graph IR, the way back from IR to source, and the 1.x → 2.0 migrator. |
DreamShader | Runtime | 8 | The log category, the canonical path helpers, the 1.x source data model, the engine side of the define table, UDreamShaderSettings, UDreamShaderMaterialInstance, the engine-version macros, and the compile interface IDreamShaderCompiler. |
DreamShaderCompiler | Editor | 19 | The compiler's back half: the pipeline, the IR emitter, the asset layer, the builtin catalog read from reflection, the product index, the parent schemas of .dsi. Through 1.9.x it was a Runtime module holding only the interface. |
DreamShaderEditor | Editor | 0 | Everything a user touches: the decompilers, dsc migrate, the commandlet, the bridge, the preview, the Material Content Browser, the provenance actions, the workspace exporter. |
DreamShaderLang and DreamShader load at PostConfigInit, early enough that the settings object and
the shader-directory mapping exist before anything asks for them; the two Editor modules load at Default.
DreamShaderEditor exports nothing and cannot be linked against — it has no Public/ folder at
all. The supported C++ entry point is IDreamShaderCompiler, declared in DreamShader
(DreamShaderCompilerInterface.h) and reached through GetDreamShaderCompiler();
DreamShaderCompiler implements it. Everything else is reachable through the editor UI, the
commandlet, or the bridge files.
The language is engine-independent: DreamShaderLang depends on Core alone, creates no UObjects
and loads no assets. Generation is the opposite — editor-only, game-thread, built on the material
editing library.
Engine support
2.0.0 was verified with single-plugin RunUAT BuildPlugin on Win64 against 5.5, 5.6 and 5.8.
5.7 was last verified for 1.8.0; every engine gate the 2.0 code added asks the engine's own headers
or types instead of a version number, so 5.7 needs no answer of its own. 5.3 and 5.4 are
source-compatible, but a recent MSVC toolchain cannot build those two engines at all — the failure is
in an engine header, before any plugin code is reached.
Feature availability differs, and the gate is compile-time — a binary built against 5.3 does not contain the Substrate code paths at all, so moving a project to a newer engine means rebuilding the plugin.
| Requires | Features |
|---|---|
| 5.4 | Substrate — Substrate.*, ShadingModel="Substrate", Base.FrontMaterial, the Strata aliases · generated Custom nodes keep their code collapsed · bHasPixelAnimation reset and export |
| 5.5 | the periodicworld transform basis · UE.TransformPosition(PeriodicWorldTileSize=…) |
| 5.6 | the firstperson transform bases · UE.TransformPosition(FirstPersonInterpolationAlpha=…) · plugin-mount validation for Root= and Path(…) · TextureSample.GatherMode round-trip |
| 5.7 | Group / SortPriority on collection parameters · BlendInputRelevance on layer-blend inputs · per-platform, per-quality material-resource diagnostics |
| 5.8 — decided by the engine's own headers, so a 5.7 that has these members gets them too | .dsi overrides of parameter-collection parameters · a ThinCustom instance re-applying kept double-vector and static-component-mask overrides |
Everything not listed behaves identically on every engine from 5.3 to 5.8. Where a feature is
missing, most source-reachable surfaces report an explicit message ending
requires Unreal Engine 5.4 or newer. rather than degrading silently.
Who implements what
DreamShader ships as two independent products that talk through files under
<Project>/Saved/DreamShader/Bridge/ and one loopback WebSocket.
| Surface | Implemented by |
|---|---|
| Parsing, generation, caching, diagnostics, decompiler | the Unreal plugin |
| Menus, toolbar, context menus, the Material Content Browser tab | the Unreal plugin |
| Preview rendering and the PNG frames | the Unreal plugin |
DShader/Packages creation, import resolution, the compile exclusions | the Unreal plugin |
| Highlighting, completion, hover, navigation, local diagnostics | the editor extension |
| Preview camera control and frame acknowledgement | the editor extension |
dreamshader.package.json, dreamshader.lock.json, install / update / store | the editor extension |
No plugin C++ reads either package file. A package resolves purely because its files exist under
DShader/Packages.
Repositories
DreamShader
The Unreal plugin: the parser, the generator, the editor tools and this documentation's source manual. MIT.
VSCode extension
Highlighting, snippets, completion, Go to Definition, Find References, hover, signature help, local and bridge diagnostics, package commands, quick templates.
Rider plugin
.dsm / .dsf / .dsh file types, grammar and PSI parsing, highlighting, completion,
navigation, diagnostics, bridge integration, semantic tokens, inlay hints, package tools.
Package Store Index
The index the extension's package store reads. A package repository is also discoverable through
the GitHub topic dreamshader-package.
Issues go to the plugin repository's issue tracker. Extension settings, commands and the package store are documented in the extension repositories, not here.
Next
- Installation — get it into a project
- Daily Workflow — the compile loop
- Editor Tools — the menus, the browser tab, the clean commands
- Changelog — what changed in
2.0.0