 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor Olav Kristensen <tor### [at] hotmail com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
