Advertisement

Texture Atlas - Best practices?

Started by June 06, 2015 07:23 PM
0 comments, last by Rattenhirn 9 years, 7 months ago

Hi everyone!

I'm currently working on a 3D third person shooter project in Unity, and I've began looking into optimizing my scenes, as my frame rate wasn't ideal. Baked lighting and baked occlusion culling aren't an option as the game's world is procedurally generated from prefabs, so optimizing everything else as much as possible is very important.

Currently I've been joining meshes and creating LODs, and I'm looking into texture atlases. Sadly, I haven't found much information on this topic other than "mixing various textures into one = less draw calls".

My project is a PC game which ideally could be ported someday to consoles such as the PS4, Wii U or Xbox One. So no mobile restrictions.

So here are some questions I couldn't find answers for, or want to make sure I understand:

  1. Usually, how big are texture atlases in modern 3D games?
  2. I know textures should be square in Unity for better performance, but what about texture atlases? Would a 1024 x 512 texture be more expensive than a 1024x1024 that isn't fully used?
  3. I assume having textures that need a transparent material shouldn't be in the same atlas as textures that don't, so a tree's trunk texture shouldn't be in the same atlas as the leaves, am I correct? Do developers usually make an atlas for transparent textures on one side, and opaque in another? So for example "vegetation01_transparent.jpg" and "vegetation01_opaque.jpg"??
  4. In my project, the player can pick up different kinds of armour, and he can have up to 5 pieces of armour of different sets equipped at the same time (e.g. metal helmet, bandit gloves, short trousers...). There'll be at least 50 pieces of armour in total in the game, highly unlikely to find pieces of the same armour set. It wouldn't make sense to group these in atlases, right?
  5. What are the best practices to establish what should be in an atlas? Is it just "things that use the same shader and usually appear near each other in the game"?

Thanks for you time, I hope you can all give me some insight into the best practices when it comes to this! biggrin.png

Hi, I have very little experience with Unity, so I can't tell you what you options there are. I have, however, give some insights on your questions from a general point of view.

Firstly, there are only two cases where texture atlases can be beneficial nowadays:

1. Reduce draw calls. By combining textures into one, more things can be drawn with one draw call. This means that they draw calls also need to have the same render states, the same vertex and index buffers, the same shaders, and if instancing is not available, the same shader parameters.

Basically, when draw calls are completely identical, except for their bound textures, they could be combined, saving on some of the overhead. There are very few cases of this is actually the case, so you should go ahead and analyze your typical scenes to estimate what the possible gains are.

Also, when the platform has texture arrays or bindless textures, use these methods instead.

2. Reduce texture memory requirements. In most cases today, texture atlases actually will need more memory than individual textures. If you're targeting platforms that have limitations like only square texture, only POT ("power or two") texture dimensions or mipmapping only for POT textures, atlases can be beneficial.

None of the platforms have any of these limitations IIRC, definitely not PC.

Also, if your textures have already been manually combined by the artist, as shown in this image texture space is used very efficiently, so that can be beneficial. But there's no good way to do these automatically and it's quite difficult to get right manually as well. Those have the additional advantage of reducing draw calls as well.

Texture atlases have a lot of downside. They are a PITA to create and manage and they are prone to artifacts due to filtering and through mipmapping, so in my opinion they are rarely worth the effort.

On to your questions:

Ad 1. Modern 3D games won't use texture atlases at all, for the reasons given above. If they do, they make them as big as possible, limited only by hardware capabilities and actual needs.

Ad 2. Atlases are exactly like normal textures, so all limitations for textures apply to atlas textures as well, plus a few additional ones. I know of no recent platform that would require square textures or performance benefits for square textures. The performance hit that Unity might be talking about is, that when it encounters a platform with only square textures, it has to make all non-square textures square on the fly, increasing load times, memory usage and texture memory pressure. But a platform like that would be an ancient one anyways...

Ad 3. It's up to you how you organize your atlases. Remember, your goal is to reduce draw calls. You can put leave and trunk texture in separate atlases and use them in two draw calls, you can put them in the same atlas and use them in two draw calls, no difference in number on draw calls. The latter method _may_ save one texture switch, if the draw calls are sequential, but that would come with a render state and possible shader switch as well, so not much upside.

Or, you could put them in the same atlas and draw them in one call, using the semi-transparent settings. You save one draw call, but render the opaque part inefficiently and possibly with artifacts. Many options, none of them are easy wins. :)

Ad 4. Very few savings possible by grouping them. In addition, I guess these armor pieces might have different meshes anyways, so it's not possible to combine these draw calls in the first place.

Ad 5. Yes, things that are likely to be used by the same shader, vertex/indexbuffer and renderstates, and are rendered in sequence, so they can be combined. Not much usually fits that bill.

Here are a few things that come to mind where texture atlases might be beneficial:

- vegetation / grass

- particle systems

- crowds

- gui, menus and other 2d elements

In short, I think you'd be better off finding something else to increase performance. Did you do measurements? Are you sure that draw calls are your #1 performance killer? PCs nowadays can handle quite a lot of those with no problems...

I hope that helps!

This topic is closed to new replies.

Advertisement