So a texture is an image that is wrapped around a 3D model to add apparent detail -- but what's a texture atlas? A texture atlas is an image that contains multiple textures. For example, below you can see a character texture on the left, and a texture atlas on the right (with four character textures).

Why use a texture atlas?

There are two main reasons to use a texture atlas. First, it can increase rendering speed by allowing you to batch more objects into a single draw call. For example, if all the plants in the game use just one texture atlas, then you can draw them all at the same time. Otherwise you would have to draw one group of plants, switch texture state, draw another group of plants, and so on.

Second, it allows you to use unusually-shaped textures. Most graphics cards are designed to use textures that are square and have dimensions that are powers of two, such as 256x256, 512x512, and so on. But what if you have a graphic that is 550x130? You would have to put it in the middle of a 1024x1024 texture, and waste all the extra space. Alternately, you could pack a lot of unusually-shaped textures into one square texture atlas, and hardly waste any space at all!

For both of these reasons, the Black Shades iPhone port has all the UI textures in the game on one texture atlas. Here is a small part of it:

How do you create a texture atlas?

To create a texture atlas you just need to combine several textures into one image, and keep track of the coordinates of each subimage. Henry created that Black Shades atlas entirely by hand, moving subimages around and checking pixel positions. However, since then he found an interesting online tool for creating texture atlases, called Zwoptex.

Alternately, you can create them automatically. There are a number of tools that you can use for this, or you can write your own. There is an algorithm with pseudocode here that you could try. In Overgrowth, after calculating shadow maps, they are automatically combined into a texture atlas.

The shadow map atlas is created using an algorithm similar to the one linked earlier, using a greedy algorithm to fill from one corner outwards. However, in the Overgrowth version, the textures are sorted by size. First, it starts at the smallest textures and walks upwards to create a list of the textures that will fit in the atlas. Then it adds the list to the atlas starting at the biggest one to make sure that there are no gaps.

Check out the post on two-part shadow maps if you're wondering why they look like this.

As you can see, the biggest textures can be many times as big as the smallest ones, which is why we have to prioritize the smallest ones if we want to include as many textures as possible.

How do you use a texture atlas?

Texture coordinates are usually relative to the size of the individual texture, with (0,0) corresponding to one corner, and (1,1) corresponding to the opposite corner. But what happens when the texture is added to an atlas? Let's consider three points on our original example, and their corresponding points in the atlas:

Each of the coordinates is scaled by (0.5,0.5) and offset by (0.0,0.5). When creating the atlas you have to keep track of the offset and scale for each texture so that you can access them again later. In Overgrowth, the shadow map offset and scale is applied using the vertex shader so that the same model can be used with multiple shadow map coordinates.

Texture atlas limitations

Texture atlases will not work with tiling textures. Instead of tiling, they will start showing other textures in the atlas, which is almost certainly not what you want. The same is true for models that have texture coordinates outside of the range from 0 to 1, assuming that they will wrap around.

It is also inefficient to use texture atlases if not all of the textures are used at once. For example, if you have all your plants on one texture atlas, and the level only uses one plant, then you are wasting a lot of texture space on the graphics card. The texture atlas should only be used if all or most of the textures are likely to be visible.

However, when used responsibly, the texture atlas is a useful tool in any graphics programmer's toolbox. Do you know of any good tools or algorithms for working with them that I didn't mention?

I was temporarily separated from my Wolfire live chat duties this past week while I was at GDC. However, the visitors continue to stream in. If you've seen all the silly Meebo posts, you might be skeptical of the fact that useful stuff does indeed happen on live chat. However, since productivity is another way of saying boring here's another onslaught of Meebo madness.

Remember if you're trying to ask me questions about Overgrowth and I'm not around or able to respond, don't despair. Just leave me your email address and I'll get back to you as soon as I can. You can also take the initiative and email me. Also, don't forget about Wolfire's public IRC channel.

The shadow maps we use in Overgrowth are unusual in that they contain two parts: direct shadows and ambient occlusion. These correspond to the two light sources in outdoor scenes, the sun and the sky. To explain how this works, let's consider this scene with a house in the desert:

The first part of the shadow map consists of direct shadows. We calculate them by dividing the scene into a grid and accumulating high-precision depth map shadows. This is done on the graphics card in order to achieve a much higher calculation speed. Here are the direct shadows for this scene:

There are some texture alignment artifacts here, but they're subtle when lit, so I'm saving them for later

The second part of the shadow map is ambient occlusion -- how much total light is received from the sky. This is calculated by accumulating the direct shadows from 64 points on the sky hemisphere. Here is the ambient occlusion for this scene:

See this post for more complex examples of ambient occlusion.

