 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
How would I go about finding a point on a ray the is equa-distant from to
other points?
--
Kevin
http://www.geocities.com/qsquared_1999/
#macro _(r)#if(r<12)#local i=asc(substr("oqshil
acefg",r,1))-97;disc{<mod(i,7)-3,div(i,7)-1,6>,z,.4
pigment{rgb 10}}_(r+1)#end#end _(1)//KL
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e18ef67@news.povray.org>, "Kevin Loney" <klo### [at] pt2m com>
wrote:
> How would I go about finding a point on a ray the is equa-distant from to
> other points?
Your message is a little garbled. You want to find a point on a ray, the
point being equidistant to two other points? This is not always
possible, not without having the point shoot off to infinity.
The point will be in a plane perpendicular to a line between the two
known points and passing through the midpoint. You can easily calculate
this plane and find the intersection of the ray with it (with trace() or
by using the plane equation), but as I mentioned, with a line it can go
off to infinity, and with a ray there is sometimes no solution.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Program ended abnormally on 1/5/03 9:50 PM, Due to a catastrophic Kevin
Loney error:
> How would I go about finding a point on a ray the is equa-distant from to
> other points?
If you have two points,
Pa = < Xa, Ya, Za >
Pb = < Xb, Yb, Zb >
then the point (M) that is in the middle will be:
M = < (Xa+Xb)/2, (Ya+Yb)/2, (Za+Zb)/2 >
Of course, in POV, you can simply use:
M = (Pa+Pb)/2
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* videotron.ca */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'll post a diagram in p.b.i in a minute it should give you a better idea of
what I'm trying to find
--
Kevin
http://www.geocities.com/qsquared_1999/
#macro _(r)#if(r<12)#local i=asc(substr("oqshil
acefg",r,1))-97;disc{<mod(i,7)-3,div(i,7)-1,6>,z,.4
pigment{rgb 10}}_(r+1)#end#end _(1)//KL
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <cja### [at] netplexaussieorg>,
Christopher James Huff <cja### [at] earthlinknet> wrote:
> The point will be in a plane perpendicular to a line between the two
> known points and passing through the midpoint. You can easily calculate
> this plane and find the intersection of the ray with it (with trace() or
> by using the plane equation), but as I mentioned, with a line it can go
> off to infinity, and with a ray there is sometimes no solution.
#macro CompPoint(pA, pB, rayStart, rayDir)
// 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. You'll need to fill in the blank.
#end
Untested, I may have made an error, or trace() might be a better idea,
it would certainly be simpler.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois Labreque <fla### [at] videotronca> wrote:
> M = (Pa+Pb)/2
Just for the sake of curiosity: This is also called average. :)
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
that solved my problem quite nicely
thank you
--
Kevin
http://www.geocities.com/qsquared_1999/
#macro _(r)#if(r<12)#local i=asc(substr("oqshil
acefg",r,1))-97;disc{<mod(i,7)-3,div(i,7)-1,6>,z,.4
pigment{rgb 10}}_(r+1)#end#end _(1)//KL
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>In article <cja### [at] netplexaussieorg>,
> Christopher James Huff <cja### [at] earthlinknet> wrote:
>
>> The point will be in a plane perpendicular to a line between the two
>> known points and passing through the midpoint. You can easily calculate
>> this plane and find the intersection of the ray with it (with trace() or
>> by using the plane equation), but as I mentioned, with a line it can go
>> off to infinity, and with a ray there is sometimes no solution.
>
>#macro CompPoint(pA, pB, rayStart, rayDir)
>// 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. You'll need to fill in the blank.
>#end
>
>Untested, I may have made an error, or trace() might be a better idea,
>it would certainly be simpler.
I think this line;
#local lRayStart = rayStart - midPt;
- should have been:
#local lRayStart = midPt - rayStart;
And there should be no need to normalize
the normal vector.
Here's how I would have written that macro:
#macro CompPoint(pA, pB, pRayStart, vRayDir)
#local pMid = (pA + pB)/2;
#local vNorm = pB - pA;
#local T =
vdot(pMid - pRayStart, vNorm)/vdot(vRayDir, vNorm);
(pRayStart + T*vRayDir)
#end // CompPoint
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
But I have not tested my code either,
so I too could be wrong.
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>Francois Labreque <fla### [at] videotronca> wrote:
>> M = (Pa+Pb)/2
>
> Just for the sake of curiosity: This is also called average. :)
Warp, I'm a little curious too:
Can you explain how it makes sense to
calculate the average of two points ?
;)
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
....
>#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
>-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
What happened to the end ?
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor Olav Kristensen <tor### [at] hotmailcom> wrote:
>>> M = (Pa+Pb)/2
>>
>> Just for the sake of curiosity: This is also called average. :)
> Warp, I'm a little curious too:
> Can you explain how it makes sense to
> calculate the average of two points ?
It makes perfect sense: The average of two numbers is the number which is
exactly in the middle of them. In the same way the average of two points is
the point which is exactly in the middle of them.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor Olav Kristensen <tor### [at] hotmailcom> wrote:
> Warp wrote:
> ....
>>#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
>>-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
> What happened to the end ?
There's nothing wrong about my sig in my original post. It must be something
with your newsreader. (My sig is 3 lines long.)
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>Tor Olav Kristensen <tor### [at] hotmailcom> wrote:
>> Warp wrote:
>> ....
>>>#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
>>>-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
>
>> What happened to the end ?
>
> There's nothing wrong about my sig in my original post. It must be something
>with your newsreader. (My sig is 3 lines long.)
>
>#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
>-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
>
I did not use a newsreader. I used the web-interface.
Please have a look here:
http://news.povray.org/povray.advanced-users/29649/210678/
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3e1905318bb9cc14b417814a0@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.
> 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.
> Here's how I would have written that macro:
Well, remember that I was writing it to both fit in the message and more
to explain something than to be used.
> 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
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...)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor Olav Kristensen <tor### [at] hotmailcom> wrote:
> I did not use a newsreader. I used the web-interface.
Thorsten will hear about this... :)
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in news:3e19873f@news.povray.org:
> Tor Olav Kristensen <tor### [at] hotmailcom> wrote:
>>>> M = (Pa+Pb)/2
>>>
>>> Just for the sake of curiosity: This is also called average. :)
>
>> Warp, I'm a little curious too:
>> Can you explain how it makes sense to
>> calculate the average of two points ?
>
> It makes perfect sense: The average of two numbers is the number
> which is
> exactly in the middle of them. In the same way the average of two
> points is the point which is exactly in the middle of them.
http://www.flipcode.com/geometry/issue08.shtml
http://www.flipcode.com/geometry/issue09.shtml
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
