10
\$\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.

\$\endgroup\$
  • \$\begingroup\$ I not surprised you did not find technical comparison, as both are implementation-dependent (more for arrays). \$\endgroup\$ – wondra May 17 '16 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 '16 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 '16 at 10:49
11
\$\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.

\$\endgroup\$
  • \$\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 '16 at 4:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.