





 
 




 
 


Ref:
http://news.povray.org/povray.general/thread/%3C609d7f7f%241%40news.povray.org%3E/
Web Message: 609a4569$1@news.povray.org
As part of the effort referenced, added a new inbuilt functions called
f_vangle(). A first pass of the help text follows.

Returns angle of rotation between two vectors. Function mimics the
traditional VAngle macro shipped with POVRay in two ways. The angle is
returned in radians. Wrap with degree() for answer in degrees.
The first an implementation of the acos of the dot product  with 1 to
1 clamping of the dot product  which is the traditional one.
Tor Olav Kristensen suggested a more accurate method to the povray
general news group on May 06, 2021 which is the second method. In
isolation it's obviously slower  sometimes significantly so  (3040%)
over the traditional acos based method. However, in the blur of branch
predictions supporting both methods and modern CPU speculative execution
the form as implemented herein is often the fastest. When slower it's
not that much slower in the context of typical parser time use.
In targeted random vector experimentation the dot product was found to
return max and min values of +1.00000000000000067 and
1.00000000000000067, respectively. Meaning with the traditional method
the 1..1 clipping is absolutely necessary to avoid acos domain errors.
Method 0. By targeted random vector experimentation the traditional
method provides for 7 digits of accuracy on when very near a zero angle
or very near pi. In practice, with vectors not near coincident, or near
exactly opposing the accuracy is much better.
Method 1. By targeted random vector experimentation the traditional
method provides for 12 significant digits of accuracy near 0.0 or pi in
angle. It often provides a few more digits.
The largest differences seen between the two methods, over tens of
millions of random vector pairs, was always less than 1e7.
Using this inbuilt function directly is up to 2.5 times faster no matter
the mode than using the macro VAngle. The macro may be more convenient
in that vectors can be passed directly.
Parameters:
1. First vector x value.
2. First vector y value.
3. First vector z value.
4. Second vector x value.
5. Second vector y value.
6. Second vector z value.
7. Method to use. If 0.0, the traditional acos(dot(v1,v2)) method is
used. If 1.0, Tor Olav's suggested method is used.

In math.inc now have:
#macro VAngle(V1, V2) f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1) #end
#macro VAngleD(V1, V2)
degrees(f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1))
#end
#macro VRotation(V1, V2, Axis)
(f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1)
*(vdot(Axis,vcross(V1,V2))<0?1:1))
#end
#macro VRotationD(V1, V2, Axis)
(degrees(f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1))
*(vdot(Axis,vcross(V1,V2))<0?1:1))
#end
Bill P.
Post a reply to this message


 
 




 
 


William F Pokorny <ano### [at] anonymousorg> wrote:
> Ref:
>
> http://news.povray.org/povray.general/thread/%3C609d7f7f%241%40news.povray.org%3E/
>
> Web Message: 609a4569$1@news.povray.org
>
> As part of the effort referenced, added a new inbuilt functions called
> f_vangle(). A first pass of the help text follows.
>
> 
> Returns angle of rotation between two vectors. Function mimics the
> traditional VAngle macro shipped with POVRay in two ways. The angle is
> returned in radians. Wrap with degree() for answer in degrees.
>
> The first an implementation of the acos of the dot product  with 1 to
> 1 clamping of the dot product  which is the traditional one.
>
> Tor Olav Kristensen suggested a more accurate method to the povray
> general news group on May 06, 2021 which is the second method. In
> isolation it's obviously slower  sometimes significantly so  (3040%)
> over the traditional acos based method. However, in the blur of branch
> predictions supporting both methods and modern CPU speculative execution
> the form as implemented herein is often the fastest. When slower it's
> not that much slower in the context of typical parser time use.
>
> In targeted random vector experimentation the dot product was found to
> return max and min values of +1.00000000000000067 and
> 1.00000000000000067, respectively. Meaning with the traditional method
> the 1..1 clipping is absolutely necessary to avoid acos domain errors.
>
> Method 0. By targeted random vector experimentation the traditional
> method provides for 7 digits of accuracy on when very near a zero angle
> or very near pi. In practice, with vectors not near coincident, or near
> exactly opposing the accuracy is much better.
>
> Method 1. By targeted random vector experimentation the traditional
> method provides for 12 significant digits of accuracy near 0.0 or pi in
> angle. It often provides a few more digits.
>
> The largest differences seen between the two methods, over tens of
> millions of random vector pairs, was always less than 1e7.
>
> Using this inbuilt function directly is up to 2.5 times faster no matter
> the mode than using the macro VAngle. The macro may be more convenient
> in that vectors can be passed directly.
>
> Parameters:
>
> 1. First vector x value.
>
> 2. First vector y value.
>
> 3. First vector z value.
>
> 4. Second vector x value.
>
> 5. Second vector y value.
>
> 6. Second vector z value.
>
> 7. Method to use. If 0.0, the traditional acos(dot(v1,v2)) method is
> used. If 1.0, Tor Olav's suggested method is used.
>
> 
> In math.inc now have:
>
> #macro VAngle(V1, V2) f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1) #end
>
> #macro VAngleD(V1, V2)
> degrees(f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1))
> #end
>
> #macro VRotation(V1, V2, Axis)
> (f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1)
> *(vdot(Axis,vcross(V1,V2))<0?1:1))
> #end
>
> #macro VRotationD(V1, V2, Axis)
> (degrees(f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1))
> *(vdot(Axis,vcross(V1,V2))<0?1:1))
> #end
Nice work Bill!
It's good to be able to choose which formula to use for the angle calculation.
But I'm struggling to see the usefulness of the VRotation() and VRotation()
macros. I can not remember that I ever had the need to do the exact calculations
they do. And if one understand the intricate explanation for how to use them,
one is likely to do fine without them. Also there's to much work preparing for
them.
Perhaps someone can post code for a case where one of them is really useful ?

