The Math Behind Circular Patterns in Vector Design
Polar coordinates are just another way to say "where things are relative to a center point at a certain angle and distance." You probably already use them without thinking about it. When you rotate something around a pivot, or distribute buttons evenly along a circular menu, or make a donut chart where each segment has the same arc length, that is polar math happening under the hood. The conversion is straightforward if you keep it simple. Take a point described as radius r and angle theta. Multiply r by the cosine of theta to get the x offset from center. Multiply r by the sine of theta to get the y offset. That gives you Cartesian coordinates, which is what pretty much every design tool actually renders on screen.
How Sketch Polar Coordinates Actually Work in Practice
I spent about three weeks dealing with a plugin that was supposed to distribute UI elements along a circular path. The documentation claimed it used polar coordinates, but the output was garbage. Turns out the angle was being passed in degrees while the sine and cosine functions expected radians, and nobody caught it because the error only showed up at larger radii. The fix was multiplying the angle by pi over 180 before any trig calls. That kind of thing eats hours you will never get back. The practical workflow usually goes like this. You define a center point on your canvas. You set a radius value. Then you decide how many items need to go around the circle. Divide 360 degrees by that count to get your angular step. Convert each step to radians. Calculate the x and y for each position using those trig functions. Place your objects at the resulting coordinates. It takes about two minutes per ring if you have a spreadsheet open. Sketch itself does not have a native polar coordinate input field. You have to use plugins or manually calculate positions. The plugin I ended up using after the failed experiment was called Polar Grid, but even that had quirks. It would lose precision when your radius went above 500 points, probably because of floating point rounding in the internal layout engine. I just switched to calculating positions in a local script and pasting the values in manually. Much faster than debugging someone else code once you know what to look for.
When This Approach Breaks Down
There are real limitations here. Precision drops off at large radii because of how computers store decimal numbers. If you are working with a 2000 point radius and trying to place 100 items evenly, you might see gaps that are visibly uneven even though your math is technically correct. The human eye can detect spacing errors as small as one or two pixels at that scale. Angle accumulation is another issue. If you generate positions iteratively by adding a fixed step to the previous angle, rounding errors compound with each iteration. By the time you reach the 50th item, your actual angle might be off by a fraction of a degree. That fractional error compounds into a visible gap when you convert back to screen coordinates. The workaround is calculating each angle independently from zero rather than building on the previous value. Not every circular layout should use polar coordinates. If you are making a pie chart where the visual weight matters more than the geometric precision, Cartesian approximation with arc paths might give you better results. The rendering pipeline in most design tools handles filled shapes more accurately than it handles individually positioned objects along a curve. I learned that the hard way when a client complained that their circular infographic looked slightly off even though every calculation checked out.
Get the Full Details
A Working Example You Can Replicate
Let us say you need six icons evenly spaced around a center point at 150 points radius. The angles in degrees are 0, 60, 120, 180, 240, 300. Convert each to radians by multiplying by pi over 180. The radian values are roughly 0, 1.047, 2.094, 3.142, 4.189, 5.236. Now calculate the offsets. At zero radians, cosine is 1 and sine is 0. That gives you an x offset of 150 and y offset of 0. At 60 degrees, cosine is 0.5 and sine is about 0.866. The offsets are 75 and 129.9. Do this for each angle and you have your six positions relative to center. Add your center point coordinates to each offset to get absolute canvas positions. If you are doing this repeatedly, a small Python script with the math module saves you from manual calculation. The script I use runs in about 200 milliseconds for 20 items and outputs a CSV I can paste directly into Sketch. Even accounting for plugin overhead, this cuts a process that used to take 15 minutes down to under a minute once the script is set up.
What Nobody Tells You About Scaling
When you increase the radius, the angular error from floating point becomes more visible. A one tenth degree error at 100 point radius moves your object about 0.17 pixels. At 500 points radius, that same angular error shifts your object nearly 1 pixel. At 1000 points, you are looking at potentially 2 pixels of drift. That matters when you are aligning things visually. The workaround is to keep your working radius reasonable and use a symbol or group if you need to scale later. Changes to the master do not recalculate polar positions, but at least you avoid compounding errors from multiple resizes. I also found that locking the center point separately from the orbiting objects prevents accidental offset during editing. Another detail that catches people is the difference between clockwise and counterclockwise angle conventions. Most math libraries treat positive angles as counterclockwise from the positive x axis. Most design tools treat the y axis as pointing down, which flips the apparent rotation direction on screen. If your objects are spiraling the wrong way, check whether you need to negate the y offset rather than changing the angle convention.
