Vector image editing by dragging a polygon as a brush

Question

The goal is to do simple vector image editing by dragging the mouse across the screen like a polygon-shaped paintbrush, creating the Minkowski sum of the brush and the path of the mouse. The new polygon would be subtracted from any previously existing polygons of a different color and merged with any existing polygons of the same color.

The plan is to take each mouse movement as a line segment from the mouse's previous position to its current position, calculate the Minkowski sum on that line segment, then do use the Weiler–Atherton clipping algorithm to update the existing polygons to include that Minkowski sum.

Since it seems likely that Weiler–Atherton would cause UI delays if run for every mouse movement, we plan to delay that step by putting it into another thread that can take its time catching up to the latest mouse movements, or alternatively save all Weiler–Atherton calculations until the drawing is finished, then do it as a bulk operation when saving. We worry that this may lead to the accumulation of a very large number of overlapping polygons, to the point that UI would be delayed by the time required to render them all.

The question is: Is the above plan the way that Inkscape and other serious vector graphics editing software would perform this operation? It seems like a mad plan, both in the trickiness of the algorithm and its computational complexity. What would an expert do?

Another option under consideration: Do the painting using simple raster operations and then convert the raster into a vector image as the final step. Conversion from raster to vectors seems no less tricky than Weiler–Atherton, and quality of the final output might suffer, but could it be the better option?

Answer 1

While the user is holding down the mouse button and drawing, you can remember all the mouse movement line segments, and simultaneously render the brush*line Minkowski sums to a screen resolution bitmap.

You can use the bitmap for painting the screen until the user releases the button. At that time you can calculate the union of all the line segment Minkowski sums and add the resulting shape to your drawing.

To calculate the union of so many shapes simultaneously, some kind of sweep-line algorithm would be best. You should be able to do the job in O(N log N) or linear time, which will not cause any noticeable delay.

Answer 2

IMO the bottleneck in Weiler-Atherton is the detection of the intersections, which requires O(N²) operations when applied by brute-force. the rest of the processing is a reorganization of the links between the vertices and intersections, which should be limited to O(N), or even O(NI), where NI denotes the number of intersections.

In this particular case, you can probably speed-up the search for intersections by means of gridding or a hierarchy of bounding boxes. (Note that gridding parallels the idea of Matt to use auxiliary bitmap rendering.)

Unless you really have billion edges, I wouldn't fear the running time.

Answer 3

If you want to do this like professional vector graphics softwares do with arbitrary brush shapes (including features such as the brush shape can react to speed or stylus pressure), it can be quite involved unfortunately.

I was experimenting with the method described in "Ahn, Kim, Lim - Approximate General Sweep Boundary of a 2D Curved Object". It seems to handle a lot of cases that I would expect from a professional drawing application —especially the details where the brush shape can be dynamic while sweeping; adaptively generate the boundary curve for the resolution you want; variable width offsetting of 2d curves; etc..

It seems you can simplify this method if you don't need a generalised method. But I would like to add it here as a reference.

---

PS: I was searching for a non-paywalled link to include here in the answer and then this came up – Looking for an efficient algorithm to find the boundary of a swept 2d shape . Looks very similar to what you're trying to do :).