POV-Ray : Newsgroups : povray.general : Why only a +1 clamp with VAngle, VAngleD macros in math.inc? : Re: Why only a +1 clamp with VAngle, VAngleD macros in math.inc? Server Time
20 Apr 2024 06:48:22 EDT (-0400)
  Re: Why only a +1 clamp with VAngle, VAngleD macros in math.inc?  
From: Tor Olav Kristensen
Date: 6 May 2021 11:05:00
Message: <web.609404fd3160e21b8e52cc8789db30a9@news.povray.org>
Alain Martel <kua### [at] videotronca> wrote:

> > In creating some testing for include file macros I came across code for
> > the two VAngle* macros (and two similar rotation related macros):
> >
> > #macro VAngle(V1, V2)

> > #end
> >
> > The min(1,..) is obviously trying to protect acos from domain errors.
> >
> > Why only the clamp to the positive side? Aren't we as exposed to <-1.0?
> >
> > Often enough in code - including POV_Ray's own - I've seen code clamping
> > to a [-1..1] range after a dot product into acos() for acos domain
> > concerns.
> >
> > I cannot come up with reasoning to clamp only the positive side. Anyone
> > else? If valid to do, we might be able to slightly streamline some
> > internal code.
> >
> > Bill P.
> >
>
> The reason is quite simple : Normally, the vdot function of two
> normalized vectors can not return a value that is less than -1 nor more
> than 1.

I think that this is only in theory. In practice there will sometimes be
roundoff errors that cause problems.


> So, the min() could probably be safely removed.
>
> #macro VAngle(V1, V2)
>  acos(vdot(vnormalize(V1), vnormalize(V2)))
> #end

--
Tor Olav
http://subcube.com
https://github.com/t-o-k


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.