Given a point in a square I need to calculate how far that point is across the square (0% progress at one end, 100% at the other). For simple horizontal (or vertical) traversals the progress is just the X-coordinate (or Y-coordinate) divided by the size of the square.
But here's where I'm struggling: I need the traversal to be at an angle, so a few (degrees? radians?) either slanting up or down. If this helps: all the points with matching "progress" values, should form a line perpendicular to the path/angle of traversal.
I need to write a method like this (most any language), that returns a value between 0 and 1:
float calculateProgress(float x, float y, float size, float angle) { }
... but not sure where to start.
Any help greatly appreciated!
Edit/Added Description: for a flat/horizontal traversal, the points that report "50% progress" would form a vertical line in the middle of the square. But rotated a little counter-clockwise, I want those same points (now rotated to form a slanting line) to report "50% progress" even though the top half are now to the left of x/size and the bottom half are now to the right of x/size.
Related
I'm trying to implement Lee's visibility graph.
There might be n number of polygons, where each side of the polygon is an edge. Let's say there is a point p1, and a half-liner parallel to the positive x-axis start at p1. I need to find edges that are intersected by r, and store them in sorted order.
An edge that is intersected first by line r has higher priority, also an edge that's closer has a higher priority, but when seen > distance.
E.g p1 = (0, 1), and a polygon with the following vertices {(2,
4),(3,6),(5, 20)}. The edges for this polygon should be sorted as
[((2, 4),(5, 20)), ((2,4),(3, 6)), ((3, 6),(5, 20))].
Hence, how can I sort these edges?
(if you go to the link and read that, I think you will have a better idea, sorry for my explanation).
My prime idea: sort them by distance and angel from p1 to the first Vertex of the edge encountered by r. Though, all vertices have more than one edge (since each vertex/edge is part of a polygon), and I don't know how to sort these two.
Any ideas or hints would be much appreciated.
Just some references:
https://taipanrex.github.io/2016/10/19/Distance-Tables-Part-2-Lees-Visibility-Graph-Algorithm.html
And a book: Computational Geometry ALgorithms and Application.
I found a way for those who are interested:
The sweep line is rotating anti-clockwise and its ordering edges based on taking measurements when it encounters the first vertice of that edge, which are: angle between the initial position of the half line (when it's parallel to positive x-axis) and the vertice encountered, the distance between p1 and the encountered vertice. The smaller the angle and distance the better, also angle has higher priority than distance.
I also take a 3rd measurement, since the half line rotates, when it reaches a vertice it should intersect it, hence I take the angle between the half line and the edge of the vertice. The large the angle the higher priority for this one, since it means the edge is closer. This angle is to differentiate between edges that have the same first encountered vertice by the half line. Therefore, the priority for this measurement is the lowest.
Hopefully, this will help someone.
I'm having trouble computing the intersection point of an ellipse and a line.
Let's say I have an ellipse at point (0/0) with radius 500. Additionaly I'm drawing a line from point (0/0) to (mouseX, mouseY).
First I check if the mouse coordinates are outside the ellipse by doing
if((mouseX*mouseX)+(mouseY*mouseY)) > 500*500){/*...*/}
Now, whenever the mouse coordinates are outside that ellipse, I want to draw the line not until the mouse, but until the 'border' of the ellipse. In order to do so, I must have the intersection point of the line and the ellipse.
Are there any libraries that simplify such trigonometric tasks? Is there any other more or less easy way to compute the intersection?
From what you've said, I'm making the following assumptions:
The ellipse is always circular (same radius all the way round).
The line is always being drawn from the centre of the circle.
If those are true then the problem is actually very simple. All you need to do is truncate the line so that its length is the same as the circle's radius, and that gives you the intersection point.
If the mouse is outside the ellipse:
Store the vector describing the line; in this case (mouseX, mouseY).
Normalize the vector (divide each component by the length of the line).
Multiply the vector by the radius of the circle.
The vector now contains the intersection point, relative to the centre of the circle.
You don't have to use a vector class for this, although it might help.
If your circle and line aren't starting on the origin (0,0) then you'll need to compensate. At step 1, subtract your new origin from (mouseX,mouseY). After step 3, add the origin back in to get the display coordinates.
I am programming a 2D, grid-based Pacman game. All the tiles are 8x8 in size. In-game, the map tiles are treated as 16x16, and the characters (Pacman and the ghosts) are treated as 32x32. In actuality, they are all pulled from a spritesheet of 8x8 tiles. I store positions as the center point of each character. Since the character tiles are bigger than the map tiles, the map is built in a way that requires the characters being able to "overlap" onto blocked tiles.
To deal with this set of problems, I created an invisible Rectangle and attached it to the character's position. Where the position is an (x,y) point, the Rectangle is a box surrounding that point. This rectangle is essentially 16x16 in-game, and is in the center of the character, which allows for the overlap necessary.
This works fine if you're working with 8px as the global movement speed, but I'd like to treat 8px as "100% speed" and have complete control over character speed with a double that is in the range [0,1). The positions are stored as double points, so on that level, this is fine. I read the positions back as integers, though, since I'm working with pixels.
So the question I ask is essentially "if this moves X amount of pixels to direction Y now, will my collision box be touching a blocked tile? But if you're moving 5px at a time, this eventually causes a very obvious issue. Say you're at x = 0, moving right. The tiles are 16x16 in-game, as stated before, and you have two of these open before the third, which is blocked. So you move, x = 5, x = 10, x = 15, x = 20, we just got to the 2nd tile, x = 25, x = 30, x = 35 now we're in the 3rd tile... but wait. We can't go there, because X = 35 collides. And unfortunately, we needed to turn and start moving down, but we can't, because now our Y-axis isn't aligned properly with the grid. Our X position needs to be 32, but can't.
My question for everyone here is, what are my options? What are some ideas or insights you have? I have a feeling I'm making it more difficult than I need to.
sounds like you have...
Why not give your "pac-man" sprite a velocity vector? The vector will describe not only the speed at which "pac-man" is traveling but in what direction, meaning you can see ahead.
"pac-man" should be calculating and ultimately making a decision based upon the following conversation..."hey, moving at this speed and in this direction..in so many seconds I'm going to hit a wall, when does that happen?". The seconds don't even have to be seconds...they could be "squares".
You would need a function which takes in the initial movement vector (direction and speed) which returns a coordinate of an X,Y point where "pac-man" must stop, where he cannot go further and must change direction (the center of a tile adjacent to a wall). Each time "pac-man" changes direction, run this calculation again...you do not need to keep checking if the next square is passable. If his direction hasn't changed and his speed is constant..you only need calculate once and let the coordinate system do the rest.
With this approach, square size and velocity is irrelevant...until "pac-man" hits or within his next movement exceeds the stopping point, continue to move along the vector.
I'm making a coastline fractal on a window that is one by one wide, and I would like to make the very first one pictured below, however, I cannot figure out which x and y coordinates to use to make the angles form 90 degrees and still fit on the screen, I don't need any code, I just would like how to figure out which x and y coordinates to use. Thanks!
Points:
1st point: (0,0.5)
2nd point: (0.25,0.75)
3rd point: (0.75,0)
4th point: (1,0.5)
My work (although messy and illegible at times):
It looks like from the picture that the first and last point both have a y-value of 0.5. Since the viewing window is one, you divide it into 4 parts each of which is 0.25 in length. The triangles that are formed if you draw a horizontal line at y=0.5 are isosceles according to the image. Thus, you solve: sin(45)=x/0.5.
re "x and y coordinates are doubles in between 0 and 1",
Then you will need to translate from your model (the set of points that make up your fractal) and the view (the GUI display). The model will go from 0 to 1, the view from 0 to the graphical window's width. A simple linear transformation where you multiply the model by some scale factor will serve.
Seems like you're wanting to map an abstract coordinate system to your screen.
Let's say your endpoints (in arbitrary coordinates) are (0, 0) and (1, 0). Then your points for the leftmost figure, in this system, will be (0, 0), (1/4, sqrt(2)/4), (1/2, 0), (3/4, -sqrt(2)/4), and (1, 0).
The other diagrams are calculated by some method. It sounded like your question was focusing on fitting it to the screen, so I'll continue with that. The method for fitting it to the screen is the same.
From there, you have a screen coordinate system. Each point is transformed to the screen. Let's say you have a 1000 by 1000 screen, with screen coordinates (0, 0) in the upper left. If you want to take up the entire screen, then you'd do the following:
Flip the y coordinates (+y is down on your screen)
Determine the full range in x and y for your arbitrary coordinates (1 for x, sqrt(2)/2 for y)
Multiply x values by 1000, and y values by 2000 / sqrt(2) to expand to the screen.
Subtract 500 from y values to center the image in the y direction.
I have an image such as this:
and I need to calculate the orientation of it. In this case the shape is pointing towards the top left of the screen. Accuracy isn't hugely important as long as 3 or 4 calculations average out to within 5 degrees or so of the actual orientation (it will be moving slightly).
Can anyone point me towards an algorithm to do this? I don't mind if the orientation is returned as a double or as a vector.
If the image is always T-shaped, you can simply get the furthest pair of pixels, then find the furthest pair from either both of those (the edges of the T), find which is further from the other two, draw a line from that one to the middle point of those two.
You can further refine it by then finding the base of the T by comparing the middle line with the edges of the base, and adjusting the angle and offset until it is actually in the middle.
The definitive solution is impossible I guess, since requires image recognition. I would project the 2D image onto axis, i.e. obtain the width and height of the image and get direction vector from these values taking them as components.
First, a couple of assumptions:
The center and centroid are "close"
The descending bar of the T is longer than the cross-bar
First, determine the bounding rectangle of the image and find the points of the image that lie along this rectangle. For points that lie along the line and are a certain distance from one another (say 5 pixels to pick a value) you'll need to only take 1 point from that cluster. At the end of this you should have 3 points, i.e. a triangle. The shortest side of the triangle should be the cross-bar (from assumption 2), i.e. find the two points closest to each other. The line that is perpendicular to the line crossing those two points is then your orientation line, i.e. find the angle between it and the horizontal axis.
I would try morphological skeletonization to simplify the image, followed by some straightforward algorithm to determine the orientation of the longer leg of the skeleton.
The solution in the end was to use a Convex Hull Algorithm, which finds the minimum number of points needed to enclose a shape with a bound.