Forums > MaxMSP

Drawing animated lines with

April 15, 2012 | 12:58 pm


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:
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. –
April 15, 2012 | 3:46 pm

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

– Pasted Max Patch, click to expand. –
April 15, 2012 | 4:14 pm

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

– Pasted Max Patch, click to expand. –
April 15, 2012 | 4:44 pm

You preempted my observation!
I have been working on a patch which draws paths based on the movements of objects in a 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?

April 15, 2012 | 9:40 pm

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

April 16, 2012 | 12:07 pm

@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 was the key, but apparently not…

February 26, 2013 | 7:32 pm

when using the evalout attribute of 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?

February 26, 2013 | 8:27 pm

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

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

– Pasted Max Patch, click to expand. –
February 27, 2013 | 7:53 am

works great, thanks again!

Viewing 9 posts - 1 through 9 (of 9 total)