In the previous article, we have created the first shader and also we explained its syntax and how it works. In this article, we will continue with the most important mathematics concept in shader development: Coordinate spaces and coordinate transformations.
Linear algebra and analytic geometry are languages of shaders. Shader development is mostly about transforming coordinates from one coordinate system to another coordinate system. I will try to explain details that are required here, but I also suggest you study linear algebra and analytic geometry if you want to master on shader development.
The model-view-projection matrix is used to convert mesh vertices to this space. It is known as clip space, because everything that ends up outside of this cube gets clipped, because it isn't visible. This information actually has nothing to do with shadows directly, but Unity will use it in a later pass. Rendering to Shadow Maps. Simple Billboard shader for Unity. GitHub Gist: instantly share code, notes, and snippets.
Contents
- Coordinate systems that are used shader development
- Clip space
Coordinate Transformations
Suppose that you are driving a car on a road. You can determine the positions of the objects according to the car’s own coordinate system. For instance, the position of the rear-view mirror can be determined according to the local coordinate system of the car. But position of the same mirror is not the same for an observer who is sitting near the road. But how are these two coordinate systems related to each other? Can we obtain coordinates in one frame if we know the coordinates in another frame?
Assume that there are two different frames. There is always a transformation matrix that transforms positions from one frame to another frame. When we want to find the positions in the frame of reference, we multiply the transformation matrix and position vector in the first frame. For instance, in our example, if we know the position of the rear-view mirror that is relative to the origin of the car, and also if we have the transformation matrix between the car’s reference frame and observer’s reference frame, then we can find the position of the rear-view mirror in observer’s frame.
In the image above, while ( (x_{car}, y_{car}) ) represents the position of the rear-view mirror in the car’s own reference frame, ( (x_{oberver}, y_{oberver}) ) represents the position of the same mirror in observer’s reference frame.
If we know the transformation matrix T between car space and observer space, then we can calculate ( (x_{oberver}, y_{oberver}) ).
Even if this example is given in 2D coordinate spaces, they can be generalized to higher dimension coordinate spaces as well.
There is good news for Unity Developers. We do not have to construct transformation matrices for main coordinate spaces. There are pre-calculated built-in variables and built-in helper functions for these transformations.
In Cg, we use mul( ) function to multiply matrices.
Coordinate systems in shader development
Six of the most important coordinate systems in computer graphics are:
- Object Space
- World Space
- View Space
- Clip Space
- Screen Space
- UV Space
Object Space
This is the reference frame in which the vertex data is stored. This is a 3D coordinate space that uses the cartesian coordinate system. Its origin is the pivot point of the object.
World Space
World space is the reference frame in which we make lighting calculations. We also use it when we manipulate something according to world space coordinates. It uses a 3D, cartesian coordinate system. The origin of the world space is the center of the scene.
If we want to obtain the coordinates of vertices of an object in world space, we need to transform object space coordinates to world space coordinates. The transformation matrix which transforms object space coordinates to world space coordinates is called “model matrix“. As we mentioned earlier, we do not have to construct it from scratch. The model matrix in Unity is given by unity_ObjectToWorld. Thus we can obtain world space coordinates by:
View Space
View space or camera space is a camera centered coordinate system. It is also a 3D coordinate space that uses the cartesian coordinate system. When we need to obtain coordinates of a point according to the camera, we transform the coordinates to the view space.
In order to transform coordinates from world space to view space, we use the “view matrix”. The view matrix in Unity is given by UNITY_MATRIX_V. We can obtain view space coordinates from world space coordinates as the following:
Even though a transformation from the world space to the view space is used seldom, you should know how to do it.
A transformation from the object space to the view space is more common. The matrix for this transformation is the “model-view Matrix”. And it is given as UNITY_MATRIX_MV in Unity. To obtain the view space coordinates from the object space, we can use the following:
Clip Space
Clip space coordinates are the output of the vertex shader. This means that, at least, we have to transform local coordinates to clip space coordinates in vertex shader. There is a stage at the end of the vertex shader stage which is called clipping. Clipping determines which object or object parts will be rendered. For instance, an object which is out of the desired coordinates will not be rendered. This coordinate space is an interesting coordinate space that is a little bit confusing.
Even though the world is 3-dimensional, we represent clip space coordinates by 4 numbers. In clip space, we use a coordinate system which is called the “homogeneous coordinate system”. The reason for that is to create the illusion of perspective which we will discuss a little bit later.
The transformation matrix from view space to clip space is the “projection matrix“. The projection matrix is given by UNITY_MATRIX_P.
This transformation is also used seldom. Generally, we use direct transformation from object space to clip space. We use the “model-view-projection matrix” to transform a coordinate from object space to clip space. In Unity, the model-view-projection matrix is given by UNITY_MATRIX_MVP.
Nevertheless, there is a built-in function that transforms object space coordinates to clip space coordinates. We generally use the following function to transform coordinates from object space to clip space:
Homogeneous Coordinate System
In Euclidean space, two parallel lines never intersect. On the other hand, as you are observed many times, train rails are seen as if they intersect at the infinity. To create this perspective, we use the homogeneous coordinate system in computer graphics.
Coordinates in the homogeneous coordinate system are represented by 4 numbers. The first three numbers represent the 3D coordinates and the fourth one is for creating perspective.
Clip space does not use rectangular coordinates. You can think of it as a truncated pyramid shape(also called a frustum). It consists of near clip plane, far clip plane, and field of angle. If you look to the camera a little bit closer you see these terms in the inspector.
Screen Space
Screen space is a 2-dimensional coordinate space in which a coordinate represents a pixel on the screen. We do not have direct control over it. In the rasterizer stage, clip space coordinates are automatically transformed to screen space coordinates.
UV Space
The UV space is a 2-dimensional coordinate space that is associated withobject. This space is used to cover the object with a 2D texture. Every coordinate on the object mapped to a point on the texture. This mapping uses UV space.
Inverse Transformations
Sometimes we need to make inverse transformations. For instance, when we want to transform a world space coordinate to object space coordinate, we have to multiply the inverse of the transformation matrix from object space to world space with the world space coordinates. In Unity, the inverse of the model matrix is given by unity_WorldToObject.
This is the seventh part of a tutorial series about rendering. The previous part covered normal mapping. Now we'll take a look at shadows.
This tutorial was made with Unity 5.4.0f3.
Directional Shadows
While our lighting shader produces fairly realistic results by now, it evaluates each surface fragment in isolation. It assumes that a ray of light from every light source eventually hits every fragment. But this is only true if those rays aren't blocked by something.
When an object sits in between a light source and another object, it might prevent part or all of the light rays from reaching that other object. The rays that illuminate the first object are no longer available to illuminate the second object. As as result, the second object will remain at least partially unlit. The area that is not lit lies in the shadow of the first object. To describe this, we often say that the fist object casts a shadow on the second one.
Unityobjecttoclippos Source
In reality, there is a transition region between fully lit and fully shadowed space, know as the penumbra. It exists because all light sources have a volume. As a result, there are regions where only part of the light source is visible, which means that they are partially shadowed. The larger the light source, and the further away a surface is from its shadow caster, the larger this region is.
Unity doesn't support penumbra. Unity does support soft shadows, but that is a shadow filtering technique, not a simulation of penumbra.
Enabling Shadows
Without shadows, it is hard to see the spatial relationships between objects. To illustrate this, I created a simple scene with a few stretched cubes. I placed four rows of spheres above these cubes. The middle rows float of spheres, while the outer rows are connected to the cubes below them via cylinders.
The objects have Unity's default white material. The scene has two directional lights, the default directional light, and a slightly weaker yellow light. These are the same lights used in previous tutorials.
Currently, the shadows are disabled project-wide. We did that in an earlier tutorial. The ambient intensity is also set to zero, which makes it easier to see the shadows.
Shadows are part of the project-wide quality settings, found via Edit / Project Settings / Quality. We'll enable them at a high quality level. This means supporting both hard and soft shadows, using a high resolution, a stable fit projection, a distance of 150, and four cascades.
Make sure that both lights are set to cast soft shadows. Their resolution should depend on the quality settings.
With both directional lights casting shadows, the spatial relationships between all objects becomes a lot clearer. The entire scene has become both more realistic and more interesting to look at.
Shadow Mapping
How does Unity add these shadows to the scene? The standard shader apparently has some way to determine whether a ray is blocked or not.
You could figure this out whether a point lies in a shadow, by casting a ray through the scene, from the light to the surface fragment. If that ray hits something before it reaches the fragment, then it is blocked. This is something that a physics engine could do, but it would be very impractical to do so for each fragment, and per light. And then you'd have to get the results to the GPU somehow.
There are a few techniques to support real-time shadows. Each has it advantages and disadvantages. Unity uses the most common technique nowadays, which is shadow mapping. This means that Unity stores shadow information in textures, somehow. We'll now investigate how that works.
Open the frame debugger via Window / Frame Debugger, enable it, and look at the hierarchy of rendering steps. Look at the differences between a frame without and a frame with shadows enabled.
When shadows are disabled, all objects are rendered as usual. We were already familiar with this process. But when shadows are enabled, the process becomes more complex. There are a few more rendering phases, and quite a lot more draw calls. Shadows are expensive!
Rendering to the Depth Texture
When directional shadows are enabled, Unity begins a depth pass into the rendering process. The result is put into a texture that matches the screen resolution. This pass renders the entire scene, but only records the depth information of each fragment. This is the same information that is used by the GPU to determine whether a fragment ends up on top or below a previously rendered fragment.
This data corresponds with a fragment's Z coordinate, in clip space. This is the space that defines the area that the camera can see. The depth information ends up stored as a value in the 0–1 range. When viewing the texture, nearby texels appear dark. The further away a texel is, the lighter it becomes.
What is clip space?
It is the space that determines what the camera sees. When you select the main camera in the scene view, you will see a pyramid wire frame in front of it, which indicates what it can see.
In clip space, this pyramid is a regular cube. The model-view-projection matrix is used to convert mesh vertices to this space. It is known as clip space, because everything that ends up outside of this cube gets clipped, because it isn't visible.
This information actually has nothing to do with shadows directly, but Unity will use it in a later pass.
Rendering to Shadow Maps
The next thing Unity renders is the shadow map of the first light. A little later, it will rendered the shadow map of the second light as well.
Again, the entire scene is rendered, and again only the depth information is stored in a texture. However, this time the scene is rendered from the point of the view of the light source. Effectively, the light acts as a camera. This means that the depth value tells us how far a ray of light traveled before it hit something. This can be used to determine if something is shadowed!
What about normal maps?
The shadow maps record the depth of the actual geometry. Normals maps add the illusion of a rough surface, and shadow maps ignore them. Thus, shadows are not affected by normal maps.
Because we're using directional lights, their cameras are orthographic. As such, there is no perspective projection, and the exact position of the light's camera doesn't matter. Unity will position the camera so it sees all objects that are in view of the normal camera.
Actually, it turns out that Unity doesn't just render the entire scene once per light. The scene is rendered four times per light! The textures are split into four quadrants, each being rendered to from a different point of view. This happens because we have opted to use four shadow cascades. If you were to switch to two cascades, the scene would be rendered twice per light. And without cascades, it is only rendered once per light. We will see why Unity does this when we look at the quality of shadows.
Collecting Shadows
We have the depth information of the scene, from the point of view of the camera. We also have this information from the point of view of each light. Of course this data is stored in different clip spaces, but we know the relative positions and orientations of these spaces. So we can convert from one space to the other. This allows us to compare the depth measurements from both points of view. Conceptually, we have two vectors that should end up at the same point. If they do, both the camera and light can see that point, and so it is lit. If the light's vector ends before reaching the point, then the light is blocked, which means that the point is shadowed.
What about when the scene camera can't see a point?
Those points are hidden behind other points that are closer to the camera. The scene's depth texture only contains the closest points. As a result, no time is wasted on evaluating hidden points.
Unity creates these textures by rendering a single quad that covers the entire view. It uses the Hidden/Internal-ScreenSpaceShadows shader for this pass. Each fragment samples from the scene's and light's depth textures, makes the comparison, and renders the final shadow value to a screen-space shadow map. Lit texels are set to 1, and shadowed texels are set to 0. At this point Unity can also perform filtering, to create soft shadows.
Why does Unity alternate between rendering and collecting?
Each light needs its own screen-space shadow map. But the shadow map rendered from the light's point of view can be reused.
Sampling the Shadow Maps
Finally, Unity is finished rendering shadows. Now the scene is rendered normally, with one change. The light colors are multiplied by the values stored in their shadow maps. This eliminates the light when it should be blocked.
Every fragment that gets rendered samples the shadow maps. Also fragments that end up hidden behind other objects that are drawn later. So these fragments can end up receiving the shadows of the objects that end up hiding them. You can see this when stepping through the frame debugger. You can also see shadows appear before the objects that actually cast them. Of course these mistakes only manifest while rendering the frame. Once it is finished, the image is correct.
Shadow Quality
When the scene is rendered from the light's point of view, the orientation does not match the scene camera. So the texels of the shadow maps don't align with the texels of the final image. The resolution of the shadow maps also ends up being different. The resolution of the final image is determined by the display settings. The resolution of the shadow maps is determined by the shadow quality settings.
When the texels of the shadow maps end up rendered larger than those of the final image, they will become noticeable. The edges of the shadows will be aliased. This is most obvious when using hard shadows.
To make this as obvious as possible, change the shadow quality settings so we only get hard shadows, at the lowest resolution, with no cascades.
It is now very obvious that the shadows are textures. Also, bits of shadow are appearing in places where they shouldn't. We'll look into that later.
The closer the shadows get to the scene camera, the larger their texels become. That's because the shadow map currently covers the entire area visible to the scene camera. We can increase the quality close to the camera, by reducing the area that is covered by shadows, via the quality settings.
By limiting shadows to an area close to the scene camera, we can use the same shadow maps to cover a much smaller area. As a result, we get better shadows. But we lose the shadows that are further away. The shadows fade away as they approach the maximum distance.
Ideally, we get high-quality shadows up close, while also keeping the shadows that are far away. Because far away shadows end up rendered to a smaller screen area, those could make do with a lower-resolution shadow map. This is what shadow cascades do. When enabled, multiple shadow maps are rendered into the same texture. Each map is for use at a certain distance.
Unity Unityobjecttoclippos
When using four cascades, the result looks a lot better, even though we're still using the same texture resolution. We're just using the texels much more efficiently. The downside is that we now have to render the scene three more times.
When rendering to the screen-space shadow maps, Unity takes care of sampling from the correct cascade. You can find where one cascade ends and another begins, by looking for a sudden change of the shadow texel size.
You can control the range of the cascade bands via the quality settings, as portions of the shadow distance. You can also visualize them in the scene view, by changing its Shading Mode. Instead of just Shaded, use Miscellaneous / Shadow Cascades. This will render the colors of the cascades on top of the scene.
How do I change the scene view's display mode?
There is a dropdown list at the top left of the scene view window. By default, it is set to Shaded.
The shape of the cascade bands depends on the Shadow Projection quality setting. The default is Stable Fit. In this mode, the bands are chosen based on the distance to the camera's position. The other option is Close Fit, which uses the camera's depth instead. This produces rectangular bands in the camera's view direction.
This configuration allows for more efficient use of the shadow texture, which leads to higher-quality shadows. However, the shadow projection now depends on the position and orientation or the camera. As a result, when the camera moves or rotates, the shadow maps change as well. If you can see the shadow texels, you'll notice that they move. This effect is known as shadow edge swimming, and can be very obvious. That's why the other mode is the default.
Don't Stable Fit shadows also depend on the camera position?
They do, but Unity can align the maps so that when the camera position changes, the texels appear motionless. Of course the cascade bands do move, so the transition points between the bands change. But if you don't notice the bands, you also don't notice that they move.
Shadow Acne
When we used low quality hard shadows, we saw bits of shadow appear where they shouldn't. Unfortunately, this can happen regardless of the quality settings.
Each texel in the shadow map represents the point where a light ray hit a surface. However, texels aren't single points. They end up covering a larger area. And they are aligned with the light direction, not with the surface. As a result of this, they can end up sticking in, through, and out of surfaces like dark shards. As parts of the texels end up poking out of the surfaces that cast the shadow, the surface appears to shadow itself. This is known as shadow acne.
Another source of shadow acne is numerical precision limitations. These limitations can cause incorrect result when very small distances are involved.
One way to prevent this problem is by adding a depth offset when rendering the shadow maps. This bias is added to the distance from the light to the shadow casting surface, pushes the shadows into the surfaces.
Unityobjecttoclippos(v.vertex)
The shadow bias is configured per light, and is set to 0.05 by default.
A low bias can produce shadow acne, but a large bias introduces another problem. As the shadow-casting objects are pushed away from the lights, so are their shadows. As a result, the shadows will not be perfectly aligned with the objects. This isn't so bad when using a small bias. But too large a bias can make it seem like shadows are disconnected from the objects that cast them. This effect is known as peter panning.
Besides this distance bias, there is also a Normal Bias. This is a subtler adjustment of the shadow casters. This bias pushes the vertices of the shadow casters inwards, along their normals. This also reduces self-shadowing, but it also makes the shadows smaller and can cause holes to appear in the shadows.
What are the best bias settings?
There are no best settings. Unfortunately, you'll have to experiment. Unity's default settings might work, but they can also produce unacceptable results. Different quality settings can also produce different results.
Anti-Aliasing
Do you have anti-aliasing enabled in the quality settings? If you have, then you might have spotted another problem of shadow maps. They do not mix with the standard anti-aliasing approach.
When you enable anti-aliasing in the quality settings, Unity will use multi-sampling anti-aliasing, MSAA. It removes the aliasing at triangle edges by performing some super-sampling along those edges. The details don't matter here. What matters is that when Unity renders the screen-space shadow maps, it does so with a single quad that covers the entire view. As a result, there are no triangle edges, and thus MSAA does not affect the screen-space shadow map. MSAA does work for the final image, but the shadow values are taken straight from the screen-space shadow map. This becomes very obvious when a light surface next to a darker surface is shadowed. The edge between the light and dark geometry is anti-aliased, while the shadow edge isn't.
Anti-aliasing methods that rely on image post-processing – like FXAA – don't have this problem, because they are applied after the entire scene has been rendered.
Does this mean that I cannot combine MSAA with directional shadows?
You can, but you will experience the problem described above. In some cases, it might not be noticeable. For example, when all surface colors are roughly the same, the artifacts will be subtle. You still get aliased shadow edges, of course.
unitypackageCasting Shadows
Now that we know how Unity creates shadows for directional lights, it is time to add support for them to our own shader. Currently, My First Lighting Shader neither casts nor received shadows.
Let's deal with casting shadows first. I have changed the spheres and cylinders in the example scene so they use our material. So now they no longer cast shadows.
We know that Unity renders the scene multiple times for directional shadows. Once for the depth pass, and once per light, for each shadow map cascade. The screen-space shadow map is a screen-space effect and doesn't concern us.
To support all relevant passes, we have to add a pass to our shader, with its light mode set to ShadowCaster. Because we are only interested in the depth values, it will be a lot simpler than our other passes.
Let's give the shadow programs their own include file, named My Shadows.cginc. They are very simple. The vertex program converts the position from object space to clip space as usual, and does nothing else. The fragment program actually doesn't need to do anything, so just return zero. The GPU records the depth value for us.
This is already enough to cast shadows directional.
Bias
We also have to support the shadow bias. During the depth pass, the biases are zero, but when rendering the shadow maps, the biases correspond to the light settings. We do so by applying the depth bias to the position in the vertex shader, in clip space.
To support the depth bias, we can use the UnityApplyLinearShadowBias function, which is defined in UnityCG.
How does UnityApplyLinearShadowBias work?
It increases the Z coordinate in clip space. What complicates this is that it are working with homogeneous coordinates. It has to compensate for the perspective projection, so that the offset doesn't vary with distance from the camera. It must also make sure that the result doesn't go out of bounds.
To also support the normal bias, we have to move the vertex position based on the normal Vector. So we have to add the normal to our vertex data. Then we can use the UnityClipSpaceShadowCasterPos function to apply the bias. This function is also defined in UnityCG.
How does UnityClipSpaceShadowCasterPos work?
It converts the position to world space, applies the normal bias, then converts to clip space. The exact offset depends on the angle between the normal and light direction, and the shadow texel size.
The UnityObjectToClipPos function just performs the model-view-projection matrix multiplication, with a caveat when using stereoscopic rendering.
Our shader is now a fully functional shadow caster.
unitypackageReceiving Shadows
The second part of the process is receiving shadows. All objects in the test scene now use our material.
Let's first concern ourselves with the shadows of the main directional light only. Because this light is included in the base pass, we have to adjust that one.
When the main directional light casts shadows, Unity will look for a shader variant that has the SHADOWS_SCREEN keyword enabled. So we have to create two variants of our base pass, one with and one without this keyword. This works the same as for the VERTEXLIGHT_ON keyword.
The pass now has two multi-compile directives, each for a single keyword. As a result, there are four possible variants. One with no keywords, one for each keyword, and one with both keywords.
After adding the multi-compile pragma, the shader compiler will complain about a nonexistent _ShadowCoord. This happens because the UNITY_LIGHT_ATTENUATION macro behaves differently when shadows are in play. To quickly fix this, open the My Lighting.cginc file and just set the attenuation to 1 when we have shadows.
Sampling Shadows
To get to the shadows, we have to sample the screen-space shadow map. To do this, we need to know the screen-space texture coordinates. Like other texture coordinates, we'll pass them from the vertex shader to the fragment shader. So we need use an additional interpolator when supporting shadows. We'll begin by just passing along the homogeneous clip-space position, so we need a float4.
We can access the screen-space shadows via _ShadowMapTexture. It is defined in AutoLight when appropriate. The naive approach is to simply use the clip-space XY coordinates of the fragment to sample this texture.
We're now sampling shadows, but with clip-space coordinates instead of screen-space coordinates. We do get shadows, but they end up compressed into a tiny region at the center of the screen. We have to stretch them to cover the entire window.
My shadows are upside down?
That is due to API differences. We'll deal with that soon.
In clip space, all visible XY coordinates fall inside the −1–1 range, while the range for screen-space is 0–1. The first step to solve this by halving XY. Next, we also have to offset the coordinates so they are zero at the bottom-left corner of the screen. Because we're dealing with a perspective transformation, how much we must offset the coordinates depends on how far away they are. In this case, the offset is equal to the fourth homogeneous coordinate, before halving.
The projection is still not correct, because we're using homogeneous coordinates. We have to convert to screen-space coordinates, by dividing X and Y by W.
The result gets distorted. The shadows are stretched and curved. This happens because we do the division before interpolation. This is incorrect, the coordinates should be interpolated independently, before the division. So we have to move the division to the fragment shader.
How does interpolation affect division?
This is best illustrated with an example. Suppose that we're interpolating between the XW coordinate pairs (0, 1) and (1, 4). No matter how we do this, X / W starts at 0 and ends at ¼. But what about halfway between those points?
If we divide before interpolating, then we end up halfway between 0 and ¼, which is ⅛.
If we divide after interpolating, then at the halfway point we end up with the coordinates (0.5, 2.5), which leads to the division 0.5 / 2.5, which is ⅕, not ⅛. So in this case the interpolation is not linear.
At this point, your shadows will either appear correct, or upside down. If they are flipped, it means that your graphics API – Direct3D – has the screen-space Y coordinates go from 0 to 1 downwards, instead of upwards. To synchronize with this, flip the Y coordinate of the vertex.
Using Unity's Code
Unity's include file provide a collection of functions and macros to help us sample shadows. They take care of API differences and platform limitations. For example, we can use the ComputeScreenPos function from UnityCG.
UnityCG.
What does ComputeScreenPos look like?
It performs the same computations that we did. The _ProjectParams.x variable is −1 when the Y coordinate needs to be flipped. Also, it takes care of texture alignment when using Direct3D9. There's also special logic required when doing single-pass stereoscopic rendering.
The AutoLight include file defines three useful macros. They are SHADOW_COORDS, TRANSFER_SHADOW, and SHADOW_ATTENUATION. When shadows are enabled, these macros perform the same work that we just did. They do nothing when there are no shadows.
SHADOW_COORDS defines the interpolator for shadow coordinates, when needed. I uses the _ShadowCoord name, which was what the compiler complained about earlier.
TRANSFER_SHADOW fills these coordinates in the vertex program.
And SHADOW_ATTENUATION uses the coordinates to sample the shadow map in the fragment program.
Actually, the UNITY_LIGHT_ATTENUATION macro already uses SHADOW_ATTENUATION. That's why we got that compiler error before. So we can suffice with using just that macro. The only change is that we have to use the interpolators as its second argument, while we just used zero before.
After rewriting our code to use these macros, we get new compile errors. This happens because Unity's macros unfortunately make assumptions about the vertex data and interpolator structures. First, it is assumed that the vertex position is named vertex, while we named it position. Second, it is assumed that the interpolator position is named pos, but we named it position.
Let's be pragmatic and adopt these names too. They're only used in a few places anyway, so we don't have to change much.
Our shadows should work again, and this time on as many platforms as Unity supports.
What do these macros look like?
Which macro versions you end up with depends on which shader keywords are enabled, and which features are supported. When SHADOWS_SCREEN is defined, you end up with the following code.
Note that the Z component of the shadow coordinates is only used when both UNITY_NO_SCREENSPACE_SHADOWS and SHADOWS_NATIVE are defined.
The tex2Dproj function does the same as tex2D, but it also takes care of the XY / W division. You can see this when looking at the compiled code.
Multiple Shadows
The main directional light is now casting shadows, but the second directional light still doesn't. That's because we don't yet define SHADOWS_SCREEN in the additive pass. We could add a multi-compile statement to it, but SHADOWS_SCREEN only works for directional lights. To get the correct combination of keywords, change the existing multi-compile statement to one that also includes shadows.
This adds four additional keywords into the mix, to support different light types.
unitypackageSpotlight Shadows
Now that we have dealt with directional lights, let's move on to spotlights. Disable the directional lights and add some spotlights with shadows to the scene. Surprise! Thanks to Unity's macros, spotlight shadows already work.
When looking at the frame debugger, you'll see that Unity does less work for spotlight shadows. There is no separate depth pass, and no screen-space shadow passes. Only the shadow maps are rendered.
The shadow maps works the same as for directional lights. They're depth maps, rendered from the light's point of view. However, there are big differences between a directional light and a spotlight. The spotlight has an actual position, and its light rays aren't parallel. So the spotlight's camera has a perspective view, and cannot be more around arbitrarily. As a result, these lights cannot support shadow cascades.
Although the camera setup is different, the shadow casting code is identical for both light types. The normal bias is only supported for directional shadows, but it's simply set to zero for other lights.
Sampling the Shadow Map
Because spotlights don't use screen-space shadows, the sampling code has to be different. But Unity's macros hide this difference from us.
What do the macros look like, for spotlights?
The shadow coordinates are found by converting the vertex positions to world space, and from there to the light's shadow space.
We found directional shadows by simply sampling the screen-space shadow map. Unity took care of shadow filtering when creating that map, so we didn't need to worry about that. However, spotlights don't use screen-space shadows. So if we want to use soft shadows, we have to do the filtering in the fragment program.
Then SHADOW_ATTENUATION macro uses the UnitySampleShadowmap function to sample the shadow map. This function is defined in UnityShadowLibrary, which AutoLight includes. When using hard shadows, the function samples the shadow map once. When using soft shadows, it samples the map four times and averages the result. The result isn't as good as the filtering used for screen-space shadows, but it is a lot faster.
What does UnitySampleShadowmap look like?
There are two versions of this function, one for spotlights and one for point lights. Here's the one for spotlights.
_ShadowOffsets contains the offsets used for the four samples that are averaged to create soft shadows. In the code below, I've only shown the first of those four samples.
Point Light Shadows
Now try some point lights. When you enable shadows for a point light, you will be greeted with a compile error. Apparently, UnityDecodeCubeShadowDepth is undefined. This error happens because UnityShadowLibrary depends on UnityCG, but doesn't explicitly include it. So we have to make sure that UnityCG is included first. We can do this by including UnityPBSLighting before including AutoLight in My Lighting.
It compiles, but all objects in range of the lights end up black. There is something wrong with the shadow maps.
When you inspect the shadow maps via the frame debugger, you will discover that not one, but six maps are rendered per light. This happens because point lights shine in all directions. As as result, the shadow map has to be a cube map. Cube maps are created by rendering the scene with the camera pointing in six different directions, once per face of the cube. So shadows for point lights are expensive.
Casting Shadows
Unfortunately, Unit doesn't use depth cube maps. Apparently, not enough platforms support them. So we cannot rely on the fragment's depth value in My Shadows. Instead, we'll have to output the fragment's distance as the result of the fragment program.
When rendering point light shadow maps, Unity looks for a shadow caster variant with the SHADOWS_CUBE keyword be defined. The SHADOWS_DEPTH keyword is used for directional and spotlight shadows. To support this, add a special multi-compile directive for shadow casters to our pass.
This adds the variants that we need.
Because points lights require such a different approach, let's create a separate set of program function for them.
To figure out a fragment's distance from the light, we have to construct the world-space vector from the light to the fragment. We can do so by creating these vectors per vertex, and interpolating them. This requires an additional interpolator.
In the fragment program, we take the length of the light vector and add the bias to it. Then we divide that by light's range to fit them in the 0–1 range. The _LightPositionRange.w variable contains the inverse of its range, so we have to multiply by this value. The result is output as a floating-point value.
What does UnityEncodeCubeShadowDepth do?
Unity prefers to use a floating-point cube map. When this is possible, this function does nothing. When this is not possible, Unity will encode the value so it is stored in the four channels of an 8-bit RGBA texture.
Sampling the Shadow Maps
Now that our shadow maps are correct, the point light shadows appear. Unity's macros take care of the sampling of those maps.
What do that macros look like, for point lights?
In this case, the same light vector is constructed as when casting the shadows. This vector is then used to sample the shadow cube map. Note that the interpolator needs only three components, instead of four. We're not passing along homogeneous coordinates this time.
In this case, UnitySampleShadowmap samples a cube map instead of a 2D texture.
Just like with spotlight shadows, the shadow map is sampled once for hard shadows, and four times for soft shadows. The big difference is that Unity doesn't support filtering for the shadow cube maps. As a result, the edges of the shadows are much harsher. So point light shadows are both expensive and aliased.
How can I make nice soft lantern shadows?
Use one or more shadowed spotlights. If there are no other shadow-casting objects nearby, you can use an unshadowed light with a cookie. That works for both spotlights and point lights, and is a lot cheaper to render.
The next tutorial is Reflections.
unitypackagePDF