Texture atlas - is it really crucial these days?

I was wondering from your personal experience, how really crucial is using texture atlases for simple 3d games?

I’m doing something in the graphic style of Delver more or less:

And I’m conflicting weather or not I should invest the extra time in making texture atlases and use them for all the tiles, doodads etc, or is it just an overkill for this graphic style and modern graphic cards (and mobile devices should I chose to port it later).

Its so much more simple to just have texture file per tile / object but I’m worried about all the texture swapping :slight_smile:


I’ve got the same thing going on right now… I’m implementing a sprite class that will draw small sprites from big texture files, sprite sheets… Each sprite sheet will be accompanied by an xml file containing all the stencil-rects or frames for each sprite…

So I am looking for a tool that creates XML data from images, that kind of thing must exist… Otherwise, I will make one.

-But I have made a few games, even a few sprite intensive ones, where I just had a loose file for each texture… I would load and unload for each level… And it worked fine for anyone who bothered running it…
Like it didn’t even matter.

Texture atlas with accompanied XML is the approach I’m planning too (when no XML is present I will treat it as a single-texture file). But I plan to simplify things, instead of using texture rects etc all the metadata I’ll hold per atlas is how many sprites there are per column & per row, and when I define a tile or object types they will only indicate which atlas file they are using and the index inside that atlas file. All the rects etc will be calculated at run-time based on texture file size and how many columns and rows in it.

The advantages of this method are:

  1. Very simple xmls and quite simple texture coords calculation.
  2. Agnostic to texture file size, eg if I want HD textures I just replace the texture file itself and as long as I maintain the same ratio and sprites count per row and column I don’t need to edit any xmls.

The caveats are:

  1. Not as optimal as actual rects, since textures are rounded to base unit size (per textures atlas).
  2. I need to group atlases by sprites propotions, eg 16x16 objects cannot reside on the same file with 32x16 objects, unless I add addition param to the objects type XML (width, height), which I’m still considering.
  3. As you can guess from this question its not yet implemented so I might discover real soon that this entire method really sucks for whatever hidden reason.

That’s actually the answer I was looking for :slight_smile: so I’m putting +1 under “overkill, don’t bother”.

1 Like

Overkill don’t bother

I had so much experience doing this ill tell you that the key doesn’t lie in if you need them in a spritesheet now or not. But the ease of which you can switch to either or more exactly the ease of usage and retreval. How you store organize your images on your drive is important. In general i found storing individual images solely in there own location some were is best.

Its way way easier to build a spritesheet then it is to tear individual images out of one.

At first i built a editor to actually do the in and out. While this helps a lot (especially if it doesn’t have xml or a sprite rectangle description file) Or when, if you need to just look at a spritesheet or some picture find a image, drag a square for were it it. Then hit save to disk and name it or save just the area as a new image, I mean ya there is paint dot net you can build your own to do it i did. but the process itself of editing is tedious and gets nerve racking real fast.

It’s way easier to to have a bunch of individual images in a folder some were. Then when you need a spritesheet grab a bunch of them the ones you want for a project, copy them to a new folder and have a little app that you just select the folder and it auto builds them to a sheet or a few sheets with a xml or in my case a simple csv file. Using the name of each file as the name of the rectangle for the image within the sheet.

For the next project you can just do it again with what ever individual images you need no need to save the sheets provided you organize your individual images on your hardrive or at the very least keep them all that way as originals.

If i ever do it again ill build them straight into a text file that i can copy paste into a class image and rectangle class file. So the variable names in the class file are the image names and rectangle positions in the spritesheet and just compile it. I could get the variable names into strings with reflection or add that as i load them in as a string into the class. So i really don’t have to do anything. lol

That would be the uberest lazy way so it must be the best.

So i would instead file this one under its best to find or build a good tool first, and keep your individual sprites in order.

But ya if you really have a lot of single images there is some overhead for texture switching at some point if you get to extreme with it. You will start to take a hit and feel it, more likely though the other guy using your app with a lesser computer will feel it first.

I am also interested in this thread.
What about particles’ textures? I use some of them to produce a sort of high quality animation at close range. Sometimes i need more than 12 textures and their size is about 512x512 at most. The half of them are 128x128 or less to allow their use in a LOD system.
Would it be faster with an atlas (at least for the big ones)
If this is an overkill feature, why even the UE3 or 4 use atlases?

Personally I came to think so too, and having you and @monopalle confirming that made me decide not to use texture atlases for anything that is not super easy to implement. For example in tiles its a bit tricky because tiles are spritesheet themselves (every tile got top, bottom, sides and merges) so its an atlas made of spritesheets and less trivial. However for simple stuff like static non animated doodads (grass etc.) I’ll probably implement something super simple, mainly because there are lots of them scattered around and it should be super easy to use atlas for them.

a dictionary where key is original texture file name and value is source rectangle in atlas - I like that idea :slight_smile:
Maybe I’ll adopt that for the doodads atlas if I end up doing it.

Particle system is a good question tbh that’s something I’d like to hear more about. I was thinking more about tiles and simple objects when opening this thread.

As for why UE implement it (never used UE but I’ll take your word for it) note that in this thread I asked about a very specific game style and I think all the answers were in that context. I’m not sure they apply to a high-end game engine like UE, especially one that competes with other game engines where every feature counts.

Well you can capture renders from any modern game and look at the textures loaded, you’ll see that it’s basically never a texture atlas, very rarely you’ll see some virtual texturing.

The textures are in the VRAM either way, when you switch to a texture only the reference changes (if your vram isn’t full).

Plus - if you want to do 3D in monogame you can forget about texture atlai anyways because you would have to make custom mip maps since the auto-generated ones are not a good fit for an atlas. But alas monogame doenst allow access to mip maps as rendeetargets, so you must be content with no texture filtering like it’s 1999 or make some super expensive dilation hacks around that issue. I think it’s beneficial even for a minecraft style game to use texture filtering

You can simulate mipmaps in 3d with either multitextureing or with a offset and scalar passed to a vertex shader provided you establish yourself some image or atlas rules basically specifications though im not sure how you go about that exactly with a loaded model for custom vertex formats and primitives you could do it.