Hello. I’ve done the Uber thingie here for those interested: https://drive.google.com/open?id=134W9blKxoJ2vI-vGzoSdaYlI-q8xDSB3 Hope you like it 
I have an idea, tell me if it’s going to work with this.
Have one material in wireframe mode with emmisive lighting and a vertex displacement ever so slightly inflating the model. And then another material “underneath” with just a flat color.
Would that work?
I’ve been trying to figure out how to render a wireframe beauty shot of models in UE4, I can do it in 3dsmax or blender sure but doing everything in engine would save me a bunch of time.
I keep getting crashes whenever I try to open a material with the feature enabled, but I’m also running off code from the 4.19 branch in GitHub, not the preview build; either way, I’ll toss up a callstack and use case to the bug reporter a bit later.
In 4.19 Preview3 when I click and start dragging the material layer in the editor’s content browser I get instant crash. Cannot open any of the materials done in 4.19 preview2, unfortunately cannot use it as it is. By the way, I’ve updated today the Uber shader I did few days ago, see the link in my post #41 Is there a way to reverse the engine to preview2 for now?
We’ll check on click and dragging, but there were a few crash fixes just submitted that unfortunately missed the cutoff for Preview 3.
No worries, take your time. it’s an experimental feature after all Still love the idea. By the way, I noticed the texture samples are not turning off with switches, and overall materials are not optimizing, so the instruction count is not dropping while ticking switches off in the material instances. But I guess it’s due to the preview version of the engine, at least I hope.
Everytime i press the empty field of background in the Material Attribute Layers UE4 crashes. Every time.
I know this is a preview and all but …
@erik007 is this happening with preview 4 too?
The crash on empty Background field should be fixed in Preview 4 - if you still see it after updating, could you please list your repro steps here? Thanks!
How do I change Paramters in a Dynamic instance?
The experimental version in 4.19 doesn’t yet have Blueprint support. This is definitely something we’re going to get added before it leaves experimental - we just want to have a better workflow than having to manually specify not just the name of the parameter, but whether it’s on a layer or a blend and what index it’s on. That could get messy, and so we want to take the time to implement a much smoother system.
Thanks!
Why don’t you implement it the way how it was before the layering system with Material Functions: Same Parameter Name drives all Layer Parameters with the Same name.
I would definitely like the ability to switch out layers at runtime. I hardly ever use material instances within the editor but almost all of my assets create new dynamic instances of materials at runtime.
When it comes to landscape blend functions, it would be really useful to have a landscape layer sample parameter that can be exposed in the blend function. Is there anything like that?
Also is it possible to assign a material layer directly to a mesh?
I’ve only been cracking at this a couple hours now, but I personally see this system being very useful to my workflow. I’d love to see a “randomize parameters” button by the layer stack that would go through and randomize all the parameters attached to each material layer. I guess you would need to set a range for each parameter somewhere along the way though. Is that something that could be implemented?
I could see this being used dynamically when objects spawn in to populate scenes, get some slight material variations across objects in the environment every time you play on the same map.
Hey, I watched the stream yesterday about material layers and there was some hesitation to implement things such as dynamic mat. etc. I just wanted to say that, in order for developers to adopt material layers, it needs to be at least equivalent in terms of features to what we currently have with regular materials. If material layers do not support landscapes, or they do not support dynamic change from code (all this being possible with regular materials), then this will be a no-go (at least for me!). So please make sure you are not restricting what we can do with mat. layers in any way compared to current material system, this is a major requirement for me and probably for many.
Also at release time, please clearly state the limitations compared to regular materials, I do not want to move all my materials to the new systems to realize I am hitting a show stopper at some point. In other words I’ll move to the mat. layers only when I can be sure I can do at least the same things as with regular materials.
Yesterday during the stream someone showed a new node that allows you to select with a drop-down menu which channel from a texture a mask will be selected, R, G, B and Alpha. I would request the option to select the “Black” Color as well, as in, no channel selected, nor alpha. In my workflow I when I pack Material Masks into channels sometimes is useful to leave some UVs in the black areas to use one more material.
Hi Raildex, hopefully this one was answered somewhat in the stream we did yesterday but I’ll try to clarify the changes and some thoughts:
- Parameters in materials are still driven together if they share a name
- Parameters within a layer (or blend) are “owned” by that layer and any with the same name are shared as a single parameter, similar to materials
- Having parameters owned by layers allows you to use multiple of the same layer with different instances and customization e.g. one base metal layer tweaked to gold and then copper can be used in the same layer stack, each layer instance using it’s own copy of the parameters.
That said, we’re still finalizing the best way to control which parameters are owned and which are shared (globally) across all layers. This is something we feel is important to get right as it will likely be core to the final workflow, we’re not there yet in the preview however.
Hi RyanGadz, so there’s two points to address here, one Lauren discussed above and the other we talked about on stream. Again I’ll try to clarify what I can, but this may be a little lengthy so apologies if it’s a little more in depth than you wanted:
Dynamic Material Instances:
Dynamic instances will work with materials using layer stacks. As Lauren discussed above, right now there isn’t a good interface for setting those at run-time but the functionality works under the hood, you could expose it yourself in the 4.19 engine code but would require lots of hard-coded layer numbers and offsets to control which would be pretty painful to work with. This is something we are planning to address for the final release.
Dynamic Layers (Part 1):
So the initial idea we had for a future release, probably not the first version, is the ability to add a layer to the stack and flag it as dynamic. This would wrap the layer in a dynamic branch so you could effectively switch it on and off in a cooked game. There would be a cost here even if the layer was off, though ideally much cheaper than evaluating the whole thing and blending out the result. The major restriction here is that you would need to build the full stack of possible layers in your material, you wouldn’t be able to swap out the layer entirely for something new. For cases like damage effects or an expensive wetness effect this is likely the right tool.
Dynamic Layers (Part 2):
The next step would be something much more free where you could change the layer stack at run-time, but this isn’t something we’re evaluating in the near future. An important thing to note about materials is that when you build a graph that gets collapsed down to code which goes through the platform-specific compilers and processing to generate the actual shader that is used to draw your object. That process is very slow. When cooking and packaging a game Unreal Engine gathers up all of your referenced materials, compiling all the variants you might need then builds them upfront so that at run-time you can swap them freely with minimal cost. Changing the layer stack requires each of those shaders to be recompiled to account for the new graph code, which isn’t something we could do dynamically without adding a huge stall every time you swapped a layer.
An alternative might be to let you create a pool of user-selected layers, pre-compile all the variants for you and then under the hood pick the best match when you swap. That would work, though would require some fairly invasive material code changes and you’d probably find a surprising amount of memory eaten up by all the shaders created.
Dynamic Layers (Part 3):
A more realistic option Lauren touched on in the stream is better grouping of parameters into a single object, this would open the door to swapping compatible layer instances at run-time. As long as the layer instances match (static switches and such), the same parameters should be valid and we could certainly try making it easier to swap them wholesale.
So, it’s not to say fully dynamic layer stacks will never happen, if we all agree that’s the right move and there’s a major benefit there we’d invest the engineering time to work on a solution, but that is time that could be spent doing something else, say general material system improvements or additional features. As we tried to stress in the stream however, feedback is key, we need to make sure we’re developing the right tools that people will benefit from, so please keep it coming!
Hi MarGon, as I mentioned in the stream, landscape compatibility isn’t something that’s been directly targeted for this preview version but is something we’ll aim to address for the first release. As landscapes already have their own unique system for stripping layers when not used on a landscape tile this might warrant something unique on the layer front too but that may end up outside the scope of the initial push.
Not at this time but there’s no reason it can’t be similar to material functions, where applying the function generates a material for you.
A cool idea but definitely outside the scope of what we’re aiming for with the first release! It would make a pretty interesting editor plugin though. If we explored the suggestion above in Dynamic Layers Pt3, that might be a fairly convenient way to go about it but it depends if you want authored variant instances or truly randomized.
Hi Eyoli, hopefully the above comments from Lauren and myself clear this up! Ultimately material layers will be compatible with all existing material functionality.
Absolutely, we’ll try to make sure the final release notes have the current limitations in there. I definitely would not recommend anyone switch their full production pipeline to material layers yet, the system is still in flux and isn’t complete. The feature is still marked experimental at this time so swapping over would be unwise.
Hi MDiamond, that was the channel mask parameter. I added it to help the common operation of picking a single channel from a texture or color which comes up a lot with layers and we noted many cases ended up using static component masks for this. As each of those added potentially introduces a new permutation we wanted a cheaper alternative that allowed better re-use of materials, especially with an instance heavy workflow. Can you please go into a little more detail of how the addition would work?
Internally that node wraps up a vector parameter and a dot product to pull out the channel data, so in that case a black value of 0 would always return 0 i.e. no mask. I could see that having it’s uses to blend something out but if you have any good use-cases it would be nice to better understand the potential here. 
Thanks for all the feedback so far everyone!
I have to dig an example of using a black ID, for now I guess its easier to educate my team to start painting Material Masks starting with the black color so the bottom-most material will be in black areas and each subsequent layer is read from the next channel.
I did however found an example of when adding masks from two channels could be useful. In the pics bellow, the chair fabric is two tone, and when blending materials, I’m selecting two channels to the fabric part, but then I’m using the Override Base Color and selecting just one of the channels.
This keeps my tiling, roughness etc values the same and makes me not pay the instruction cost of adding another fabric layer and using the same parameter values as the first fabric layer. I guess for weird exceptions I will make my own blend function that allows dot products of more channels at once, which is the beauty of the current implementation as I see it, unless there’s a better way to handling cases like that.
That looks very useful! Great work 
As RyanGadz said, the ability to switch layers at runtime would mean a lot too. Without dynamic layers, this feature is “just” a workflow improvement for manually made assets.
With dynamic layers, this feature also improves visual customization options at runtime, which is non-negligible!