<p><code>texelFetch</code> doesn't do any computations. The texture coordinates are in integer texels in texel space. That represents the exact texel you're asking for. The same goes for the <code>lod</code>: it specifies the exact mipmap level to fetch from, with 0 being the base level (largest) for the texture.</p>
<p><code>sampler * P</code> is not valid GLSL. Samplers are <a href="https://www.khronos.org/opengl/wiki/Opaque_Type" rel="nofollow noreferrer">opaque types</a>; the only way to access the resources the sampler represents is to use the standard library functions like <code>texelFetch</code>. You cannot &quot;simulate the behavior of <code>texelFetch</code>&quot; with a sampler.</p>

CC BY-SA 4.0
2022-08-23T15:18:27.797Z
Thanks for this information. I understand that sampler has opaque types and texelFetch isn't something that I can simulate but I am doing the implementation for verification purpose. What I am asking is how the code below the texelFetch may look like.
BusyCoder
CC BY-SA 4.0
2022-08-23T15:29:18.640Z
@BusyCoder: What are you trying to "verify" here? Because you *can't* verify anything. If you have a texture in some memory, you have to use the texture interface to access its data. You can't backdoor them and access the memory directly; the most you could do is allocate some buffer and access that buffer arbitrarily. But you wouldn't be verifying anything because the texture would have separate memory from that buffer. "Verification" is a process for catching mistakes. What mistake do you think your verification is going to catch?
Nicol Bolas
CC BY-SA 4.0
2022-08-23T15:31:11.973Z
@BusyCoder: "*how the code below the texelFetch may look like*" It would look like a series of pointer offsets and array indexes. But that's dependent on the byte layout of the texel data.
Nicol Bolas
CC BY-SA 4.0
2022-08-22T17:44:54.843Z
2022-08-22T17:51:09.177Z
2022-08-22T17:51:09.177Z
Nicol Bolas
<p>I am trying to simulate the behavior of &quot;texelFetch()&quot; and so far I've understood the following:</p>
<p>If &quot;gvec4 texelFetch(gsampler3D sampler, ivec3 P, int lod)&quot; is given then :</p>
<p>result = sampler * P</p>
<p>But what should I do with &quot;lod&quot;? Is it supposed to be used to scale the sampler?</p>
<p>I've read sufficient information about the purpose of <em>lod/level-of-details/mipmapping level</em> theoretically but I would like to understand the computation usage of it in the sampling process.</p>

