Improving shortest route algorithm - path-finding

I have working A* algorithm, but I want to improve it. It finds the shortest path and everything appears as it should. The problem is that I want for route to keep distance (1 empty node or more) from non-walkable grid cells.
Any ideas how to solve this problem?
How it looks now:
What I want to do:

Solution 1:
Make your dot think it is bigger than it actually is (3x3 instead of 1x1) then work out path based on edges of the 3x3 square. (May require collision detection code, also a bypass to allow it through 1 block size gaps.)
Solution 2:
Calculate path as normal with an additional check so move your block 1 space away from the wall if there is space to do so.

Related

Is there a formula to find affected square by sized-brush on a grid?

I am not sure how to put this problem in a single sentence, sorry if the title is misleading.
I am currently developing a simple terrain editor with a circle-shaped brush size. The image below shows a few cases that represent my problem.
additional info: the square size is fixed and uniform and in the current version, my concern is only to find which one is hit and which one is not (the amount of region covered is important for weighting the hit, but probably not right now)
My current solution (which is not even correct for a certain condition) is: given a hit in a position (x, y) with radius r, loop through all square from (x-radius, y-radius) to (x+radius, y+radius) and apply 2-D box to circle collision detection. But I don't think this is optimal (or even correct IMO).
Can anyone help me with this one? Thank you
Since i can't add a simple comment due to bureaucracy on this website i have to type it out here.
Anyway you're in luck since i was trying to do this recently as well! The way i did it is i iterated through the vertex array and check if the current vertex falls inside the radius of the circle. But perhaps what you want is to check it against each quad center and if that center falls inside the radius then add the whole quad as it's being collided.
Of course depending on the size of your grid the performance will vary so it's good to try to iterate through as few quads as needed. Though accessing these quads from the array is something you have to figure out yourself.

How can I make DOT/neato graphs more compact without introducing overlap?

My question is essentially the same as this one but the given answer doesn't work for me.
Here is a sample rendering (source) with
compound=true;
overlap=scalexy;
splines=true;
layout=neato;
There is some unnecessary overlap in the edges but this isn't too bad, the main problem is all the wasted space.
I tried setting sep=-0.7; and here's what happens.
The spacing is much better but now there is some overlap with the nodes. I experimented with different overlap parameters and this is the only one which gives remotely acceptable results.
I tried changing to fdp layout and setting the spring constant attribute K globally but I just got stuff like this:
The source is all straightforward a--b--c sort of stuff, no fancy tricks.
What I want is for all edges to be shortened as much as possible (up to a minimum) provided that this adjustment doesn't introduce any new overlaps, which is where sep fails completely. That doesn't seem like it should be too hard for a layout engine to do. Is it possible with the graphviz suite? I don't mind changing rendering software, but I don't want to annotate the source on a per-node or per-edge basis.
My ideal result would be to minimize the deviation in edge length, considered one node at a time, i.e. each node would have edges of equal length apart from the necessary exceptions, but that's wishful thinking. The priority is to reduce the length of each edge with the constraint that this cannot introduce overlap.
I will accept partial solutions but they must be fully automatic and open source.
How can I do this? Thanks.
I found https://sites.google.com/site/kuabus/programming-by-hu/graphviz-test-tool, an interactive tool for parameterizing the many options and repeatedly rendering them. I went through the full list provided by the Java application, eventually ending up with this set of attributes:
overlap=false
maxiter=99999999
damping=9999999
voro_margin=.001
start=0.1
K=1
nodesep=999999999999
labelloc=c
defaultdist=9999999
size=20,20
sep=+1
normalize=99999999
labeljust=l
outputorder=nodesfirst
concentrate=true
mindist=2
fontsize=99999999
center=true
scale=.01
inputscale=99999999
levelsgap=9999999
epsilon=0.0001
I was not able to find a parameterization of neato that made producing the desired "moderately scaled" graph possible.
You should set
overlap = compress;
this should compress it at much as possible.
Try sep = +1; first, and then play with values between 0 and +1 to find the optimal setting for you.
I have a graph with 50 nodes and 68 edged (sorry cannot publish the whole picture, just a fragment). Found two reasonable presets (1 and 2):
digraph {
graph[
# 1. Less overlaps but less compact.
# This is the choice for now.
layout=neato; overlap=prism; overlap_scaling=-3.5;
# 2. More compact but some overlaps exist (may be adjusted by `sep`).
#layout=neato; overlap=voronoi; sep=-0.15;
# The following is common.
outputorder=nodesfirst, # Will always draw edges over nodes.
splines=curved;
]
node[fontname="Helvetica",];
node[shape=box;style="filled";penwidth="0.5";width=0;height=0;margin="0.05,0.05"];
edge[label=" ";color="#000080";penwidth="0.5";arrowhead="open";arrowsize="0.7";];
. . .
}

