[GEM-dev] gemframebuffer flood

[cyrille henry]

Le 26/10/2011 12:08, Guido Tamino a écrit :
> 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.

with no rectangle mode, things can be a bit weird since the GPu can put a 500x500 image size in a 512x512 memory size.
coordinate are in pixel. so, coordinate 500 + 1 is 501, and it did not loop since memory size is 512.
This is just a supposition. that why i ask you to make test with buffer size 512.



> 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 3d one (on a separate mail), should solve you problem.


> The framebuffer size can't be fixed as it is changing wildly while adjusting the blur amount,
yep, that one must also be solve.
frambuffer size can't be change in realtime.

cyrille

> gl_nearest (quality 0) will bring weird artifacts and the glsl thing is pretty clever but feels like a workaround to me.
>
> Best,
> Guido
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>