It’s been a long time coming, but finally I get the time to explain the technique I came up with for drawing shader-based dynamic 2D shadows.
If you want to dive right into the code, you can go to the sample’s page.
Still here? Ok then, let’s get started.
The core of the technique is drawing all the possible shadow casters around a light into a texture, and then using a few shaders to turn this image into one containing all shadows cast in the scene. First, for a general view, consider the following scene.
Out goal is to have all objects cast shadows, with the two orange squares being the sources of light.
The first step is to build for each light a image of all the casters around it. This basically means drawing all objects with a black color into a texture, centered around the light. The technical side of this should be pretty trivial, and can also be seen in the code.
The tricky part comes next and this is the main part of the technique. I will explain the whole process a little later, but for now just know that the technique I use takes as input these “caster maps” and produces a “shadow image”, as seen below.
Having these two shadow images, it is now easy to blend them together, using the desired light color for each, and then blending the result over the “ground”.
In the end, drawing the items in the scene leads to our desired result.
Most of these steps should be fairly easy. The problem comes in getting from the image containing all the shadow casters to the image containing the shadows themselves.
The technique is really not that complicated, so I’ll explain each step, together with shader code and images. So let’s start with the beginning, namely the shadow casters image.
1. Starting from this, for each non-transparent pixel (non-white in the illustration), I output the distance from the center of the texture to that pixel (i.e. the distance from the light source to the pixel).
float4 ComputeDistancesPS(float2 TexCoord : TEXCOORD0) : COLOR0
{
float4 color = tex2D(inputSampler, TexCoord);
//compute distance from center
float distance = color.a>0.3f?length(TexCoord - 0.5f):1.0f;
//save it to the Red channel
distance *= renderTargetSize.x;
return float4(distance,0,0,1);
}
One thing to notice is that I multiply by the size of the render target and save to a floating point format. I do this in order to preserve precision. You could store this as a value between 0 and 1, and write it into a render target with the Color surface format, but this can lead to some imprecision when using large lights.
The results looks something like below (shown in grayscale for easy visualization).
2. In the next step, I divide the image into four quadrants around the light (center of this image), and distort it in such a way that all “light rays” (which are at the moment spreading in all directions from the light) are positioned in parallel. This is much easier to understand with an image, as seen below.
In the pictures above, the quadrant to the left (and the one to the right) has been distorted so it takes up half of the image, and all pixels are placed as if the rays starting from the light are parallel. The reason I am doing this will be obvious in the next step. Since I need this data for all the quadrants, I make the same operation for the vertical direction (rotating the result so it’s also horizontal).
I know the text doesn’t make as much sense as I would like but hopefully the images illustrate what I mean. Finally, to reduce memory usage and to perform more computations in parallel, I store the result of the horizontal distortion in the red channel, and the result of the vertical distortion in the green channel.
I know it doesn’t look like much, but know that all the data we need for all directions is now stored in a single texture. The code that achieves this step is the shader function below. This code can probably be simplified (to avoid the conversions between the [0,1] and [-1,1] domains, but I find it clearer this way.
float4 DistortPS(float2 TexCoord : TEXCOORD0) : COLOR0
{
//translate u and v into [-1 , 1] domain
float u0 = TexCoord.x * 2 - 1;
float v0 = TexCoord.y * 2 - 1;
//then, as u0 approaches 0 (the center), v should also approach 0
v0 = v0 * abs(u0);
//convert back from [-1,1] domain to [0,1] domain
v0 = (v0 + 1) / 2;
//we now have the coordinates for reading from the initial image
float2 newCoords = float2(TexCoord.x, v0);
//read for both horizontal and vertical direction and store them in separate channels
float horizontal = tex2D(inputSampler, newCoords).r;
float vertical = tex2D(inputSampler, newCoords.yx).r;
return float4(horizontal,vertical ,0,1);
}
3. Now that we have the distorted images of the distances from the light along each ray going out from the light, it’s time to compute the minimum along each of these rays. I do this by successive reduction of the image along the horizontal direction, until a texture of width 2 is obtained. This texture is something very similar to a shadow map in 3D, in that it contains for each ray, the minimum distance from the light where a shadow caster is present.
This step is also currently the bottleneck of the algorithm, since reducing a texture of 512*512 to a size of 2*512 requires about 9 passes (the dimension is reduced by a factor of 2 through each pass). The reduction shader is a simple one:
At this point, it should be clear why I distorted the pixels in such a way (in order to be able to apply a horizontal reduction) and why the vertical components were also rotated and stored in a separate channel. Basically, we make the reductions on all directions at the same time.
Note: because this is the bottleneck, an option is to store the caster texture and do all operation on half the size of the actual light area. Thus for a light area of 512*512 you could make the processing on textures of 256*256. This way you loose some crispiness (not always a bad thing when it comes to shadows) but you also gain some performance.
4. At this moment, we can generate the shadow image. We draw the area surrounding the light, and for each pixel, we compare the distance between this pixel and the light to the distance stored in the shadow map along the same ray. This information tells us if we are in front or behind the shadow caster.
float4 DrawShadowsPS(float2 TexCoord: TEXCOORD0) : COLOR0
{
// distance of this pixel from the center
float distance = length(TexCoord - 0.5f);
distance *= renderTargetSize.x;
//apply a 2-pixel bias
distance -=2;
//distance stored in the shadow map
float shadowMapDistance;
//coords in [-1,1]
float nY = 2.0f*( TexCoord.y - 0.5f);
float nX = 2.0f*( TexCoord.x - 0.5f);
//we use these to determine which quadrant we are in
if(abs(nY)<abs(nX))
{
shadowMapDistance = GetShadowDistanceH(TexCoor
}
else
{
shadowMapDistance = GetShadowDistanceV(TexCoord);
}
//if distance to this pixel is lower than distance from shadowMap,
//then we are not in shadow
float light = distance < shadowMapDistance ? 1:0;
float4 result = light;
result.b = length(TexCoord - 0.5f);
result.a = 1;
return result;
}
The functions that read from the shadow map make an inverse transformation of coordinates in order to read from the proper location in the shadowmap.
float GetShadowDistanceH(float2 TexCoord)
{
float u = TexCoord.x;
float v = TexCoord.y;
u = abs(u-0.5f) * 2;
v = v * 2 - 1;
float v0 = v/u;
v0 = (v0 + 1) / 2;
float2 newCoords = float2(TexCoord.x,v0);
//horizontal info was stored in the Red component
return tex2D(shadowMapSampler, newCoords).r;
}
float GetShadowDistanceV(float2 TexCoord)
{
float u = TexCoord.y;
float v = TexCoord.x;
u = abs(u-0.5f) * 2;
v = v * 2 - 1;
float v0 = v/u;
v0 = (v0 + 1) / 2;
float2 newCoords = float2(TexCoord.y,v0);
//vertical info was stored in the Green component
return tex2D(shadowMapSampler, newCoords).g;
}
(Note: in the source code, you might notice a commented out version of the DrawShadowsPS function. That one was using three taps in order to smooth out the aliasing of the shadows, quite similar to what PCF method for 3D shadow maps does. This was left out because the smoothing through blur is much better looking)
Another thing to notice is that we store the distance from the center in the Blue component of the result. This is useful when we want to smooth out the shadows by applying Gaussian blur, with radius depending on the distance from the light. Thus we obtain harder shadows closer to the light source, and softer shadows further away.
5. Next in my implementation, I apply a horizontal blur, followed by a vertical blur. The code for this is not too special, except for the fact that the blur radius depends on the distance from the light. All shader source can be seen in the attached archive, and I will not reproduce the blur shader here. When doing the final blur step, I also add some attenuation to the light, and the result is finally the one we were looking for.
And this concludes the explanations about the algorithm I used for the shader-based soft 2D shadows. I hope my explanations were clear enough
Hi all,
I know it’s been a while and believe me, no one regrets me not having enough time to release samples more than me, but sometimes that’s the way it is. I believe last time I left you all with a big tease about that dynamic 2D image based shadows sample… I promise I will release it at some point in the future (hopefully sooner rather than later), even if it’s just the code, without a full-fledged tutorial.
On a more happy note, I have been re-awarded the title of XNA/DirectX MVP for 2010, and I’m extremely happy about it. Especially so because this is a great year for XNA, with the release of a new version and a new platform, and I’m glad to be in the middle of it. So enough mushy-wushy talk… What did I do this year to deserve this? Here’s a list of some of my contributions to the XNA community throughout 2010:
I’ve had my share of posts on the XNA forums. I hope at least half of them helped someone out.
Held a talk about XNA game programming at a local university in Cluj-Napoca
Held a two-part online webcast course for a university in Iasi
Gathered and posted links to XNA-related stuff and other News items
Made plans for other cool stuff on sgtconker, but didn’t have time to bring them to completion
That’s about it. Looking back, the list is not as long as I would have liked, but it’s been a busy year for me, so I take shelter is knowing that I did as much as I could
I’ll try to post more cool or interesting stuff later this year, so stay tuned! Also, watch www.sgtconker.com for other XNA news and articles!
I’m happy to announce a new tutorial, which happened by chance I accidentally stumbled upon some old drafts of mine for a project that never saw the light of day, and I decided to post one of those drafts online.
It talks about the High Level Shading Language, some of its history, syntax and structure. The whole tutorial can be found either here on this site; or on sgtconker.com. I hope you enjoy it!
What is Sgt. Conker? It is the new website for games development related articles, news, gossip and whole lot more.
Whenever you want to see something new on the XNA development front, give us a visit, or just subscribe to the site’s RSS feed.
I also take this opportunity to announce one of the upcoming features on Sgt. Conker, the Shader Challenges, where we’ll be challenging you to finish an incomplete shader, or fix a broken one, which we hope will be an interesting way for you to improve your HLSL skills. Stay tuned for this, because it’s comming in the near future, together with a whole lot more!
In my efforts to make the shadows soft, based on the formulas for penumbras, I finally realized that my method does not support physically correct penumbra softness, but I will explain the reason for this when I do the tutorial.
Until then, here’s what I came up with, after applying some Gaussian blur to the final shadow image. (variable degree of softness)
Even if it’s not physically correct, I still think the softness looks good enough.
There’s also an interesting looking result when the radius of the Gaussian Blur depends on the distance from the light…
Those that follow my twitter account have seen this already, but I wanted to let everyone know I’m working on a system for 2D dynamic shadows, again.
However, this one is very different from the last sample I made on the subject. In that one, you had to define the geometry of the shadow casters, and build the shadows based on that. This process also implied lots of computations done each frame on the CPU, which yielded in low peformance. So all in all, even though it looked great, I was never really satisfied with tat technique for shadows.
I spent a lot of time thinking of an alternative way to do dynamic 2D shadows, while not using the CPU too much, and having unlimited complexity for the shadow casters. And two weeks ago, the idea hit me. I’m not going to go into technical details just yet, since I plan to make a nice tutorial about this, but I can say that my idea was based on taking the concept of shadow maps from 3D and somehow use it in 2D.
Here’s two pictures of how it looks so far:
As you can see, the casters can have any shape and complexity, and furthermore, the complexity of the shadow casters has no effect on the framerate.
I’m still working on this, but you’ll know as soon as it’s done.
Last time, I talked about my experience with drawing and animating 2D images with ToonBoom. In the end of that post, I said that one way to load ToonBoom animations in XNA was to export the animation as a sequence of images, and then load these images and animate them in XNA. So today we will look at a quick way to to just that.
The exporting part is easy enough: just user File->Export Movie in ToonBoom, and then select Image Sequence as the Export Format. The result will be a collection of images, depending on the framerate you choose. The result from my cat animation can be seen in this archive.
The next step is assembling all the images in a single image, usually called a sprite-sheet. Of course, you could also simply load all the images as they are in several Texture2D variables, but working with sprite-sheets yields better performance. For the creation of the sprite-sheet, there are several options.
The first one is to open an image processing application, load all small images, and assemble them in a single image manually. You can imagine this is time consuming, and only worthy if you plan on doing this operation for a very small number of sprites.
The second option, which I used for this sample, is to write a small program that takes the images as input, and generates the sprite-sheet as you want it. My version of this was quickly hacked in a few minutes, so you can see from the source code (get it here) that it makes several assumptions:
all input images are the same size, and are rectangular
the output sprite will contain all input sprites arranged on a single row
the input files are all named similarly (cat1.png, cat2.png, …, cat14.png)
While definitely not an elegant solution, it did it’s job, and I was quickly able to obtain the following image (click for larger size):
The third option, which is the recommended one for a larger project, is to use a more complex program for creating sprite-sheets. You can either create one yourself, based on certain file formats you want to use internally, or around certain restrictions you want to impose on your engine; or you can use an existing one, such as Ziggyware’s Sprite Sheet Creator. Note that if you go for this option, you’ll have to follow certain conventions in your runtime code, imposed by your program used for creating the sprite-sheets.
That being said, we now have a sprite sheet with all the frames of the walking cat animation, and are ready to load this in XNA.
After creating a new XNA project, I read through Nick’s article about Sprite Sheet Animations, and created the following class to hold all information needed for animations. For a detailed explanation, go ahead and read Nick’s article.
1:class Animation
2: {
3: Rectangle[] frames;
4:float frameLength = 1f / 5f;
5:float timer = 0f;
6:int currentFrame = 0;
7:
8:/// <summary>
9:/// Gets of sets the FPS of the animation
10:/// </summary>
11:publicint FramesPerSecond
12: {
13: get { return (int)(1f / frameLength); }
14: set { frameLength = 1f / (float)value; }
15: }
16:
17:/// <summary>
18:/// Gets the Rectangle containing the current frame of animation
19:/// </summary>
20:public Rectangle CurrentFrame
21: {
22: get { return frames[currentFrame]; }
23: }
24:
25:/// <summary>
26:/// Creates an animation object
27:/// </summary>
28:/// <param name="width"> the total width of the input image</param>
29:/// <param name="height"> the height of the input image</param>
30:/// <param name="numFrames"> the number of frames in the sprite-sheet</param>
31:/// <param name="xOffset"> the X origin of the sprite-sheet</param>
32:/// <param name="yOffset"> the Y origin of the sprite-sheet</param>
33:public Animation(int width, int height, int numFrames, int xOffset, int yOffset)
34: {
35: frames = new Rectangle[numFrames];
36:int frameWidth = width / numFrames;
37:for (int i = 0; i < numFrames; i++)
38: {
39: frames[i] = new Rectangle(xOffset + (frameWidth * i), yOffset,
40: frameWidth, height);
41: }
42: }
43:
44:/// <summary>
45:/// update the animation
46:/// </summary>
47:/// <param name="elapsed"> seconds since the last frame</param>
Next, I created a class for the cat, holding a few members we need for the animation.
1:class Cat
2: {
3: Texture2D texture; //sprite-sheet containing the cat animation
4: Animation walkingAnimation; //animation object used for animating
5: Vector2 velocity; //movement direction
6:float movementSpeed; //movement speed
7: Vector2 origin; //origin of the image
8:bool isMirrored = false; //draw the image mirrored
9:
10:public Vector2 Position { get; set; } //position on the screen
Nothing really special here… Maybe except the isMirrored variable. We use this because our image for the cat shows it facing left. So when we want it to move towards the right, rather than creating a separate sprite with the cat facing right, we mirror the existing sprite. Of course, you can’t always use this trick (or a right-handed character suddenly becomes left-handed), but there are many cases when this trick is enough.
The constructor is straightforward, with some hard-coded values tweaked until I was satisfied with how things looked.
1:public Cat(Texture2D texture, int frameCount, Vector2 origin)
2: {
3:this.texture = texture;
4://create a new animation object
5: walkingAnimation = new Animation(texture.Width, texture.Height, frameCount, 0, 0);
6:
7://tweak the FramesPerSecond and movementSpeed values until you're satisfied with how things move
8: walkingAnimation.FramesPerSecond = 14 * 3;
9: movementSpeed = 256;
10:
11://reset position
12: Position = Vector2.Zero;
13:
14:this.origin = origin;
15: }
For movement, input from both keyboard and gamepad is analyzed, and the velocity’s value is updated.
In the Update function, we first look which way the cat is facing, and update the value of isMirrored. Then, if the cat is moving, we update the animation and position on the screen.
1:publicvoid Update(GameTime gameTime)
2: {
3:
4://mirror the cat if we are moving towards the right
23: Position += velocity * elapsed * movementSpeed;
24: }
Finally, the Draw function takes as a parameter the active spriteBatch, and draws the current animation frame using it. Here we can see how to mirror the sprite using SpriteEffects.FlipHorizontally.
With this class created, using it in our Game class is trivial. Simply load the texture in LoadContent() and create a Cat object, update it’s input and internal state in Update() and draw it in Draw().
If you run the game now, you’ll be able to move the cat around the screen with the keyboard or the mouse. As you can see, getting an animation from ToonBoom into an XNA game is not difficult at all.
I hope you enjoyed this short post, and if you did, you can download the source for this sample here: ToonBoomAnimationSample.zip
Over the last week or so, I had the chance to play around with ToonBoom Studio, which is a software for creating graphics and animations using a large range of techniques. I won’t start to enumerate the whole feature set, which you can see in the video tour, or the detailed features list. However, I will talk about my own experiences with the software, about what I was able to do and of course about integrating it with XNA.
The first thing that needs to be said is the ToonBoom is not just a software for drawing images, but has features designed specifically for creating animations, which lack in other drawing packages such as Photoshop, GIMP, or Paint.Net. So because they serve different purposes, you can’t directly compare Toon Boom with these tools.
The interface is nice and after a few hours of fooling around, and reading some tutorials, you get the hang of it and start being productive. After some experiments that are not really worthy of being shown, my first serious attempt was to try and draw the following image in ToonBoom.
My favorite feature of ToonBoom is the ability to take an image, and put it on the Static Light Table (semi-transparent background) so you can draw over it using the ToonBoom drawing primitives. In less than an hour, I was able to create something similar to the source cat image, but all done with vector graphics.
Now it was time to animate it, and the technique that seemed easiest to me was the cut-out animation technique. In this technique, you can isolate areas of the image, creating body parts, and link them together to create a hierarchy of part, just like you would do a skeleton in a 3D modeling animation. Then, in order to animate, you simply set the keyframes with different position and rotation values for each body part, and ToonBoom will take care of interpolating and animating your scene.
Since this was also a learning exercise, it took several hours, but in the end, I had the following animation:
Considering it’s my first jab at 2D animation, I was very satisfied with the results.
The whole cat drawing was based on someone else’s art as a source image, so I felt like a little cheater This is why today I found one of my older “concept drawings” (if you can name it so), and decided to try and make the character in ToonBoom.
As you can see, my art skills are not something to be proud of. However, about 2 hours later, the result looked much better.
I’m sure a talented artist would have done this much faster, and with much better results, but from my point of view, it is a great progress. Some things I did to help me out:
I used my concept art for static light, and drawn over it using the brush tool, or the poly-line tool
I used random images on the internet to try and understand how to make a sword look sharp
I used a picture of Mickey Mouse as inspiration for drawing the shape of the boots
For the clothing details, I took them one at at time, and tried to add some simple details (the belt, the buttons, the shine on the boots) to make them look more interesting.
From now on, if I want to animate this particular fellow, rigging him for the cut-out animation technique should be rather easy.
A point of interest is how to integrate this tool with XNA for creating games. The first thing to know is that ToonBoom doesn’t have any special features to connect it to XNA.
What it can do is to export the animation as a sequence of images (at the framerate you desire, where intermediate frames will be generated automatically by the software), so after that, you still have to take those images, assemble them as sprite sheets, and write code to animate them in your game. You can’t fault ToonBoom Studio for that, because there really isn’t any software out there that does more than this.
But I can still dream. [dream state on] Just like ToonBoom Studio has a plugin to load a ToonBoom animation project in Flash and just use it directly, I think there is potential for something similar to be done for XNA. If the project format was open, I’m sure someone could create the necessary components (Content Importer + Content Processor + Runtime classes) to ensure an easy transition of animations and scenes from ToonBoom to XNA. Not for the vector art (which would need to be converted into sprites), but at least for the animations and scenes planning. [dream state off]
With that said, I think ToonBoom Studio is a wonderful tool for 2D drawing and animation, and I wholeheartedly recommend everyone to go and download the trial, and see for yourselves if it can help your game. I, for one, am going to use it for all my future 2D game graphics needs.
P.S. Creator’s Club Premium Members get a nice discount for Toon Boom Studio. See this for more information.
![istockphoto_3797058-smiling-cat-cartoon[1]](http://www.catalinzima.com/wp-content/uploads/2009/07/istockphoto-3797058smilingcatcartoon1.jpg "istockphoto_3797058-smiling-cat-cartoon[1]")
