<p>The memory layout of a (2D) array texture is pretty <strong>similar to a 3D texture, with the individual image layers stored one after the other in a big 3D-array of pixels</strong>. So that's also how you set them. You either load each individual image into a big <code>GLubyte</code> array one after the other and set it with <code>glTex(Sub)Image3D</code> or you load each image into its own <code>GLubyte</code> array and transmit that to the texture with <code>glTexSubImage3D</code> one after the other (or any other more complex process involving buffers or whatever, but you get the idea).</p>
<p>So much to the theory. The problem here is the part where you say</p>
<blockquote>
<p>However there's no guarantee that the textures are the same dimensions.</p>
</blockquote>
<p>This contradicts with how array textures work. As the corresponding documentation you link to says:</p>
<blockquote>
<p>An <strong>Array Texture</strong> is a Texture where each mipmap level contains an array of images of the same size.</p>
</blockquote>
<p>So the <strong>individual layers of an array texture <em>have</em> to be the same size</strong>. Simplifyingly said, an array texture is really just a 3D texture without filtering along the z-axis. So you can't get different-sized textures into such a regular box of pixels.</p>
<p>There's a few options you have here, though:</p>
<ul>
<li><p>You could <strong>scale every image to a common size</strong>, depending on <em>how</em> different they really are and what rescaling means to your quality and/or memory demands.</p>
</li>
<li><p>You could just <strong>drop using array textures</strong> and implement whatever you want to do with normal 2D textures and a likely more complicated process on the CPU side.</p>
</li>
<li><p>You could use <strong><a href="https://www.khronos.org/opengl/wiki/Bindless_Texture" rel="nofollow noreferrer">Bindless Textures</a></strong>. This is a rather modern non-core feature (only usable through extensions yet) that is really flexible and allows you to <strong>access textures in a shader by using a unique GPU handle</strong> (a 64-bit ID, so to say). This allows you to use whatever and how many textures you want in a shader, depending on some arbitrarily input value (even a vertex attribute).</p>
<p>In this case you wouldn't just a have access to a continuous array of N textures, rather than the wealth of all the textures you have allocated. You would just use normal independent 2D textures and use their respective texture handles rather than an array index. Of course this comes with a few limitations and intricacies, too. But more about that in the corresponding documentation.</p>
</li>
</ul>

CC BY-SA 4.0
2018-07-06T14:07:36.593Z
2018-07-06T14:15:00.110Z
2020-06-18T08:32:12.800Z
Christian Rau
<p>I have been reading the <a href="https://www.khronos.org/opengl/wiki/Array_Texture" rel="nofollow noreferrer">OpenGL documentation</a> but it is not clear to me how to achieve the following.</p>

<p>Say we have an array of strings. Each string in the array is a valid relative path to an image file (.png, .jpeg...)</p>

<p>We have a method that can read and store into a GLubyte array the image information of each file.</p>

<p>We want to allocate the needed memory for the textures, and save said information into a texture array. However there's no guarantee that the textures are the same dimensions.</p>

<opengl><texture><data-structure><3dtexture>
How do you load multiple textures into an array texture with OpenGL?
Makogan
# How do you load multiple textures into an array texture with OpenGL?

(Asked by: username_0 on 2018-07-06)

I have been reading the [OpenGL documentation](https://www.khronos.org/opengl/wiki/Array_Texture) but it is not clear to me how to achieve the following.

Say we have an array of strings. Each string in the array is a valid relative path to an image file (.png, .jpeg...)

We have a method that can read and store into a GLubyte array the image information of each file.

We want to allocate the needed memory for the textures, and save said information into a texture array. However there's no guarantee that the textures are the same dimensions.

**Tags:** opengl, texture, data-structure, 3dtexture


---

## 1 answers

### Answer by username_1 on 2018-07-06. Score: 3 | Accepted answer

The memory layout of a (2D) array texture is pretty **similar to a 3D texture, with the individual image layers stored one after the other in a big 3D-array of pixels**. So that's also how you set them. You either load each individual image into a big `GLubyte` array one after the other and set it with `glTex(Sub)Image3D` or you load each image into its own `GLubyte` array and transmit that to the texture with `glTexSubImage3D` one after the other (or any other more complex process involving buffers or whatever, but you get the idea).

So much to the theory. The problem here is the part where you say

> However there's no guarantee that the textures are the same dimensions.

This contradicts with how array textures work. As the corresponding documentation you link to says:

> An **Array Texture** is a Texture where each mipmap level contains an array of images of the same size.

So the **individual layers of an array texture *have* to be the same size**. Simplifyingly said, an array texture is really just a 3D texture without filtering along the z-axis. So you can't get different-sized textures into such a regular box of pixels.

There's a few options you have here, though:

* You could **scale every image to a common size**, depending on *how* different they really are and what rescaling means to your quality and/or memory demands.
* You could just **drop using array textures** and implement whatever you want to do with normal 2D textures and a likely more complicated process on the CPU side.
* You could use **[Bindless Textures](https://www.khronos.org/opengl/wiki/Bindless_Texture)**. This is a rather modern non-core feature (only usable through extensions yet) that is really flexible and allows you to **access textures in a shader by using a unique GPU handle** (a 64-bit ID, so to say). This allows you to use whatever and how many textures you want in a shader, depending on some arbitrarily input value (even a vertex attribute).

  In this case you wouldn't just a have access to a continuous array of N textures, rather than the wealth of all the textures you have allocated. You would just use normal independent 2D textures and use their respective texture handles rather than an array index. Of course this comes with a few limitations and intricacies, too. But more about that in the corresponding documentation.


---

