Ok, so now that I have a bit more familiarity with creating materials in UE4, I have some questions from a development stand point. While the flexibility is enormous, I anticipate that shader complexity can definitely play a role in performance.
What kind of materials do you typically make for your vfx? How complex are they? Do you have a few “master” materials that you instance? How do your materials differ for mesh effects versus straight up particles?
I think that’s all the questions I have for now. I’m super excited to start experimenting with different settings and seeing what this engine can really do!
Edit: Changed “Master shaders” to “master materials” for clarification.
Well you can use shaders for your advantage of achieving a specific/unique look/feel to your work. The thing is that UE let you make “materials” that not the professional statement for shaders since a material is an instantiate of a shader. Now that comes with limitions in terms of shader developing in unreal but for an artist it gives the easy approach to work on the visual feedback. That said for a developer messing with unreal shader eco system is a bit a pain.
About what kind of materials it’s a big question ^^ but start with small things like scrolling UV to get animated textures , or scrolling UV and Normls to get even better look . Also distortion effect or manipulating the transformation of mesh (vertex shader).
The best way to approach “shaders” for vfx’s is potentially one master material in which you put all the control you need (with the use of parameters,static switches, bools etc) and use material instances (and material instance-instances or “Master Instances”) to change settings like panner speed, brightness, which texture/mask you are using, other values and branches.
That way you can have one or two master materials that only need value tweaking.
Then there will always be effects that just need something so different you can create separate materials for that, hopefully further down the line using that material for multiple effects as well.
The advantage of matInstances is that they dont need to recalculate what did not change and ue4 will love you for that.
Now if you change something big in an instance (static parameter switch that changes 50+ calculations or whatever) you might want to make that a master “instance” of which you branch of other instances so that the big change doesnt need to be recalculated anymore.
Similar to what Yoeri said, building master shaders is usually the way to go in production. Since you cannot change a shader’s lighting model during runtime, I usually go with having a few different master shaders, i.e. UnlitTransparent, UnlitMasked, LitTransparent, LitMasked.
The shader networks get pretty big though, so take it one feature at a time! I usually start out with just being able to control color and opacity, and from there I add things as they as needed. Before you know it you’ll have a shader that does depth fade, distortion, UV tiling and panning, texture blending, exposure compensation, velocity blur, etc etc etc etc
I would abandon all master shaders for vfx It is easier to optimize and debug if U got small simple materials. Also in many cases U will need something unique.It also enable fast iterations .Later U can merge all similar shaders. Also start using render to material for optimalization - it will be next big thing in UE4. Render everything that is static to texture if possible. About complexity - as small as U can - but not smaller.
Honestly, with UE4, I would no longer approach as a master shader base in the old way - ie one shader asset. This is due to the problems listed above - they are just so big to maintain and end up being a little too unwieldly.
In larger productions I would favour using either Material Functions, that encapsulate all of the feature/s you want, and plug those in as and when you need them. You can go further and use Material Functions that contain material attributes too - meaning an entire shader can be held in the Material Function and its plug and play. You get the plus sides of a master shader - quick to produce instances/variants, global optimisations or improvements - but will still have flexibility on a per material basis.
You’ll still get long compile times and a few production issues, but the upshot is, if you are clever about it, you can override stubs on the material function. So you could explicitly override bits of your master shader, if you need just a small tweak.
Another negative would have be visibility - if you are hiding lots of nodes in to one function, it can be difficult for an end user to know or gauge how expensive something might be! Definitely worth being wary of.
TL:DR; I’d use Material Functions that contain MaterialAttribute systems to quickly build up flexible shaders whilst not being beholden to one single shader asset. A few advantages, a couple of same-old disadvantages.
I dont agree with Marcin in this case.
time/workflow wise just editing a few parameters in an instance is almost always faster than working in the material editor due to recalculations when tweaking/iterations. -but, thats partly personal preferences, partly how powerful the rig used is.
I do agree with the render2Texture part, which can be a nice performance gainer.
Material functions are (afaik) recalculated per material, so the optimization you (Alex) mentioned are mostly not true.
Unless something changed within ue4 that I missed that actually does share information between mat functions in seperate materials.
Ah, I may not have been too clear. You don’t gain optimization as such, but you gain ease of use. If you’re using one shader across your entire game, and all you want to do is tweak it for one effect/edgecase, you’ve got a long recompile time as it goes over thousands of shaders.
If your using material functions, yes, you’ve still got a long time to wait if you tweak that function, but at an asset level you’ve got less time to wait as there are now less dependancies from your material.
Basically you shift up the long compile times & dependancy chains from a shader basis, which is more likely to get tweaked for any number of reasons, up to a function/asset basis.
When I mention optimisations, I mean you still get the ability to perform global optimisations across all shaders by tweaking these functions; you’ll still have a long time to wait, but there’s no disadvantages to moving dependancy chains up. You still maintain all the reasons you’d use Master shaders for, but in an easier to iterate way and actually more flexible.
Another example:
Lets say you shift out a master shader in to a function that contains all your typical material attributes.
Using this, you expose a function Input for TextureCoordinate.
Now you can, at a material level, either just use your MF as a standard material base as normal, or if you find you need to distort UVs just for this one occasion, you just override the function input.
Because you don’t now have 5000+ shaders to recompile across your game, you are dealing with a smaller section. It’s all about removing those child dependancies for me.
And if all that is by-the-by, at least you dont have to work in yet more static switch gates!
Edit: this is all from experience having had to manage several environment shaders for a large team. I rolled their master shader - which took ages to compile as every asset in the project had a dependancy on it - in to a MA_MF, and had several master shaders doing slightly different logic. They all used the core master shader which was familiar to them, but on an asset basis they’d do something completely different. Of course that new function was a complete PITA to update, but there’s no getting around that.
This is, tbh, more technical art than VFX in this example, but it’s for sure how I’d build up my VFX assets now.
Further Edit: this is all with regards to larger production teams btw and more about the esoteric side of managing assets. I might have gone off on a tangent, but it’s just what I found
Thats exactly what you’d do in a material instance, if your master material is set up properly though, and no need to compile a bleepload of shader instructions again.
You’d only go back to the master material to add functionality, and lets be honest… after a few projects you can basically copy/paste most of it as a proper master material would work in multiple situations.
By now I have one master material for my vfx I could use in 80 - 90% of situations, regardless of theme, style, etc, and due to proper usages of instances & master instances the instructions and recalculations are extremely low.
That said, thats what I’d do for big productions.
If I just make stuff for myself, or fast prototyping, id just drag & drop a few nodes + MF’s to get the result I want.
Also, and probably also very important, is that in my case I do mostly fantasy/magic kind of vfx, as realism (bullets, regular explosions, muzzles, etc) bore me to death.
If you go the master material route, you should put everything behind switch parameters, and default everything but just the texture multiplied by particle color and opacity as False/Off. Then just turn on what you need per instance. Usually you can use a master material for most things, but keep flexibility for custom materials if it’s something you can’t achieve with your master and it’s going to be awesome! Try and keep your more inherently expensive materials cheap in instructions and node complexity. Things like Volumetric Directional lighting for translucency is expensive, but actually makes use of normal maps for lighting your particles, so we use it almost exclusively for smoke, and only when it’s going to be persistently on screen. It’s just 3 texture calls and a few multiplies, and a dynamic parameter for flow map control.
Fun fact: comment boxes can help you keep your materials organized, but you can also change their color as well!
For materials on meshes, make sure to include vertex color in your material, and use the SubUv texture node instead of the standard if you want your flipbook to run on your mesh.
I generally try to make and use material functions for things that take up a lot of screen space, just for organizational purposes.
One last thing, if you are going to make a master material, always, Always, ALWAYS, give every parameter /parameter switch a unique name. I can’t tell you how many times something didn’t work as intended because Texture_Pan_X was used twice when I should have numbered them as well. Switches can really test your logic choices when you are hooking them up, so always be prepared to iterate and refine how things are organized.
Wow, all of this is extremely helpful! Looks like I’ll have a lot to mull over in how we approach things. I hadn’t even considered Material Functions, so I’ll be looking into that as well.
After 42k recompilation several times in landscape and player building master cuz of function changes I tend to avoid functions. Id rather keep some copy paste code in some old file and paste it in small materials. I cant imagine making vfx without opened material editor… But thats just a habit. Funtions can be sometimes. replaced by render2texture… I just made wind system that render small tilable texture with direction and power and just sample it in grass bushes and trees. That replaces some nasty and heavy functions…
From my experience, I tend to agree with @alex.underhill on this one. I am a fan of material functions over monolithic master materials these days, excepting in cases where you know you can get a lot of mileage out of a single master material.
A good example of that would be something like “flares.” Most of us have authored about a million and one flares for particle systems, and because they are going to be so widely used it makes a lot of sense to have a single master “flare shader” that has a lot of behavior sectioned off via switches and material instances that change those behaviors.
Going with master shaders for your really common building block (flares, sparks, smoke) and one-off shaders for things more specific seems to be the method I end up falling into. Of course at FXVille we are nearly always working on teams with existing practices, so by far the best thing to do is to do what the other artists are comfortable working in.
This is a great mention and a really important point that I think lots of answers (including my own) have glossed over!
Master materials have huge advantages in terms of fewer draw calls, better sorting, and optimizations that propagate throughout the entire game, but this absolutely does not mean that 100% of your effects have to use this shader! Let your master shaders handle 85% of your effects, and go nuts on custom shaders for those other 15%. “Default shader” might be more of an apt term than “master”.
I’m just stressing this point since I’ve met lots of artists coming from UE4 with a “One shader for one emitter”-kind of mentality, which can quickly create lots of issues.
+1 for that. that exactly what I meant in my first comment because they make materials and not shaders.
its messing two definitions and shader developers won’t recommend unreal mentanilty
Master materials have huge advantages in terms of fewer draw calls, better sorting, and optimizations that propagate throughout the entire game, but this absolutely does not mean that 100% of your effects have to use this shader! Let your master shaders handle 85% of your effects, and go nuts on custom shaders for those other 15%. “Default shader” might be more of an apt term than “master”.
I’m just stressing this point since I’ve met lots of artists coming from UE4 with a “One shader for one emitter”-kind of mentality, which can quickly create lots of issues.
I am not sure if master material is considered 1 shader. If U got many switches - every other combination got its own shader in memory. So there is no gain in that. But I d like to ask some expert in unreal4 1st
It is easier to optimize and debug if U got small simple materials. Also in many cases U will need something unique.It also enable fast iterations .Later U can merge all similar shaders. Also start using render to material for optimalization - it will be next big thing in UE4. Render everything that is static to texture if possible. About complexity - as small as U can - but not smaller.