Current Limitations

Current boundaries, compatibility notes, and recommended alternatives for DreamShaderLang.

DreamShaderLang intentionally covers the material-authoring patterns that are practical to generate and maintain as text. Some Unreal graph features still require generic nodes or manual Unreal editing.

Graph Limitations

Limitation	Alternative
Complex shader control flow directly in `Graph`	Move it to `Function` or `GraphFunction`.
Unsupported specialized Unreal node shorthand	Use `UE.Expression(...)`.
Ambiguous multi-output expressions	Use explicit variables and output arguments.
Large visual-only node layouts	Use `Layout` metadata or keep one-off graphs in Unreal.

Type Limitations

Limitation	Alternative
Unsupported custom Unreal struct types	Use supported scalar, vector, texture, or `MaterialAttributes` types.
Ambiguous implicit casts	Add constructors such as `vec3(x)` or `float4(v, 1)`.
Unsupported texture forms	Use documented texture types and plugin-supported parameters.

Import and Package Limitations

Limitation	Alternative
Fragile deep package imports	Export stable package entry files.
Circular dependencies	Move shared helpers to a lower-level `.dsh`.
Machine-specific paths	Use project-root or package imports.

Diagnostic Boundaries

Editor diagnostics depend on parser support, reflected Unreal metadata, and bridge export freshness. When a UE.Expression(...) call uses a rare Unreal node, the plugin may only validate it during generation.

Version Migration Tips

Change area	Recommendation
New plugin versions	Review changelog and regenerate bridge metadata.
New VSCode extension versions	Restart the editor if language-service metadata changed.
Decompile exports	Treat exported `.dsm` / `.dsf` as a starting point and clean names/layout.

Design Principle

Prefer explicit source for behavior that must be reviewed, regenerated, or shared. Use Unreal's visual editor for exploratory or highly visual one-off graphs, then migrate stable parts into DreamShaderLang.