[NOTE] This tutorial is based off of Part 1, you can find it here.

Now we have our shader created and ready to mess with through script, we need to decide what we’re going to make.

In this tutorial, we’ll learn how to add or minus a scalar value to our material through scripts. This approach is massively crude, but by learning this basic concept, we can go on to create more complex and interesting effects through scripting.

So, the end goal of this guide –

Pressing [Enter] will cause the value to go UP

Pressing [Delete] will cause it to go DOWN

Note, I’ve made some superfluous scripting for the purpose of the tutorial – it simply prints what button was pressed, and what the new value is. It can really be useful to have some kind of network setup so that you can see what is going on under the bonnet – sometimes, you might find a script or system you’ve set up doesn’t exactly work how you expect it to, and when you debug through traditional methods, most notably Variable Tracing, the variable will not be in scope and you’ll be bum out of luck. I’ll include the very very simple script right at the end, but for now, lets get onto changing materials through programming.

Once we’re done, we should end up with something like this –

Step 1 – Decide where we want our functionality

The location of our script relies entirely on the context. Ask yourself – do we want to give the PLAYER the ability to change visuals, or is it more of a transient, passive thing? In this instance, we want the PLAYER to have control, so we’ll put our functionality inside the Pawn class. Setting up a custom game mode and pawn is a bit beyond the scope of this tutorial, but if you’re struggling, simply jump into any template by Epic and alter their Pawn classes.

However, if we were to work with something that is not tied to the player’s input, we’d want to either put it in an abstract actor class, the game mode, or the actor itself – whatever is most suitable. In my Seasonal Environment, i used the GameMode, whereas if we were having a cube change colour ever X seconds, it would probably be most appropriate to put the logic in the Cube Actor itself. If we want to change something on a more uniform, level wide scale without tying the mechanic to just the ONE level, we might want to consider an abstract manager class – but we’re getting ahead of ourselves.

We need the pawn because of how the engine handles Input. By default, there are only one or two classes liable to receive inputs from your keyboard; the Pawn, understandably, is one of them.

Step 2 – Scripting

Although this step isnt TOTALLY necessary, I always like to make my scripts as variable as possible. And, to do that, well, we’ll need some variables. Create 2 Float variables called IncreaseAmount and DecreaseAmount. This will be the amount we’re going to increment or decrement the Scalar Value by after each event if fired. I know a single variable could be created to handle BOTH changes; however, I like having the option having different increment/decrement amounts.

Now we have all the variables we need, its time to look into the saving grace of scripted art – Gets/Sets for Parameter Values.

This node is EXACTLY what we need. It comes in two flavours;

Get/Set Scalar Parameter Value – access any Scalar values we set up in a specified Material Param Collection

Get/Set Vector Parameter Values – access any Vector values we set up in a specified Material Param Collection.

The nice thing about these nodes is that it will automatically detect content in our content browser, and list them in the dropdown boxes. If you remember, in Part 1, we set up a MPC (MPC_TutorialValues) and populated it with a single Scalar value (MaterialAlpha). If you see below, the node found our MPC, and ONLY listed the scalar value we put in there.

The above script will detect input from the player, namely when they press Enter or Delete. Enter increases the value and Delete decreases it. We get the value, subtract/add a value to it, and set it to our new, altered value. Because the value is tied so directly to the shader, all we have to do is alter the value externally and the shader will update in real time.

Step 3 – Conclusion, and why bother?

I know, its fantastically simple. However, if we consider the implications of this concept, we can start work on some seriously complex systems. We dont HAVE to drive this through key events; we could like an event to a timeline, to a gate that opens or closes, to an OnHit event, anything!

But…why? I recently worked on a project that involved improving previous work from earlier years – the game had a “rage buff” that caused the player to move more quickly and change colour. The previous system was a straight up material swap – this required 2 materials, which, in the grand scheme of things, adds an extra draw call, an unnecessary overhead. I created a new system that only required 1 material, and blended between the two based on a custom BuffRecieved and BuffEnded event. In the end, we had a significantly prettier effect and one less drawcall to worry about. So….thats why we bother.

As always, feel free to get in touch and follow me on Twitter @tomshinton for more tutorials and articles.

OH, and the print to screen event

Just as a side note, in-case any of you guys are interested, i use a simple Print To Screen custom event that accepts a new value and a string in order to quickly keep track of things.

It might seem trivial, but having something like this already defined is actually massively useful – if you’re into this field of work, then having a quick and easy way of getting feedback from your scripts without having to variable trace can save a lot of heartache.

I wont go through step by step, but here it is. Its actually very simple, it simply accepts 2 arguments, a string and a float, and concatenates them before drawing it to the screen. Im considering creating a simple MacroLibrary for stuff like this, so if you guys have any suggestions, feel free to message me and i’ll see what i can do.