Since the posts easily get a bit lengthy, I decided to divide this into a series of more bite-sized posts so that I don’t have to sacrifice all too much clarity for the sake of space. This is part two, about one of two shaders that make use of separate cameras and render textures!
Some of the effects are connected to slightly fundamental parts of the story, and since the game ended up being really short due to time constraints, I recommend you play the game first to avoid the spoilers and get the most out of the game with it’s little twists! So I’ll be adding a “read more” tag at to some parts to hide some of the stuff from the front page of the blog.
Note: the game was made in Unity and the shaders were written accordingly and so any code will be given as boiled down versions of the shader code written for that, but obviously everything is readily convertible to something like GLSL with minor to no changes.
This one is not a spoiler! c:
When picking something up, or clicking something on the inventory bar that was picked up earlier, the player will see a 3D view of the item in question along with some descriptive text.
This view is rendered by a separate camera than the main one to get a nice 3D render of the spinning artefact. The main camera that renders the room (still visible behind the UI) cannot see this model, and the camera that renders the inventory view cannot see anything except the inventory item.
Separate camera setup
This is achieved in Unity by setting inventory items to a render layer of their own, and then unchecking that layer from the main camera, while unchecking everything except that layer on the inventory camera.
Then you’re free to render your inventory and your game world in the same place, without them actually interfering with each other, like so:
Next, we need to create a texture for the inventory camera to render what it sees onto, since we don’t want it to render into the main game view and replace what the main camera sees. A render texture can be added by right-clicking somewhere in Unity’s file inspector and finding the option in the create menu.
It then needs to be connected to the camera, but we’ll not be using the field in the inspector for this, as it won’t work as intended. Instead we’ll be creating a small script that sets the camera up with the texture as the game starts. Something like this at the top:
[SerializeField] private Camera m_cam; [SerializeField] private RenderTexture m_tex;
This way we’ll be able to drag and drop the camera and the render texture onto our script. Then as the game starts we’ll call this:
m_cam.targetTexture = m_tex;
Simple as that! Finally we’ll need to draw the texture somewhere so that we can see it. We’ll do this by adding a “raw image” to our UI canvas which will take the render texture as its sprite/texture, and that’s it. Now during runtime the UI will show what the inventory camera sees in that image, and we can edit the UI element as usual to get it to appear where we want it!
Remember we can also adjust the resolution of the render texture by opening it up in the inspector, in case the default 256×256 is too small, or has the wrong proportions.
You may have noticed we haven’t actually done any shader work yet! ヽ(ﾟДﾟ)ﾉ
We can see there is a white border around the inventory item’s model, and also a circle behind it. But of course that’s not automatic. Without any shader, the inventory would now look like so:
Not very fanciful, nor stylised. And potentially difficult to see, depending on the background! And of course this game’s UI has a dark overlay, so we want that white border around the model to make it stand out nicely no matter what’s below!
Border shaders can be tricky or not depending on the circumstances. In our case we’ve got a mostly transparent image with some non-transparent pixels in the middle; namely, those that make up the model. This makes it simple: we look for pixels that are transparent but have an adjacent non-transparent pixel at a particular distance from it (which will determine the thickness of the border), in which case we make those pixels as opaque as we wish and then assign the border colour to them! (◕‿◕✿)
Remember that we get the colour of the pixel/fragment at any given position in the texture by sampling a UV coördinate. To get the currently processed pixel, we just use the unmodified x and y that we got from the vertex shader:
fixed4 col = tex2D(_MainTex, i.uv);
To for the alpha value of any pixel around this one, we need to offset the UV coördinate by as much as it takes to move on to the next pixel. We’ll start simple, by only sampling the nearest pixels above, below, to the left and to the right of the current pixel. This gives us a less smooth border, but is easier to keep track of.
UV’s are normalised between 0.0 and 1.0, so to get the size of a pixel at this scale, we will need to divide 1.0 by the width and height of the texture’s resolution (in pixels). If we want our border to be thicker than one pixel, we can multiply the result by some value.
fixed2 one = fixed2(1.0 / width, 1.0 / height) * thickness;
Now we can get the alpha values around the current pixel by sampling the surrounding UV’s and only storing the alpha value and ignoring the RGB components.
fixed left = tex2D(_MainTex, i.uv - fixed2(one, 0.0)).a; fixed right = tex2D(_MainTex, i.uv + fixed2(one, 0.0)).a; fixed up = tex2D(_MainTex, i.uv - fixed2(0.0, one)).a; fixed down = tex2D(_MainTex, i.uv + fixed2(0.0, one)).a;
The case may well be that up actually means positive values rather than negative depending on your coördinate system, but it makes absolutely no difference to the end result of this effect, so we need not worry about it. ᕕ( ᐛ )ᕗ
Now we can accumulate alpha values by adding all of these together, then clamping the result to 1.0 and do some more maths to finish up, which will be explained below the complete line of code.
fixed border = min(1.0, left + right + up + down) - col.a; col.rgba += border * transparency;
Finally we subtract the alpha value of the original pixel that we are currently processing.
- If all surrounding pixels as well as the original pixel are transparent, the end result will also be transparent, and we’ll either get no border at all, or a semi-transparent border pixel, which will give a nice and smooth result so long as the original model was also rendered with anti-aliasing.
- If the original pixel was not transparent, the border value will be reduced (all the way to 0.0 if the original pixel was completely opaque; otherwise a semi-transparent value) and the original colour will overtake the border, since there will be nothing to add when we finally add the border value to all of the channels (RGBA) of the final colour.
We can also multiply the value we add by some factor below 1.0 to only apply a semi-transparent border. Et voilà!
This border actually also samples pixels diagonally from the original pixel to make it even smoother. Note that this doubles the number of texture lookups, which can be slow, so choose carefully whether to add this extra overhead depending on the needs of your own application.
As you can see we still haven’t added that circle, but this post is getting lengthy, and you can get an idea of how to render a circle all in shader from the previous post. It’s one of the easiest things one can do, actually! Or you could just add a circle image to your UI below the UI image with the render texture if you’re not feeling up to it!
That’s it for this part! In the next one (and I won’t be posting it right away as I don’t want to be spammy), we’ll be talking about some UV scrolling shaders (one of which is a spoiler) before we move on to the second effect in the game that required extra cameras and render textures, which will be a SPOILER, so play the game first! c:
Remain at the edge of your seat! ☆