POV-Ray : Newsgroups : povray.unofficial.patches : New f_vangle inbuilt with povr branch. Server Time16 Sep 2024 06:17:40 EDT (-0400)
 New f_vangle inbuilt with povr branch. (Message 1 to 7 of 7)
 From: William F Pokorny Subject: New f_vangle inbuilt with povr branch. Date: 13 May 2021 16:09:35 Message: <609d877f\$1@news.povray.org>
Ref:

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 POV-Ray in two ways.  The angle is

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 - (30-40%)
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 1e-7.

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.
 From: Tor Olav Kristensen Subject: Re: New f_vangle inbuilt with povr branch. Date: 13 May 2021 23:25:00 Message:
William F Pokorny <ano### [at] anonymousorg> wrote:
> Ref:
>
>
> 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 POV-Ray in two ways.  The angle is
>
> 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 - (30-40%)
> 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 1e-7.
>
> 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/t-o-k
 From: Tor Olav Kristensen Subject: Re: New f_vangle inbuilt with povr branch. Date: 14 May 2021 04:55:00 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/t-o-k
 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.
 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.
 From: Bald Eagle Subject: Re: New f_vangle inbuilt with povr branch. Date: 14 May 2021 06:40:00 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  :)
 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.
>

---

Web Message 3e459994@news.povray.org

---
Looks like maybe the files came from: