maaark

I'm trying to make a drawing app in which the drawn forms kind of "come to life" and will keep moving a bit so that the drawing looks like it's animated.

I started with this sketch by R. Ramirez found here: 

https://cycling74.com/forums/periodically-capture-jit-gl-sketch-to-texture-to-cope-with-strokelimit

and added a bit which gets a random point and adds a deviation to it. I could easily do a drawing app by making a poly for each new form.

The only problem is, sometimes it seems to suddenly get/set weird values, creating these spikes in the line.

I'm trying to make a drawing app in which the drawn forms kind of "come to life" and will keep moving a bit so that the drawing looks like it's animated.
I started with this sketch by R. Ramirez found here: https://cycling74.com/forums/periodically-capture-jit-gl-sketch-to-texture-to-cope-with-strokelimit
and added a bit which gets a random point and adds a deviation to it. I could easily do a drawing app by making a poly for each new form.
The only problem is, sometimes it seems to suddenly get/set weird values, creating these spikes in the line.
Any ideas/suggestions?


drawing-animated-lines-with-jit-gl-path

Still haven't fixed the spikey points...!

With uzi it looks better BTW.
Still haven't fixed the spikey points...!


When the pathstyle is tube and the joinstyle round, it doesn't occur.

I have been working on a patch which draws paths based on the movements of objects in a jit.phys.world where the gravity keeps shifting. I had the same problems of spikes (which don't occur if one only draws lines, by the way.)

One thing that I have noticed is that as the pointcount climbs (I have mine limited to 500) my CPU-use climbs as well. I guess that the gl.path object is continually calculating the messages to be sent to the GPU. The CPU-use is in direct proportion to both the number of points and the segments between points, and is noticible primarily when the path is not drawn as a line. I had originally assumed that once a path had been drawn, it would be in the domain of the GPU. Could this be a bug?

You preempted my observation!
I have been working on a patch which draws paths based on the movements of objects in a jit.phys.world where the gravity keeps shifting. I had the same problems of spikes (which don't occur if one only draws lines, by the way.)

One thing that I have noticed is that as the pointcount climbs (I have mine limited to 500) my CPU-use climbs as well. I guess that the gl.path object is continually calculating the messages to be sent to the GPU. The CPU-use is in direct proportion to both the number of points and the segments between points, and is noticible primarily when the path is not drawn as a line. I had originally assumed that once a path had been drawn, it would be in the domain of the GPU. Could this be a bug?


@maaark: from what i can tell, the problem only occurs with @joinstyle angle.

@lembert.dome: gl.path uses both CPU and GPU to render.

if you make any changes to the path data (add, edit, change segments or interpmode, etc) the path must be recalculated.

one possible thing to try, is precompute your path, and use the @evalout attribute to make it "grow".

i'm not sure if that will help cpu use or not in your particular case, but it's worth trying.

 @lembert.dome: gl.path uses both CPU and GPU to render.
if you make any changes to the path data (add, edit, change segments or interpmode, etc) the path must be recalculated.

one possible thing to try, is precompute your path, and use the @evalout attribute to make it "grow".
i'm not sure if that will help cpu use or not in your particular case, but it's worth trying.


@Robert, You're right. OK so I tried to do this with a poly~ so I could make a drawing with various paths... doesn't work, it's too CPU heavy. Is there another way so I could draw (various forms, maybe bezier curves?), have them in an array and slowly adjust the points so it seems like a "living drawing"?

Seems quite hard to do it CPU-friendly, thought jit.gl.path was the key, but apparently not...

@Robert, You're right. OK so I tried to do this with a poly~ so I could make a drawing with various paths... doesn't work, it's too CPU heavy. Is there another way so I could draw (various forms, maybe bezier curves?), have them in an array and slowly adjust the points so it seems like a "living drawing"?
Seems quite hard to do it CPU-friendly, thought jit.gl.path was the key, but apparently not...


when using the evalout attribute of jit.gl.path to make it grow, the path rendering steps seem to refer to the number of segments between points. so if two points are very distant from each other (but have been created with 20 segments) it takes the same amount of steps to draw the (longer) line between them as to draw a much (shorter) line between two points that are very close to each other and have also been created with 20 segments between each other... is there the possibility to use evalout not based on segments or to somehow "desegmentarize" the gl.path after its creation and overwrite the previous segments with new ones along the path structure that all have the same length?

what you are seeing is the difference between evaluating based on distance between points (the normal evaluation mode) and evaluating evenly based on total length of the path. the @evalin and @evalout parameters only evaluate using normal evaluation.

fortunately, there is a way to do what you want using the jit.path @evalmatrixmode evallength

you can send in your path points to jit.path, and output a new path that is evenly spaced by distance between path points, using the "outputeval" message, and send this new matrix to jit.gl.path.

the following patch should explain this technique.

hi tobiasros.
what you are seeing is the difference between evaluating based on distance between points (the normal evaluation mode) and evaluating evenly based on total length of the path. the @evalin and @evalout parameters only evaluate using normal evaluation.

fortunately, there is a way to do what you want using the jit.path @evalmatrixmode evallength
you can send in your path points to jit.path, and output a new path that is evenly spaced by distance between path points, using the "outputeval" message, and send this new matrix to jit.gl.path.

the following patch should explain this technique.
hope this helps.


I was wondering if you could explain how you got the previous line to disappear when you start drawing a new one? I've been trying to get jit.gl.line to do that for me and I can't figure it out. Thanks

Hi Mark
I was wondering if you could explain how you got the previous line to disappear when you start drawing a new one? I've been trying to get jit.gl.line to do that for me and I can't figure it out. Thanks


You mean when the "maximum" number of points is reached? So that the tail keeps the same way? have a loop at the [route pointcount] in the patch, with the [< 100] below it. If the amt of points is greater than 100, it deletes the first one, causing the tail to "forget" that point.

If you're wanting to start a new line on clicking the mouse, you could just bang clear to jit.gl.path on mousedown, before drawing any line. But that is something which the patch above doesn't do.

Very curious as to what you're doing. jit.gl.path is not very suitable for large amounts of points, I've noticed I can only go up to about 700 before it starts really lagging. But that might have to do with the update and random routine

I'm working on my final year college project and I'm using sensor data from an irish dancer to create visuals and line is one of the objects i'm using.

Thanks for the reply on this. essentially what i'm trying to do is make the tails "fade away" during the routine. At the moment its a lot of lines on screen but I want to avoid my on screen visuals looking overcrowded.

I'm working on my final year college project and I'm using sensor data from an irish dancer to create visuals and line is one of the objects i'm using.
Thanks for the reply on this. essentially what i'm trying to do is make the tails "fade away" during the routine. At the moment its a lot of lines on screen but I want to avoid my on screen visuals looking overcrowded.


OK. What you could do is limit the amount of lines in the [>] object (put it from 300 down to 20 for example), and give the argument 0. 0. 0. 0.1 to jit.gl.render, instead of 0. 0. 0. 1.

OK. What you could do is limit the amount of lines in the [>] object (put it from 300 down to 20 for example), and give the argument 0. 0. 0. 0.1 to jit.gl.render, instead of 0. 0. 0. 1.
This will make it fade slowly.

Drawing animated lines with jit.gl.path