I have adjacency matrix for graph. I need to vizualize this graph without intersecting edges.
Vertex in the graph can be arranged randomly. I know one solution - enumeration of all edges for intersections. If the edges intersect, then rearrange the vertex, but it's too expensive for a large number of vertexes (more than 20).
Any other ideas how to check for intersecting edges?
It's really easy to visualise any graph in a 3D plane with disjoint edges.
1) Place all the vertices in any point in the 3D plane such that no three vertices are collinear and no four vertices are in same plane.
2) Traverse through the adjacency matrix and draw a line/curve to connect the vertices.
In a 2D plane it's not guaranteed for the existence of a solution. For example take the worst case scenario that there are some 10 vertices and every vertex is connected to each other.
Related
I have a set of polygons described by their vertices. My question is, given a certain vertex, how can I find the vertices of all the polygons to which I can draw a line segment from the given vertex without overlapping the polygons.
Is it possible to do in less than O(n^2)?
I have a connected graph in 2D plane composed of some vertices and some edges defined between them. The overall shape of the graph is not necessarily convex, i.e. the adjacent vertices on the convex hull are not always connected by an edge. Now is there an existing algorithm that finds the 'outline' of this graph? The issue that's troubling me the most is that this outline polygon may contain vertices that are not vertices in the original graph, but rather the intersection of two edges, so I'm not quite sure how to deal with it...
Thanks!
Niko
Graph drawing algorithms, such as those described here, check all the vertices two-by-two and apply additional forces if two vertices are connected by an edge. If we have a very large graph, checking all pairs of vertices would be costly. Is there any graph drawing algorithm that draws a large graph using only existing edges, not by verifying all possible pairs?
EDIT
By drawing algorithm, I meant an algorithm that assigns a 2D or 3D position to each vertex such that rendering spheres or circles (or any other shape) as vertices at their assigned positions lead to a plausible visual representation of the whole graph.
Check this Spring-Electrical Embedding
It is in O(nlog n).
If you have sparse matrix you can consider about creating graph as list of neighbours or simplier like pair of vertices (e.g. (1, 3) and 1 and 3 are the numbers of vertices).
Lets say I have a set of points and I have lines/edges between them. All of these edges create non-overlapping triangles within the convex hull of my points. All points are connected to triangles.
How can I efficiently check which points are part of which triangle? I could check incident points of each edge and gradually construct a triple of points, but that sounds awefully slow (o(n^2)?).
Is there something like linesweep or so to do that?
cheers.
If you have a 2-dimensional set-up like you described, then you have a fully triangulated planar graph (no intersecting edges when you exclude the endpoints) which spans the convex hull of your points. In this case, if you sort the edges around each vertex circularly according to the angle they make with the vertex, then you know for sure that each pair of adjacent edges makes a triangle. Furthermore, every triangle can be found this way if you perform this procedure for each vertex. Each triangle will be found 3 times when you iterate over all vertices. You can either use a hash table to detect duplicates, or sort all your triangles when you are done to identify duplicates. If you use hash table, then the overall complexity if you have V vertices is O(V log d), where d is the maximum degree of a vertex (because the total number of edges is linear in the number of vertices because you have a planar graph). So absolute worst-case is O(V log V), which is the same worst-case if you sort all triangles to find duplicates (because the max number of triangles is also linear in the number of vertices). The only caveat to make this work is that you need to know the neighbor vertices (i.e. the incidental edges) for each vertex.
The edges define an undirected graph G and the triangles are the set of cycles in G with length=3.
Geometric triangulations typically have relatively low nodal degree (degree d is the number of edges adjacent to each node, d<=10 is typical for geometric triangulations) and, as such, here is a reasonably efficient O(n*d^3) algorithm that can be used to construct the set of triangles.
Setup a graph-like data structure, supporting access to the list of edges adjacent to each node.
Iterate over all nodes. Consider all pairs of edges adjacent to a given node i. For a given pair of edges adjacent to i, we have a potential nodal triplet i,j,k. This triplet is a triangle if there is an edge joining nodes j,k, which can be checked by scanning the edge lists of j,k.
Duplicate triangles will be generated by a naive implementation of (2). Maintain a hash table of triangles to reject duplicate triplets as they're considered.
I've assumed that the edges define a valid disjoint triangulation, being non-intersecting, etc.
Hope this helps.
So I have triangular mesh approximating a surface.
It's like a graph with the following properties:
The vertices on the graph border are trivially identifiable. (Number of neighbor vertices > number of containing triangles)
You can trivially calculate the distance between any two vertices. (Euclidean distance)
For any vertex v, any vertex that is not a neighbor of v must have a greater distance to v than at least one of v's neighbors. In other words, no non-neighbor vertices may appear within v's neighborhood ring.
For each vertex v, I want to calculate the smallest distance from v to any border vertex.
I can do this by brute force, build a list of all border vertices, compare v's distance to each, and keep the minimum. But this is inefficient.
I believe the most efficient way for each single vertex v is to do have a priority queue where the top element is the closest to v. The queue is initialized with v's neighbors. While the top of the queue is not a border vertex, pop the top and push all the neighbors of the popped vertex.
Let's say vertex v has 6 neighbors, and I calculate the minimum border distance for each of the 6, and I recorded the exact border vertex that gave the minimum for the 6 neighbors. I know that one of these must also give v's minimum border value. I can't really prove this, but I think it's intuitive. If v's surrounded by it's neighbors, the closest border vertex to v must also be the closest border vertex to one of its neighbors.
I want to know if there is a way to use this knowledge to efficiently computing the minimum for each point in the graph. More efficient than a breadth first search from each vertex.
If you do breadth-first search until you find a border vertex, this does not guarantee that this is the closest border vertex. To see this, note that for any triangulated planar graph in 2-d, you could add a very small distinct z-coordinate to each vertex, and define a 3-d surface whose natural simplest good approximating triangular mesh (giving a perfect approximation) is simply the mesh corresponding to the original planar graph. So it suffices to give an example of a triangulated planar graph where there are vertices v whose closest border vertex in terms of minimum #edges on a path connecting v to the border vertex is not the closest border vertex in terms of euclidean distance. Here's an example of such a planar graph.
First draw a right triangle with vertices (0,0), (1,0), (0,1). Then choose a large number of vertices along the edge from (1,0) to (0,1), such that the vertices break up the edge into equal sized segments. Connect all these vertices to (0,0). Then, for all the vertices you added, for each pair of neighboring vertices draw an equilateral triangle that uses the two vertices as two of the equilateral triangle vertices. Connect all the "tops" of the equilateral triangles with a straight line. Now you should have a region that looks like the first level of a house of cards. Similarly add the second level of the house of cards on top of the first. This is the graph, and it satisfies your properties. Now note, for all of the vertices you added along the edge from (1,0) to (0,1), they have (0,0) as a neighbor and this is a border vertex. However, the closest border vertex in terms of euclidean distance will be one of the border vertices along the perimeter of your 2-level house of cards, which will be almost always be 2 edges away. A breadth first search from one of these interior vertices would return (0,0) as the closest border vertex, which is incorrect. I think this example is just a glimpse of how complicated things can get, such that your assumptions are still satisfied. The fastest algorithm may indeed be to just enumerate all border vertices, and then for each vertex test all border vertices to find the closest. If you have a nice "fat" mesh with most of the vertices not being border vertices, at least the number of border vertices will be much smaller than the total number of vertices, so the complexity is at least reduced some from the worst-case O(N^2) if you have N vertices.