[SHELVED] Material Layering Feedback for 4.19

Will this work with decals? Eg floating ones…

I will definitely use it on my game under development, but thinking on Content Creators they will mostly prefer to stick with compatibility over several engine versions than bringing something new just because it is new.

… … I’ve been waiting 19 engine versions for this!

Right now we haven’t hooked up Blueprint controls for this, because we’re planning out what will be the smoothest workflow for users. Right now if we did expose something, you’d have to manually type in the parameter name, as well as the index of the layer or blend, and that’s not ideal. Definitely keep posted though, it’s something we will be working on before we remove experimental status.

So, the biggest gains will be if your project currently has a lot of master materials that are similar except for one section of graph, or has lots of reuse of different functions or blend types. For one material each done in the old way vs. the new way, the shader complexity should be similar. As you get more materials and instances though, if you set up the new material stacks well, you can end up with a lot of savings.

Yes, it should work with decals!

Tried last night and I was very satisfied, covers a lot of limitations that I was facing previously. If there is way to somehow hook the final output stack to the Render to Texture blueprint to generate static textures and not having to worry about the high instruction count associated with this workflow…That would be the cherry on the cake.

While I have not tried this with the Material Layers, you could try using the following How - To as that will work with both Materials and Material instances.

Does it peform any optimizations automatically? Like discarding bottom layers early if they’re fully covered by upper layers?

I was trying to recreate the original MatLayerBlend functions with the new interface, starting with the Override Base Color with an option to input a texture, but for some reason the UV tiling parameter does not work when the Matterial Layer Instance is in the stack. GIFs below. Any ideas?


I’ve been using this to great effect, however there are some things that don’t appear to be working as expected - for instance i’m not able to use a Transform Vector node inside of a layer blend - i get an "Invalid node used in vertex/hull/domain shader input when I use it and plug it into the Alpha of a Blend Material Attributes node.

Noticed something a little strange when trying to work with the new system a little bit. Putting a static switch parameter in the actual material works as normal, but putting one in the material layer itself makes it so parameters from both true and false show up in the material instance. I don’t think it has any performance difference, but usability wise it does clutter things a little bit in the list.

Other than that though, I’m really enjoying the new system so far and plan on changing my project over to use it for a lot of things! The only thing I really wish it had was some way of reducing instructions if a pixel was 100% masked (out of concern for performance using this project wide), but I’m not sure if that can be done.

Alternatively, what I would really love to see is some way to bake down the end result for the standard maps (base color, packed, normals) at a given resolution (or better yet, at a uniform texel density) across the entire project at once for lower spec machines. That way if it does become an issue for some users, there’s an easy way to scale it back in an options menu without redoing the textures for the whole project.

These are very good points! Gears of War 4’s Coalition had a way (in their custom material system) to bake down several layers into flattened ones - but skipping those intentionally marked as dynamic/tiled. The materials seems also to be easy to assign and swap. Unfortunately the presentation is behind a paywall.

Spent a bit more time working on it tonight and found a few bugs/problems with the layering system:

If you tweak a material layer enough, eventually it stops updating in the world and doesn’t refresh on a new compile. Requires an engine restart to fix.
Thumbnails for instances don’t update if you change the properties, leading to misleading appearances (so a thumbnail showing a red sphere may really be a green one). If you duplicate the instance however, the new generated thumbnail is correct.
The parent dropdown doesn’t filter the instances properly, it still lets you pick an instance from another material layer entirely. This leads to buggy results and requires a little bit of fiddling afterwards to fix it. Not sure if this is intentional, but it seems like the intent is to have it only show instances for the material layer you pick for the parent, which is a great way of filtering things. Right now though, as stated, it shows instances for every single layer, not just the selected one.

My gosh, this was my dream for so looong! I’ve been working with layered materials for ages!

Not at the moment - but this is something we would like to look into for future updates to the feature.

I passed both of these along to QA to take a look at - thanks for letting us know!

Yep, this is actually on my list to fix :smiley:

Awesome, great to hear! The masking is something that we would like to investigate in the future, so thanks for the feedback there as well.

We have seen this with texture parameters and are currently investigating - if you are seeing it with other parameter types, could you upload a screenshot?

This should be fixed in the next preview - and yes, the intended goal is for the asset dropdown to only show instances of the material in the “Parent” field. If that parent is the same in the master material/the parent of the instance you’re currently working on, sticking to the filtered instances should give you more performant variations.

Thanks so much for all the feedback, this is really useful!

Also, for everyone working with Material Attributes, check out the Get, Set, and Blend Material Attributes nodes. They’ll make changing just a few attributes way easier than having to reconnect all the nodes of a Break to a Make. More info about them is in the 4.14 Release Notes