In article <web.3e19c1f28bb9cc14b417814a0@news.povray.org>,
 "Tor Olav Kristensen" <tor### [at] hotmailcom> wrote:


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

I figured it out...I forgot a small part of the equation, just one 
character:
#local T = -vdot(Norm, lRayStart)/vdot(Norm, rayDir);
My tracer uses:
    double t = (distance - 
direction.Dot(ray.origin))/direction.Dot(ray.direction);
But Dist is 0 here, so I left it out, and accidentally omitted the '-' 
too. Your version actually does the same thing, but swaps the signs 
further up, doing something conceptually wrong from the way I was 
looking at it, but mathematically correct. I was mentally solving the 
complete equation, never noticing the missing sign.


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

You are right, I was thinking of something else, something which was 
removed from this equation.


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

Why?


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

I don't understand...your method does all the same work mine does, and 
then some more. Your macro is less efficient, and your check is less 
efficient. No part of it regains any efficiency. Though it would be 
possible to check, your method needs to call the macro in order to do 
the check, by which time my method has already done it.


> def t: norm.(Dot: ray.origin - midPt)/norm.(Dot: ray.direction);
> 
> Can you explain how that is to be
> interpreted ?

Vectors have a Dot method ("member function", if you know C++ or Java) 
that takes another vector and returns the dot product.
norm.(Dot: ray.direction)
is the dot product of "norm" and the member "direction" of the "ray" 
object. The result is given the identifier "t".

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message