defetto
December 13, 2008, 7:51pm
1
dont know if it’s actually a bug…
it’s something that i have in mind sice a long time:
clear set to 0, if you want clean the render slowly usually you use a quad with low alpha and same color as the background…
but if the alpha is too low it doesnt clean it properly not even in a long time;
why is this happening? it remains a bit dirty you know what im talkin about…
the only way i found is to increase the alpha, so it works but it’s too fast
or there is a workaround if you enable the quad only for short intervals
anybody?
yep experienced the same problems… and a friend of mine reported similar effects with processing and opengl ? maybe an imperfection in the concept?
sven
December 14, 2008, 6:56pm
3
The problem with that concept is, that the subtraction of the remaining alpha (think of the actual value that is being subtracted frame by frame) does not lead to perfect zero. So you sort of ‘miss’ the target value (the exact background color). So I’d consider this being a floating-point issue, but not a bug.
tonfilm
December 15, 2008, 10:31pm
4
that is because of the 8 bit per color channel… 256 steps isn’t that much. the workaround is quite simple… you have 3 days ;)
defetto
December 16, 2008, 1:44am
5
ok here’s the solution :)
big up to tonfilm…
64bit_colors.v4p (8.5 kB)
so that means 64 bit color resolution is only accessible via render to texture?
