<p>I've a texture (2048 x 2048) Pixels.
I am looking for an algorithm to transform the normalized texture coordinate [0 1] to pixel coordinate [0 2047]. This should be a perfect fit...</p>
<p>So when the texture sampler has a GL_NEAREST interpolation the following code should output the same:</p>
<pre><code>ivec2 texSize = textureSize(tex);
vec2 normalizedCoordinate = someValue;
ivec2 pixelCoordinate = AlgorithmIamLookingFor;
vec4 color = texture(tex, normalizedCoordinate);
vec4 color2 = texelFetch(tex, pixelCoordinate, 0);
</code></pre>
<p>So <code>color</code> and <code>color2</code> should have the same value.</p>
<p>I've tried the following:</p>
<pre><code>pixelCoordinate.x = int(normalizedCoordinate * 2047)
</code></pre>
<p>But the last pixel (2047) will not show up or be extremely small.</p>

CC BY-SA 4.0
2022-10-13T12:00:15.857Z
What is the sampler that is being used with the texture function? Anything but nearest will give an averaged result using a filter.
pmw1234
CC BY-SA 4.0
2022-10-13T18:17:15.913Z
Assuming that glsl `int (myFloat)` rounds to zero, why not `pixelCoordinate = int(normalizedCoordinate * 2048)` ?
leone ruggiero
CC BY-SA 4.0
2022-10-14T06:24:29.177Z
@pmw1234 like I wrote in my question: the sampler is "GL_NEAREST" so `color` will output the color of the pixel without any interpolation...
Thomas
CC BY-SA 4.0
2022-10-14T06:26:19.977Z
@leoneruggiero when `normalizedCoordinate.x` is 1, the output would be 2048, which is outside [0 2047]
Thomas
CC BY-SA 4.0
2022-10-14T06:38:36.627Z
@Thomas Have you tried? As far as I know if a primitive ends up in a pixel it means it crosses the pixel center and texture coordinates are evaluated at the pixel center for that primitive, so the only way for them to be exactly 1 is that the vertex with texCoords=1 is exactly at the center of a pixel...in that case `clamp` should solve the issue.
leone ruggiero
CC BY-SA 4.0
2022-10-14T10:57:28.857Z
@Thomas Oops, that is such a common mistake I guess I typed before reading. A handy way to check texture coordinate math is compare it against gl_fragCoord in the fragment shader. (not necessarily looking for an exact match, but there should be a consistent difference, then output a strange color where they don't line up...like bright pink) This can help pinpoint casting and rounding differences as well as other trivial errors that are easy to overlook.
pmw1234
<glsl>
GLSL normalized texture coordinate to pixel coordinate
Thomas
# GLSL normalized texture coordinate to pixel coordinate

(Asked by: username_0 on 2022-10-13)

I've a texture (2048 x 2048) Pixels.
I am looking for an algorithm to transform the normalized texture coordinate [0 1] to pixel coordinate [0 2047]. This should be a perfect fit...

So when the texture sampler has a GL\_NEAREST interpolation the following code should output the same:

```
ivec2 texSize = textureSize(tex);
vec2 normalizedCoordinate = someValue;
ivec2 pixelCoordinate = AlgorithmIamLookingFor;
vec4 color = texture(tex, normalizedCoordinate);
vec4 color2 = texelFetch(tex, pixelCoordinate, 0);

```

So `color` and `color2` should have the same value.

I've tried the following:

```
pixelCoordinate.x = int(normalizedCoordinate * 2047)

```

But the last pixel (2047) will not show up or be extremely small.

**Tags:** glsl

> **Comments:**
> **username_1**: What is the sampler that is being used with the texture function? Anything but nearest will give an averaged result using a filter.  
> **username_2**: Assuming that glsl `int (myFloat)` rounds to zero, why not `pixelCoordinate = int(normalizedCoordinate * 2048)` ?  
> **username_0**: @username_1 like I wrote in my question: the sampler is "GL_NEAREST" so `color` will output the color of the pixel without any interpolation...  
> **username_0**: @username_2 when `normalizedCoordinate.x` is 1, the output would be 2048, which is outside [0 2047]  
> **username_2**: @username_0 Have you tried? As far as I know if a primitive ends up in a pixel it means it crosses the pixel center and texture coordinates are evaluated at the pixel center for that primitive, so the only way for them to be exactly 1 is that the vertex with texCoords=1 is exactly at the center of a pixel...in that case `clamp` should solve the issue.  
> **username_1**: @username_0 Oops, that is such a common mistake I guess I typed before reading. A handy way to check texture coordinate math is compare it against gl_fragCoord in the fragment shader. (not necessarily looking for an exact match, but there should be a consistent difference, then output a strange color where they don't line up...like bright pink) This can help pinpoint casting and rounding differences as well as other trivial errors that are easy to overlook.  

---

## 0 answers

