James Dunn wrote:
Thanks - it's interesting but doesn't seem to do quite what I need. Even with a maximum alpha value, I still want the lines to stay on full brightness for longer. Also, I'm drawing some fine lines and there are some weird artefacts like blocks appearing in the trail. Is there something else I could try?
This is probably caused by the texture being 8-bit per channel, so decay coefficients are quantized in 1/256 increments, which makes long decay times hard to achieve (the slowest decay's coefficient is 255/256, which isn't as close to 1.0 as you want, I guess).
You could keep some data about the history of each line segment (position, time created, colour, etc), and draw them all fresh each frame - this will be much less efficient than texture feedback but you would have more control over the fade, with the possibility to do things like change colour (not just alpha) over time with other-than-exponential decay curves, etc.
Probably pd/doc/Gem/02.advanced/20.double-gemhead_vs_repeat.pd helps.
If that gets too slow you could combine the drawing of the line segments into one glBegin/End block at the price of some flexibility. And if that gets too slow, there's probably something that can be done with vertex arrays/buffers or whatever they're called (if it's even possible in Gem - I'm not sure, but I'd like to find out!).
Claude
Quoth cyrille henry, on 22/01/10 21:45:
have a look at example 07.texture/08.MotionBlur.pd all you have to do is remplace the teapot with a line that you can draw or not (to make it fade out)
Cyrille
James Dunn a écrit :
I've been sending x/y values to [curve] to draw some lines in gem and the only way I've been able to get them to stay rendered is to use single buffer mode using [buffer 1( messaged to [gemwin].
Can someone suggest a better method using double buffer perhaps? I would like the lines to fade out after some seconds. I looked at pix_snap2tex and gemframebuffer but could only get one line rendered. Is this possible with the particle objects?
thanks
James