POV-Ray : Newsgroups : povray.beta-test : VPerp_To_Vector() macro bug, also Axial_Scale_Trans() Server Time
29 Jul 2024 14:25:18 EDT (-0400)
  VPerp_To_Vector() macro bug, also Axial_Scale_Trans() (Message 1 to 6 of 6)  
From: Gelu Stoicescu
Subject: VPerp_To_Vector() macro bug, also Axial_Scale_Trans()
Date: 6 May 2002 14:12:46
Message: <3cd6c79e@news.povray.org>
WinPOV 3.5.beta.RC3.icl.win32, AMD K6-II 3D 333MHz 160M RAM, Win98SE
(not that it matters whatsoever, only to embarrass myself with my
outdated hardware)

This is the kind of thing a beginner (like me) would spot, getting busy
with the ready made stuff. Let me quote the definition, for the sake of
explanations:

#macro VPerp_To_Vector(V)
   vnormalize(vcross(V, vrotate(V, <90, 90, 0>)))
#end

However, when V has values such as <1, 1, -1> (and all proportional
vectors such as <2, 2, -2>, <-1, -1, 1> etc - what matters is the
direction) the two rotations performed by vrotate() bring the vector in
a round trip right where it started (isn't math amazing? I wouldn't see
it coming either), then vcross() has identical vectors and returns <0,
0, 0>, so vnormalize() throws the appropriate error. IMHO the purpose of
this VPerp_To_Vector() macro is rather confusing. Manual says "Find a
vector perpendicular to the given vector". I'm no Einstein, but vectors
perpendicular to a given vector are more than one (actually a whole
plane of them), and this function only picks one by its own acquired
taste. Such a "pick a card" tweak may find its use (whoever made it
probably needed it; I woun't be so cheeky as to mention Rune's name -
oops!), although I saw it used quite sparingly (only 2 occurences in 2
different files in \include). But the preferential choice of the two
axis in vrotate(), leaves a "blind angle" on the mentioned direction.
I guess the workaround would be to add to the code a lil' test for the
offending direction and return an explicit vector. Here I feel I must
state that me for one I wouldn't vote for returning phony values from
vnormalize() for zero-lenght vectors - just to cut down another
extensive debate.
BTW the VPerp_To_Vector() macro also causes Axial_Scale_Trans() macro to
display the same behaviour (throws error for the mentioned direction)
and that's only what I stepped on.
All above is a beginner's opinion, no IRTC entry yet, please no flames
(at need I can plead non native English speaker). If it's known issue,
yesterday news etc., merely ignore.

Gelu


Post a reply to this message

From: Christoph Hormann
Subject: Re: VPerp_To_Vector() macro bug, also Axial_Scale_Trans()
Date: 6 May 2002 14:38:27
Message: <3CD6CDA3.7D5FDA25@gmx.de>
Gelu Stoicescu wrote:
> 
> [...]
> All above is a beginner's opinion, no IRTC entry yet, please no flames
> (at need I can plead non native English speaker). If it's known issue,
> yesterday news etc., merely ignore.
> 

This problem is being worked on, i think you can expect it to be fixed in
the next beta.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 05 May. 2002 _____./\/^>_*_<^\/\.______


Post a reply to this message

From: Rune
Subject: Re: VPerp_To_Vector() macro bug, also Axial_Scale_Trans()
Date: 6 May 2002 16:36:01
Message: <3cd6e931@news.povray.org>
Gelu Stoicescu wrote:
> However, when V has values such as <1, 1, -1> (and
> all proportional vectors such as <2, 2, -2>, <-1, -1, 1>
> etc - what matters is the direction) the two rotations
> performed by vrotate() bring the vector in a round trip
> right where it started

Yes, this has been noticed and the new version will use a different
approach which should work for all input vectors with no exceptions
(well, except <0,0,0>).

> I'm no Einstein, but vectors perpendicular to a given
> vector are more than one (actually a whole plane of them),
> and this function only picks one by its own acquired taste.

That is correct.

> Such a "pick a card" tweak may find its use

