I seem to be getting unexpected behavior (which means I’m making an incorrect assumption I’m sure). I’m rendering a single test point sprite with a width and height of 5 pixels using an orthographic projection. I try to calculate an index based on the uv value in a fragment shader, so if the GPU is rendering the pixel with center x of 2 and y of 2, that should be the center pixel of the 5x5 sprite. I would assume the uv value would be (.4, .4). Sometimes this seems to be the case, but if for example I draw a vertex value of (8.23, 5, 5) (with a fractional x value) the uv values seem to shift such that it’s not .4 anymore for the center pixel.
My final goal is to compute an index such that the middle pixel would have an index of 0, the right most of 2, and the leftmost pixel of the sprite -2, but I can’t reliably do this if the uv value is shifting slightly. Thanks for any help!
That’s intentional. Varyings (texcoords) are evaluated at pixel centers during rasterization, and the rasterizer uses sub-pixel precision. So the you’re seeing the difference between [value at center of pixel at edge of polygon] and [value at edge of polygon].
This is what you want for high-quality texture filtering when moving an object across the screen very slowly.
Ah that makes sense, thank you! This has been driving me nuts trying to figure it out.
I can see why that is intentional behavior in the sense of high quality filtered 3D objects, but in my case for GPGPU work, is there any way to counteract that somehow? Maybe I need to rethink my approach.
I somehow need to reliably transform the uv position into a index so I can use the index to compute a Gaussian function, i.e. -2,-1,0,1,2 in x and y as multipliers against a Gaussian smoothing kernel across the 5x5 sprite. Thanks for the help
For GPGPU using GLSL, probably the simplest thing to do is to use gl_FragCoord.
Draw a quad (not a point sprite, as you can’t control the size clamping) and gl_FragCoord will be evaluated at pixel centers. Floor it to get ints (or use pixel_center_integer layout in newer GLSL versions.)
But if you’re really after GPGPU, other options are CUDA or OpenCL.
Thanks for the help. In the end I’ll have a lot of sprites/quads moving around on the screen, so I’m not sure how to isolate each one with gl_FragCoord since it returns window coordinates? Sorry I should have mentioned that earlier on.
CUDA or OpenCL would be great but unfortunately my target market will be mostly low-end laptops with Intel HD Graphics which don’t yet support OpenCL as far as I know (although they are supposed to next year?)