I’m not sure I have the workflow down / somethings going wrong. I tried to recreate the awesome Death Blossom’s master material from the Infiltrator (shown below)
But after only a couple of layers I’ve run out of texture samplers.
I’ve tried to show a examples of what I’ve put together, I think I need to add bolts, decals and emissives to the material so I’m only about 1/2 way and hit the 16 samplers limit where as the original material only had 14//16 used.
I assume it’s something to do with the way I’ve put it together.
Solved my earlier issue of running out of texture samplers by putting masks into a material input collection. Problem is I think I’m using those wrong as if I want to put another type of mask i.e. body, head, coffin section it’ll overwrite the other masks in the shared material input collection…
Raildex excuse my ignorance but why are you using a Vertex Interpolator?
Can’t you just connect the parameter to the input like my pic below?
It didn’t work without VertexInterpolator either. My original Setup didn’t use the VertexInterpolator, but since the Message says something about VertexParameter and PixelParameter my assumption was it cannot convert he SharedInput to PixelShader instructions or something like that.
Something that would really make development faster for me would be the ability to use Materials like Material Instances to tweak parameters on the fly for things in the scene. Is there anyway you could add a toggle onto the Material so that you could tweak it without recompiling (maybe in a separate window)? This would allow faster testing without creating new assets.
In the new MaterialLayerblend, why am i not able to use operations such as TransformVector, or PixelNormalWS (VertexNormalWS seem to work)? Anything tangent/normal seem to be unavailable, think someone else mentioned the TransformVector doesnt work earlier in this thread. I want a snow material to show up on the slopes of my mesh.
In my Material Layer Blend when I’m trying to create an alpha that is based on base color, normal etc in the incoming layers i get an error in the Material with the layer stack:
“(Node MakeMaterialAttributes) Error on property BaseColor”
Why doesnt this work? If this is not possible then a Blend Material is almost useless…
Hi Showster, are you using shared samplers in your layer texture samples? There are global shared clamp and wrap samplers which will likely cover most use-cases unless you’re after some manual mip-biasing. The one thing that could hit here is that each texture parameter is owned by a layer so they’ll be duplicated as objects even if set to the same value, just to maintain the ability to swap them independently. SharedInputs would be the short-term solution in the current preview, though as we mentioned in the stream we’re likely removing those as a concept as we’d like a better option long-term, perhaps per-parameter you could flag as global/shared in addition to the instance stack level having an option to tag parameters to link as shared.
One suggestion I’d give is to take advantage of the Layer Stack node’s input. It takes in a MaterialAttributes which is then available as the input to every layer, so in some of these cases you could e.g. Set your texture parameters as BaseColor, Emissive, Normal on a SetMaterialAttributes node, pass that in to your layer stack node, then in each layer use the GetMaterialAttributes on the input and grab that data. Whilst they have those attribute names, under the hood it’s mostly just groups of data e.g. BaseColor is a Vector3 being passed through so you can re-use it how you wish. In that way you can either treat it as arbitrary data or as the original intention, which was a “base attributes” input to the stack so you can get that same data in each layer.
Hi Railex_, thanks for trying out the feature but that definitely sounds like a bug. Are you using the GetSharedInput for a few different material attributes perhaps? The error reads as though it created a per-pixel variant of the shared Set graph, but then tried to use it for a per-vertex attribute, so it should really have made one for each required case.
Hi Erik007, TransformVector is a known issue, it’s not usable for every case as the information required for the transform isn’t always there. The error is a bit overly aggressive though and I believe it was toned down but perhaps that missed the 4.19 branch. We made a bug tracker to chase this and I’ll see it’s there for 4.20 at least. Some of the others may be down to the attributes they’re used with; In general BlendMA is a bit tricky because of the Normal attribute being in there, so if you have a simple graph that uses PixelNormalWS as a blend input for two MA inputs, it will try to blend the normal with the result of the blend you’re in which expectedly fails. You can work around it by manually blending the normal with Get/SetMA nodes alongside the BlendMA node with some other type of blend, or manually create an alternative transition. There’s also a few flags on the BlendMA node to opt in/out of pixel or vertex attribute blending which can help clear the graph in some cases if you want to just blend those groups separately across multiple blend nodes.
As an FYI for everyone using the experimental layers feature:
After a fair bit of discussion internally and much external feedback we’re very likely going to remove the SharedInput asset and associated nodes from the next 4.19 preview build. As a support class for an experimental feature it isn’t quite checking the boxes it needs to and only building up dependencies that we’ll later have to remove. For the sake of Layers in 4.19 I’d recommend using the MaterialAttributes input to the Stack node by pulling from the input within each layer to accomplish the same as the SharedInputs were offering and please continue to give feedback about workflow improvements you’d like to see here.
I’ll update this post if we go ahead and have the primary post updated to show an example of that alternate workflow!
EDIT: This should be in the next preview version, I’ll work with to get the release notes and main post samples updated. Anyone using shared inputs will find the nodes missing when they open their graph and will need to update the connections. The shared input collection assets will still be in your content browser but no longer function and can simply be deleted.
The editor option for enabling material layers has moved and will need re-toggling. It’s now under “Project Settings > Rendering > Experimental” as this now also changes some run-time behavior.
Since the Material Layer Stack is just a collapsed Graph, why don’t you set Parameters by their name just like it was before Layers?
Before Layers, Parameters in Material Functions are Parameters globally in the whole Material.
I guess it’s important for many developers that you can atleast drive parameters of single layers at runtime. Building a Material at runtime (adding, removing layers ) shouldn’t have that much of demand if you ask me.
Hi Raildex_, as mentioned on the stream this was a pain point even with material functions as it was impossible to add multiple function calls that happened to have overlapping parameters. The workflow there was to replace parameters as inputs if you wanted them unique, which made the usage a little more tedious. Whilst we’re not quite exposing the control to set each parameter as global/shared yet this is a step towards that. Ideally you’d be able to set each parameter or function call if they are global or owned/instanced as there’s lots of use for both.
For the initial iteration of material layers we took the most common request of instancing parameters for each layer as that opens up the most productivity and workflow improvements by allowing fewer graphs and more variants through layer instances as well as having multiple of the same parent layer per stack, something that’s impossible otherwise and more embraces the goals of the feature.
Ultimately it will be up to you, but we’re not there just yet.
Dynamic parameter control is vital to many projects and is a core feature of the material system. This is still unfinished for material layers but as mentioned will work for the final release. Changing a material itself at runtime is impossible in the engine as changing the graph requires recompiling the shaders which can easily take several seconds per material. See my reply on page 4 for a little more detail if you’re interested.
I did try shared inputs originally but I felt like I was making a mess. I’ve had a go with the SetMaterialAttributes node but I do feel like I’m bodging the system.
I don’t quite yet understand how to work with the idea of global / shared texture samplers in UE4 material layers. I get the concept just not sure of how to best execute it.
The other place I can see the samplers being eaten up is in the blends, the same mask is called for each layer. I did try this with SharedInputs but I do need to be able to change the mask and well I just ended up making a mess haha.
Late to the party - but currently testing this. Just in case someone can’t find how to turn on material layers - it’s under Edit->Editor Preferences->Experimental->Materials as of Preview 5. A Mod may want to adjust original post.
When you have a Layered Material, but don’t provide Material Layers within the LayerStack Node, the Editor will crash as soon as you want to create an Instance and look at the Layer Paramters
Can anyone confirm/deny if I broke my setup? I have what I would think is the simplest test for this. Just passing in a base color and normal from 2 textures in a material layer. I have NO blend at all for testing purposes. I create a material, use the layer attributes, then make an instance. I can confirm the post above me that if you forget to assign a default it crashes so it’s not that issue. With that out of the way anytime I press + to add a new layer I get a crash. Should I be able to use material layers in 4.19p5?
Yes this happened to me too. I’ve been trying out the new layered material since the first preview. It works fine before preview 5, All the instanced layered material now will crashes when ever i click the layer parameter tab.
There is also a strange behavior with just using a regular material instance (non layered), the parameter just won’t change. First I thought the real time was unchecked, but that was not the case and when i hit save the material parameter instance sometimes disappear but there was no changes were made. The regular material behaves normal again after i disable the layered material in experimental. Can some one confirm to check on this?
I can confirm this. It was brought up in the discord and I ran into it today trying to set up some examples. Material Layers are causing some serious issues in P5. You will notice for this problem above that when you turn on material layers in experimental it now says “global” for the instance parameters and they never save/apply.
