5

I've searched the Internet and maybe I'm missing some correct keywords but I managed to find nothing like this. I only found the poly-lines (or just the lines) which are not exactly the graphs. I would like to generate a graph outline (of radius r) as seen in the picture. Is there something already available? I would like to avoid reinventing the wheel so to speak.

enter image description here

If anyone can at hint me at something or at least at some basic principle how to do it it would be great. Otherwise I'll "invent" one on my own of course.

Optimally in C#.

Update: I need to calculate outline polygon, not just visually draw it. The green points represents the resulting polygon. Also the "inner" holes are ignored completely. Only one outline polygon should be enough.

Update 2: Better picture to show some more extreme cases. Also the edges of graph never overlap so no need to accommodate for that.

Update 3: Picture updated yet again to reflect the bevel joins.

payloc91
  • 3,724
  • 1
  • 17
  • 45
SmartK8
  • 2,616
  • 1
  • 29
  • 37
  • 1
    how about drawing every edge with a thickness of 2r? that whould be the graph outline filled! – Hamid Pourjam Feb 01 '15 at 22:36
  • 1
    Oh, I don't need to draw it, but to calculate the resulting polygon. I'll edit the question to reflect that. Good point. – SmartK8 Feb 01 '15 at 22:37
  • What angles will there be? If an angle like the one at the top left gets smaller and smaller, what should happen to the outline? should it move towards infinity?? Also: Can the lines come closer so that the outlines merge? – TaW Feb 01 '15 at 23:51
  • Drawing at a good resolution and then tracing the result for the corners still is an option, imo; at least if the resolution can be good enough.. – TaW Feb 01 '15 at 23:54
  • I will draw a slightly modified version to show some overlap also. I would consider the tracing option a last resort. The problem is that this image is small to fit SO, but otherwise the graph can be really large (pixel wise). So the resulting image would be crazy (10k x 10k pixels or even more). – SmartK8 Feb 01 '15 at 23:58
  • Updated the image and description a bit. My fault for not being clear (but it didn't occurred to me initially). – SmartK8 Feb 02 '15 at 00:06
  • Maybe compute a "concave hull" on the point set. See http://ubicomp.algoritmi.uminho.pt/local/concavehull.html – tmlen Feb 02 '15 at 00:11
  • tmlen: I was really excited this might be it, but then I realized that some green points actually don't exist ahead of time. Like the 3rd green point from left (x coordinate - kinda hard to pinpoint it) or 2nd or 4th or 6th. I take it you meant generating 4 corner points for each edge and then running concave hull on it. But how to solve it for points that actually are created by the process (many of them actually). – SmartK8 Feb 02 '15 at 00:17
  • It won't bring you closer to a solution, but my question about small angles was very real: do you want to cut them off (miter) or shall they create huge spikes or can't they happen anyway? – TaW Feb 02 '15 at 08:50
  • You're right. I guess they should be cut that means "round" or "bevel" join. But obviously "round join" is kinda harder and would result in a more complex resulting polygon. So at this point I guess the "bevel" join is the way to go if above radius is conserved for all the points of the original graph and corresponding outline. – SmartK8 Feb 02 '15 at 09:02
  • I'm starting to understand why I cannot find anything on this. It seems this problem is kinda tough to do. There are plenty of polyline outlines but I have no idea how to scale it to graph a different beast IMO. – SmartK8 Feb 02 '15 at 09:15
  • Thanks, Minkowski sum sounds exactly like what I want. I'm investigating it. So far the only slight possible problem I see that I don't have polygon but graph. But maybe it doesn't matter. I hope it doesn't. – SmartK8 Feb 02 '15 at 10:09
  • Yeah well, that's true but you still need to connect these lines in order to create a closed polygon. But I'm still working on testing it. I found a library called Clipper that does Minkowski sum in C#. – SmartK8 Feb 03 '15 at 08:37

1 Answers1

0

First, for every "line piece" from point A to B, generate the rectangle to it (all 4 points as "path", so to say). Then search two overlapping rectangles and merge them:

Merging is a bit complicated, the idea: Start with calculating the angle of all 8 lines (eg. if the rectangles are traversed clockwise). Then traverse one rectangle until the first line-line-intersection, check with the angles which direction is "outside", and move along the crossing line of the second rectangle ... until you arrive at the start point again => Now you traversed the shape of both together (and hopefully saved it somewhere).

Merge until only one large piece is left (or multiple non-overlapping pieces). In theory, starting from any point, you can traverse the whole shape, but there´s another problem: Holes are possible.
If one shape has two or more disjuct sets of points (where no point from set 2 is reachable from set 1 and vice-versa), all but one disjunct path is of a hole. An easy possibility to get the real outer border is to search for an extremum, ie. the point with the largest or smallest X or Y coordinate (only one of the 4 combinations in enough). This point surely is a part of the outer border.

deviantfan
  • 11,268
  • 3
  • 32
  • 49
  • I know it's just an idea but wouldn't the merging scale badly? I mean. You merge two rectangles, but then you have to traverse that whole merged rectangle again when another one is being merged into it? I'll have thousands of these graph edges. Also the graph never overlaps itself (edge crossing another edge). But also the hole problem you mentioned is kinda profound you would basically need to do CSG on the rectangles. But I'm considering your solution (the implications and feasibility I mean). – SmartK8 Feb 01 '15 at 23:01
  • Sorry it was night here. The first approach looks OK, by "turning" angle until there's an intersection, but I'm afraid that merging of thousands of rectangles would indeed result in crazy amount of merging and line-intersections - unfeasible (as this supposed to be real-time). I don't probably understand the second approach of the extremes. Because in my opinion merging two rectangles can produce 6 point polygon and I don't know how to detect the inner (non "extreme") points. Maybe elaborate a bit if you will. – SmartK8 Feb 02 '15 at 08:42