CC BY-SA 4.0
2022-08-22T16:18:37.783Z
when having a texture with its level of details, you can use the `dFdx()` and `dFdy()` function of the textureCoordinate variable to see, how the textureCoordinate vary in fragment shader stage... The important information in general is: What textureCoordinate has the neighboring pixel, to decide which LOD to use
Thomas
CC BY-SA 4.0
2022-08-22T16:23:31.017Z
please look at http://www.bluevoid.com/opengl/sig00/advanced00/notes/node57.html there you can see a texture and its mipmaps... when using `texelFetch` the `int lod` parameter is the selection of the mipmap, where 0 is the original image, 1 is the next smaller image and so on.
Thomas
CC BY-SA 4.0
2022-08-22T16:38:24.570Z
Mipmaps are normally precomputed and would be presented to the sampler as an array of images, each one half the size of the previous. So as far as `texelFetch` is concerned, the `lod` value is simply an array index, and sampling proceeds as normal within the selected mip level. (BTW, I don't know what you mean by "result = sampler * P". A sampler is a data structure, not a number that you can multiply by...)
Nathan Reed
CC BY-SA 4.0
2022-08-22T16:55:23.313Z
@NathanReed Your information is really helpful.I understood that the lod is an array index so it shows the selection of which level is being used. but I have a follow-up question. I am trying to implement texelFetch function for verification purpose so when I said "result = sampler * P" I meant that :
 result.x = sampler.x * P.x;
 result.y = sampler.y * P.y;
result.z = sampler.z * P.z;
result.w = sampler.w * P.w;
But what I don't understand is that how does `lod` fit into this computation for my implementation? I got the theory part but I'm trying to understand the mathematical aspect now
BusyCoder
CC BY-SA 4.0
2022-08-22T16:56:49.073Z
@NathanReed Considering the example I gave should I first do `Sampler * lod` and then ` result = sampler * P ` ?
BusyCoder
CC BY-SA 4.0
2022-08-22T17:46:00.437Z
@BusyCoder: "*I am trying to implement texelFetch function for verification purpose*" That's not a thing you can do. `texelFetch` represents the lowest level way to access data from a texture. You cannot "implement" it without calling it or a higher-level function like `texture`. `sampler * P` is not valid GLSL, nor is `sampler.x * P.x` or any other variations.
Nicol Bolas
<opengl><glsl><sampling><mipmap>
How is mipmap level used mathemetically in image sampling?
BusyCoder
# How is mipmap level used mathemetically in image sampling?

(Asked by: username_0 on 2022-08-22)

I am trying to simulate the behavior of "texelFetch()" and so far I've understood the following:

If "gvec4 texelFetch(gsampler3D sampler, ivec3 P, int lod)" is given then :

result = sampler \* P

But what should I do with "lod"? Is it supposed to be used to scale the sampler?

I've read sufficient information about the purpose of *lod/level-of-details/mipmapping level* theoretically but I would like to understand the computation usage of it in the sampling process.

**Tags:** opengl, glsl, sampling, mipmap

> **Comments:**
> **username_1**: when having a texture with its level of details, you can use the `dFdx()` and `dFdy()` function of the textureCoordinate variable to see, how the textureCoordinate vary in fragment shader stage... The important information in general is: What textureCoordinate has the neighboring pixel, to decide which LOD to use  
> **username_1**: please look at http://www.bluevoid.com/opengl/sig00/advanced00/notes/node57.html there you can see a texture and its mipmaps... when using `texelFetch` the `int lod` parameter is the selection of the mipmap, where 0 is the original image, 1 is the next smaller image and so on.  
> **username_2**: Mipmaps are normally precomputed and would be presented to the sampler as an array of images, each one half the size of the previous. So as far as `texelFetch` is concerned, the `lod` value is simply an array index, and sampling proceeds as normal within the selected mip level. (BTW, I don't know what you mean by "result = sampler * P". A sampler is a data structure, not a number that you can multiply by...)  
> **username_0**: @username_2 Your information is really helpful.I understood that the lod is an array index so it shows the selection of which level is being used. but I have a follow-up question. I am trying to implement texelFetch function for verification purpose so when I said "result = sampler * P" I meant that :  result.x = sampler.x * P.x;  result.y = sampler.y * P.y; result.z = sampler.z * P.z; result.w = sampler.w * P.w; But what I don't understand is that how does `lod` fit into this computation for my implementation? I got the theory part but I'm trying to understand the mathematical aspect now  
> **username_0**: @username_2 Considering the example I gave should I first do `Sampler * lod` and then ` result = sampler * P ` ?  
> **username_3**: @username_0: "*I am trying to implement texelFetch function for verification purpose*" That's not a thing you can do. `texelFetch` represents the lowest level way to access data from a texture. You cannot "implement" it without calling it or a higher-level function like `texture`. `sampler * P` is not valid GLSL, nor is `sampler.x * P.x` or any other variations.  

---

## 1 answers

### Answer by username_3 on 2022-08-22. Score: 1 | Accepted answer

`texelFetch` doesn't do any computations. The texture coordinates are in integer texels in texel space. That represents the exact texel you're asking for. The same goes for the `lod`: it specifies the exact mipmap level to fetch from, with 0 being the base level (largest) for the texture.

`sampler * P` is not valid GLSL. Samplers are [opaque types](https://www.khronos.org/opengl/wiki/Opaque_Type); the only way to access the resources the sampler represents is to use the standard library functions like `texelFetch`. You cannot "simulate the behavior of `texelFetch`" with a sampler.

> **Comments:**
> **username_0**: Thanks for this information. I understand that sampler has opaque types and texelFetch isn't something that I can simulate but I am doing the implementation for verification purpose. What I am asking is how the code below the texelFetch may look like.  
> **username_3**: @username_0: What are you trying to "verify" here? Because you *can't* verify anything. If you have a texture in some memory, you have to use the texture interface to access its data. You can't backdoor them and access the memory directly; the most you could do is allocate some buffer and access that buffer arbitrarily. But you wouldn't be verifying anything because the texture would have separate memory from that buffer. "Verification" is a process for catching mistakes. What mistake do you think your verification is going to catch?  
> **username_3**: @username_0: "*how the code below the texelFetch may look like*" It would look like a series of pointer offsets and array indexes. But that's dependent on the byte layout of the texel data.  

---

