15
\$\begingroup\$

Unity 5.4 (currently in beta), will bring a much awaited feature (since 2013) that is array-textures - in the same vain as OpenGL's ArrayTexture. However, after doing some reading about arrays-textures and texture atlases, I still can't quite understand the technical differences on their usage by CPUs and GPUs.

So, to be more specific, I would like to ask for an explanation on the main differences between how texture atlas and texture arrays are dealt with by CPU and GPU and, most importantly, how such differences can impact on performance and memory handling (e.g. how texture arrays can be more performance than texture atlases, etc).

If technical details on Unity's implementation are lacking due to its unfortunate closed-sourceness, I would be happy enough with an answer regarding OpenGL.s ArrayTexture.

Improve this question
\$\endgroup\$
3
  • \$\begingroup\$ I not surprised you did not find technical comparison, as both are implementation-dependent (more for arrays). \$\endgroup\$
    – wondra
    May 17, 2016 at 10:18
  • \$\begingroup\$ You are going to have a hard time getting information on how the internals of the Unity engine function, as it is a closed source, black box. The only thing you can do, is profile each case and get yourself a comparison of the cpu and gpu usage. To understand how it works, would require a Unity engineer to step in, or their source code to be opened up or leaked. \$\endgroup\$
    – jgallant
    May 17, 2016 at 10:46
  • \$\begingroup\$ @Jon Fair enough, but actually I was more interested in an engine-agnostic answer. If it varies that much, I can update the question to talk about, for instance, OpenGL's ArrayTexture: opengl.org/wiki/Array_Texture \$\endgroup\$
    – ASteer
    May 17, 2016 at 10:49

1 Answer 1

Reset to default
15
\$\begingroup\$

As noted in the comments above, performance is going to depend on implementation, your particular hardware, and what you're trying to do with the textures, so the only reliable answer there is to profile each alternative.

There are a few differences in terms of how you use each option though, which will apply consistently:

One big difference is that, for array textures, each texture is treated separately for purposes like wrapping texture coordinates or mipmapping.

This avoids common problems with texture atlases where we need to add padding between adjacent texture swatches to keep samples at their edges from bleeding together, especially in deeper mip levels.

This also means if you want your textures to tile, you can use the texture sampling hardware to do it just like with a vanilla texture. With atlases, we usually have to do the tiling math in our fragment shader, since the sampler only wraps/mirrors/clamps/borders texture coordinates over the whole atlas, not individual tiles inside it.

The main restriction with array textures is that they require all their constituent textures to have the same resolution and number of mip levels. If you're trying to batch-together textures with very different resolution needs (say, storing terrain tiles whose LoD falls off with distance in a virtual texture) then you may want the flexibility of an atlas instead.

Improve this answer
\$\endgroup\$
4
  • 1
    \$\begingroup\$ Thanks, that was exactly what I was after. I mean, not an answer about precisely which is faster less memory intensive - since of course these are dependent on implementation. Still, I was sure that some pointers on the functioning of each case could be useful to understand their usual best and worst fit scenarios. Your answer has indeed helped me on that. \$\endgroup\$
    – ASteer
    May 20, 2016 at 4:41
  • \$\begingroup\$ Another disadvantage of array textures: they are limited by GL_MAX_ARRAY_TEXTURE_LAYERS. On my semi-modern GPU, this is 2048, so if you want tons of tiny textures, this limit might be too low. \$\endgroup\$
    – jwd
    Nov 22, 2019 at 2:11
  • \$\begingroup\$ @jwd Couldn't you solve that by just making a second array texture? \$\endgroup\$
    – Dan
    Jun 18, 2020 at 10:25
  • 1
    \$\begingroup\$ @Dan: Sure, but then you have to manage those multiple textures. If, for example, you currently have a texture atlas solution, and are considering switching to texture arrays, this is one of the things you'll need to consider. It could be that the current system assumes everything is in one texture, for instance. \$\endgroup\$
    – jwd
    Jun 19, 2020 at 17:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .