Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> Solve slope (m):
>      m1 = (y12-y11)/(x12-x11)

Note that there's a formula that does not cause any division by zero
because of the lines being vertical.

-- 
                                                          - Warp

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.
>
>
>
>

A single trace call should be enough in most cases, at most two.
You call the trace from a point along one of the lines toward another 
point on that same line. You replace the second line by a thin cylinder.

Post a reply to this message

That all very cool folks :)

Yesterday I did a cheat-version:

//###########################################
camera {
location  <0,0,-4>*5
direction 1.5*z
right     x*image_width/image_height
look_at   0
}

light_source{<-1,1,-1>*30 color rgb 1}
default{pigment{color rgb 1}}

#declare P1=vrotate(<2,3,0>,z*clock*360);
#declare P2=vrotate(<6,-4,0>,z*clock*360);
#declare P3=vrotate(<5,5,0>,z*clock*360);
#declare P4=vrotate(<-2,-6,0>,z*clock*360);

#declare T=16;
cylinder{P1,P2,1/T}
cylinder{P3,P4,1/T}
cylinder{x*-10,x*10,1/T}
cylinder{y*-10,y*10,1/T}

#macro Intersect(P1,P2,P3,P4)
#local TO=cylinder{P1,P2,1/999999}
trace(TO,P3,P4-P3)
#end

sphere{Intersect(P1,P2,P3,P4),1/8}
torus{.8,1/32 rotate x*90 translate Intersect(P1,P2,P3,P4)}
//###########################################


All right that doesn't count - but it works ;)
Holger

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > I now realize what the problem is...
>
> Sorry it doesn't make sense to me.
>

It *is* a bit of a brain-twister, I admit.

The situation is probably best illustrated by a simple test scene.  (It took a
test *animation* for me to clearly see it; but here it's just a static scene.)
And I've arranged things in an even simpler way than might occur normallly, for
clarity: the two lines (which naturally have to be on the same plane for an
intersection to even occur, statistically speaking) are both on the vertical
plane running through the origin, -x to +x.

While *special* values can be chosen for both lines' end points to produce
a trace that looks like a perfect 'hit' at the intersection, it's not really
so.

The wild card is trace's shoot-from point (which represents any arbitrary
beginning point of the non-target line.) If that value is anything other than a
'special case', the found point (the traced point) doesn't coincide with the
true intersection. That's because of the unchanging nature of trace's
'direction' vector. (BTW, trace 'normalizes' that vector, I think.)

The RED cylinder is the target line; ORANGE is the other line (where trace
starts, and with the unchanging end point used as trace's 'direction');
GREEN is the *actual* trace direction--which almost never coincides with the
orange line.

Plug in different values for the orange line's y ('trace_shoot_from') to see
what happens; this represents any naturally arbitrary value for that line's
start point. You might also see the 'parallel' concept I mentioned (more easily
seen with an orthgraphic camera placed in -z).

The real key to understanding all this is that trace's 'direction' vector
doesn't automatically/dynamically change to always point at a particular
location in space.

------
global_settings {assumed_gamma 2.2}

camera {
  perspective
  location  <-4, 8, -20>
  look_at   <8, 0,  0>
  right     x*image_width/image_height
  angle 67
}

light_source {
  <0, 0, 0>
  color rgb <1, 1, 1>
  translate <-30, 30, -30>
}

light_source {
  <0, 0, 0>
  color rgb <1, 1, 1>
  translate <30, 30, -30>
}

background{rgb .7}

plane{y,0 pigment{rgbt <.8,.9,1,.3>}}

// ----------------------------------------
// RED--The 'target' line
#declare target_line_start_point = <5,-12,0>;
#declare target_line_end_point = <9,10,0>;

// ORANGE--the other line. These are the start and end points, which
// are also used in trace().
#declare trace_shoot_from = <-2,9,0>;
#declare trace_direction = <18,-8,0>; // i.e., the line end point

#declare norm = <0,0,0>;

#declare target_object =
cylinder{target_line_start_point,target_line_end_point, .2}

#declare found_position =
trace(target_object,trace_shoot_from,trace_direction,norm);

// A sphere to indicate the found position. (If this ends up AT the
// origin, then the trace ray has totally missed the target line.)
#if(vlength(norm) !=0)
sphere{0,.35
no_shadow
pigment{rgb 1*<.3,1,1>}
translate found_position
}
#else
#end

// RED--the 'target' cylinder
object{target_object
no_shadow
pigment{rgb 1*<1,.3,.3>}
}

// ORANGE--The other line--which might be imagined to be the trace
// ray direction, but is not.
cylinder{trace_shoot_from,trace_direction, .1
no_shadow
pigment{rgb 1*<1,.7,0>}
}

// GREEN--this CORRECTLY illustrates the trace ray direction...
cylinder{trace_shoot_from,found_position, .1
no_shadow
pigment{rgb 1.2*<.3,1,0>}
}

// the origin axes
union{
// X axis
cylinder{-40*x,40*x,.05}
// Y axis
cylinder{0,3*y,.05}
// Z axis
cylinder{-5*z,5*z,.05}
 no_shadow
 pigment{rgb .3}
}

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Samuel Benge" <stb### [at] hotmailcom> wrote:
> > Or for more accuracy, make one line a plane.
>
> I guess this assumes that the two lines DO lie on the same plane.

Haha, yeah. Usually when I need to find a line-line intersection, my lines
aren't all wild and going whatever-which-way; they are already laying along the
same plane.

Sorry if that sent you off on a tangent!

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> While *special* values can be chosen for both lines' end points to produce
> a trace that looks like a perfect 'hit' at the intersection, it's not really
> so.

Sorry, that didn't clearly express what I meant.  Reworded:

"While particular values CAN be chosen for both lines' start/end points to
produce a trace that *looks like* a perfect hit at the intersection, the result
is most likely not very accurate."

Also...

>
> // A sphere to indicate the found position. (If this ends up AT the
> // origin, then the trace ray has totally missed the target line.)
> #if(vlength(norm) !=0)
> sphere{0,.35
> no_shadow
> pigment{rgb 1*<.3,1,1>}
> translate found_position
> }
> #else
> #end
>

It's probably better to leave out the #if/#else/#end; then a trace ray that
misses the target will actually SHOW the sphere at the origin.

Post a reply to this message

"Samuel Benge" <stb### [at] hotmailcom> wrote:

>
> Sorry if that sent you off on a tangent!

Funny! ;-)

