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.
Related
If an edge can be solved by only rotating the right, left, up and down faces, it is considered correctly oriented. If solving the edge requires the turning of the front or the back faces, it is considered misoriented or "bad". Rotating the cube, so that the front and back faces become different ones, is not allowed.
Here is an example:
Image from here
This site details a deductive way for humans to determine the edge orientation. I'm wondering if there is a more optimal way to do it from a program (also, the steps taken to scramble the cube are known).
There seems to be an answer to your question already on the site.
Look at the U/D faces. If you see:
- L/R colour (orange/red) it's bad.
- F/B colour means you need to look round the side of the edge. If the side is U/D (white/yellow) it is bad.
Then look at the F/B faces of the E-slice (middle layer). The same rules apply. If you see:
- L/R colour (orange/red) it's bad.
- F/B colour (green/blue) means you need to look round the side of the edge. If the side is U/D (white/yellow) it is bad.
so it's simply a matter of looping through colors on U/D/F/B faces (or you could do on a single edge basis) and if any of them break the rules you know that edge is bad. This way only looks at each edge once, so I'd say it's fairly efficient. This ignores knowing the scramble algorithm though.
Simply using the scramble algorithm to determine edge orientation would be much harder as you'd have to watch for patterns in the turns and if the scramble is long enough this could end up taking more time than what is explained above. But for completeness I will give a short example of how it could be done.
Start with the state of all edges oriented and where they lie, (only 12 positions so number accordingly). Or again if you're interested in one only track one.
Then iteratively go through the list
any time a F/B is turned an odd number of times flip the orientation on the edges on whichever face was turned.
That could be run backwards keeping track of the state of an edge as you move it back to completeness and if in the end your edge claims to be "misoriented" you'll know it was actually opposite the state that you started with (as the solved cube has all edges oriented).
This however runs in O(n) where n is the length of the scramble, and the first runs in O(1) so if you're expecting very short scrambles this second method may be better. but you're guaranteed speedy results with the first.
I would provide pseudo-code however I don't think these algorithms are very complex and I'm not sure how the data may be stored.
I'm trying to implement a polyline simplification algorithm. The original article can be found here: http://archive.is/Tzq2. It seems straightforward in concept but I don't understand the sample algorithm (I think it's poorly worded) pseudocode supplied and was hoping someone could provide some insight. From the article, I gathered that the basic idea is to
Calculate the effective area (formed by the triangle between three consecutive points on a line) for each point and delete those with 0 area
Starting with the smallest area, compare the point's area with a threshold, and if the area is below that threshold, delete it from the polyline.
Move to the two adjacent points and recalculate their areas as they've changed
Go back to 2 until all point areas under the threshold have been removed
The algorithm is as follows (copied verbatim from the article):
Compute the effective area of each point
Delete all points with zero area and store them in a separate list with this area
REPEAT
Find the point with the least effective area and call it the current point. If its calculated area is less than that of the last point to be eliminated, use the latter's area instead. (This ensures that the current point cannot be eliminated without eliminating previously eliminated points.)
Delete the current point from the original list and add this to the new list together with its associated area so that the line may be filtered at run time.
Recompute the effective area of the two adjoining points (see Figure 1b).
UNTIL
The original line consists of only 2 points, namely the start and end points.
I'm confused with the 'if' clause in the first step under 'REPEAT'... could anyone clarify?
FWIW Mike Bostock, the creator of d3.js, wrote a tight javascript implementation of this algorithm (Visvalingam's Algorithm).
Source code
Demo
Discussion on Hacker News
The essence of the algorithm is ranking of points by their significance. Significance of the point is approximated by its effective area.
Suppose you have eliminated Point A and then recalculated the effective area of Point B. The new area can be larger or smaller than the old one. It can be smaller than the effective area of A. However, the algorithm still views B as more significant than A.
The purpose of the if clause is to ensure that Point B is more significant than A in the final list, that's all.
I was confused by this too, went back and read the article again, and afaict it's not needed if you're removing points as you go - aka if you're doing a one-off simplification with a fixed area threshold. afaict the javascript implementation works this way, so it actually doesn't need the 'if' statement (but it has it anyway, oh well).
The 'if' statement is needed if you're keeping all the points around. In that case, you're storing the 'effective area' with each point so that later you can filter them, perhaps using an interactive slider that controls the # of output points. By storing that larger effective area, you preserve the proper ordering.
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.
I am now looking for an elegant algorithm to recursively find neighbors of neighbors with the geohashing algorithm (http://www.geohash.org).
Basically take a central geohash, and then get the first 'ring' of same-size hashes around it (8 elements), then, in the next step, get the next ring around the first etc. etc.
Have you heard of an elegant way to do so?
Brute force could be to take each neighbor and get their neighbors simply ignoring the massive overlap. Neighbors around one central geohash has been solved many times (here e.g. in Ruby: http://github.com/masuidrive/pr_geohash/blob/master/lib/pr_geohash.rb)
Edit for clarification:
Current solution, with passing in a center key and a direction, like this (with corresponding lookup-tables):
def adjacent(geohash, dir)
base, lastChr = geohash[0..-2], geohash[-1,1]
type = (geohash.length % 2)==1 ? :odd : :even
if BORDERS[dir][type].include?(lastChr)
base = adjacent(base, dir)
end
base + BASE32[NEIGHBORS[dir][type].index(lastChr),1]
end
(extract from Yuichiro MASUI's lib)
I say this approach will get ugly soon, because directions gets ugly once we are in ring two or three. The algorithm would ideally simply take two parameters, the center area and the distance from 0 being the center geohash only (["u0m"] and 1 being the first ring made of 8 geohashes of the same size around it (=> [["u0t", "u0w"], ["u0q", "u0n"], ["u0j", "u0h"], ["u0k", "u0s"]]). two being the second ring with 16 areas around the first ring etc.
Do you see any way to deduce the 'rings' from the bits in an elegant way?
That depends on what you mean by Neighbor. I'm assuming this is being used in the context of a proximity search. In that case I would think that your best bet would be to search from the outermost ring inward.
Assume you can find the outermost set (longest proximity) in the searchable Universe. Store that as the new Universe and then find the next inner set in that Universe. This search should subtract that inner set from the Universe. Store the old Universe (the outermost ring) and repeat this process until you hit the center. Each search after the first one will reduce your search area and give you a ring.
Start by constructing the sides immediately around the central geohash i.e. top, right, bottom and left, initially each of these will only comprise a single geohash and a corner. Then recursively iterate the sides using the adjacent function with direction as corresponds that side (i.e. expand left for the left side) whilst maintaining an appropriate result set and the sides for the next iteration. You also need to handle the diagonal/corner geohash for each side (e.g. left-top for left, top-right for top, if using a clockwise association). For an example of the procedure see this implementation I did in Lua or Javascript (but with additional functionality), which start with a call to Grid().
Just wondering if there was a nice (already implemented/documented) algorithm to do the following
boo! http://img697.imageshack.us/img697/7444/sdfhbsf.jpg
Given any shape (without crossing edges) and two points inside that shape, compute all the paths between the two points such that all reflections are perfect reflections. The path lengths should be limited to a certain length otherwise there are infinite solutions. I'm not interested in just shooting out rays to try to guess how close I can get, I'm interested in algorithms that can do it perfectly. Search based, not guess/improvement based.
I think you can do better than computing fans. Call your points A and B. You want to find paths of reflections from A to B.
Start off by reflecting A in an edge, and call the reflection A1. Can you draw a line from A1 to B that only hits that edge? If yes, that means you have a path from A to B that reflects on the edge. Do this for all the edges and you'll get all the single reflection paths that exist. It should be easy to construct these paths using the properties of reflections. Along the way, you need to check that the paths are legal, i.e. they do not cross other edges.
You can continue to find paths consisting of two reflections by reflecting all the first generation reflections of A in all the edges, and checking to see whether a line can be drawn from those points through the reflecting edge to B. Keep on doing this search until the distance of the reflected points from B exceeds a threshold.
I hope this makes sense. It should be easier than chasing fans and dealing with their breakups, even though you're still going to have to do some work.
By the way, this is a corner of a well studied field of billiards on tables of various geometries. Of course, a billiard ball bounces off the side of a table the same way light bounces off a mirror, so this is just another way of thinking of reflections. You can delve into this with search terms like polygonal billiards unfolding illumination, although the mathematicians tend to dwell on finding cases where there are no pool shots between two points on a polygonal table, as opposed to directly solving the problem you've posed.
Think not in terms of rays but fans. A fan would be all the rays emanating from one point and hitting a wall. You can then check if the fan contains the second point and if it does you can determine which ray hits it. Once a fan hits a wall, you can compute the reflected fan by transposing it's origin onto the outside of the wall - by doing this all fans are basically triangle shaped. There are some complications when a fan partially hits a wall and has to be broken into pieces to continue. Anyway, this tree of reflected fans can be traversed breadth first or depth first since you're limiting the total distance.
You may also want to look into radiosity methods, which is probably similar to what I've just described, but is usually done in 3d.
I do not know of any existing solutions for such a problem. Good luck to you if you find one, but incase you don't the first step to a complete but exponential (with regard to the line count) would be to break it into two parts:
Given an ordered subset of walls A,B,C and points P1, P2, calculate if a route is possible (either no solutions or a single unique solution).
Then generate permutations of your walls until you exceed whatever limit you had in mind.
The first part can be solved by a simple set of equations to find the necessary angles for each ray bounce. Then checking each line against existing lines for collisions would tell you if the path is possible.
The parameters to the system of equations would be
angle_1 = normal of line A with P1
angle_2 = normal of line B with intersection of line A
angle_3 = normal of line C with ...
angle_n = normal of line N-1 with P2
Each parameter is bounded by the constraints to hit the next line, which may not be linear (I have not checked). If they are not then you would probably have to pick suitable numerical non-linear solvers.
In response to brainjam
You still need wedges....
alt text http://img72.imageshack.us/img72/6959/ssdgk.jpg
In this situation, how would you know not to do the second reflection? How do you know what walls make sense to reflect over?