Snow Shader Tutorial with Unity

Let It Snow! How To Make a Fast Screen-Space Snow Accumulation Shader In Unity

Have you ever wondered how much time does it take to apply snow to all of the textures in your game? Probably a lot of times. We’d like to show you how to create an Image Effect (screen-space shader) that will immediately change the season of your scene in Unity.

3D model house village with trees in the background in Unity

How does it work?

In the images above you can see two screenshots presenting the same scene. The only difference is that in the second one I enabled snow effect on the camera. No changes to any of the textures has been made. How could that be?

The theory is really simple. The assumption is that there should be a snow whenever a rendered pixel’s normal is facing upwards (ground, roofs, etc.) Also there should be a gentle transition between a snow texture and original texture if pixel’s normal is facing any other direction (pine trees, walls).

Getting the required data

For presented effect to work it requires at least two things:

  • Rendering path set to deferred (For some reason I couldn’t get forward rendering to work correctly with this effect. The depth shader was just rendered incorrectly. If you have any idea why that could be, please leave a message in the comments section.)
  • Camera.depthTextureMode set to DepthNormals

Since the second option can be easily set by the image effect script itself, the first option can cause a problem if your game is already using a forward rendering path.

Setting Camera.depthTextureMode to DepthNormals will allow us to read screen depth (how far pixels are located from the camera) and normals (facing direction).

Now if you’ve never created an Image Effect before, you should know that these are build from at least one script and at least one shader. Usually this shader instead of rendering 3D object, renders full-screen image out of given input data. In our case the input data is an image rendered by the camera and some properties set up by the user.

It’s only the basic setup, it will not generate a snow for you. Now the real fun begins…

The shader

Our snow shader should be an unlit shader – we don’t want to apply any light information to it since on screen-space there’s no light. Here’s the basic template:

Note that if you create a new unlit unity shader (Create->Shader->Unlit Shader) you get mostly the same code.

Let’s now focus only on the important part – the fragment shader. First, we need to capture all the data passed by ScreenSpaceSnow script:

Don’t worry if you don’t know why we need all this data yet. I will explain it in detail in a moment.

Finding out where to snow

As I explained before, we’d like to put the snow on surfaces that are facing upwards. Since we’re set up on the camera that is set to generate depth-normals texture, now we are able to access it. For this case there is

in the code. Why is it called that way? You can learn about it in Unity documentation:

Depth textures are available for sampling in shaders as global shader properties. By declaring a sampler called _CameraDepthTexture you will be able to sample the main depth texture for the camera.

_CameraDepthTexture always refers to the camera’s primary depth texture.

Now let’s start with getting the normal:

Unity documentation says that depth and normals are packed in 16 bits each. In order to unpack it, we need to call DecodeDepthNormal as above seen above.

Normals retrieved in this way are camera-space normals. That means that if we rotate the camera then normals’ facing will also change. We don’t want that, and that’s why we have to multiply it by _CamToWorld matrix set in the script before. It will convert normals from camera to world coordinates so they won’t depend on camera’s perspective no more.

In order for shader to compile it has to return something, so I set up the return statement as seen above. To see if our calculations are correct it’s a good idea to preview the result.

RGB Rendering of Camera Space for Unity Shader Tutorial

We’re rendering this as RGB. In Unity Y is facing the zenith by default. That means that green color is showing the value of Y coordinate. So far, so good!

Now let’s convert it to snow amount factor.

We should be using the G channel, of course. Now, this may be enough, but I like to push it a little further to be able to configure bottom and top threshold of the snowy area. It will allow to fine-tune how much snow there should be on the scene.

Snow texture

Snow may not look real without a texture. This is the most difficult part – how to apply a texture on 3D objects if you have only a 2D image (we’re working on screen-space, remember)? One way is to find out the pixel’s world position. Then we can use X and Z world coordinates as texture coordinates.