Post a reply to this message

> // ORANGE--the other line. These are the start and end points, which
> // are also used in trace().
> #declare trace_shoot_from = <-2,9,0>;
> #declare trace_direction = <18,-8,0>; // i.e., the line end point

?? The above line really confused me, the trace direction is not the 
line end point. The trace direction is the difference between the start 
and end point (and possibly normalized too to make it clear it's a 
direction).

> // ORANGE--The other line--which might be imagined to be the trace
> // ray direction, but is not.
> cylinder{trace_shoot_from,trace_direction, .1
> no_shadow
> pigment{rgb 1*<1,.7,0>}
> }

You shouldn't be using a direction vector as a parameter for the 
cylinder primitive...

Much clearer to write it like this:

#declare trace_shoot_from = <-2,9,0>; // line start point
#declare trace_shoot_to = <18,-8,0>; // i.e., the line end point
#declare trace_shoot_direction = vnormalize(trace_shoot_to - 
trace_shoot_from);
...
trace(target_object,trace_shoot_from,trace_direction,norm);
...
cylinder{trace_shoot_from,trace_shoot_to, .1}

Post a reply to this message

scott <sco### [at] scottcom> wrote:

>
> You shouldn't be using a direction vector as a parameter for the
> cylinder primitive...
>
> Much clearer to write it like this:
>
> #declare trace_shoot_from = <-2,9,0>; // line start point
> #declare trace_shoot_to = <18,-8,0>; // i.e., the line end point
> #declare trace_shoot_direction = vnormalize(trace_shoot_to -
> trace_shoot_from);
> ...
> trace(target_object,trace_shoot_from,trace_direction,norm);
> ...
> cylinder{trace_shoot_from,trace_shoot_to, .1}

Hmm, that DOES work...and always hits the correct two-line intersection. Nicely
done! To re-word my own phrase, and using your idea, "...trace's 'direction'
vector CAN dynamically change to always point at a particular location in
space." The general idea, although probably not the right words.

In looking at your code, it occurred to me that I've actually used this very
thing in the past; don't know how I could have forgotten it so easily. Maybe
because useful code snippets/ideas can get 'lost' when not used on a regular
basis. My excuse, anyway...  :-/

This results in my orange and green cylinders being like so..
// ORANGE--
cylinder{trace_shoot_from,trace_shoot_to, .1}

// GREEN--
cylinder{trace_shoot_from,trace_shoot_to, .1}

Identical!--which at first I thought couldn't be right. But yes, it's correct.

BTW, looking back at our posts here shows me that I misunderstood one of your
suggestions...

> Define a cylinder between points A and B with a small radius.
> Use the trace command to trace from point C in direction (D-C) ... etc.

I mistook that for a shorthand way of simply saying "D *TO* C" rather than "D
MINUS C".

Sorry for the bit of confusion--and thanks for clarifying it with the fix.

Post a reply to this message

> Hmm, that DOES work...and always hits the correct two-line intersection. Nicely
> done! To re-word my own phrase, and using your idea, "...trace's 'direction'
> vector CAN dynamically change to always point at a particular location in
> space." The general idea, although probably not the right words.

The direction vector that trace needs is purely a direction, like a 
heading in geography (eg north-east or 45 degrees) - it doesn't contain 
any information about location in the scene. Trace will then start at 
the "start position" you specify and fire a ray in the direction you 
specify.

If you want the ray to pass through a certain point then you can 
calculate the direction like I did, by taking the difference between the 
point you want it to pass through and the start point.

> In looking at your code, it occurred to me that I've actually used this very
> thing in the past; don't know how I could have forgotten it so easily. Maybe
> because useful code snippets/ideas can get 'lost' when not used on a regular
> basis. My excuse, anyway...  :-/

Perfectly valid excuse :-) Most of my scenes involve plenty of 
copying&pasting from previous scenes, it's much faster than trying to 
look up how to use certain features again (this is where an IDE like the 
one Mike Raiford was developing would be really helpful).

> BTW, looking back at our posts here shows me that I misunderstood one of your
> suggestions...
>
>> Define a cylinder between points A and B with a small radius.
>> Use the trace command to trace from point C in direction (D-C) ... etc.
>
> I mistook that for a shorthand way of simply saying "D *TO* C" rather than "D
> MINUS C".

OK yes that would get things backwards - sorry for the confusion! 
Nothing beats posting actual code :-)

Post a reply to this message