[GEM-dev] gemframebuffer flood
Guido Tamino
guido.tamino at gmail.com
Wed Oct 26 12:08:04 CEST 2011
Hi Cyrille,
> imagine a 10 pixels size frambuffer. in rectangle mode, coordinate
> goes from 0 to 1. so 1st pixel coordinate goes from 0 to 0.1, 2nd
> pixel goes from 0.1 to 0.2 etc.
> so 1st pixel center is at 0.05 and 2nd pixel center is at 0.15
> when rendering in gl_linear, you interpolate between pixels. so
> reading texture at position 0.05 gives exactly the color of the 1st
> pixel.
> but reading at 0.1 gives a mix between 1st and 2nd pixel.
> now, if you have to read at position 0.01, then, you also have to
> interpolate. between 1st pixel at position 0.05, and previous pixel.
> this previous pixel can be the same as the 1st one in "repeat 0"
> mode, or the same as the last pixel of the texture (position 0.95)
> in "repeat 1" mode.
this makes perfect sense, wonderful.
I think we are getting close to the osx issue. As you said before, the
0 and -0.5 position in a normalized texture (no rect) with no repeat
should have the same color of the 1 position (the first pixel), but it
doesn't. This is clearly visible if i change the texture coordinate,
see the image. I guess this is causing the problem in the same way the
pixel size not fitting the rendering size was causing the repeat
artifact.
http://img256.imageshack.us/img256/9208/texturei.png
Thanks for your solutions but none of them is completely solving the
problem. The framebuffer size can't be fixed as it is changing wildly
while adjusting the blur amount, gl_nearest (quality 0) will bring
weird artifacts and the glsl thing is pretty clever but feels like a
workaround to me.
Best,
Guido
More information about the GEM-dev
mailing list