How to Create a Texture Atlas in Unity (and Actually Cut Draw Calls)

You combined your meshes, but the draw calls barely moved. The reason is almost always materials: every unique material is a separate draw call, and no amount of mesh combining helps until your textures share one. A texture atlas fixes exactly that — here's how it works and three ways to build one.

Why your draw calls didn't drop

Unity issues one draw call per material per object (roughly). If your scene has 200 props using 200 materials, you get ~200 draw calls — even if every prop is a 12-triangle box. Mesh combining merges geometry, but combined meshes that still reference 15 different materials still cost 15 draw calls. The material count is the ceiling; geometry merging only gets you to that ceiling.

A texture atlas attacks the ceiling directly. Instead of 20 small textures on 20 materials, you pack all 20 textures into one big image, point every mesh at that single texture through one shared material, and 20 draw calls become 1. This is the single highest-leverage optimization for prop-heavy, modular, or kit-bashed scenes.

What an atlas actually is (the UV math)

An atlas is just a big texture divided into regions, where each region holds one of your original textures. The magic is in the UV coordinates: every mesh's UVs get remapped so they sample only their own region of the atlas instead of the full 0–1 range of their original texture.

Say your atlas is a 2048×2048 image and one prop's texture occupies the rect starting at (1024, 0) with size 1024×1024. In normalized UV space that's the rect (0.5, 0.5, 0.5, 0.5) — x, y, width, height. A UV of (0.25, 0.75) on the original texture becomes:

// Remap a mesh's UVs into one region of a texture atlas
void RemapUVsToAtlas(Mesh mesh, Rect atlasRect)
{
    Vector2[] uvs = mesh.uv;
    for (int i = 0; i < uvs.Length; i++)
    {
        uvs[i] = new Vector2(
            atlasRect.x + uvs[i].x * atlasRect.width,
            atlasRect.y + uvs[i].y * atlasRect.height
        );
    }
    mesh.uv = uvs;
}

// Example: prop texture lives in the top-right quadrant of the atlas
RemapUVsToAtlas(propMesh, new Rect(0.5f, 0.5f, 0.5f, 0.5f));

That's the entire trick. Everything else — padding, mipmaps, packing algorithms — is about doing this at scale without visual artifacts.

Method 1: Unity's Sprite Atlas (2D only)

For 2D games, Unity has a built-in solution: Window → 2D → Sprite Atlas. Create an atlas asset, drag your sprites in, configure padding and compression, and Unity packs them automatically at build time. Sprites sharing the atlas and material batch into fewer draw calls with zero code.

Limitations: it's sprite-oriented. For 3D meshes with their own UV layouts, the Sprite Atlas won't remap your model UVs — you need one of the methods below.

Method 2: Manual atlas in an image editor

For full control, build the atlas yourself:

1. Collect every texture used by the meshes you want to merge. Note each texture's size — aim for a power-of-two atlas (1024, 2048, or 4096).
2. Pack them into one image in Photoshop, GIMP, or a packing tool. Leave 4–8 pixels of padding between regions (more on why below). Record each region's pixel rect.
3. Convert each pixel rect to normalized UV space: divide x and y by atlas width/height.
4. Remap each mesh's UVs with the code above, using its region rect.
5. Combine the meshes with Mesh.CombineMeshes (or a tool), assign one material using the atlas texture, and verify in the Frame Debugger.

This works, but it's labor-intensive and fragile: add one new prop and you repack the whole atlas and re-remap everything. Fine for a final art pass on a small game; painful for anything iterative.

Method 3: Automated atlas baking (the practical choice)

Atlas baker tools do steps 2–4 for you: they collect textures, pack them with proper padding, remap every mesh's UVs, and output one material. The packing algorithm matters — a good packer minimizes wasted space (which costs texture memory) while keeping enough padding to prevent bleeding.

What to look for in a baker: padding control, power-of-two enforcement, handling of normal maps and metallic/roughness maps (these must be packed as separate atlases, not crammed into the color atlas), and preservation of your second UV channel if you use baked lightmaps.

Atlas pitfalls that break your visuals

Texture bleeding. Without padding, bilinear filtering samples neighboring regions at UV seams and you get colored fringes on your models. Fix: 4–8px padding, more for small atlases.

Mipmap bleeding. At lower mip levels, regions shrink and neighbors bleed together even with padding. Fix: generous padding, and keep functionally different textures (opaque vs alpha-tested) in separate atlases.

Non-power-of-two sizes. Mobile GPUs compress poorly (or not at all) with NPOT textures. Keep atlases at 1024/2048/4096.

Max texture size. A 4096 atlas with 64 props means each prop gets ~512px of texture — fine for background props, blurry for hero objects. Split hero assets into their own materials; atlas the rest.

Lightmap UV2. If you bake lighting, Unity needs a second UV channel. Atlas bakers must preserve or regenerate UV2 — verify this before committing to a tool.

The one-click way: MeshWeld Pro Lite

Doing this by hand for a scene with hundreds of props is a full day of tedious, error-prone work — and it all breaks the moment art changes. MeshWeld Pro Lite combines the whole pipeline into one editor action: select your meshes, and it merges the geometry and bakes the texture atlas with correct padding, power-of-two sizing, and UV remapping, outputting a single material. Change your art, re-run, done.

Measuring the win

Don't trust vibes — verify with the Frame Debugger (Window → Analysis → Frame Debugger). Before the atlas, you'll see one draw event per material; after, the atlased props collapse into a single draw event. Check the Game view Stats panel too: watch "Batches" drop. A typical prop-heavy scene goes from 150–300 batches to under 50 with combining + atlasing, which is often the difference between a stuttering 40fps and a locked 60 on mid-range hardware.

One more check: profile on your actual target device. Draw-call overhead is CPU-side, so a scene that runs fine on your development PC can still choke a phone or Quest — the atlas savings show up biggest exactly where you need them.