Now here’s some math that is not a subject of this article. All you need to know is that vpos is a viewport position, wpos is a world position received by multiplying _CamToWorld matrix by viewport position and it’s converted to a valid world position by dividing by the far plane (_ProjectionParams.z). Finally, we’re calculating the snow color using XZ coordinates multiples by _SnowTexScale configurable parameter and far plane to get sane value. Phew…

Unity Snow Texture for Unity3D shader tutorial

Merging it!

It’s time to finally merge it all together!

Here we’re getting the original color and lerping from it to snowColor using snowAmount.

The final touch: let’s set _TopThreshold value to 0.6:

Voila!

Summary

Here’s a full scene result. Looking nice?

Lowpoly Township Set on the Unity Asset Store

Low Poly 3D Snow Village Unity Asset Shader

Feel free to download the shader here and use it in your project!

Scene that has been used as the example in this article comes from Lowpoly Township Set. Inspired by this particular redditor.

Coroutines in Unity Part 3

Coroutines in Unity – Encapsulating with Promises [Part 3]

 

In the last part of the series we’re going to build a real example of a REST API Interface using Unity’s Coroutines as an internal web requests tool and Promises as an encapsulation layer. We’re going to use the fake REST API service available for everyone to test their services on. It’s a simple API that implements the classic user to-do lists, posts & comments section as well as the album & photos scenario. Very useful if you’re building your own front-end but don’t have your own running server just yet.

NOTE: This tutorial is a bit more advanced and it won’t teach you REST backend theory or JSON serialization. It also assumes you’re already familiar with the RSG Promises we’ve covered in Part 2.

The project

Our project is going to be based around the user to-do lists. The main feature is simple: it’ll take a username as input and provide a list of tasks associated with that user. The application is going to get a list of all the users, find the searched username in it and if that user exists it will then grab all the tasks. Ideally you’d want the user searching to be done server-side, but for the sake of this example let’s say someone hadn’t thought it through and left you to do your job.

For JSON deserialization we’re using the popular JSON .NET framework. If your project is going to be cross-platform you should take a look at JSON.NET for Unity, which uses the same namespace and structure so it can easily be used as a drop-in replacement.

We’re going to work with Unity 5.4.0f3. You can download the .unitypackage here with a complete project and all the necessary plugins. Let’s dive into it.

The project features a Plugins directory, Scenes directory with the single example scene as well as Scripts directory, where the whole codebase sits. The code is structured as follows:

devenv_2016-08-24_11-09-12

Let’s start from the top.

The Models

The Models directory is where the data models’ classes are. They’re essentially the classes with properties mapped to JSON object keys. For example our JSON of a single Task object looks like this:

The associated Model class is then being implemented in the following way:

As you can see, JSON .NET allows for an extremely easy mapping using the JsonProperty attribute. Actually, you can skip these entirely if the property name matches the JSON key. Personally I prefer camelCase in my JSONs and PascalCase in my properties. Keep in mind that for AOT platforms you should use JSON .NET for Unity or use regular fields. Refer to the documentation for more information.

The User model is a stripped model as the jsonplaceholder returns a much bigger JSON, but for the purpose of this example we will not implement all the properties.

Promises as a service interface

Let’s say you’re working on a REST API for a month only to find out that management of your company decided to move to Websocket. Or perhaps you’re ahead of your backend department and want to test new features on your own without the need of using a real server. To remedy this it’s a good idea to implement the Factory pattern which let you choose the exact implementation of your service (APIServiceFactory) by encapsulating a common interface for all of them (IAPIService). The interface is using Promises as the abstraction layer so it’s very easy to use.

To search users and list their tasks we only need two functions:

If you’re going to need another API implementation in the future all you have to do is create a new class that will implement these two methods. The instantiation is done via the factory and the provided config (IClientConfig and ClientConfig):

RestAPIService

The REST API implementation uses the Unity’s Coroutines and the UnityWebRequest class under the hood. Because of that, the factory creates a GameObject and attaches the RestAPIService class, which also extends the MonoBehaviour. This lets us encapsulate the coroutines even further – you’ll be able to use the service in all of the classes, because the interface deals with Promises only. For example, getting the user tasks is done like so:

