Is there an analytical solution to find the intersection point between the placed grain and grain 1 if the placed grain is lowered [in the reference frame of the image] along the dotted line? We know the radius of both circles. We have graphical figured out the intersection point and labelled it for reference in the image.
Assuming
a right angle between the dotted line and the line through the center of g1 and g2
the dotted line is a tangent of g1
you can use the following:
Consider the situation when g1 and gp touch. In that case, the length of the line segment between center g1 and gp is equal to radius(g1) + radius(gp). Which is also the hypotenuse of a right-angled triangle for which radius(g1) is a cathetus. arccos(radius(g1)/(radius(g1) + radius(gp))) gives you then the angle between the hypotenuse and cathetus around the center of g1.
This angle and the length radius(g1) are polar coordinates of the intersection point relative to the center of g1.
Related
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.
How do you get the points of lines tangent to two circles, where both starting point and end point of line are exactly touching their respective circles?
Please help. Thanks.
The angles at p4 and p2 are 90 degrees. If you conceptually put them at the base of a quadrilateral p2-p4-c2-c1, you can get the angle at C2 (from p4-c1) and at c1 (from p2-c2). With that angle, you can easily construct it.
My requirement is to find the point closest to three circles. So lets say the three circles are C1, C2, C3. I want to find the point in the space such that the SUM of its distance from C1, C2 and C3 is MINIMUM.
The distance of a given point from a circle is the distance of the given point from the point that lies on the circle and is intersection of the circle with the line joining the given point with the center of the circle.
Is there a simple logic of find such a point?
Unless one of the distances will be zero, the circle radii are irrelevant: the sum of the distances to the circles will be the sum of the distances to the centers minus the sum of the radii. So in effect you are asking for the geometric median of the circle centers. You might want to iteratively compute an approximation. Or you make use of the fact that you have three circles, in which case the median is the Fermat point of the triangle formed by their centers.
If the point constructed as above lies within one of the circles, then you can move towards that circle while decreasing the sum. So you'd have to consider all the points on that given circle, which you can express as a one-parameter family. You could then compute the distance as a function of that parameter, and the derivative of the resulting formula, and setting that equal to zero will give the optimal solution for this case.
How to find Centroid for a rectangular section inclined at an angle theta? Is there any general formula available?
Centroid of a rectangle is situated at intersection of it's diagonals (or arithmetic mean of all vertices). So it is enough to find vertice coordinates after inclination
Centroid of a rectangle does not changes, after inclination.
Only the co-ordinates of a Rectangle changes with the following equation.
x′=xcosθ − ysinθ
y′=xsinθ + ycosθ
where,
(x,y)-initial co-ordinates of rectangle.
(x',y')-final co-ordinates of rectangle.
θ-angle of inclination.
Refer link for detail.
I have a set of vertices to draw a circle, but I want to draw a high-res circle by drawing twice the number of vertices, I cant just increase the number of vertices what I need is to calculate the mid points from the supplied vertices, if that makes sense
So from that image how can I calculate the points A, B, C, ... given the points V0, V1, V2, ... and the center point of the circle ?
Please note that I cant just calculate the mid-points by rotating the vertices they need to be calculated using their position
Thanks
The center of the circle can be determined by making a perpendicular line to two neighboring "sides", and intersecting them.
If there are an even number of vertices, just pick two which are opposite to each other, and "avarage them" - calculate the midpoint.
Then, you can just rotate all the vertices to either way by 180°/No.vertices around this center, so you get the ones you are looking for. Of course, you should keep the existing ones too.