Looks like that answers my question!
Should I put my feedback here on in UDN? So far I’m going to leave it here.
I’m missing that the TexCoord node doesn’t have a parameter version, so I cannot make that exposed in the layer.
The shader compilation gets negative numbers so you never know when it’s going to finish.
Also you cannot expose uvs variables(vector2) so to deal with uv I have to expose 2 scalars or 1 vector. Not cool.
The process of creating new material layers and material layers blend should be done from the material isntance with simple buttons to create default ones in the current folder (or where the material lives). I spend too much time duplicating my stuff for the new layers…
It would be good to see an overview of the cost of the final shader.
That’s all for now
Is there a way to view the finalized layer stack material graph? I feel like this would be a good debug feature to add so we can make sure the layer stack output is sufficiently optimized
Hi there,
Just an organisational issue I’ve come across.
When making a layer I am trying to use static bool switches to keep parameters of a similar type organised. But unlike with a standard material instance, all the parameters are shown instead of those under the in-active branch being invisible.
So a standard instance works like so:
But the same behavior doesn’t occur in a layer stack:
Just thought it necessary to flag in case this hasn’t been picked up. Because it goes a long way to keeping things in order.
I assume that the current Layer Stack implementation is completely static, ie. it can only compile what’s in the Material Layer Stack, and not what’s in the Material Instances
Are we likely to see this functionality in 4.20? The whole system has been a fantastic opportunity to expand our project, but the lack of blueprint support has stopped some planned features in their tracks.
Bumping this thread for Almighty_gir’s post. Are the Material Layers accessible through BPs in 4.20? This is a feature our dev team has been waiting for as well. I know the 4.20 Preview 1 is released just recently but I have not seen any news regarding to this.
Looks great! Playing around with this at the moment and try do use it on terrains.
Does this work?
Can i dynamically add layers using e.g. a Height Blend?
Hi is anyone else missing the layer stack when you create the instance.
Also is this pretty unstable? It seems really crashey. How is the stablity for the rest of you guys
It crashes constantly for me.
I’m trying to have a material blend, with more than one blend material attribute node, and when I assigned it, its instant crash, every time. Overall it seams that some times deleting the material instance and creating a fresh one resolves that issue.
I’m setting up a material blend with vertex paint and if function, to choose which material to use, the top or bottom.
I get some very inconsistent results… The system works when the value provided is equal to 0.1, but it does not when its above that (my test mesh is just planes with values 0.0-1.0). It also gives different results if there is an inactive/disabled layer in the stack.
Is there any known issue with Vertex Paint or If statements in a Material Blend?
I’m trying to figure out if my setup is wrong or I hit a bug.
So yeah… I found the solution! And as it was expected, it was my setup 
My Pixel and Vertex Attribute Blend Type were both set on Use B, for sure something that I changed when I experimented with the system on the first try.
Fixing that gave the result that I was expected from my material graph.
I also found that many of my engine crashes where coming from the use of the Debug Scalar Parameters.
I had one hooked up in the Blend Graph, and in some cases it was throwing an error on compile, but still the compile was going through. At the moment that I was connecting the blend to the instance of my blend material, instant engine crash.
Solving the error with the Debug Scalar Parameters stopped my crashes.
Hey all,
Unfortunately due to some reorganization within our team, the Material Layering feature is being put on hold indefinitely. While we hope to revisit and expand its capabilities, no further updates will be coming at this time.
Please keep in mind that this is still an experimental feature, so we cannot ensure the stability of your projects that may be utilizing it.
We can’t thank you all enough for the incredible feedback you’ve provided thus far. Hopefully, we’ll be able to incorporate it in the future.
That’s actually what we all expected after the shutdown of Paragon.
Feature not needed anymore, so it’s development is halted.
Sorry to hear it got put on hold. FWIW Definitely was a key feature I was looking forward to for both individual projects and sustaining faster content development as a whole
I’m sure you don’t take things lightly and consider them carefully, but still this is very disappointing. The feature almost feels like complete (but guess it’s not).
Things like this and things like no clear word about certain tech in UE (like what’s the future of distance field tech, more importantly DF GI - terrain GI or full GI) start to make UE a risky engine to use. Please consider some more transparency in developing UE.
Actually this particular decision is quite unfortunate. I have notice over a longer period of time that for quite a few people the material system in UE is confusing or complicated. Material layering would make things definitely easier.
Whatever the reasoning is, it is a good move. Never seemed like the whole system was worth dev efforts.
Dam n, I was really looking forward to this feature, sooooo much nicer workflow than layering material functions together 
I really hope they resurrect this.
To you maybe.
To me, and clearly many other devs, the idea of modular materials seemed brilliant. Now we’re back to shuffling textures. Oh well.
I liked the idea, but the way it was implemented and the choice of words used was just so confusing. Scary enough I feel a similar vibe from Niagara, I wonder if it will be next.