<p>Say we've idetified that we have a varying number of textures that are upper capped by 2 parametrs. thus we allocate the maximum amount of memory needed to store all textures as follows:</p>

<pre><code>glTexStorage3D(GL_TEXTURE_2D_ARRAY, 1, GL_RGBA8, max_width, max_height, texture_num);
</code></pre>

<p>One by one we allocate each texture to each layer as follows:</p>

<pre><code>glTexSubImage3D(GL_TEXTURE_2D_ARRAY, 0, 0, 0, file, width, height, 1, color_format,
            GL_UNSIGNED_BYTE, data);
</code></pre>

<p>Now since for  some textures width &lt; max_width and height &lt; max_height, when sampling, our sample is off as trying to sample at a value of 1 would result in sampling outside of the bounds of the texture.</p>

<p>One could naively try to solve the issue by multiplying the sampling coordinate by the stretching coefficient.</p>

<pre><code>uv*=width/max_width.
</code></pre>

<p>However this only solves the problem for sampling that happens within the (-1,1) rnage. However, any texture that is meant to be tiled will be wrong. Thus we must do floating mod as well. the final calculation is thus:</p>

<pre><code>u = (u*width/max_width)%(width/max_width)
v = (v*height/max_height)%(height/max_height)
</code></pre>

<p>(Each coordinate is differnece since the vertical stretch could be different from the horizontal stretch)</p>

<p>Thus to do our final rendering we would need to create and store an array of vec2's where the first value is the horizontal stretching coefficient and the second value is the vertical stretching coefficient on teh CPU. Then load that into a uniform buffer or SSBO.</p>

<p>And read these values on the shader side. </p>

<p>This seems a little bit cumbersome. Is there a way to instruct OpenGL to handle these varying sizes or is the only way to solve this issue the one I described?</p>

CC BY-SA 4.0
2018-07-10T09:54:04.210Z
Yes, this *is* cumbersome. But it has already been explained in the answers to [this question](https://computergraphics.stackexchange.com/q/7773/6) that there is no way for OpenGL to directly handle those varying sizes in a texture array. This of course assumes that you *need* a texture array to begin with and aren't just using it for storage convenience. Otherwise texture views *might* offer some flexibility in reinterpreting an existing array layer. But in that case you of course can't have *array texturing* and would just be stuck with individual textures again.
Christian Rau
CC BY-SA 4.0
2018-07-10T22:46:54.273Z
Possible duplicate of [How do you load multiple textures into an array texture with OpenGL?](https://computergraphics.stackexchange.com/questions/7773/how-do-you-load-multiple-textures-into-an-array-texture-with-opengl)
Nicol Bolas
<opengl><texture><c++><uv-mapping><3dtexture>
Handling varying texture sizes in an array texture
Makogan
# Handling varying texture sizes in an array texture

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

Say we've idetified that we have a varying number of textures that are upper capped by 2 parametrs. thus we allocate the maximum amount of memory needed to store all textures as follows:

```
glTexStorage3D(GL_TEXTURE_2D_ARRAY, 1, GL_RGBA8, max_width, max_height, texture_num);

```

One by one we allocate each texture to each layer as follows:

```
glTexSubImage3D(GL_TEXTURE_2D_ARRAY, 0, 0, 0, file, width, height, 1, color_format,
            GL_UNSIGNED_BYTE, data);

```

Now since for some textures width < max\_width and height < max\_height, when sampling, our sample is off as trying to sample at a value of 1 would result in sampling outside of the bounds of the texture.

One could naively try to solve the issue by multiplying the sampling coordinate by the stretching coefficient.

```
uv*=width/max_width.

```

However this only solves the problem for sampling that happens within the (-1,1) rnage. However, any texture that is meant to be tiled will be wrong. Thus we must do floating mod as well. the final calculation is thus:

```
u = (u*width/max_width)%(width/max_width)
v = (v*height/max_height)%(height/max_height)

```

(Each coordinate is differnece since the vertical stretch could be different from the horizontal stretch)

Thus to do our final rendering we would need to create and store an array of vec2's where the first value is the horizontal stretching coefficient and the second value is the vertical stretching coefficient on teh CPU. Then load that into a uniform buffer or SSBO.

And read these values on the shader side.

This seems a little bit cumbersome. Is there a way to instruct OpenGL to handle these varying sizes or is the only way to solve this issue the one I described?

**Tags:** opengl, texture, c++, uv-mapping, 3dtexture

> **Comments:**
> **username_1**: Yes, this *is* cumbersome. But it has already been explained in the answers to [this question](https://computergraphics.stackexchange.com/q/7773/6) that there is no way for OpenGL to directly handle those varying sizes in a texture array. This of course assumes that you *need* a texture array to begin with and aren't just using it for storage convenience. Otherwise texture views *might* offer some flexibility in reinterpreting an existing array layer. But in that case you of course can't have *array texturing* and would just be stuck with individual textures again.  
> **username_2**: Possible duplicate of [How do you load multiple textures into an array texture with OpenGL?](https://computergraphics.stackexchange.com/questions/7773/how-do-you-load-multiple-textures-into-an-array-texture-with-opengl)  

---

## 0 answers

