Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><Pre> 1) Calculate the polygon's perimeter (or estimate it if exact time of circling is not critical) 2) divide the perimieter by the time desired for circling 3) move point around polygon at this speed. </pre></p> <p><strong>Edit</strong> following ire and curses' comment.</p> <p>Maybe I read the question too literally, I fail to see the difficulty or the points raised by ire_and_curses.</p> <p>The following describes more specifically the logic I imagine for step #3. A more exact description would require knowing details about the coordinate system, the structure used to describe the polygon, and indication abou the desired/allowed animation refreshing frequency.</p> <p>The "travellng point" which goes around the polygon would start <em>on</em> any edge of the polygop (maybe on a vertex, as so to make the start and end point more obvious) and would stay on an edge <em>at all time</em>.</p> <p>From this starting point, be it predetermined or randomly selected), the traveling point would move towards towards a vertex, at the calculated speed. Once there it would go towards the other vertex of the edge it just arrived to, and proceed till it returns to the starting point. </p> <p>The equations for calculating the points on a given edge are the same that for tracing a polygon: simple trig or even pythagoras <strong>(*)</strong>. The visual effect is based on refreshing the position of the traveling point at least 15 times or so per second. The refresh frequency (or rather its period) can be used to determine the distance of two consecutive points of the animation.</p> <p>The only less trivial task is to detect the end of a given edge, i.e. when the traveling point needs to "turn" to follow the next edge. On these occasions, a fractional travel distance needs to be computed so that the next point in the animation is on the next edge. Special mention also for extremely short edges, as these may require the fractional distance logic to be repeated (or done differently). </p> <p>Sorry for such a verbose explanation for a rather straight forward literally ;-) algorithm... </p> <p><strong>Correction</strong>: as pointed out by Jefromi in comment for other response, all that is needed with regard to the tracing is merely to decompose the x and y components of the motion. Although we do need Pythagoras for calculating the distance between each vertex for the perimeter calculation, and we do need to extrapolate because the number of animation steps on an edge is not [necessarily] a integer.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload