Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed last year.
Improve this question
I have read from Hearn and Baker computer graphics book. I read the test#2 painter's theorem which image is given below. Painter's theorem of test#2 image from Hearn and Baker
This image showing surface S is completely behind the surface S', by checking Substitute the coordinates of all vertices of S(x, y,z) into the plane equation of S' and check for the sign. If all vertices of S are inside S' then S is behind S'. (Fig. 1).
i. e. Ax + By+ Cz + D < 0 ,x, y, z are S vertices.
But I have read from this websites which showing this concepts but in totally opposite manner.
See this image I read from that site, which showing opposite thing on same image. This showing
all vertices of S are outside of S'.
i. e. Ax + By+ Cz + D > 0 ,x, y, z are S vertices.
My question is how is it possible Hearn and Baker saying S is completely inside the surface S' but my mentioned website saying S is outside of S' by sign test of plane equation?
The sign of the distance depends on S' orientation. Let me explain what is happening. When you substitute the points of S into the "implicit" equation of the S' plane you get a signed distance from the point to the S' plane. That distance is the shortest one because it goes in the direction of the normal vector of the S' plane.
Now, there are two possible directions for the normal vector of the S' plane. Lets say you compute the normal vector N using whatever suitable method, then the negaive of that vector -N is also a normal vector to the plane i.e., you can form a valid plane equation using either N or -N.
Usually in computer graphics the sense of normal vector is determined by the order of the vertices of the polygons. If they are clockwise the normal is -N (by convention) and if order is counterclock wise the notmal is N (by convention). Anyway, usually all planes in your space should have the same orientation so you don't need to care about that.
So the discrepance on the sign can be regarded as a difference in orientation of the planes (CW v.s. CCW) or difference in coordinate systems (e.g., right handed v.s. left handed coordinate system). So both are correct under adequate assumptions. In the end, picking an orientation is a tecnicism or implementation detail.
Related
I've been wanting to build a 3D engine starting from scratch as a coding challenge with the end objective of implementing it on a fantasy console.
The best (i.e. most simple?) way I found was raytracing/raycasting. I haven't found much by looking online for raycasting algorithms, only finding point-in-polygon problems (which only tell me whether a ray intersects a polygon or not, not quite my interest since I wouldn't have info about the first intersection nor I'd have the intersection points).
The only solution I could think of is brute forcing the ray by moving it at small intervals and every time check whether that point is occupied by something or not (which would require having filled shapes and wouldn't let me have 2D shapes since they would never be rendered, although none of those is a problem). Still, it looks way too complex performance-wisely.
As far as I know, most of those problems are solved using linear algebra, but I'm not quite as competent as to build up a solution on my own. Does this problem have a practical solution?
EDIT: I just found an algebric solution in 2D which could maybe be expanded in 3D. The idea is:
For each edge, check whether one of the two vertices are in the field of view (i.e. if O is the origin of every ray and P is the vertex, you have to check first that the point is inside the far point of sight, and then whether the angle with the forward vector is less than the angle of vision). If at least one of the two vertices is inside the field of view, add them to an array E.
If we have an array R of rays to shoot and an array of arrays I of info about hit points, we can loop for each ray in R and for each edge in E and then store f(ray, edge) in I, where f is a function that gives us info on whether the ray and the edge collided and where they did.
f uses basic linear algebra: both the ray and the edge are, for all purposes, two segments. Two segments are just parts of two lines. Let's say that if the edge has vertices A and B (AB is the vector that goes from A to B) and if the far point is called P (OP is the vector that goes from O to P). We can create two lines, r and s, defined by A + ηAB and O + λOP. After we do a check to see whether r and s are parallel (check if the absolute value of the dot product of AB and OP is equal to the norm of AB times the norm of OP), it's trivial to get the values for η and λ.
Now, if η < 0 OR η > 1 we have that the two segments are not colliding.
After we've done this for every ray and every edge, we compare every element in each array i in I to see which one had the lowest λ. The lowest λ carries the first collision and hence the data to show on screen.
Everything here is linear algebra, though I fear that it might still be computationally heavy, since there's a lot going on, and it's still only 2D.
I'm trying to code the Ritter's bounding sphere algorithm in arbitrary dimensions, and I'm stuck on the part of creating a sphere which would have 3 given points on it's edge, or in other words, a sphere which would be defined by 3 points in N-dimensional space.
That sphere's center would be the minimal-distance equidistant point from the (defining) 3 points.
I know how to solve it in 2-D (circumcenter of a triangle defined by 3 points), and I've seen some vector calculations for 3D, but I don't know what the best method would be for N-D, and if it's even possible.
(I'd also appreciate any other advice about the smallest bounding sphere calculations in ND, in case I'm going in the wrong direction.)
so if I get it right:
Wanted point p is intersection between 3 hyper-spheres of the same radius r where the centers of hyper-spheres are your points p0,p1,p2 and radius r is minimum of all possible solutions. In n-D is arbitrary point defined as (x1,x2,x3,...xn)
so solve following equations:
|p-p0|=r
|p-p1|=r
|p-p2|=r
where p,r are unknowns and p0,p1,p2 are knowns. This lead to 3*n equations and n+1 unknowns. So get all the nonzero r solutions and select the minimal. To compute correctly chose some non trivial equation (0=r) from each sphere to form system of n+1 =equations and n+1 unknowns and solve it.
[notes]
To ease up the processing you can have your equations in this form:
(p.xi-p0.xi)^2=r^2
and use sqrt(r^2) only after solution is found (ignoring negative radius).
there is also another simpler approach possible:
You can compute the plane in which the points p0,p1,p2 lies so just find u,v coordinates of these points inside this plane. Then solve your problem in 2D on (u,v) coordinates and after that convert found solution form (u,v) back to your n-D space.
n=(p1-p0)x(p2-p0); // x is cross product
u=(p1-p0); u/=|u|;
v=u x n; v/=|v|; // x is cross product
if memory of mine serves me well then conversion n-D -> u,v is done like this:
P0=(0,0);
P1=(|p1-p0|,0);
P2=(dot(p2-p0,u),dot(p2-p0,v));
where P0,P1,P2 are 2D points in (u,v) coordinate system of the plane corresponding to points p0,p1,p2 in n-D space.
conversion back is done like this:
p=(P.u*u)+(P.v*v);
My Bounding Sphere algorithm only calculates a near-optimal sphere, in 3 dimensions.
Fischer has an exact, minimal bounding hyper-sphere (N dimensions.) See his paper: http://people.inf.ethz.ch/gaertner/texts/own_work/seb.pdf.
His (C++/Java)code: https://github.com/hbf/miniball.
Jack Ritter
jack#houseofwords.com
I have two rings in 3 space each represented by a normal vector, center coordinate, and a radius.
How can I determine if the rings are linked. I.e. a point on one circle lies in the other disk.
This will be implemented in a tight loop so I am concerned about performance. I feel like there should be a closed form solution. So far I've only thought iterative solutions.
Any help?
Outline of the algorithm:
Handle the cases where the planes of the circles are parallel or concurrent.
Find the line of intersection of the planes of the circles.
Find the intersections of the circles with this line.
All the circle intersections with the line are on both planes. We can now do distance checks to see if the circles are linked.
Details:
I'll assume that the circles C1 and C2 are given by a center point (p1, p2), unit normal axis vector (n1, n2) and radii (r1, r2).
If n1 == k n2 for some scalar k, then the planes are parallel or concurrent. If they're concurrent this becomes the trivial 2d problem: check whether dist(p1, p2) < r1+r2.
Otherwise, the planes intersect at a line L. If the circles are linked, then they must both intersect L since linking implies that they mutually pass through each other's plane of definition. This gives you your first trivial rejection test.
L is given by a point q and a vector v. Finding v is easy: It's just the cross product of n1 and n2. q is a little trickier, but we can choose a point of nearest approach of the lines
l1(s) = p1 + s (v X n1)
l2(t) = p2 + t (v X n2)
These lines are perpendicular to v, n1 and n2, and are on the planes of C1 and C2. Their points of nearest approach must be on L.
You can refer to this post to see how to find the points of nearest approach.
Finally, the only way the circles can intersect is if they both have points on L. If they do, then consider the intersection points of C1 and L as they relate to C2. The circles are linked if there are two intersection points q11 and q12 of C1 and L and exactly one of them are inside of C2. Since L is on the plane of C2, this becomes a planar point-in-circle test:
IF dist(p1, q11) < r1 THEN
linked = (dist(p1, q12) > r1)
ELSE
linked = (dist(p1, q11) < r1)
ENDIF
Of course this pseudo-code is a little sloppy about handling the case that the circles actually intersect, but how that should be handled depends on your application.
A straightforward solution that is relatively easy to code: compute the line of intersection of the two planes and rotate and translate everything (in my case the six points defining the two circles) together so that the line becomes the Z axis (x=y=0). Then the planes can be rotated separately around Z so that the first circle, C1, lies on the XZ plane and C2 lies on the YZ plane. Now the centers and radii are easy to find (in my situation I don't initially have them). These rotations do not change the link/no link property and the link or lack of it can be easily determined from the order of the four intersections of the circles with the Z axis. (If either of the circles does not intersect x=y=0, there is no link.) (I may have confused the axes but I think this will work.)
Thank you.
Is this the 3D circle-disk intersection problem? Or, is it the circle-circle intersection problem?
If it's the former, there is a fast, closed form algorithm. First, weed out the circles-too-distant case: dist(CIR1.c, CIR2.c) > CIR1.r + CIR2.r
Handle the edge case: coplanar circles.
Extrude the disk into its plane, then intersect the circle with this plane. If there are 1 or 2 intersection points, test to see if they meet pointInDisk(p, CIR) logic. Report out any surviving intersection points.
A computational geometry textbook might have a good solution!
But I don't have a computation geometry textbook handy at the moment. If I were going to roll my own right now, based on my own (very limited) intuition, I think I'd start with 3d axis-aligned bounding boxes.
e.g., create an "just inside the circle" bounding box, as well as a "just outside the circle" bounding box. I believe it's trivial to figure out if two axis-aligned boxes overlap (section 2.1 of a homework assignment I once did talks about a related problem in the 2D situation --- finding the nearest rectangle to a point: http://juliusdavies.ca/uvic/report.html ).
I suspect the following assertions would hold (but I could be wrong):
If the inner-boxes overlap, then the rings are definitely connected. (I now think this is wrong...)
If the outer-boxes DO NOT overlap, then they are definitely not connected --- I am very confident this assertion holds! :-) :-)
If the outer-boxes overlap, but the inner-boxes do not, then they might be connected.
That's where I'd start, if I were rolling my own.
Conclusion: uhhh, I hope you have better luck with the other answers. :-)
Suppose you have an arbitrary closed curve (endpoint returns relatively close to first point) generated through a bunch of dataset coordinates, how do you find the centerpoint and the boundaries of the resulting shape?
There are two possible interpretations (perhaps more) for your question.
The first one was already addressed by #AakashM, and we may depict it in the following plot:
Where the red square is the "boundary".
I'll cite #AakashM here, because I understand his remark VERY important:"(I note that for you to have a closed curve, you need the endpoint to be not just 'close to', but coincident with the first point)"
As for the centerpoint, you have at least two "natural ways" for calculating it with this definitions:
Centerpoint = Middle Point of the Red Square
Centerpoint = { Mean of x coordinates of your curve, Mean of y coordinates of your curve}
Both of them may serve as a center point, but the results will be different.
The other way of dealing with the problem is finding the Convex Hull of your curve, as depicted below:
If you google for it, you will find algorithms for finding the Convex Hull, a nice introduction is here.
Again, you have two "natural ways for calculating the centerpoint:
Centerpoint = { Mean of x coordinates of your curve, Mean of y coordinates of your curve}
Centerpoint = { Mean of x coordinates of the CH points, Mean of y coordinates of the CH points}
HTH!
(I note that for you to have a closed curve, you need the endpoint to be not just 'close to', but coincident with the first point)
If by 'centerpoint' you mean center of mass, and you are assuming uniform density, then this question has what you want.
If by 'boundaries' you mean bounding rectangle with sides parallel to the axes, you just need the minimum and maximum x and y values on the curve.
If either of those aren't what you mean, please say...
For the boundaries, you can refer to the answers given by #belisarius and #AakashM.
As for centerpoint, you want "center of mass". Good 'ol Wikipedia has explanations and recipes at http://en.wikipedia.org/wiki/Center_of_mass and http://en.wikipedia.org/wiki/Centroid.
In general, you get a different result calculating the centroid than calculating the average of the vertices. This difference will be pronounced if the vertices are not uniformly distributed.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I have a Latitude, Longitude, and a direction of travel in degrees true north. I would like to calculate if I will intersect a line defined by two more Lat/Lon points.
I figure the two points defining the line would create my great circle and my location and azimuth would define my Rhumb line.
I am only interested in intersections that will occur with a few hundred kilometers so I do not need every possible solution.
I have no idea where to begin.
The simple answer is yes -- if you start from any lat/lon and continue traveling along some great circle, you will eventually cross any and all other great circles on the earth. Every two great circles on earth cross each other in exactly two points (with the notable exception of two identical great circles, which, well, cross each other in all their points.)
But I guess you are not merely asking a yes/no question. You may be wondering where, exactly, those two great circles intersect. We can use the following strategy to find that out:
Each great circle lies on a plane that goes through the center of the earth.
The intersection of those planes is a line (assuming they are not both the exact same plane.)
That intersecting line crosses the surface of the earth at two points -- exactly where our two great circles intersect.
Our mission is thus: (1) find the planes. (2) find their intersection line. (3) find the two intersection points, and finally, (4) express those intersection points in terms of lat/long. (5) extra credit for figuring out which intersecting point is closer to the lat/lon you started at.
Sounds good? The following does this with trig and vector math. To simplify the math somewhat, we'll:
work with the unit sphere, the one centered at the origin of our (x,y,z) coordinate system, and has a radius of 1: x^2+y^2+z^2=1.
we'll assume the earth is a perfect sphere. Not a geoid. Not even a flattened sphere.
we'll ignore elevation.
Step 1 -- find the planes:
All we really care about is the plane normals. Here's how we go and find them:
--One great circle is defined by two points on the earth that it crosses
The normal will be the cross product of the (x,y,z) vectors of each point from the origin (0,0,0). Given the lat/lon of each point, using spherical coordinates conversion, the corresponding (x,y,z) are:
x=cos(lat)*sin(lon)
y=cos(lat)*cos(lon)
z=sin(lat)
With that, and our two points given as lat1/lon1 and lat2/lon2, we can find out the vectors P1=(x1,y1,z1) and P2=(x2,y2,z2).
The first great circle normal is then the cross product:
N1=P1 x P2
--The other great circle is defined by a point on the earth and an azimuth
We have a point P3 and an azimuth T. We'll find a point P4 along the great circle going through P3 at azimuth T at a distance of PI/4 by using the spherical law of cosines (also solved for our convenience here):
lat4=asin(cos(lat3)*cos(T))
lon4=lon3+atan2(sin(T)*cos(lat3),-sin(lat3)*sin(lat4))
Then the normal is as before:
N2=P3 x P4
Step 2: find the planes intersecting line:
Given the two plane normals, their cross product defines their intersecting line:
L=N1 x N2
Step 3: find the intersection points:
Just normalize the vector L to get one of the intersection points on the unit sphere. The other point is on the opposite side of the sphere:
X1=L/|L|
X2=-X1
Step 4: express the intersection points in terms of lat/lon:
Given X=(x,y,z), using spherical coordinate conversion again, and taking into account the point is on the unit sphere:
lat=asin(z)
lon=atan2(y,x)
Step 5: which of the two points is closer?
Use the haversine formula to figure out the distance from your point to X1 and X2, choose the nearer one.
I think your best bet is to use stereographic projection to map the problem from the sphere to the plane. This projection is very useful in that it maps your rhumb line to a logarithmic spiral of form R=exp(θa) (aka a loxodrome) and maps your great circle to a circle on the plane. So your problem reduces to finding the intersection of a logarithmic spiral and a circle (after which you map back to the sphere).
This is just a sketch to get you started. If you need more details, just ask.