<p>Your understanding of the behavior of texture units and state is confused. That's to be expected: OpenGL's pre-DSA API is not making it easy to understand this.</p>

<p>As far as core profile OpenGL is concerned, the <em>only</em> texture unit state is what textures are bound to which targets. That's all. Therefore, all <code>glTexParameter</code> calls affect the state of the texture <em>object</em> bound to the currently active texture unit, not of the texture unit itself.</p>

<p>So there is no "precedence". Texture objects have state, which are modified by <code>glTexParameter</code> calls. This is made more clear in direct state access APIs, because <code>glTextureParameter</code> directly takes a texture object, rather than a bound texture target.</p>

<p>If you call <code>glTexParameter</code> when texture object 0 is bound to the given texture target, then you're setting the parameter of the default texture object for that unit/target. And you shouldn't do that.</p>

CC BY-SA 4.0
2018-07-24T16:29:51.230Z
This means that when I set parameters for `GL_TEXTURE_2D` with `glTexParameter` while e.g. `GL_TEXTURE0` unit is active, I'm actually setting the parameter for the texture object currently bound in `GL_TEXTURE0`'s `GL_TEXTURE_2D` ''slot". And these parameters will remain in effect if I bind the same texture object to another texture unit. Correct?
Drinkwater
CC BY-SA 4.0
2018-07-24T16:58:54.067Z
Yes. That's how *all* functions that set state into OpenGL objects work.
Nicol Bolas
CC BY-SA 4.0
2018-07-23T15:38:44.570Z
2018-07-23T15:38:44.570Z
Nicol Bolas
<p>I am writing a procedural terrain renderer for OpenGL. To shade the terrain I use multitexturing, that is 4 material textures and a blend map which distributes them across the terrain (encoded in RGBA).</p>

<p>Should I decide to split my terrain patch into two, blend map, consequently gets split too. Now there is a seam problem. Because of texture filtering, on the edges, the color "bleeds" from the opposite side of the texture. I recognize this can be fixed by setting texture repeat parameter to GL_MIRRORED_REPEAT or GL_CLAMP_TO_EDGE.</p>

<p>I believe that glTexParameteri function sets parameters for currently bound texture unit, still I'm unsure if these parameters get saved in texture unit's state, e.g. each texture unit "remembers" its parameters. Moreover, I know these parameters can be set per texture object. In that case whose parameters should take precedence?</p>

<p>On a more concrete note, I sample blend map from GL_TEXTURE0. So I had an idea to set repeat parameters for GL_TEXTURE0 once before rendering all terrains, but it doesn't work.</p>

<p>However, if I set this for every terrain rendered (absolutely the same code), it works. I'm inclined to believe that texture units don't "remember" their parameters. Is there something else I'm missing here?</p>

<opengl><texture><filtering>
Texture units parameters in OpenGL
Drinkwater
# Texture units parameters in OpenGL

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

I am writing a procedural terrain renderer for OpenGL. To shade the terrain I use multitexturing, that is 4 material textures and a blend map which distributes them across the terrain (encoded in RGBA).

Should I decide to split my terrain patch into two, blend map, consequently gets split too. Now there is a seam problem. Because of texture filtering, on the edges, the color "bleeds" from the opposite side of the texture. I recognize this can be fixed by setting texture repeat parameter to GL\_MIRRORED\_REPEAT or GL\_CLAMP\_TO\_EDGE.

I believe that glTexParameteri function sets parameters for currently bound texture unit, still I'm unsure if these parameters get saved in texture unit's state, e.g. each texture unit "remembers" its parameters. Moreover, I know these parameters can be set per texture object. In that case whose parameters should take precedence?

On a more concrete note, I sample blend map from GL\_TEXTURE0. So I had an idea to set repeat parameters for GL\_TEXTURE0 once before rendering all terrains, but it doesn't work.

However, if I set this for every terrain rendered (absolutely the same code), it works. I'm inclined to believe that texture units don't "remember" their parameters. Is there something else I'm missing here?

**Tags:** opengl, texture, filtering


---

## 1 answers

### Answer by username_1 on 2018-07-23. Score: 4 | Accepted answer

Your understanding of the behavior of texture units and state is confused. That's to be expected: OpenGL's pre-DSA API is not making it easy to understand this.

As far as core profile OpenGL is concerned, the *only* texture unit state is what textures are bound to which targets. That's all. Therefore, all `glTexParameter` calls affect the state of the texture *object* bound to the currently active texture unit, not of the texture unit itself.

So there is no "precedence". Texture objects have state, which are modified by `glTexParameter` calls. This is made more clear in direct state access APIs, because `glTextureParameter` directly takes a texture object, rather than a bound texture target.

If you call `glTexParameter` when texture object 0 is bound to the given texture target, then you're setting the parameter of the default texture object for that unit/target. And you shouldn't do that.

> **Comments:**
> **username_0**: This means that when I set parameters for `GL_TEXTURE_2D` with `glTexParameter` while e.g. `GL_TEXTURE0` unit is active, I'm actually setting the parameter for the texture object currently bound in `GL_TEXTURE0`'s `GL_TEXTURE_2D` ''slot". And these parameters will remain in effect if I bind the same texture object to another texture unit. Correct?  
> **username_1**: Yes. That's how *all* functions that set state into OpenGL objects work.  

---

