Christopher James Huff wrote:
>In article <web.3e1905318bb9cc14b417814a0[at]news.povray.org>,
> "Tor Olav Kristensen" <tor### [at] hotmailcom> wrote:
>
>> I think this line;
>> #local lRayStart = rayStart - midPt;
>>
>> - should have been:
>> #local lRayStart = midPt - rayStart;
>
>No, I don't think so. That code is transforming the ray by the inverse
>of a transformation that would translate the plane to its position. This
>is simply a subtraction from the ray origin.

Are you sure ?
Try this code and have a look at
the output. Then try my suggestion.

#macro CompPoint(pA, pB, rayStart, rayDir)
  #local midPt = (pA + pB)/2;
  #local Norm = vnormalize(pB - pA);
  #local lRayStart = rayStart - midPt;
  #local T = (vdot(Norm, lRayStart)/vdot(Norm, rayDir));
  (rayStart + rayDir*T)
#end

#declare p0 = <1, 3, 2>;
#declare p1 = <0, -4, -1>;
#declare pR = <5, 2, -3>;
#declare vR = -<0, 1, 1>/2;
#declare pH = CompPoint(p0, p1, pR, vR);
#debug "\n"
#debug str(vlength(pH - p0), 0, -1)
#debug "\n"
#debug str(vlength(pH - p1), 0, -1)
#debug "\n"


>> And there should be no need to normalize the normal vector.
>
>There is. If the normal is twice as long, the intersection will be found
>twice as far away. This could be with the exact same plane, and is
>obviously wrong.

Again: Are you sure ?

Try my macro with the 10 last lines
above and look at the results.


>> And here's how I would test the ray:
>>
>> #declare pHit = CompPoint(p0, p1, pRay, vRay);
>>
>> #if (vdot(pHit - pRay, vRay) < 0)
>>   #debug "There is no point on the ray that has"
>>   #debug "equal distances to both points."
>> #end
>
>Needlessly complex, but it would work. Here's what I'd use (still highly
>simplified and spread out, though):
>
>#macro CompPoint(pA, pB, rayStart, rayDir, Res)
>// The midpoint and plane normal.
>    #local midPt = (pA + pB)/2;
>    #local Norm = vnormalize(pB - pA);
>
>// Compensate for the plane not passing through the origin.
>    #local lRayStart = rayStart - midPt;
>
>// Solve for intersection distance with line.
>    #local T = (vdot(Norm, lRayStart)/vdot(Norm, rayDir))
>
>// If T is > 0, there is a ray intersection at rayStart + rayDir*T.
>// Otherwise, no intersection.
>    #local isectFound = T > 0;
>    #if(isectFound)
>        #declare Res = rayStart + rayDir*T;
>    #end
>
>    (isectFound)
>#end
>
>#declare hitPoint = < 0, 0, 0>;
>#if(CompPoint(pA, pB, rayStart, rayDir, hitPoint))
>    ...
>#end

Yes, I considered something like
that, but I always try to avoid
making macros like that.

So I'm willing to even sacrifice a
little efficiency in order to do so.

I have found that in many cases it
can be rewarding to check first if
the macro needs to be called at all.

And such "cheap" checks can often
regain some or all of the lost
efficiency caused be the macro.


>Just for fun, a possible over-verbose Sapphire version:
>method ComputePoint: result EquidistantTo: pA And: pB AlongRay: ray {
>    def midPt: (pA + pB)/2;
>    def norm: (pB - pA).(Normalize);
>    def t: norm.(Dot: ray.origin - midPt)/norm.(Dot: ray.direction);
>    if(t > 0) {
>        result = ray.(Evaluate: t);
>        return true;
>    }
>    else {
>        return false;
>    }
>}
>
>def pt: Vector.(Clone);
>if(.(ComputePoint: pt EquidistantTo: pA And: pB AlongRay:
>Ray.(RayWithOrigin: orig Direction: dir)))
>    ...
>
>(I wouldn't seriously use "ComputePoint:EquidistantTo:And:AlongRay:",
>though...just self-documentation to an extreme. Some Objective-C method
>names get even longer, though...)

I have looked at your Sapphire code
above. And have become very confused
by this part:

def t: norm.(Dot: ray.origin - midPt)/norm.(Dot: ray.direction);

Can you explain how that is to be
interpreted ?


Tor Olav

Post a reply to this message