Best
In the following image, you can view the setup of my problem.
In general, i've 2 cameras which have a view-angle of 48° and 64°.
Secondly, I know the position of my camera's (which means i can calculate the distance between the two cameras )
And Thirdly, I know the angle (alpha) of my object for each of the cameras
Now the question is: Can I know all the other things? Like the distance of the purple dot according to the blue dots. (+ also the position)
Kind regards
EDIT
Without knowing the angle between the camera-view-angle and the Red line
If you know the angle of each camera from the red line connecting them, then you have everything you need.
Assume the length of the red line is L and the distance from the purple dot to the red line is D.
Let a = the angle formed from the red line to the line connecting camera A to the purple dot.
Let b = the angle formed from the red line to the line connecting camera B to the purple dot.
Now, a and b can easily be calculated as you know each camera's angular range, its angle from the red line, alpha1 and alpha2.
The distance D is given by:
D = L.sin(a).sin(b)/sin(a+b)
Related
In a paper.js project, I have two points A and B, that lie on a simple shape. This shape can be a circle, a line, an ellipse, a rectangle, etc. I need to highlight the points that lie on the shape from point A to point B.
For example, if I was given the triangle below, and the points A and B, I want to high the line AB as shown in the diagram.
image of a triangle drawn in black with line AB highlighted in purple
I would like to understand how to implement this. Of course I can do it the brute force way by tracing tangent points, but that will be slow. I was wondering if there's a better way to do this.
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.
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.
I'm experimenting with a vector based graphics style with objects represented as series of line segments with a given width(it would probably be easier to think of these as rectangles). The problem is that these segments are connected at the center and leave a gap (shown below). I've determined that the most efficient way to cover this gap is simply to cover it with a triangle, and since I'm working in OpenGL, all I need are the points of the two points that don't overlap with the other rectangle, the third point being the center point where the two line segments(rectangles) are connected. How can I determine which points I need to use for the triangle, given that I have all of the points from both rectangles?
EDIT: I will also accept alternative solutions, as long as they cover up that gap.
EDIT 2: Nevermind, I solved it. I'll post code once I have better Internet connection.
Maybe I'm misunderstanding the question... but if you zoom in on the top corner of your red pentagon, you get something like this, am I right?
where A and B are nodes on the rectangle for edge1 and C and D are nodes on the rectangle for edge2. You say you already know these coordinates. And from what you say, the edges meet at the centre, which is halfway between A and B, and also halfway between C and D. So call this point X, and you can calculate its coordinates easily I guess.
So all you need to do is draw the missing triangle AXC, right? So one way would be to determine that A and C are on the "outside" of the polygon (and therefore need filling) and B and D are on the "inside" and therefore don't. But it's probably easier to just draw both, as it doesn't hurt. So if you fill AXC and BXD, you'd get this:
The solution I found assumes that there are 3 basic cases:
First, the three unique center points for the two rectangle proceed upward (positive y direction) so the gap is either on the left or right of the connection. In my code, I had the corner points of the rectangle organized by their orientation to the left or right of the center point, so if the bottom rectangle's left point is below the top rectangle's left point, then the gap is between the left points of the two rectangles, otherwise the gap is between the right points.
Second, the three unique center points have a maximum at the center most of the center points, so the gap is on the top. The gap is then between the two points with the maximum y values.
Third, the three unique center points have a minimum at the center most of the center points, so the gap is on the bottom. The gap is then between the two points with the minimum y values.
[I'll post pictures of the example cases if it is requested]
I have read an example and tried to duplicate it's methods but with weird results. This is a 1 shot deal so I do not want to buy a package to do this. Also, it will be executed on a Multi-Valued database in a Basic that not many programmers write in anymore.
If anyone can post a small example of this It would be most helpful. Specifically, I need a box centered on an 8x11 paper with the left 1/3 filled in Green, the center 1/3 in Yellow and the last 1/3 in Red. Then Draw a line thru 3 points within each color of the box.
Thanks.
The simplest way is to draw 3 boxes. You'll have to position each one on your own doing your own math to determine where to start the first one to make it centered etc.
First position your cursor at the top left of the first box, draw it, move to the top left of the next box, draw it, and do the same for the last. Here is some code:
<esc>&u300D<esc>*t300R<esc>*p300x300Y<esc>*r3U<esc>*v2S<esc>*c300a300b5P<esc>*p600x300Y<esc>*r3U<esc>*v3S<esc>*c300a300b5P<esc>*p900x300Y<esc>*r3U<esc>*v1S<esc>*c300a300b5P
Here is the explanation:
<esc>&u300D<esc>*t300R -- set the Unit of Measure and Resolution (in this case 300 dpi)
<esc>*p300x300Y -- move cursor to 300x 300y (1 inch x 1 inch)
<esc>*r3U<esc>*v2S -- set the color palette to RGB and use color 2 (green)
<esc>*c300a300b5P -- draw a box that is 300 wide and 300 tall, use current fill pattern
<esc>*p600x300Y -- move cursor to 600x 300y
<esc>*r3U<esc>*v3S -- set the color palette to RGB use color 3 (yellow)
<esc>*c300a300b5P -- draw a box that is 300 wide and 300 tall, use current fill pattern
<esc>*p900x300Y -- move cursor to 900x 300y
<esc>*r3U<esc>*v1S -- set the color palette to RGB use color 1 (red)
<esc>*c300a300b5P -- draw a box that is 300 wide and 300 tall, use current fill pattern
Here are the other colors and palettes, keep in mind this is the simple way, you can specify your own RGB etc.
RGB Palette
<esc>*r3U<esc>*v1S - Red
<esc>*r3U<esc>*v2S - Green
<esc>*r3U<esc>*v3S - Yellow
<esc>*r3U<esc>*v4S - Blue
<esc>*r3U<esc>*v5S - Magenta
<esc>*r3U<esc>*v6S - Cyan
CMYK Palette
<esc>*r-3U<esc>*v1S - Cyan
<esc>*r-3U<esc>*v2S - Magenta
<esc>*r-3U<esc>*v3S - Blue
<esc>*r-3U<esc>*v4S - Yellow
<esc>*r-3U<esc>*v5S - Green
<esc>*r-3U<esc>*v6S - Red
<esc>*r-3U<esc>*v7S - Black
Problem Solved: The error of my thinking was that it was a difference between 300 dpi and 600 dpi so I was dividing by 2 and the answer appeared almost correct. The Real problem was a difference between 3oo dpi and 720 Decipoints. The real factor needed to be 2.4 and now it works perfectly.