Notice how easily we control the output with promise.Resolve() and promise.Reject().

TestAPIService

The test implementation is just an example of what you can do. It returns objects without any external calls, but you could also use it as a room to test your JSON deserialization without launching a real server. The bottom line is that this should be the space to mess around with no worries that you’re hard-coding some test scenarios which need to be commented out later. All you have to do is change the config to the real service and you’re done.

So for example, if you’d like to test how your tasks` UI look, but don’t have the tasks functionality done server-side just yet, simply implement the test service and the GetUserTasks() method to return a bunch of test objects:

Notice that you can resolve promises instantly when needed.

The result

The payoff is the example test scene and the MainScreenController class which utilizes the interface. First, it initializes the service using the Factory:

As mentioned earlier, changing to Test implementation is as simple as swapping that APIType property in the config. The UI consists of a single input field where you type in the username and a button to get all the user tasks. Using the common interface it couldn’t be any simpler:

2016-08-24_10-46-14

Summary

And at last we come to an end of the series. Again, the final project can be downloaded as the .unitypackage here. In conclusion Promises prove to be a great way to abstract your code from Unity specific Coroutines. They can also be used in many different cases and are an elegant way to create clean interfaces. We hope you’ll enjoy them as much as we do. If you have any questions about the series or the example project, feel free to leave a comment in the section below.

Should You Install Unity Cache Server on localhost

Should you install Unity Cache Server on localhost?

Do you already know how to use Unity Cache Server? If you’re one of the maniacs trying to optimize every aspect of their development environment, then you most probably do! It’s a great solution for the teams that are working on large projects, especially for mobile devices. But does it make sense to install it for only one person… locally?

How Unity imports assets

The first thing you need to understand is the way Unity imports assets. When you put a file into your Assets folder, Unity executes an asset processor. The textures will be converted to optimal texture format for your target platform: sounds to mp3/ogg (or any other) conversion, models to internal Unity mesh format and so on. Some conversions are done so fast, that you won’t even notice it, but for some it may take enormous amount of time. For instance, processing Android and iOS textures may even take several hours!

This is not an issue if you’re working on a game for a single platform, but usually you are not. For instance, if you’re working on an Android game, most probably you’d like to build an iOS version too. Unfortunately when you switch your target platform, Unity removes previously processed data as you’d never intend to use it again. As a result, switching between multiple platforms may take more time than actual development of your game!

Let’s install Cache Server

Cache Server solves that issue by storing processed assets in the persistent database for later use. If you’re working alone or if your internet connection is not that great, it may be a wise choice to install it locally.

Cache Server is written on the top of NodeJS. If you’re not familiar with this technology, don’t worry. It’s distributed along with cache server zip file, so you don’t even need to install it! (well, I don’t know now why I even mentioned it…)

Now it’s time to get the Cache Server files. These can be found on Team License web page (Team License is now available for everyone). Just click on the download button.

a280306e-a6e8-4ebe-806a-9ff04bd439a3

Unpack the downloaded zip contents in the location where you want to keep your processed asset database. Cache Server by default creates its database in-place, so be prepared to have at least 50 gigabytes of free space on your drive. Now you’re ready to launch it. Go into the CacheServer directory and double-click on RunWin.cmd file. There are appropriate script files for Mac and Linux too.

d4a57c8c-7df2-41ad-824d-881f87cdbfd2

When you see the output like this one, you know that your Cache Server is operational:

f7548b51-d00c-46d0-8afe-be95a1b26bd5

Now, don’t close this command line window! Your cache server works only when it’s open. When closed, you can re-launch it again and your data will be still there, but if it’s not running Unity is not storing anything in it (obviously).

Configuring Unity

Let’s now open Unity preferences. Go into the Cache Server tab, and use localhost as the IP Address.

3fc6f3ce-5cd7-43a8-8a67-6c7a6ea9b3bf

When you see Connection successful message, this means that your Cache Server is fully operational! Now you have to reimport your assets at least once to have it uploaded to the cache server. Later on instead of usual asset importing progress you will be seeing something like this:

using cache server

How long it will take depends only on the speed of your hard drive.

If you’re interested in more information about the Cache Server, you can find it in the official Unity manual. Please also note that Cache Server may require a license different than free (it got a little confusing after latest changes in licensing, so I cannot tell for sure).

Steamworks and Unity – P2P Multiplayer

share_steam_logoSome time ago we talked about how to integrate Steamworks.NET with Unity game. It is a good start, but now let’s go further and talk about multiplayer in Steam. This won’t be a tutorial, but a guide on using Steamworks in your own game. We will be using Steamworks.NET library that is a wrapper to steam_api.dll.

Please note that you need a Steam App ID of your game to get it work. You can get one by getting greenlit or by having your game approved directly by Valve. Still, this is a guide, so if you only want to check if Steam is a convenient platform, just read on…

P2P Multiplayer

One of the greatest features of Steamworks is matchmaking and P2P network communication. You don’t have to worry about servers’ setup – all the things are already there.

You may not be familiar with building a multiplayer game using P2P connection, because the most popular approach involves setting up client and server as a separate entity. In this situation client is the game itself and the server is an application that contains server-side logic, connects all the players together and protects them from cheaters. Since client-server scenario may be good for bigger games, for something relatively small and less competitive consider dropping-off the server part for the favor of two clients speaking with each other. Server-side logic will be included only in a single entity, so you won’t have to worry about writing additional applications to make it work. For that reason we will put P2P Steamworks communication in good use.

Is it really that easy?

Steamworks is trying to be as simple as it can be. You don’t even have to worry about making a connection, all you need is a SteamID (SteamID is a unique steam user identifier. Usually it is a big number wrapped inside a CSteamID object. You can easily get a CSteamID of any user you’re interacting with, for instance through the lobby.) When you have it, all you need is to execute this method:

pubData is the data we want to send, cubData is the number of bytes we want to send, eP2PSendType is a method of delivery. Let’s not talk about nChannel, the default value is enough for now.

Here’s an example of how to send a “Hello!” string:

There are four of these regarding the delivery method:

  • k_EP2PSendUnreliable – Small packets, may get lost, can arrive out of order, but fast.
  • k_EP2PSendUnreliableNoDelay – As above, but won’t do any connections checks. For this purpose it can be thrown away, but it is the fastest possible method of delivery.
  • k_EP2PSendReliable – Reliable message send. For big packets, will arrive in order.
  • k_EP2PSendReliableWithBuffering – As above but buffers the data before sending. Usually when you’re sending a lot of small packages that is not so important to be delivered immediately. (will be forced to send after 200 ms.)

What about the other side?

If one peer is sending the data, the other one receives it in some way. Of course there are some security precautions. You cannot send the data to any Steamworks’ client that’s out there. Before client can receive your data, he has to accept your P2P session request.

P2P session request is something that occurs when you try to send the first chunk of data to the Steamworks’ client. The process will repeat itself if you haven’t sent any data for a while (usually a couple of minutes.) You should accept only the connections you’re expecting to be made, like from another player in the lobby you’re in.

How to accept the session request? It’s really easy! All you have to do is write a code like this one:

This way a P2P session will be accepted and you’ll be ready to…

Read the message

All the messages are stored in the Steamworks message queue. To read it you have to tell it you’re ready to get it. Usually a good place to do so is an Update() function. Your application will check for new messages as soon as possible.

That’s it!

Summary

This guide does not cover cleaning up (it’s optional because unused sessions are being cleaned up automatically) and error handling. You can read about them in official Steamworks documentation, but remember that you need to be Steam partner to to have access to it. If you’re not, I hope that after our articles about Steamworks you will take into consideration becoming one.