Epic's DM-Deck map used in this example

Steve and I worked together on Criminal, which was an open-world game using Unreal Engine 3 -- an engine which is amazing for games with constrained environments, but struggles with open-world layouts. Needless to say, performance and memory footprint were one of the highest priorities of our lives.

The credit for this nifty trick goes to Steve, who has given me permission to reproduce it here (thanks Steve!).  Be sure to check out Steve's Site as well.

Why do we care about free?

In particular, a shader which requires a texture (otherwise known as "Maximum Texture Dependency Length", or "M.T.D.L." in UE3) to drive another, is incredibly slow.  

NOTE: There is a hidden M.T.D.L. dependency when using the "ReflectionVector" node in the Material Editor --it will not have the magenta outline. 

To quote Steve: 

The problem isn't that the shader has more than one texture - it's that the output of one texture is used (whether directly or indirectly) to drive the texture coordinate for a second texture.  I've always called this a "dependant texture" where one texture depends on the other.  This is bad because the shader compiler breaks the code up into three bits:  Before texture lookup, Texture lookup and After texture lookup.  This is so that one GPU processor can be running the "Before" part for one pixel while the texture hardware is looking up the maps for the previous pixel and a different GPU processor is running the "After" part of the pixel before that.  That way nobody has to wait while the textures are being looked up.  That means that it has to reshuffle your code around so that all of the textures can be looked up at the same time.  The texture lookup part can look up a lot of textures in parallel - so putting a modest number of textures into a single shader isn't all that expensive.

BUT - if you have the texture coordinate input of one map being provided by the output of another map then there is no way to split the program into those three parts because it can't look up the second texture until it's figured out what was in the first one (and maybe done some math on it).  So what it has to do is to run the shader in two internal passes where it does the true "Before" part, looks up the first texture, then skips over the "After" part - does a SECOND trip through the "Before" part to run any math that has to be done on the output of the first texture - then it can do the lookup of the second texture and finally run a second "After" bit to.  This means that the shader takes at least twice as long as it should - and probably much worse than that because of all of the internal reconfiguring going on.

Replacing that first texture with some math breaks that double-cost - and makes the shader run at least twice as fast.

Here are a couple of videos to compare their motion.

Implemented the standard way in the Material Editor, and a simple puddle can suck entire milliseconds from your GPU time (or if you're less technically inclined, think of it costing a couple of frames per second).  Too expensive for a shipping game.  BUT....we like rippling water.  We like it a lot.  And that's why you should care about getting ripples for free.  Here's how to do it.

Expensive Ripples - Shader Graph - click to enlarge

Cheap Ripples - Shader Graph - click to enlarge

Again, many thanks to Steve.  We can all now have free ripples without fearing the wrath of graphics engineers!

For this post, I'm using the "DM-Sanctuary" map included in Epic's UDK.

Original Image --> Distance Color Blend Image --> Depth Mask

Using the Scene Depth node, you can create a realtime depth mask to use in your shader, which I tend to do a lot.  One of the quick-and-easy benefits of using a depth mask is that you can tune foreground and background chroma and value independently to dial in the effect you're after.

For the purposes of this post, I've created a shader graph that enables foreground- and background-specific colors (currently multiplied), and individual saturation control.  The shader graph can easily be modified to control foreground/background brightness as well, or anything else you might dream up.  (See the link at the end of this post for the actual .upk file.)

Shader Graph (click to enlarge)

To bring the scene's depth into perceptible range, the node must be divided by a relatively large number (what I've labeled as the "Gradient Spread").  Here are some examples at different numbers.  Notice the castle fades more quickly to blue the smaller the value:

Once created, the foreground and background colors will of course remain relative to the player's camera, rather than the scene.  Notice how distance blues turn into oranges in the following progression:

Here is the UDK package file for the Distance Color Blend post effect material.