I have Square and Round Icons on the Branch Lines in the TortoiseGit Log Graph. What is the meaning of Square Icons?
Square = Merge Commit
Round = Commit
In the graph line there are two types of shapes:
The circles indicate normal commits w/o any branching.
The squares indicate merges and branchings. In the first case these are merge commits (i.e., a commit with more than one parent) and in the latter case these are also normal commits. A square was chosen here to indicate that a branch goes off.
The colors of the lines (and of the shapes) are just there to make the graph better readable (i.e., to see to which branch they belong) and are configurable: https://tortoisegit.org/docs/tortoisegit/tgit-dug-settings.html#tgit-dug-settings-colours3
It's for the diverged and merged point.
Related
I am trying to develop an online map editing program for a game that I play.
The data for the map is a little large. A medium size map's data is close to 1 mb if I send the data for every square.
What I thought I could do was find the boundaries on the map and create polygons based off of that.
Currently I:
Find the northwestern most boundary and start there. For my sample map, it's (3,2)
Then, check North, East, South, then West and go to the first unvisited location that does not have 1 as its data.
If there are no unvisited locations, go to the location that is the furthest back in the history.
Steps Taken
This works fine, for northern areas. However, when I get to a southern area, it checks north and finds that it's an unvisited location and goes to that. The coordinates of where it messes up is at 13,11.
Obviously, this doesn't give me the boundary that I want and it doesn't walk the entire map. So, something needs to change.
I considered adding a boundary check in the same order of operations as before(NESW). However, it is possible to mess that up as well.
At (13,11) it would check to the north and see that it's an unvisited location. And this time, there is a boundary there, so it would think it's ok to go there.
What should I do to walk the entire outer boundary?
I did take a look at the convex hull algorithm that is mentioned here, but I don't think it would be what I need. I might be incorrect, but this is what I would expect the result of a convex hull to look like.
While that does reduce the size of the map by a little bit, there is still a lot of data I don't need. And when I need to get the internal borders of items in the map, the size reduction is lost because they would be irregular as well.
So, how would I ensure that I'm actually walking the outer border?
Here is the expansion of the answer I suggested in the comment.
Imagine if you're in a dark labyrinth. what do you do to make sure you
traverse the whole labyrinth? Simple, just feel the wall to your left;
turn left whether possible; turn right when forced to.
Ok, more precisely:
Find a starting point on the boundary of the map, which I think you already know how.
Make sure to represent the current facing of your agent. (up,down,left,right)
Prioritize the relative direction of movement like this: (left, forwards, right, backwards)
Move in the prioritized direction if possible.
While walking, note down the visited position as part of the answer. And also check if you have come back to a visited place or not in order to terminate the program.
EDIT: correct the priority. left before forwards, not the other way round.
Not sure if I got a problem right, but it looks like the outer border can be presented as an array of orthogonal normal vectors. Or rather sections. Imagine a grid in which map squares belong to cells. Lets start marking our sections from the top left starting with 0. In that notation the beginning of outer border for pic. 1 would be ((3, 2), (4, 2)), ((4,2), (5,2)) and so on.
Every section, which belongs two cells, one of each is map square "1" and other not is a border. You can traverse through the grid and simply collect them.
Then you would have to sort them into cycles. That's easy. If two sections have one common coordinate - they do belong to the single cycle. If two cycles have a common coordinate beneath their sections - they are the one cycle, you just concatinate ones data to another.
When you have a set of definitely different cycles, the longest one, the one which has the most sections, would be your outer border.
If of course the map is in one piece.
I have a grid with a start, finish, and some walls. Units take the shortest path (moving only up/down/left/right) from the start to the finish, without passing through walls.
The user is allowed to add as many extra walls as they want to change the path.
However, notice that no matter how many walls are added or where they're added, there are some squares that can never be part of the shortest path!
These squares can never be part of the shortest path!
I'm looking for a way to detect which squares can never be part of the shortest path.
The above cases are easy enough to find; but there are more complex cases. Consider:
In the above image, none of the squares with red dots can ever be part of the best path, because there's only one entrance to that area, and it's only two spaces wide. If it were three spaces wide, or if any one of the walls were removed, most of those squares could potentially be part of the best path.
I've been trying to figure out a way to detect cases like the above (mostly using min-cuts and flood-fills), but without success. Does anyone know of a way to solve this problem?
Consider any path from S to F. That path could be a shortest path (if you delete every other square) unless you can take "shortcuts" using only those tiles. This only happens when you have two adjacent squares that aren't adjacent in the path. So you need to consider all pairs of adjacent squares; anything they disconnect from S or F (without disconnecting S from F) can't be part of a shortest path. Also, tiles that can be disconnected by a single square can't be part of any path (that doesn't repeat vertices) from S to F, so they need to go too.
Let N be the number of squares in the grid. For any particular pair of squares (there are O(N) of them), what gets disconnected can be computed in O(N) time with a floodfill, so this is O(N^2). Which is cheaper than min-cut, which you mentioned trying, so I assume its cheap enough for you.
first we see that, the areas can be blocked by one or two adjacent grids will never be in any shortest path.
see the case in your example, it's those two yellow grids who make the dots blocked.
blocked by one grid is easy to understand. When blocked by two:
if not adjacent, we may add extra walls to make it the only path, go
in through one and go out from the other one, so we may need the
inside ones.
if adjacent, we can always go from one directly to the other, so we
still don't need the grids inside that area.
So here's comes the algorithm:
enumerate each empty grid
put a wall on it and use flood-fill to find the blocked areas, they
are of no use.
try put a wall on one of it's four adjacent grid(if empty), use
flood-fill to find the blocked areas, they are of no use.
What is the algorithm for generating the maze in the game Netwalk?
The source code is available at Google Code, so you can read it for yourself and find out! The maze is generated by the function generate_maze in game.c, lines 78ff.
Update: try the demo!
Netwalk generates a maze by running a randomized version of Prim's algorithm to find a minimum spanning tree. Prim's algorithm iteratively grows a tree once branch at a time, starting from a source node (or nodes: in this case, the "server", the dark blue double-height box). At any given point in the running of the algorithm, the data structure looks something like this:
The cells coloured in green are cells at the tips of the growing branches: they still have at least one empty neighbour into which they might grow. At each step, the algorithm picks one of these green cells, and then picks one of its empty neighbours(1), and adds a branch into that neighbour. This new branch block neighbouring branches from growing in its direction. When a branch has no more empty neighbours(2), then it is removed from the list of green cells.
Eventually the green list is empty: none of the branches of the network have any empty neighbours. This means that the board is full, and every cell is connected to the server by a single path.
[I've idealised the details in a couple of places: (1) in fact the Netwalk algorithm is a bit naïve, and just picks a random direction, and if the neighbour in that direction is non-empty, it does nothing and continues to the next iteration. (2) Branches with no empty neighbours are not detected in a timely manner: they are only removed from the green list if they happen to be selected. The demo fixes these minor infelicities.]
I've got a raster grid of values that looks something like the image below (white is high values, the black background value is zero).
I'm trying to write some kind of path-following code to start at the end of one of the lines and trace to the other end, going via the highest possible values (that is, the whiter the pixels chosen to be in the line the better) but still getting to the other end.
I've been struggling with this for a while, and can't seem to get anything I try to work. So I wondered, has a generic algorithm already been developed for this sort of problem? I've done a lot of searching, but most path algorithms seem to be designed to work on vectors/networks, not raster grids like this.
Any ideas?
The simplest idea probably is to use the A* algorithm, where each pixel is a node, and the cost of the node is the pixel darkness.
Update: Found a nice tutorial.
One way to do this:
Filter the image to get it closer to black and white only pixels.
Draw a line through the white pixels. To do this, start at a white pixel. Draw a line from that pixel to each other white pixel a distance of 2 (or 3 or so) away, but ignore pixels near a previous line. Keep going until you've covered every pixel not close (2 or 3 pixels) from a line. You'll have to do some minor adjustments here to get it to work well.
Connect the endpoints of the lines you've drawn. If there are two endpoints near (1 or 2 pixels?) one another, connect them. You should end up with a few lines made up of a lot of short segments, possibly with some loops and forks.
Get rid of any small loops in the lines, and seperate the lines at forks, so you have a few lines made of a lot of short segments.
Reduce points. For each line, check to see if it is nearly straight. If so, remove all the interior points. If not, check the two halves of the line recursively until you get down to the minimum segment lengths.
You can optionally fit a spline curve through the lines at this point.
Profit.
It will take some tweaking to get it to work well, but it is possible to do it this way. One other variant is to outline the white sections, if they are wider than 1 or 2 or 3 pixels, and combine the double lines afterward.
I don't think you'll need a genetic algorithm or anything ridiculous; good old fashion recursion and dynamic programming should suffice. I am initially thinking, that you should be able to accomplish your goal by doing a breadth first search. From your starting point, you visit all the neighbors with scores greater then that paths value --all cells start out at infinity, and costs to black cells would be infinity, and these are the paths you can prune off). Once at your destination, if reachable, you should be able to backtrack to find the path. It's greedy, but if your paths are well behaved like these are, it should be fine.
For paths with more gray and twists and turns, it might be a good idea to convert the raster image to a graph, with the edge weight being the the gray scale values of the neighbors (or difference in gray scale values, depending on what this data actually means). So, you should be able to use any algorithm for shortest paths based on that interpretation.
If you are doing this on big scale or for research you might try whit http://en.wikipedia.org/wiki/Ant_colony_optimization, but if you are doing this for money just pick up something like flood fill http://en.wikipedia.org/wiki/Flood_fill
Introduction
As part of a larger program (related to rendering of volumetric graphics), I have a small but tricky subproblem where an arbitrary (but finite) triangular 2D mesh needs to be labeled in a specific way. Already a while ago I wrote a solution (see below) which was good enough for the test meshes I had at the time, even though I realized that the approach will probably not work very well for every possible mesh that one could think of. Now I have finally encountered a mesh for which the present solution does not perform that well at all -- and it looks like I should come up with a totally different kind of an approach. Unfortunately, it seems that I am not really able to reset my lines of thinking, which is why I thought I'd ask here.
The problem
Consider the picture below. (The colors are not part of the problem; I just added them to improve (?) the visualization. Also the varying edge width is a totally irrelevant artifact.)
For every triangle (e.g., the orange ABC and the green ABD), each of the three edges needs to be given one of two labels, say "0" or "1". There are just two requirements:
Not all the edges of a triangle can have the same label. In other words, for every triangle there must be two "0"s and one "1", or two "1"s and one "0".
If an edge is shared by two triangles, it must have the same label for both. In other words, if the edge AB in the picture is labeled "0" for the triangle ABC, it must be labeled "0" for ABD, too.
The mesh is a genuine 2D one, and it is finite: i.e., it does not wrap, and it has a well-defined outer border. Obviously, on the border it is quite easy to satisfy the requirements -- but it gets more difficult inside.
Intuitively, it looks like at least one solution should always exist, even though I cannot prove it. (Usually there are several -- any one of them is enough.)
Current solution
My current solution is a really brute-force one (provided here just for completeness -- feel free to skip this section):
Maintain four sets of triangles -- one for each possible count (0..3) of edges remaining to be labeled. In the beginning, every triangle is in the set where three edges remain to be labeled.
For as long as there are triangles with non-labeled edges:Find the smallest non-zero number of unallocated edges for which there are still triangles left. In other words: at any given time, we try to minimize the number of triangles for which the labeling has been partially completed. The number of edges remaining will be anything between 1 and 3. Then, just pick one such triangle with this specific number of edges remaining to be allocated. For this triangle, do the following:
See if the labeling of any remaining edge is already imposed by the labeling of some other triangle. If so, assign the labels as implied by requirement #2 above.
If this results in a dead end (i.e., requirement #1 can no more be satisfied for the present triangle), then start over the whole process from the very beginning.
Allocate any remaining edges as follows:
If no edges have been labeled so far, assign the first one randomly.
When one edge already allocated, assign the second one so that it will have the opposite label.
When two edges allocated: if they have the same label, assign the third one to have the opposite label (obviously); if the two have different labels, assign the third one randomly.
Update the sets of triangles for the different counts of unallocated edges.
If we ever get here, then we have a solution -- hooray!
Usually this approach finds a solution within just a couple of iterations, but recently I encountered a mesh for which the algorithm tends to terminate only after one or two thousands of retries... Which obviously suggests that there may be meshes for which it never terminates.
Now, I would love to have a deterministic algorithm that is guaranteed to always find a solution. Computational complexity is not that big an issue, because the meshes are not very large and the labeling basically only has to be done when a new mesh is loaded, which does not happen all the time -- so an algorithm with (for example) exponential complexity ought to be fine, as long as it works. (But of course: the more efficient, the better.)
Thank you for reading this far. Now, any help would be greatly appreciated!
Edit: Results based on suggested solutions
Unfortunately, I cannot get the approach suggested by Dialecticus to work. Maybe I did not get it right... Anyway, consider the following mesh, with the start point indicated by a green dot:
Let's zoom in a little bit...
Now, let's start the algorithm. After the first step, the labeling looks like this (red = "starred paths", blue = "ringed paths"):
So far so good. After the second step:
And the third:
... fourth:
But now we have a problem! Let's do one more round - but please pay attention on the triangle plotted in magenta:
According to my current implementation, all the edges of the magenta triangle are on a ring path, so they should be blue -- which effectively makes this a counterexample. Now maybe I got it wrong somehow... But in any case the two edges that are nearest to the start node obviously cannot be red; and if the third one is labeled red, then it seems that the solution does not really fit the idea anymore.
Btw, here is the data used. Each row represents one edge, and the columns are to be interpreted as follows:
Index of first node
Index of second node
x coordinate of first node
y coordinate of first node
x coordinate of second node
y coordinate of second node
The start node is the one having index 1.
I guess that next I should try the method suggested by Rafał Dowgird... But perhaps I ought to do something completely different for a while :)
If you order the triangles so that for every triangle at most 2 of its neighbors precede it in the order, then you are set: just color them in this order. The condition guarantees that for each triangle being colored you will always have at least one uncolored edge whose color you can choose so that the condition is satisfied.
Such an order exists and can be constructed the following way:
Sort all of the vertices left-to-right, breaking ties by top-to-bottom order.
Sort the triangles by their last vertex in this order.
When several triangles share the same last vertex, break ties by sorting them clockwise.
Given any node in the mesh the mesh can be viewed as set of concentric rings around this node (like spider's web). Give all edges that are not in the ring (starred paths) a value of 0, and give all edges that are in the ring (ringed paths) a value of 1. I can't prove it, but I'm certain you will get the correct labeling. Every triangle will have exactly one edge that is part of some ring.