##
Shadows in WebGL Part 1
*December 12, 2011*

*Posted by Andor Saga in FSOSS, Open Source, point cloud, webgl, XB PointStream.*

4 comments

4 comments

In my last blog I wrote about an anaglyph demo I created for my FSOSS presentation in October. It was part of a series of delayed blogs which I only recently had time to write up. So, in this blog I’ll be proceeding with my next fun experiment: Shadows in WebGL.

Shadows are useful since they not only add realism, but can also provide additional visual cues in a scene. Having never implemented any type of shadows, I started by performing some preliminary research and found that there are numerous methods to achieve this effect. Some of the more common techniques include:

- vertex projection
- projected planar shadows
- shadow mapping
- shadow volumes

I chose vertex projection since it seemed very straightforward. After a few sketches, I got a fairly good grasp of the idea. Given the position for a light and vertex, the shadow cast (for that vertex) will appear at the line intersection between the slope created by those points and the x-intercept. If we had the following values:

- Light = [4, 4]
- Vertex = [1, 2]

Our shadow would be drawn at [-2, 0]. Note that the y component is zero and would be equal to zero for all other vertices since we’re concentrating on planar shadows.

At this point, I understood the problem well; I just needed a simple formula to get this result. If you run a search for “vertex projection” and “shadows” you’ll find a snippet of code on GameDev.net which provides the formula for calculating the x and z components of the shadow. But if you actually try it for the x component:

It doesn’t work.

When I ran into this, I had to take a step back to think about the problem and review my graphs. I was convinced that I could contrive a working formula that would be just as simple as the one above. So I conducted additional research until I eventually found the point-slope equation of a line.

## Point-Slope Equation

The point-slope equation of a line is useful for determining a single point on the slope give the slope and another point on the line. This is exactly the scenario we have!

Where:

**m** – The slope. This is known since we have two given points on the line: the vertex and the light.

[**x1**, **y1**] – A known point on the line. In this case: the light.

[**x**, **y**] – Another point on the line which we’re trying to figure out: the shadow.

Since the final 3D shadow will lie on the xz-plane, the y components will always be zero. We can therefore remove that variable which gives us:

Now that the only unknown is x, we can start isolating it by dividing both sides by the slope:

Which gives us:

And after rearranging we get our new formula, but is it sound?

If we use the same values as above as a test:

It works!

I now had a way to get the x component for the shadow, but what about the z component? What I did so far was create a solution for shadows in 2 dimensions. But if you think about it, both components can be broken down into 2 2D problems. We just need to use the z components for the light and point to get the z component of the shadow.

## Shader Shadows

The shader code is a bit verbose, but at the same time, very easy to understand:

void drawShadow(in vec3 l, in vec4 v){ // Calculate slope. float slopeX = (l.y-v.y)/(l.x-v.x); float slopeZ = (l.y-v.y)/(l.z-v.z); // Flatten by making all the y components the same. v.y = 0.0; v.x = l.x - (l.y / slopeX); v.z = l.z - (l.y / slopeZ); gl_Position = pMatrix * mVMatrix * v; frontColor = vec4(0.0, 0.0, 0.0, 1.0); }

## Double Trouble

The technique works, but its major issue is that objects need to be drawn twice. Since I’m using this technique for dense point clouds, it significantly affects performance. The graph below shows the crippling effects of rendering the shadow of a cloud consisting of 1.5 million pointsâ€”performance is cut is half.

Fortunately, this problem isn’t difficult to address. Since detail is not an important property for shadows, we can simply render the object with a lower level of detail. I had already written a level of detail python script which evenly distributes a cloud between multiple files. This script was used to produce a sparse cloudâ€”about 10% of the original.

## Matrix Trick

It turns out that planar shadows can be alternatively rendered using a simple matrix.

void drawShadow(in vec3 l, in vec4 v){ // Projected planar shadow matrix. mat4 sMatrix = mat4 ( l.y, 0.0, 0.0, 0.0, -l.x, 0.0, -l.z, -1.0, 0.0, 0.0, l.y, 0.0, 0.0, 0.0, 0.0, l.y); gl_Position = pMatrix * mVMatrix * sMatrix * v; frontColor = vec4(0.0, 0.0, 0.0, 1.0); }

This method doesn’t offer any performance increase versus vertex projection, but the code *is* quite terse. More importantly, using a matrix opens up the potential for drawing shadows on *arbitrary* planes. This is done by modifying all the elements of the above matrix.

## Future Work

Sometime in the future I’d like to experiment with implementing shadows for arbitrary planes. After that I can begin investigating other techniques such as shadow mapping and shadow volumes. Exciting! (: