 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen <mca### [at] aol com> wrote:
> On 12/02/2013 8:22 PM, Christian Froeschlin wrote:
> > Stephen wrote:
> >
> >>> Since you are dealing with lines in 3-space (x,y,z), the lines will only
> >>> intersect if they lie on the same plane.
> >
> >> Can that be right?
> >
> > take two pens, and you will find you can easily hold them
> > so that they do not intersect, are not parallel, and with the
> > point of closest approach clearly within the physical pen
> > boundaries (and not just their projection to infinity).
> >
>
> Yes, that is true.
>
> >> What about the lines of the three axis?
> >
> > any two axes lie within a plane and intersect at the origin.
>
> And is the third axis, in 3D space, in the same plane as the plane of
> the first two axis?
>
>
> --
> Regards
> Stephen
The x & y axis intersect because they are both on the same plane (x-y plane with
z as the normal), similar for the y & z and x & z. So yes they are co-planar.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 12/02/2013 8:22 PM, Christian Froeschlin wrote:
>> Stephen wrote:
>>
>>>> Since you are dealing with lines in 3-space (x,y,z), the lines will
>>>> only
>>>> intersect if they lie on the same plane.
>>
>>> Can that be right?
>>
>> take two pens, and you will find you can easily hold them
>> so that they do not intersect, are not parallel, and with the
>> point of closest approach clearly within the physical pen
>> boundaries (and not just their projection to infinity).
>>
>
> Yes, that is true.
>
>>> What about the lines of the three axis?
>>
>> any two axes lie within a plane and intersect at the origin.
>
> And is the third axis, in 3D space, in the same plane as the plane of
> the first two axis?
>
>
The X and Y axis are coplanar, so are X and Z and Y and Z, it's just
that they don't share the same planes.
Any 2 lines that intersect are always coplanar, but any 3 or more
intersecting lines are not always coplanar relative to the same plane.
Each pair of lines can define different planes.
Next, any pair of parallel lines are also always coplanar.
Finaly, you have non-parallel lines that don't intersect.
The mention of using a very thin cylinder to represent one line and
using the trace function is interesting. A returned normal of <0,0,0>
indicating non-intersecting lines that MAY be parallel. Replacing the
target line by a plane WILL result in false positives in the case of
non-coplanar lines.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm puzzled totaly. Are you the same Holger Karsten who posted a windmill robot
flying around a backyard with Povray-renderings copyied in front of a real
video? Or are you an other person? If you are, you should be able to solve this
simple linear algebra issue. If you are not, you have a clone here.
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Catch the first line in a formula and then the second. Then some algebraic magic
you'll find the intersection no matter how many dimensions you're dealing with.
The clou is If formula1=formula2, you have the intersection.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Samuel Benge" <stb### [at] hotmailcom> wrote:
> scott <sco### [at] scottcom> wrote:
> > ...or do it numerically by using the trace function. You could define
> > one of the lines as a very thin cylinder, then do a trace from the start
> > point of the 2nd line towards its end point.
>
> Or for more accuracy, make one line a plane. Use VPerp_To_Vector or
> Point_At_Trans to align the plane along the line and translate it to one of its
> endpoints. Then use trace(). I do that every time I need to find a line
> intersection and it works perfectly. Also, using trace()'s fourth parameter
> helps make sure you get an intersection: if the ray hits nothing (the normal is
> <0, 0, 0>) then just reverse its direction.
I guess this assumes that the two lines DO lie on the same plane.
But wouldn't using trace() require essentially an infinite number of trace
points, so that trace doesn't 'miss' the intersection? Or is it an iterative
approach--i.e., when the returned trace point is 'close' to the target spot,
then trace is used again, but restricted to that smaller vicinity (and so on)? I
can see that working successfully, to a certain precision; but it doesn't seem
possible to find the *exact* point of intersection (without infinite trace
rays.) In a practical sense, though, an exact match might not be necessary.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> But wouldn't using trace() require essentially an infinite number of trace
> points, so that trace doesn't 'miss' the intersection?
Oops, it occurred to me that I was thinking about purely 'mathematical' lines
(and maybe incorrectly at that.) If the two lines (or even one) are replaced
with actual cylinders--just temporarily, as test objects--then a *single* trace
would work very well, using your scheme.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Samuel Benge" <stb### [at] hotmailcom> wrote:
>
> Or for more accuracy, make one line a plane. Use VPerp_To_Vector or
> Point_At_Trans to align the plane along the line and translate it to one of its
> endpoints. Then use trace().
It might be even easier, no V_Perp_To_Vector or Point_At_Trans needed : Let the
trace's initial 'position' (its "shoot-from" point) be the beginning point of
one line (call that the 1st line); then make a small-diameter cylinder for the
2nd line; then shoot a single trace ray toward the 1st line's end point (which
would be trace's "trace direction.") Voila! Trace will either hit the 2nd-line
cylinder and return its position, or it will not (and return <0,0,0> for the
normal--in which case, the two lines don't actually intersect.) The only
remaining detail is to add the cylinder's radius to the found point, for a
precise result. (Which will take some extra math, as the cylinder alignment will
most likely not be *perpendicular* to the trace ray; but using a *very
small*-diameter cylinder may make that computation unnecessary, from a practical
standpoint.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> It might be even easier...
This works; but I forgot to specifically mention that the 2nd 'line' (the
cylinder) is the object that's put into the trace() command, for it to work on;
perhaps that was obvious.
> ...but using a *very small*-diameter cylinder may make that computation
> unnecessary, from a practical standpoint.)
I've found that there's actually a limit to how small the radius can be. Trace()
has a problem working with an object below about six least-significant digits in
size. (Like, .000001) Seems to depend on the particular direction vector used.
Probably a result of ONE of trace's <x,y,z> computations dropping below a
certain precision 'threshold',
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It might be even easier, no V_Perp_To_Vector or Point_At_Trans needed : Let the
> trace's initial 'position' (its "shoot-from" point) be the beginning point of
> one line (call that the 1st line); then make a small-diameter cylinder for the
> 2nd line; then shoot a single trace ray toward the 1st line's end point (which
> would be trace's "trace direction.") Voila! Trace will either hit the 2nd-line
> cylinder and return its position, or it will not (and return <0,0,0> for the
> normal--in which case, the two lines don't actually intersect.)
That's exactly what I suggested in my post :-) Sorry if it wasn't clear.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scottcom> wrote:
>
> That's exactly what I suggested in my post :-) Sorry if it wasn't clear.
Sorry; I was concentrating on Sam's post, and my mind went blank on everything
else :-/
But unfortunately (maybe for both of us), the 'simpler' method, as I called it,
doesn't work. Actually, it *did* work in my initial test, but I didn't pay close
enough attention to what I was seeing.
I now realize what the problem is (and I should have remembered it, as it's
fooled me in the past): Trace's 'direction' vector is solely a *direction*; it
doesn't actually correspond to any particular point in space--like the end of
'line 1' in my example. It never changes. So by using this scheme and, for
example, varying trace's 'shoot-from' point but NOT its 'direction', the
direction it shoots in always remains 'parallel to itself', if that makes any
sense. Like your hand with a stiff finger pointing out, while moving the hand up
and down. So trace *might* hit the test cylinder--but that's an extremely
special case; and trace's returned result may not even correspond to the lines'
true intersection point (as I found out.)
So it seems that Sam's method is *definitely* the better one. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
