The snow shader adds a top snow dusted appearance:

Overview of the graph

Parameters

It supports a couple of parameters to drive how much snow will be on the model.

Snow Start: A value from 0..1 of where the snow will start lerping / appearing.

Snow End: A value from 0..1 of where the snow will finish lerping.

Everything else is different textures for the base / snow effect.

Graph Setup

Creating the top mask

Using a normal vector configured to world with a dot product and Vector3.up works well to get the top mask.

The only issue is that this will of course return [-1, 1] since that is the range of the dot product.

The remap node is a handy node in this case, remapping the output from [-1, 1] to [0, 1]

Right now we don’t have any control over where the snow actually goes. You can see from the remap node that it is a smooth gradient from 0 to 1 from bottom to top. To turn it to a point where we have black where we don’t want snow and white where we do, the smoothstep node is great.

It takes a minimum value and returns 0 for anything under it, and 1 for everything above a max value. It does an interpolation between min and max otherwise.

Dot Product

Since we are doing a dot product with the global Vector3.up. The dot product of 2 vectors will be 1 if they are facing the same direction, -1 if they are facing opposite, and 0 if they are 90 degrees from each other.

Note the geometric definition of a dot product is:

Since we are dealing with normalized vectors, $\lVert A \rVert$ and $\lVert B \rVert$ will both be 1.

This site has a nice visualization: https://maththebeautiful.com/dot-product/

Mixing a second material

Since the snow will be mixed with two materials, a base and a snow a little bit of effort has to be put into the mixing. Here is the base, roughness and normal mixing.

Both color and roughness are the same node setup. I think there is not much to say about them other then the “T” value comes from the smoothstep discussed above.

A little bit of care has to be taken when lerping normals. The normals have to be normalized after the lerp.

Vertex movement

This graph uses a little bit of vertex movement to get the snow pushing out ontop effect. Each of the vertexs will be moved along its normal to sort of poof out the snowy parts of the object. There is a requirement to have enough vertex density for the effect to make sense!

Part of the motivation of this thinking is that in godot the NORMAL comes in view space by default:

NORMAL (vec3): Normal that comes from the vertex() function, in view space. ...

INV_VIEW_MATRIX (vec4): View space to world space transform.

Convert from view space to world space

n_world_space = INT_VIEW_MATRIX * vec4(NORMAL, 0.0)

Convert from world space to local space

mat4 inv_model_matrix = inverse(MODEL_MATRIX);

vec3 n_local = (inv_model_matrix * vec4(n_world_space, 0.0)).xyz;

Working with vec3 and vec4

When working with some of these values we have to use a vec. There is a handy shortform:

vec4(vec3, value) which converts this to vec4(vec3.x, vec3.y, vec3.z, value);

To retrieve values, or convert down we have vec4().xyz which will return a vec3.

View/Camera Space

View space (or camera space) shifts the center of the universe to the camera lens. While it is natural to assume the camera looks straight forward down the Z-axis, Godot’s right-handed coordinate system flips this logic. The positive Z-axis actually points backward out of the screen toward you, meaning the camera is technically staring down the negative Z-axis into your 3D world.

World Space

Think of world space as the master grid of your entire game level. It is the global, shared coordinate system where the origin (0, 0, 0) acts as the exact center of the universe. All transformations are calculated relative to this grid. If you place a cube at (5, 0, 3), you are defining its absolute location within the world, regardless of how the object itself is rotated or where the camera is looking.

Model/Local space

Think of model space as an object’s personal, internal blueprint. The origin (0, 0, 0) is simply the pivot point of the mesh itself. Whenever you scale or rotate an object locally, you are manipulating it inside this specific space. A 3D cube might be placed a thousand miles away in the game world, but inside its own model space, its vertices still sit perfectly around its own center, ranging predictably from (-1, -1, -1) to (1, 1, 1).

Tangent Space

Normals point in the direction of the z-axis away from the face. Tangent space originates at the point on the polygon that it is being calculated at. The z-axis is point straight away from the mesh and the x,y are pointing perfectly flat along the polygon.

Links

• Godot - Fragment Built Ins
• Godot - inverse function
• OpenGL - Normal Mapping
• Github comment - ajhmain

I am using Unity 6.4 LTS and URP for this project.

This is a simple effect that has an outline disolve. Its being used when an object is shown / hidden in a project. It would be used for things like Sci-Fi spawn / despawn, xray vision / deactivation mode, ghostly transitions, etc.

Here is a sample with a slider placed into the shader graph, this slider is driven by a variable normally.