( I didn't originally come up with the concept of the macro, I just
rewrote it (with the error that was later spotted, oops...). I
personally prefer the VPerp_Adjust macro, which doesn't leave things to
chance. )

> All above is a beginner's opinion, no IRTC entry yet,
> please no flames (at need I can plead non native
> English speaker). If it's known issue, yesterday news
> etc., merely ignore.

Even though the bug happened to have already been fixed when you
reported it, your bug report was correct and precise, so if you find
other bugs in the future, don't hestitate to report those too. :)

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Apr 14)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk


Post a reply to this message

From: Slime
Subject: Re: VPerp_To_Vector() macro bug, also Axial_Scale_Trans()
Date: 7 May 2002 00:49:57
Message: <3cd75cf5$1@news.povray.org>
> > However, when V has values such as <1, 1, -1> (and
> > all proportional vectors such as <2, 2, -2>, <-1, -1, 1>
> > etc - what matters is the direction) the two rotations
> > performed by vrotate() bring the vector in a round trip
> > right where it started
>
> Yes, this has been noticed and the new version will use a different
> approach which should work for all input vectors with no exceptions
> (well, except <0,0,0>).

Heeey! My multivariable calculus and matrix algebra class comes to use!
Apparently <1,1,-1> is an eigenvector of the transformation matrix defined
by the rotation, since Ax = lx (where A is the transformatoin matrix and l
is some constant). So, the question is, is there such thing as a three by
three matrix with no eigenvalues?

I vaguely remember prooving that there isn't such a thing with a 2 by 2
matrix... but I may be wrong... (yup, i just proved myself wrong, it's
entirely possible by a simple rotation.)

OK, so, if it's possible in 2D space, is it possible in 3D space? I'm
willing to bet it will be...

Well, let's see... by setting det(A-l) = 0, and trying to find an
unsolveable case, we get a cubic polynomial... but if we make sure the main
diagonal of the matrix is all zero (to simplify things), then we'll get

-l^3
+  l * (A(1,3)*A(3,1) + A(1,2)*A(2,1) + A(2,3)*A(3,2))
+  A(1,2)*A(2,3)*A(3,1) + A(1,3)*A(2,1)*A(3,2)
= 0

But... wait... there's a cubic term in there without a coefficient... so
this can always have a solution... shoot. I'll have to *not* restrict myself
to a main diagonal of all zeros. Rrrrr...

OK, solved it, but I'm not going to write it out here for time's sake.
Unfortunately, this *also* has a cubic term without a coefficient that I
have any control over.

I guess it's not possible. Not with a single transformation matrix. An if
statement will be necessary.

Someone who knows about this stuff, tell me if I'm right, please =)

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]


Post a reply to this message

From: KalleK
Subject: Re: VPerp_To_Vector() macro bug, also Axial_Scale_Trans()
Date: 11 May 2002 12:21:35
Message: <3cdd450f@news.povray.org>
>
> Heeey! My multivariable calculus and matrix algebra class comes to use!
> Apparently <1,1,-1> is an eigenvector of the transformation matrix defined
> by the rotation, since Ax = lx (where A is the transformatoin matrix and l
> is some constant). So, the question is, is there such thing as a three by
> three matrix with no eigenvalues?

I'm new to this, but I would say no: To get the eigenvalues of a matrix A you
calculate this:
det(A-zE)=0
(z are the eigenvalues, E is the matrix with ones on main diagonal and zeros
at all other places)
That's a polynom. You can always get values of z (at least one value)
sometimes they are complex, but with a third-degree polynom you get at least
a real one. (just guessing...)
So there's always at least one eigenvalue (that could be zero, but non the
less)

cukk


Post a reply to this message

From: Anders K 
Subject: Re: VPerp_To_Vector() macro bug, also Axial_Scale_Trans()
Date: 14 May 2002 14:12:22
Message: <3ce15386@news.povray.org>
It's even simpler to note that by Brouwer's Fixed Point Theorem (any
continuous mapping of a unit ball to itself will have a fixed point), if
VPerp_To_Vector() could be made continuous, there would be at least one unit
vector that is "perpendicular" to itself. Whoops!

Anders


Post a reply to this message

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