{"id":50911,"date":"2020-10-06T06:00:15","date_gmt":"2020-10-06T10:00:15","guid":{"rendered":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=50911"},"modified":"2020-10-08T11:27:59","modified_gmt":"2020-10-08T15:27:59","slug":"project-bug-hunt-5-more-about-the-atlas","status":"publish","type":"post","link":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=50911","title":{"rendered":"Project Bug Hunt #5: More About the Atlas"},"content":{"rendered":"

Last time I talked about what an atlas texture is, why we need them, and how I use them. The important thing is that I’m not hand-crafting the atlas every time I add a new texture. I have some code that does all of this for me. It reads all the images in a particular folder, sorts them-large-to-small for efficient packing, and then generates my atlas texture. It also stores the location of each texture within the atlas. So later when I’m busy generating walls and level geometry, I can say:<\/p>\n

cell = LibraryAtlas.Lookup (“textureName”);<\/p>\n

That gives me the location of the sub-texture within the atlas. Now I can plot uv<\/b> coords as if I was using a standalone texture and not worry about the atlas at all. That’s immensely important when you’re building polygons with code and you want to keep things as simple as possible.<\/p>\n

Last time I shared my atlas texture.\u00a0Actually, that was just one fourth of the atlas. Sort of? The point is, I don’t just have one atlas texture. I have four.<\/p>\n

<\/p>\n

The Atlas Collection<\/h3>\n

So how it works is I hand the shader four different textures. These are all atlas textures with the same exact layout of sub-images, but each atlas contains different data. The shader looks at all the different atlases and does some calculations to figure out what the final color will be for this particular pixel.<\/p>\n

It’s important to note that a texture is a collection of four channels of data: Red, green, blue, and alphaAlpha just means transparency.<\/span>. Sure, RGB values are normally used to store color, but since I’m writing this shader myself I can interpret the data however I want. I can use a blue channel in one of the textures to determine how much to tint the base texture pink. To the shader, it’s all just numbers.<\/p>\n

So let’s talk about these four different textures.<\/p>\n

The Diffuse Map<\/h3>\n

<\/p>\n

This is the simplest and most obvious of our four textures. It contains the traditional texture data that most people are familiar with. If this was 1997, then this would be the only textureAside from baked shadow maps, which aren’t worth exploring right now.<\/span>. But even though I’m planning on using retro-ish assets, I’m not sticking to pure retro technologies.<\/p>\n

So we need a few more textures.<\/p>\n

The Normal Map<\/h3>\n

<\/p>\n

In the really old days, objects looked very primitive. A supposedly round support pillar would have just six sides. Character models would have primitive mitten hands with the fingers painted on the surface. Everything was blocky and chunky in appearance.<\/p>\n

But then as technology progressed, we gained the freedom to use more polygons. That flagon of ale didn’t need to be based on a five-sided cylinder. Characters didn’t need to have flat faces with a pyramid for a nose. Instead you could model the eyes, lips, cheekbones, and other features.<\/p>\n

But eventually you get diminishing returns and expanding costs if you continue to add detail with polygons. It would be a nightmare to model a wall where every brick, every crack, and every surface imperfection was fully realized in 3D. All of those millions of polygons would multiply the work needed to be done by the rendering system. Drawing the wall would be slower. Lighting the wall would be slower. Casting shadows would be slower. Heck, just loading the level would take forever.<\/p>\n

You end up with this horrible system where making a room look 10% more detailed would make it 100x slower to draw. Moore’s Law<\/a> has done a lot for us, but even Gordon Moore can’t save us from a growth curve this steep.<\/p>\n

But!<\/strong><\/p>\n

We don’t need to model walls down to the individual brick. The problem we’re trying to solve is that walls look a little too flat when you shine a light on them. Shine a light on the right side of a brick wall, and you expect to see the right edges of the bricks catch the light, and the left edges go dark. If it doesn’t, then the wall doesn’t feel like a brick wall, it feels like a wall covered in brick-patterned wallpaper.<\/p>\n

The solution here is a normal map. Texture maps are intended to hold visual data – pictures of bricks and such. But there’s nothing saying you can’t<\/b> store positional \/ directional data in them. So a normal map uses the RGB color channels to store X, Y, Z vectors. Essentially, the normal map says, “When you render this bit of the wall, pretend the wall faces this direction before you do the lighting calculations.” The bricks will be lit as if they’re really protruding from the wall, without us needing to spend hours of modeling work and millions of polygons to make it happen.<\/p>\n

When I make a texture map, I also make a 3D relief map to go with it. The relief map tells the atlas generator to pretend that bright pixels protrude from the surfaces and dark pixels are depressions in the surface. From there it just takes a little math to create a normal map. <\/p>\n

The Specular Map<\/h3>\n

<\/p>\n

(In the image above, you see some images are greyscale and some are red. The grey ones are leftover from the early stages of the project before I decided how all of this was going to work. Just ignore them. We’re interested in the pink \/ red sections for now.)<\/p>\n

Specular lighting is when you get metallic or glossy highlights from a surface. Let’s consider a few different kinds of surface:<\/p>\n