Finding shortest paths to all desired points in a graph

I was asked the following question in an interview
You are given a 4 X 4 grid. Some locations on the grid contain
treasure. Your task is the visit all the locations that contain the
treasure and collect it. You are allowed to move on the four adjacent
cells (up, down, left, right). Each movement and the action of
"treasure collection" is of a single unit cost. You need to traverse
the entire grid, and collect all the treasure on the grid, minimizing
the cost taken.
If I can recall properly, here is a sample graph that was given:
U..X
..X.
X..X
..X.
Where, U is my current position and X marks the position of the treasure.
The solution that I presented was to use breadth first search traversing the graph and "collecting the treasure" while doing so. However, the interviewer insisted that there was a better way to minimize the cost. I hope you could help me in figuring it out.
You should have recognized that this is a Traveling Salesman Problem in a small disguise. Using breadth-first, you can determine the shortest way between the different vertices you have to visit which gives you a derived graph containing just those ways as weighted edges between the vertices. From then on, it's a classic TSP.
BFS alone is not going to solve it for you, because you cannot move in all directions at the same time. It is not a single-source shortest path problem, because once you collect the treasure, you start your path to the next one from your current spot, not from the original spot.
The time that it takes to collect all treasure depends on the order in which you visit the boxes with X. Since there are only five of them, you can try all 120 orderings, compute the cost, and pick the best one.
Note that if the order is fixed, the solution is trivial: you add up manhattan distances between the cells in order, and pick the smallest result.

Generate subdivided triangle-strip cube?

I want to generate a cube where each face is divided into bits, like the following image:
http://img59.imageshack.us/img59/2504/gridcube165c3.jpg
Now, I can do this pretty simply if I'm just rendering quads, by just spacing vertices along each face plane at regular intervals, but my problem comes in when I want to turn the whole thing into a triangle strip. I've just got no idea how to unwrap it programmatically- is there some pattern to unwrapping that I'd follow?
I'm thinking of starting with the vertex at the top left corner as Row 0 Column 0 (R0C0), I'd want (first triangle) R0C0, ROC1, R1C1, (second triangle) R0C0, R1C0, R1C1 and so forth, and then when I reach the end of a row I guess I'd use a degenerate triangle to move to the next row, and then when I reach the end of the face I'd do the same to start a new face.
My main problem is that I can't visualize the program loop that would do this. I can reason out which vertex comes next visually, which is how I worked out the order above, but when I try to think programmatically I just stare blankly.
Even worse, with the end product I want the generated cube to be UV-mapped with a simple cube-map unwrap (the kind that looks like a T or t).
I guess, really, the best solution would be to find a library that already does this for me.
You could take a look at Ignacio CastaƱo's 'Optimal Grid Rendering' even though it's not triangle strips, it may inspire you.
Otherwise, you could use NVTriStrip library and be done with it.

Find All Cycle Bases In a Graph, With the Vertex Coordinates Given

A similar question is posted here.
I have an undirected graph with Vertex V and Edge E. I am looking for an algorithm to identify all the cycle bases in that graph. An example of such a graph is shown below:
Now, all the vertex coordinates are known ( unlike previous question, and contrary to the explanation in the above diagram), therefore it is possible to find the smallest cycles that encompass the whole graph.
In this graph, it is possible that there are edges that don't form any cycles.
What is the best algorithm to do this?
Here's another example that you can take a look at:
Assuming that e1 is the edge that gets picked first, and the arrow shows the direction of the edge.
I haven't tried this and it is rather greedy but should work:
Pick one node
Go to one it's neighbors's
Keep on going until you get back to your starting node, but you're not allowed to visit an old node.
If you get a cycle save it if it doesn't already exist or a subset of those node make up a cycle. If the node in the cycle is a subset of the nodes in another cycle remove the larger cycle (or maybe split it in two?)
Start over at 2 with a new neighbor.
Start over at 1 with a new node.
Comments: At 3 you should of course do the same thing as for step 2, so take all possible paths.
Maybe that's a start? As I said, I haven't tried it so it is not optimized.
EDIT: An undocumented and not optimized version of one implementation of the algorithm can be found here: https://gist.github.com/750015. But, it doesn't solve the solution completely since it can only recognize "true" subsets.

Resources