The quad I'm drawing always has a (0,0) origin and is sized to fit the current reduction (256,256)->(128,128), etc.
I think it may have more to do with how I'm swapping textures? I'm using two ping ponged framebuffers with attached textures. I'm using a grayscale test image which contains a single 255 valued pixel but my reduction filter is only returning 128 (.52 to be exact) as the highest pixel in the texture. I'm trying to use parallel reductions to find the max/min values from a texture using glsl but I'm running into some issues. Removing the half texel shift from my orthographic projection seems to have fixed the issue, I am now getting the correct maximum and minimum of a texture.Īt least that is what I believe was happening, if anyone can correct my understanding I would welcome any corrections. For example: after 8 reductions the first texel would be written to (4,4) rather than (0,0). Curiously desktop OpenGL 4.5 core spec pdf does not mention the string 'anisotropy' at all. These shifts would add up over successive reductions causing pixels to be skipped and the texture to be offset by a non-trivial amount. Neither on native GLES3 or desktop OpenGL side specifications, I was not able to find a spec wording about this, although testing locally on native desktop OpenGL 4.4.0 (Windows+NVidia), this works. However, as I am using texel fetch which uses un-normalized integer pixel coordinates, I had been sampling from an unshifted texture position such as (30, 24) and writing to a shifted position (30.5, 24.5). In order to account for the 0.5 texel shift I had shifted the orthographic projection by 0.5 texels up and to the right. shaders and at least MAXTEXTUREIMAGEUNITS images for fragment shaders. I had been using an orthographic projection matrix to map from screen coordinates to vertex coordinates.
0 kommentar(er)
