Starting to go into the interesting field of water shaders, I’m trying to understand in detail, how the translucent water shader by Epic works, which is found on marketplace and described by Alan Willard in https://www.youtube.com/watch?v=-XyeFXdKi08.
Here, I’m focusing on the water depth calculation. It is a more theoretical thread, but I’m not just interested in throwing ready made stuff into my level. Instead I want to understand how the nodes work and this is useful for doing own stuff later on as well, expecially all that depth based stuff.
This is the part of the Shader doing the depth - quite confusing to me at the first glance, especially that Divide node, even along with Alan’s presentation.
I made the following picture of how I would go for that - to understand the math behind the nodes arrangement
X is the depth perpendicular to the water surface down to the ground - that’s the water depth we actually want to calculate.
For the CP and AWP positions, only the Z-value is of interest to get the camera height above water CH = CP(z) - AWP(z)
So this means:
(X + CH) / SD = CH / PD
which results in:
X = (CP - AWP) * (SD/PD - 1)
There’s no extra height information involved. The shader for this looks as follows:
BTW: Not sure, which is better: first subtract vectors and then mask or first mask and then subtract scalars only?
I do not get the point, for what purpose the original shader needs the Water Height Parameter. It even requires to use a blueprint to get that parameter set to the water surface z value in the construction script to make the shader work.
EDIT: I even wondered, why passing in water height as parameter to the original shader - actually, shouldn’t this be already contained in the Absolute World Position nodes Z-component, because the water is just a horizontal plane? I tested this, and it also works perfect. So no need to pass in water height even when using the original shader logic.
I did a comparison material just to visualize the depth by color changes and switch between both versions, just feeding in results into a switch:
and there’s no visual difference, except that the orignal needs that change to the height parameter whenever moving the plane up/down. Don’t bother all that stuff in my test scene…
First image shows original version:
The modfied version
The modified version, just changed Z for the water plane - no need for height parameter changes
I believe, my version is simpler and less error prone, but I suspect, that I might be completely wrong and might have missed some important point here.
Someone with any thoughts on that?