Tor Olav
http://subcube.com
https://github.com/tok
Post a reply to this message


 
 




 
 


William F Pokorny <ano### [at] anonymousorg> wrote:
>...
> Method 0. By targeted random vector experimentation the traditional
> method provides for 7 digits of accuracy on when very near a zero angle
> or very near pi. In practice, with vectors not near coincident, or near
> exactly opposing the accuracy is much better.
>
> Method 1. By targeted random vector experimentation the traditional
> method provides for 12 significant digits of accuracy near 0.0 or pi in
> angle. It often provides a few more digits.
>...
Method 1:
You mention the traditional method also here. Did you mean the new method ?

Tor Olav
http://subcube.com
https://github.com/tok
Post a reply to this message


 
 


From: William F Pokorny
Subject: Re: New f_vangle inbuilt with povr branch.
Date: 14 May 2021 06:22:24
Message: <609e4f60$1@news.povray.org>



 
 


On 5/13/21 11:24 PM, Tor Olav Kristensen wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
>
> Nice work Bill!
>
Thanks. Today I'll be working through several git commits including this
work.
> It's good to be able to choose which formula to use for the angle calculation.
>
> But I'm struggling to see the usefulness of the VRotation() and VRotation()
> macros. I can not remember that I ever had the need to do the exact calculations
> they do. And if one understand the intricate explanation for how to use them,
> one is likely to do fine without them. Also there's to much work preparing for
> them.
>
> Perhaps someone can post code for a case where one of them is really useful ?
VRotation is used in Rune S. Johansen's Spline_Trans from
transforms.inc. I see that as the immediately significant one.

Searching through my archives turned up a couple more.
 Tim Atwood put out a spline_tools.inc  which looks quite similar to
Rune's code.
 Michael Andrews published a convhull.in which uses it.
All make use of VProject_Plane for the arguments. As to whether the
VRotation use was strictly needed...
I didn't turn up any use of VRotationD.
Bill P.
Post a reply to this message


 
 


From: William F Pokorny
Subject: Re: New f_vangle inbuilt with povr branch.
Date: 14 May 2021 06:24:21
Message: <609e4fd5$1@news.povray.org>



 
 


On 5/14/21 4:50 AM, Tor Olav Kristensen wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> Method 0. By targeted random vector experimentation the traditional
>> method provides for 7 digits of accuracy on when very near a zero angle
>> or very near pi. In practice, with vectors not near coincident, or near
>> exactly opposing the accuracy is much better.
>>
>> Method 1. By targeted random vector experimentation the traditional
>> method provides for 12 significant digits of accuracy near 0.0 or pi in
>> angle. It often provides a few more digits.
>> ...
>
> Method 1:
> You mention the traditional method also here. Did you mean the new method ?
>
Ah, thank you! Extra points for letting me know ahead of the commit of
my mistake. :)
Bill P.
Post a reply to this message


 
 




 
 


William F Pokorny <ano### [at] anonymousorg> wrote:
>  Michael Andrews published a convhull.in which uses it.
I would like to take a look at that  can't seem to find where it was published.
Thanks :)
Post a reply to this message


 
 


From: William F Pokorny
Subject: Re: New f_vangle inbuilt with povr branch.
Date: 14 May 2021 07:15:24
Message: <609e5bcc$1@news.povray.org>



 
 


On 5/14/21 6:39 AM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
>>  Michael Andrews published a convhull.in which uses it.
>
> I would like to take a look at that  can't seem to find where it was published.
>

There was a povray.binaries.images thread:
http://news.povray.org/povray.binaries.images/thread/%3C3e459994%40news.povray.org%3E
Web Message 3e459994@news.povray.org

Looks like maybe the files came from:
http://news.povray.org/povray.binaries.scenefiles/thread/%3C3e459b0a%40news.povray.org%3E/
Web Message: web.44cabb94759cbd10546ee4f70@news.povray.org
but the file links look messed up there. Let me see if I can still post
to that thread from Thunderbird. Nope. Apparently fell off the end...
I'll post a tarball of the files also to povray.binaries.scenefiles to
be consistent.
Bill P.
Post a reply to this message


 
 




 

