Hey everyone, I’ll try to keep this as brief as I can but the problem is a bit nuanced:
I’m curious if anyone knows a way to have generic “flash material” that, conceptually, I could “overlay” over top of a given static mesh. This would be used for when the enemy is hit to briefly flash a color indicating damage was done.
I realize I can simply swap materials quickly to achieve a similar effect then swap the materials back to their original state; but I was hoping to apply an effect that would flash then quickly fade off instead of instantly switching to and from materials in a binary manner.
I’ve got such an effect working in a single material, but what I don’t want is to have to apply this effect to every single material I’m using on an actor that can be damaged in the game. I’m hoping for a way to have this “flash” be able to be applied to somehow to any given mesh or material (whatever would work), that way I could easily swap materials on damageable actors and still have the flash effect applied to them.
I know this might be difficult to conceptualize in text, but if anyone could provide guidance to a solution I’d really appreciate it!
for the clear answer, Ryan! I’ll give this a shot soon enough, but this seems like a very practical approach. The trick with the sine wave and time of hit is very clever so thank you for sharing it!
Also, if I can geek out for a minute; Fortnite looks awesome
We have a few ways of dealing with this on Fortnite. Mainly master shaders and customdepth post processing.
I would personally recommend the master shader approach over the custom depth one.
A master shader is a material that is set up to be flexible with lots of parameters in order to handle a large number of assets. On Fortnite, all of the environment props are instances of a single master material. That material utilizes staticswitchparamters to give flexibility without bloating up rendering cost.
The really nice thing about that, is that you can put things in the master shader that are basically defaulted to “off” that you selectively enable either through switches for hand created variation, or by creating MIDs and modifying the parameters.
As an example, you could create a material function called “Flash Damage” and add a few input scalar parameters. I suggest you add one input parameter called “Time of Hit” to start. Inside the function itself, you take Time - ‘time of hit’. What that does is give you a new time counter starting at 0 but without having to pay to tick the MID via blueprint or timeline. Then inside the material function you can use sine or whatever to make a nice pulsing animation and simply add an emissive output component that is multiplied by that sine of time-‘timeofhit’ part. You could of course mix in any artistic effects you want such as fresnel.
That is actually how we cheaply animated many of the interactive bits to react to user touch for the Zen demo. You only pay the cost of setting a parameter once( the “time of hit” one I mentioned) via Blueprint once instead of ticking the MID every frame.
The other approach is to use the custom depth option to set which meshes are hit and make them emissive using the post process system. It would be a bit more complicated to individually animate the damage although should be doable.
I’ve been playing with this and have it to the point where I have a function which flashes with a sine using the time of hit as suggested, but I’m curious how to make it so the flash only happens once instead of indefinitely. Any further guidance you could lend? again for your time
It might be better to clamp the result coming out of that time equation, which would limit your result to any point along that sine (clamp the input of sine as opposed to the output).
I suggest you check out the content examples project and load up the “Math Hall” level. There are a bunch of graphs showing various functions you could use and some examples.
Thank you for you detailed answer. However, I still wonder about the performance implications, especially on mobile devices, since I need to instance a material (MID) for every actor that could receive damage.
as long as you aren’t writing to the MIDs all the time it shouldn’t be a big deal at all. The cost of the dynamic part is purely about how often you update them. Updating on tick is expensive for example. In that case you would want to use material parameter collections, but that doesn’t help if each update needs to be unique as with character damage effects.