Utilizing inputs we can customize the following elements:

• Color
• Disolve Progress
• How thick the edge is
• Color of the edge

Overview of the graph

Graph Setup

Because we are using alpha clipping the shader must have alpha clipping enabled.

Step node

Step node returns 1 if in > then the edge value otherwise 0. This can be a great way of developing masks. For example:

• if the input is 0.4 and the edge value is 0.5 then it will return 0.
• if the input is 0.6 and the edge value is 0.5 then it will return 1.

We can develop an interesting alpha clip with this, creating a bit of a fade out effect.

Edge Effect

Because the gradient is smooth, we can use it to also get a bit of an edge effect with the step node. This is a little subtle in the images.

The smooth gradient is important, without it the outline can’t exist. We are essentially using the smoothness to determine how thick the line edge is. Because both the line edge step function and the alpha clip step function are operating on the same input, the edge step function is just cutting away a little bit more than what the alpha clip is using. This little bit more is the edge effect size.

Another way to think about it is to think we are developing a mask with the step node that defines where the base color is. The edge will be everywhere else.

Different Types of Noise - Gradient Noise

Different Types of Noise - Voronoi

Properties

Links

• https://docs.unity3d.com/Packages/com.unity.shadergraph@6.9/manual/Step-Node.html
• https://docs.unity3d.com/Packages/com.unity.shadergraph@6.9/manual/Lerp-Node.html

Once this system is in place you can have reasonable confidence that the prefabs are not being altered, the settings are remaining in place. This allows for people to alter the prefabs without having to consider issues like setting overrides or scene based links breaking. This ends up being a more robust prefab because you have enhanced guarantees that it is not being modified in many different ways. To enable prefab overrides a top level script can be used to act on the prefab at runtime.

Here is an animation of the read only behaviour being triggered:

And here is the flow for altering a prefab:

Builds

We decided on having dedicated builds for desktop and VR. We wanted the ability to turn off VR. To do this we needed a couple of things.

1. Some way of configuring the project to be in VR or Desktop mode.
2. A way for the project to know what mode it was in and spawn correct player prefab
3. Unload VR related loaders.

Configuration

Configuration is handled by a ScriptableObject that looks something like the following:

[CreateAssetMenu]
public class GlobalConfiguration : ScriptableObject
{
    [HideInInspector]
    public bool useVR;

    public void TurnVROn()
    {
        // ...
    }

    public void TurnVROff()
    {
        // ...
    }
}

A custom inspector is used to introduce a button that will trigger the TurnVROn and TurnVROff functions.

Configuring VR Loaders

The following chunk of code will assign a loader.

XRGeneralSettingsPerBuildTarget buildTargetSettings = null;
EditorBuildSettings.TryGetConfigObject(XRGeneralSettings.k_SettingsKey, out buildTargetSettings);
XRGeneralSettings settings = buildTargetSettings.SettingsForBuildTarget(BuildTargetGroup.Standalone);      
XRPackageMetadataStore.AssignLoader(settings.Manager, typeof(Unity.XR.OpenVR.OpenVRLoader).FullName, BuildTargetGroup.Standalone);

Lets break down each of the lines.

1. XRGeneralSettingsPerBuildTarget buildTargetSettings = null;

   We are creating a variable to store our XRGeneralSettingsPerBuildTarget in.

2. EditorBuildSettings.TryGetConfigObject(XRGeneralSettings.k_SettingsKey, out buildTargetSettings);

   Retrieve the build target settings and store them into buildTargetSettings.

3. XRGeneralSettings settings = buildTargetSettings.SettingsForBuildTarget(BuildTargetGroup.Standalone);

   Get the XR settings for the Standalone (BuildTargetGroup.Standalone) build.

4. XRPackageMetadataStore.AssignLoader(settings.Manager, typeof(Unity.XR.OpenVR.OpenVRLoader).FullName, BuildTargetGroup.Standalone);

   Turn the OpenVRLoader on.

If we focus on line 4, we could also do XRPackageMetadataStore.RemoveLoader(...) to remove a loader.

Other types of loaders can be removed / added by changing the loader type from OpenVR to whatever loader is being used.

See also:

• Unity XR Management Documentation

Prefab Management

Prefab management is fairly straightforward. Simply have a PlayerSpawner that will look at the globalconfiguration.useVR value and spawn either a VR prefab or a Desktop prefab depending on the scenario. When the prefab is spawned a game event is triggered to let the scene know so it can self-configure from there.

Live demo

Live demo