As the pic show, both curves are of spline line, and have limited points. I want to figure out the count of green points. Is there any idea?
I assume the black curve is x-monotone (otherwise the "one above the other" term can be ambiguous).
A simple approach is to consider the black curve as a polygonal line and for each point p on the red curve find the point q on the polygonal line with the same x-coordinate. Then the green points are those p that have a larger y-coordinate than their corresponding q.
Finding the point q corresponding to a given p amounts to going over the segments of the polygonal line and identifying segments that have one endpoint with smaller x-coordinate and the other with larger. Once you have such a segment the y-value of q is just a linear interpolation.
Since the polygonal line is x-monotone, the x-coordinates of the points are sorted. Therefore, the search for the corresponding segments can be done efficiently using logarithmic binary-search.
Related
How to place n points in a plane so that the distance between every two points is unique and at the same time we could choose one of them that is the closest for all others n-1 points.
I tried to draw it. But I was able to draw it only for max n=5. I drew two perpendicular lines. One point I was intersection of the lines and the others points lie on the line so that they formed a quadrilateral and point I was inside. With more points it seems impossible to me but I can't prove why
The Xiaolin Wu algorithm draws an anti-aliased line between two points. The points can be at sub-pixel, i.e. non-integer coordinates. I'll assume the reader is familiar with the algorithm and just recall the important features. We loop across the major (longer) axis of the line, let's say it's the x-axis, basically proceeding column-by-column. In each column we color two pixels. The computation is equivalent to this: place a 1x1 square centered on the line, at the point whose x coordinate is the center of the the given column of pixels. Let's call it S. If we think of each pixel as a 1x1 square in the plane, we now calculate the area of intersection between S and each of the two pixels it straddles, and use those areas as the intensities with which to color each pixel.
That's nice and clear, but what is going on with the calculations for the endpoints? Because the endpoints can be at non-integer positions, they have to be treated as a special case. Here's the pseudocode from the linked Wikipedia article for handling the first endpoint x0, y0:
// handle first endpoint
xend := round(x0)
yend := y0 + gradient * (xend - x0)
xgap := rfpart(x0 + 0.5)
xpxl1 := xend // this will be used in the main loop
ypxl1 := ipart(yend)
plot(ypxl1, xpxl1, rfpart(yend) * xgap)
plot(ypxl1+1, xpxl1, fpart(yend) * xgap)
I edited out the if (steep) condition, so this is the code for the case when the slope of the line is less than 1. rfpart is 1-fpart, and fpart is the fractional part. ipart is the integer part.
I just have no idea what this calculation is supposed to be doing, and I can't find any explanations online. I can see that yend is the y-coordinate of the line above xend, and xend is the x coordinate of the pixel that the starting point (x0, y0) is inside of. Why are we even bothering to calculate yend? It's as if we're extending the line until the nearest integer x-coordinate.
I realize that we're coloring both the pixel that the endpoint is in, and the pixel either immediately above or below it, using certain intensities. I just don't understand the logic behind where those intensities come from.
With the Xiaolin Wu algorithm (and sub-pixel rendering techniques in general) we imagine that the screen is a continuous geometric plane, and each pixel is a 1x1 square region of that plane. We identify the centers of the pixels as being the points with integer coordinates.
First, we find the so-called "major axis" of the line, the axis along which the line is longest. Let's say that it's the x axis. We now loop across each one-pixel-wide column that the line passes through. For each column, we find the point on the line which is at the center of that column, i.e. such that the x-axis is an integer. We imagine there's a 1x1 square centered at that point. That square will completely fill the width of that column and will overlap two different pixels. We color each of those pixels according to the area of the overlap between the square and the pixel.
For the endpoints, we do things slightly differently: we still draw a square centered at the place where the line crosses the centerline of the column, but we cut that square off in the horizontal direction at the endpoint of the line. This is illustrated below.
This is a zoomed-in view of four pixels. The black crosses represent the centers of those pixels, and the red line is the line we want to draw. The red circle (x0, y0) is the starting point for the line, the line should extend from that point off to the right.
You can see the grey squares centered on the red crosses. Each pixel is going to be colored according to the area of overlap with those squares. However, in the left-hand column, we cut-off the square at x-coordinate x0. In light grey you can see the entire square, but only the part in dark grey is used for the area calculation. There are probably other ways we could have handled the endpoints, for instance we could have shifted the dark grey region up a bit so it's vertically centered at the y-coordinate y0. Presumably it doesn't make much visible difference, and this is computationally efficient.
I've annotated the drawing using the names of variables from the pseudocode on Wikipedia.
The algorithm is approximate at endpoints. This is justified because exact computation would be fairly complex (and depend on the type of endpoint), for a result barely perceivable. What matters is aliasing along the segment.
I've been trying to figure out how to determine a bounding polygon around a specific set of points (set A) from another set of points (set B) such that the polygon only contains points in set A. For simplicity, we can assume the polygon will be convex, set A will only include 2 points, and a solution will exist from the given data.
For example, given:
these points, I want to create a polygon around the blue points from the red points like this. This could be done by finding the next point with the greatest angle while not cutting through the blue points, but I don't want the result to be too minimal like this.
Any suggestions or algorithms for solving this problem?
Seems that if you calculate triangulation over all (red and blue) points, then triangles containing blue vertices, form the first approximation of needed region. This approximation usually would be concave, so one need to cut off "ears".
If result looks too small, it is possible to add the third vertices of outer border triangles if they don't violate convexity.
In my current project I need to calculate the intersection area of triangles and the unit squares in an infinite grid.
For every triangle (given by three pairs of floating point numbers) I need to know the area (in the interval (0,1]) it has in common with every square it intersects.
Right now I convert both (the triangle and the square) to polygons and use Sutherland-Hodgman polygon clipping to calculate the intersection polygon, which I then use to calculate its area.
This approach now shows to be a performance bottleneck in my application. I guess a more specialized (analytical) algorithm would be much faster. Is there a standard solution for this problem, or do you have any idea? I only need the areas, not the shape of the intersections.
Your polygon are convex. There are some algorithms for convex polygons faster than general ones. I've used O'Rourke algorithm with success (code from his book here, I believe that good description exists). Note that some values may be precomputed for your squares.
If your polygons not always intersect, then you may at first check the fact of intersection with separating axes method.
Another option to try- Liang-Barski algorithm for clipping every triangle edge by square.
Edit: You can quickly find all intersections of triangle edges with grid using algorthm of Amanatides and Woo (example in grid traversal section here)
To process this task with hi performance , i suggest some modifications of
Vatti line sweep clipping.
http://en.wikipedia.org/wiki/Vatti_clipping_algorithm
Stepping from minimal Y vertex of your Triangle make such steps:
sort vertexes by Y coordinate
step Y higher to MIN(nextVertex.Y, nextGridBottom)
Calculate points of intersection of grid with edges.
Collect current trapezoid
repeat from step2 until vertex with highest Y coordinate.
Split trapezoids by X coordinate if required.
here is example of Trapezoidalization in X direction
http://www.personal.kent.edu/~rmuhamma/Compgeometry/MyCG/PolyPart/polyPartition.htm
It illustrate main idea of line sweep algorithm. Good luck.
You are not mentioning what precision you are looking for. In case you are looking for a analytical method, disregard this answer, but if you just want to do antialiasing I suggest a scanline edge-flag algorithm by Kiia Kallio. I have used it a few times and it is quite fast and can be set up for very high precision. I have a java implementation if you are interested.
You can take advantage of the regular pattern of squares.
I'm assuming the reason this is a bottleneck is because you have to wait while your algorithm finds all squares intersecting any of the triangles and computes all the areas of intersection. So we'll compute all the areas, but in batches for each triangle in order to get the most information from the fewest calculations.
First, as explained by others, for each edge of the triangle, you can find the sequence of squares that edge passes through, as well as the points at which it crosses each vertical or horizontal edge of a square.
Do this for all three sides, keeping a list of all the squares you encounter, but keep only one copy of each square. It may be useful to store the squares in multiple lists, so that all squares on a given row are all kept in the same list.
When you've found all squares the triangle's edges pass through, if two of those squares were on the same row, any squares between those two that are not in the list are completely inside the triangle, so 100% of each of those squares is covered.
For the other squares, the calculation of area can depend on how many vertices of the triangle are in the square (0, 1, 2, or 3) and where the edges of the triangle intersect the sides of the square. You can summarize all the cases in a few pencil-and-paper drawings, and come up with calculations for each one. For example, when an edge of triangle crosses two sides of the square, with one corner of the square on the "outside" side of the edge, that corner is one angle of a small triangle "cut off" by that edge of the larger triangle; use the points of intersection on the square's sides to compute the area of the small triangle and deduct it from the area of the square. If two points instead of one are "outside", you have a trapezoid whose two base lengths are found from the points of intersection, and whose height is the width of the square; deduct its area from the square. If three points are outside, deduct the entire area of the square and then add the area of the small triangle.
One vertex of the large triangle inside the square, three corners of the square outside that angle: draw a line from the remaining corner to the triangle's vertex, so you have two small triangles, deduct the entire square and add those triangles' areas. Two corners of the square outside the angle, draw lines to the vertex to get three small triangles, etc.
I'm phrasing this so that you always assume you start with the entire area of the square and reduce the area by some amount depending on how the edge of the triangle intersects the square. That way, in the case where the edges of the triangle intersect the square more than twice--such as one edge cuts across one corner of the square and another edge cuts across a different corner, you can just deduct the area cut off by the first edge, then deduct the area cut off by the second edge.
This will be a considerable number of special cases, though you can take advantage of symmetry; for example, you don't have to write the complete calculation for "cut off a triangle in one corner" four times.
You'll write a lot more code than if you just took someone's convex-polygon library off the shelf, and you will want to test the living daylights out of it to make sure you didn't forget to code any cases, but once you get it working, it shouldn't take much more effort to make it reasonably fast.
Idealy I want to supply a sequence of points and have a line drawn at a right angle at every point (starting at the second point).
The direction of each line would alternate, so if I happened to draw a curve cosisting of 6 points, a line of a given lenth would be drawn for each point starting with the second point, i.e 5 additional lines on alternating sides of the curve, a bit like a caterpillar with alternating legs.
(I understand that the lines won't be entirely at right angles to the curve but rather at right angle to the line formed by any two points on the curve).
It's a question of vector mathematics. You can calculate the directing vector between two points A and B by subtracting A from B. In 2D and only in 2D the vector right angled to this vector can be obtained by reversing x and y component and taking one component negative. If you negate the new x component you'll make a left turn, by negating y you'll make a right turn. You can then reduce the directing vector to unit size (= of length 1) by dividing each component by the length of the vector (sqrt(xx + yy)). Finally you can stretch the unit vector again by your desired length and have one of the size you want. If you add this vector to either A or B you'll get a point to which you want to draw your line.
Here's a little math help:
These are points A and B expressed as vector.
The directing vector is calculated by a simple subtraction.
The normal vector is given by flipping the directing vector, that is to reverse the components and make one component negative. nl = normal, flipped to the left, nr = normal, flipped to the right
The unit vector of the normal vector is given by dividing each component by the length of the vector.
Calculates the length of a vector
If you want to draw a line from B to the left (when coming from A) you calculate the point P to draw the line to as
So you want to alternate that one time you draw to the left and one time to the right when iterating over the points.
If you have points lying outside your canvas, then you length is probably too large. You can of course calculate the point at which the vector to P would cross the boundary by calculating the intersection point of the vector BP and the border.