Drawing animated lines with jit.gl.path

Apr 15, 2012 at 12:58pm

Drawing animated lines with jit.gl.path

Hi,

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: http://www.cycling74.com/forums/topic.php?id=35566
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?

– Pasted Max Patch, click to expand. –
#62983
Apr 15, 2012 at 3:46pm

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

– Pasted Max Patch, click to expand. –
#227309
Apr 15, 2012 at 4:14pm

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

– Pasted Max Patch, click to expand. –
#227310
Apr 15, 2012 at 4:44pm

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?

#227311
Apr 15, 2012 at 9:40pm

@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.

#227312
Apr 16, 2012 at 12:07pm

@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…

#227313
Feb 26, 2013 at 7:32pm

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?

#227314
Feb 26, 2013 at 8:27pm

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.

– Pasted Max Patch, click to expand. –
#227315
Feb 27, 2013 at 7:53am

works great, thanks again!

#227316

You must be logged in to reply to this topic.