We could store both of these shadow maps separately, but for efficiency we can combine them into one shadow map. The graphics card stores images with three color channels (red, green and blue), so we can store the direct shadows in the red channel and the ambient occlusion in the green channel. Below you can see the direct shadows, the ambient occlusion, and the combined two-part shadow map.

To apply shadowed lighting, we just modulate the direct lighting by the direct shadows, and the ambient lighting by the ambient occlusion. We then add the modulated direct and ambient lighting to get the total lighting for each pixel. Below you can see the modulated direct lighting, modulated ambient lighting, and combined total lighting.

Now all we need to do is combine the lighting with the color map, and we have our finished image! Here is the total lighting, the color map, and the final image.

We recently discussed why ambient occlusion is important for characters (in this post), and it's important for environments for the same reasons -- it helps define the space and adds depth to shadowed areas. Below we have a comparison shot without ambient occlusion on the left and with ambient occlusion on the right. Look under the awning and the wooden walkway to see how it helps define enclosed spaces.

Many games approximate direct and indirect lighting using cascading shadow maps, screen-space depth comparisons, and deferred light accumulation. These techniques are powerful and fun to use, but their rendering artifacts and hardware requirements make them inappopriate for Overgrowth. For us, the efficiency and accuracy of baked shadow maps make them a better choice.

Here is what is new in Overgrowth in the 70th weekly alpha. If you are confused what a weekly alpha is, or even what Overgrowth is, please read our fancy FAQ. Basically, we are developing a massive video game from the ground up -- we are able to do this completely independently by accepting preorders for the game before it's done!

Here are a few highlights from the source repository:

• Starting to switch from ODE to Bullet
• Enabled Mac loading animation
• New Windows installer
• Improved AngelScript error handling
• Added material events
• Added per-material footstep sounds

Bullet box test!

Thanks as always for all the support! See you guys in IRC and the forums.

Some of you probably noticed that I have been neglecting my live chat duties on Wolfire's contact page. The reason was that while the rest of the team spent most of their week fighting the good fight on Overgrowth, I was hanging out at GDC 2010 in San Francisco.

The Independent Games Summit

Tuesday marked the start of the Independent Games Summit. It was great to see all the indies together again. Many of the guys I hadn't seen since Austin. The summit kicked off with Ron Carmel's explanation of the new Indie Fund which sounds like a cool way for indies to raise capital for gaming projects without getting pwned by the terms of a standard publishing contract.

Photo courtesy of the Game Developers Conference

I also had the great honor to give a speech about our practice of Open Development. It was similar to the 60 minute GDC Austin PR presentation except there was even more I wanted to talk about (Game Connection Lyon and the Organic Indie Preorder Pack) and I only had a 30 minute time slot to do it in.

I think the speech went pretty well except for a random error that popped up right when I tried to play the infamous Race Course video. I suspect the Whale Man had something to do with it, but fortunately I was able to work around the problem without losing too much time. Arnold Schwarzenegger and Deckard Cain impressions may have occurred over the course of the speech. Aubrey kindly attempted to record the presentation with my digital camera but it ran out of battery power. :(

The Independent Games Festival (IGF)

One of the most exciting parts of GDC was definitely the Independent Games Festival. There were so many good games this year that it was a real treat to walk from booth to booth trying them out.

You can see from the final awards tally that Andy Schatz, whose exceptional disc golf skill we mentioned earlier in the week, ended up winning the grand prize for his expertly-crafted game Monaco. I played Monaco first hand with Andy and I assure you it was quite entertaining. It feels a little like a cross between Thief, Schizoid and the Lost Vikings.

Parties

We managed to move around to quite a few of the after-parties where most of the networking tends to take place.

Me and Dave chilling with the DToid robot.

Also, the awesome guys from ModDB happened to be in town promoting their new online distribution platform, Desura. Thanks to Dave Traeger's awesome schmoozing skills, we were even put on the list for the Destructoid party. It was really awesome to shake hands with Anthony Burch who has given us repeated shout outs.

Miscellaneous Commentary

• Last year the independent games summit was given a room which could fit about 100 people. This year, our lecture hall was big enough to seat over 500 people. Perhaps this is a good omen for indies.

• The second-to-last day of GDC is traditionally kilt day for all the conference volunteers. Sadly, I didn't get the memo in time so I was not able to join in, but I'll be ready next year.

• Edmund McMillen, whose project Super Meat Boy was an IGF finalist, also happens to be growing a mean beard. Whose do you think is mightier?

My beard might have met its match.

• I ran into Mega64 while I was wandering around and made a point of shaking their hand and thanking them for their marvelous videos.

• Google gave me and the other GDC speakers a free Droid smartphone, so now even if I'm not at my computer, I'll be able to read and respond to customer service emails. I've never had a smartphone before and so far it feels like the Droid is smarter than I am. :)