I want to conduct an experiment about graph drawing algorithms and for this purpose I have to generate graphs, but I don't know what is the optimal number of graph vertices that should be generated, is it 100 or 200 vertices ? What is the best number of vertices that humans can understand and comprehend ? How can I decide that, do you have any ideas or some papers that are useful for me, I searched online about this topic in Google scholar and many other papers search engine, but I did not find anything.
Thanks in advance
This is a very broad question. Size and type of graphs may depend on the research focus.
The GDToolkit (which i am not affiliated with) publishes several graph drawing test case collections from academic literature which might be a starting point.
In general graph drawing gets more interesting the higher the number of vertices is, especially if labelling comes into play.
A number of vertices up to 100 (maybe more in graphs with a structure to exploit geometrically) has the benefit that you can ask humans to layout the graph and compare their results with what the tested algos produce.
As for the maximum number of vertices that people can 'understand', there is no fixed limit - think of a 2D or 3D lattice, the number of vertices up to which humans can grasp the essence of the graph is virtually unlimited.
There is of course a lot of leeway in what you mean exactly by 'understand'. In general human respondents will be able to tell about non-trivial properties of the graph or create hypotheses on such properties if some visual pattern shows up (this might be an interesting research topic in itself [I have not checked for existing work in this domain], think of 'distorted' drawings of lattices or drawings projections of lattices in higher dimensions).
Related
I need to visualize a very large number (10k) of distinct networks, all on the same page, and label each node a type (binary). Each network aside from a few are relatively small. Link lengths/weighting is not important for this dataset, and a high degree of overlap on the bigger networks is fine as long as density is evident.
I have gone over some of the Igraph documentation and have been able to create individual graphs using a node/link list. However, I would like some insight if possible on how to translate this large number of networks (currently just 10k arrays with node identity and type inside) into 10k plots, and whether this is a feasible task with Igraph.
Any insight is greatly appreciated.
The detection of edges in 3d objects may be the first step for the automatic processing of particular characteristics and landmarks.
Thus, I'm looking for a method to identify such edges for some of my 3d-scanned objects.
However, with all my ideas (Hough transformation, angles threshold for neighboring vertices) I didn't succeed.
Thus, I'd be quite happy if someone could point me to a solution to the edge-finding-problem for 3d point clouds which can be applied using R.
There is a nice paper from last year about this topic.
Basically, you need to compute several features, for each point, based on it's neighbors.
I usually prefer Python over R so I'm not aware of any point-cloud processing package un R. But the implementation of that paper in R should be easy.
If you can translate Python-R, you can take a look at this library that I wrote as it has already implemented the computation of all the features mentioned on that paper.
If that helps you, in this answer you can find example code on how to add the curvature for each point. You just have to replace the word curvature with the other names of features.
What I'm trying to achieve:
Have a look at the following image from this paper
It's taking a road graph that is likely represented as segments/junctions, giving the lines width (call it what you like, sweeping, thickening) and then generating triangulated geometry for the roads.
Why I am asking this question:
This operation seems to be a fairly standard thing to do, but I can't any papers that directly deal with how to do it. Most GIS / procedural city generation papers focus on the generation of the road graph itself (e.g. creating interesting topologies), but the step involving taking the graph data and generating triangle meshes / UVs is always glossed over.
Here's a really nice video of complex road intersections with nice texturing and good-looking junctions. This is the level of quality I'd eventually like to achieve, but an incremental step towards this would be more than acceptable to me. Here's another video showing interactive road graph creation with a 3d visualisation.
There is a paper to go with that video but nothing is said about the triangulation strategy :(
I have my own approach to try that's too long-winded to detail here, but I'd much rather implement an existing solution / algorithm if one exists, as it'll be better than anything I cook up in the next few weeks.
Can anyone point me in the right direction?
Thanks.
What you are seeking is the offset polygon for each of the regions bounded by roads. If all those regions are convex, this is an easy computation. If some are nonconvex, then it is more difficult, but still well-studied. You can find links at Wikipedia under straight skeleton, or here on StackOverflow under "An algorithm for inflating/deflating (offsetting, buffering) polygons."
What are some path finding algorithms used in games of all types? (Of all types where characters move, anyway) Is Dijkstra's ever used? I'm not really looking to code anything; just doing some research, though if you paste pseudocode or something, that would be fine (I can understand Java and C++).
I know A* is like THE algorithm to use in 2D games. That's great and all, but what about 2D games that are not grid-based? Things like Age of Empires, or Link's Awakening. There aren't distinct square spaces to navigate to, so what do they do?
What do 3D games do? I've read this thingy http://www.ai-blog.net/archives/000152.html, which I hear is a great authority on the subject, but it doesn't really explain HOW, once the meshes are set, the path finding is done. IF A* is what they use, then how is something like that done in a 3D environment? And how exactly do the splines work for rounding corners?
Dijkstra's algorithm calculates the shortest path to all nodes in a graph that are reachable from the starting position. For your average modern game, that would be both unnecessary and incredibly expensive.
You make a distinction between 2D and 3D, but it's worth noting that for any graph-based algorithm, the number of dimensions of your search space doesn't make a difference. The web page you linked to discusses waypoint graphs and navigation meshes; both are graph-based and could in principle work in any number of dimensions. Although there are no "distinct square spaces to move to", there are discrete "slots" in the space that the AI can move to and which have been carefully layed out by the game designers.
Concluding, A* is actually THE algorithm to use in 3D games just as much as in 2D games. Let's see how A* works:
At the start, you know the coordinates of your current position and
your target position. You make an optimistic estimate of the
distance to your destination, for example the length of the straight
line between the start position and the target.
Consider the adjacent nodes in the graph. If one of them is your
target (or contains it, in case of a navigation mesh), you're done.
For each adjacent node (in the case of a navigation mesh, this could
be the geometric center of the polygon or some other kind of
midpoint), estimate the associated cost of traveling along there as the
sum of two measures: the length of the path you'd have traveled so
far, and another optimistic estimate of the distance that would still
have to be covered.
Sort your options from the previous step by their estimated cost
together with all options that you've considered before, and pick
the option with the lowest estimated cost. Repeat from step 2.
There are some details I haven't discussed here, but this should be enough to see how A* is basically independent of the number of dimensions of your space. You should also be able to see why this works for continous spaces.
There are some closely related algorithms that deal with certain problems in the standard A* search. For example recursive best-first search (RBFS) and simplified memory-bounded A* (SMA*) require less memory, while learning real-time A* (LRTA*) allows the agent to move before a full path has been computed. I don't know whether these algorithms are actually used in current games.
As for the rounding of corners, this can be done either with distance lines (where corners are replaced by circular arcs), or with any kind of spline function for full-path smoothing.
In addition, algorithms are possible that rely on a gradient over the search space (where each point in space is associated with a value), rather than a graph. These are probably not applied in most games because they take more time and memory, but might be interesting to know about anyway. Examples include various hill-climbing algorithms (which are real-time by default) and potential field methods.
Methods to procedurally obtain a graph from a continuous space exist as well, for example cell decomposition, Voronoi skeletonization and probabilistic roadmap skeletonization. The former would produce something compatible with a navigation mesh (though it might be hard to make it equally efficient as a hand-crafted navigation mesh) while the latter two produce results that will be more like waypoint graphs. All of these, as well as potential field methods and A* search, are relevant to robotics.
Sources:
Artificial Intelligence: A Modern Approach, 2nd edition
Introduction to The Design and Analysis of Algorithms, 2nd edition
I am doing an EDA-analysis program. Reading some articles I have found that my problem has a name (Vertex-Disjoint Menger Problem). But all the articles describes algorithms for planar graphs - needless to say that I have non-planar undirected graphs.
This problem is equivalent to finding the minimum s-t vertex cut in a undirected graph.
Also, instead of high-level algorithmic descriptions, I would like functional C/C++ code. As far as I can tell, BOOST has no such functionality.
As mentioned in another question, finding the minimum s–t vertex cut in a undirected graph can be reduced to finding the minimum s–t edge cut in a directed graph, for which many algorithms and implementations exist.