this is most probably the fastest algorithm that doesn't require precomputed data. Other ways exist that use some precomputations to speedup things. If your're going to use it for real time (and you have a lot of intersections) then perhaps you may want to give a look to those algos (Jacco Bikker implemented one of them in his series of tutorial about raytracing. You can give a look to www.realtimerendering.com geometric intersection reference.

Quote:Original post by gohkgohk

Quote:Original post by cignox1
this is most probably the fastest algorithm that doesn't require precomputed data. Other ways exist that use some precomputations to speedup things. If your're going to use it for real time (and you have a lot of intersections) then perhaps you may want to give a look to those algos (Jacco Bikker implemented one of them in his series of tutorial about raytracing. You can give a look to www.realtimerendering.com geometric intersection reference.

does this method consider the line which has defined start point and end point?
thx

Rays are usually defined as a point (origin) and as a normalized vector (direction). These algorithms usually suppose the ray to be defined this way, but you can convert from one representation to another without troubles:

if your segment has two points START and END then you use this (pseudocode):

ray.origin = START;
ray.direction = END - START;
normalize(ray.direction);

Actually, you may encounter a few problems:
-if you want your ray to be of finite lenght, you must have another variable with the lenght (in your case ray.length = LENGTH(END - START); )
-Normalization requires a sqrt(): the less sqrt you have the better. Usually you need to normalize it anyway tough, so perhaps is not really a problem.

I suggest to use the parametric representation, I've seen it in every raytracer that I know: you always need the direction (i.e. for shading) so it is better to have it ready to use instead than calculating it everytime (sqrt() ghost :-)

Hope this helps