POV-Ray : Newsgroups : povray.general : computed rotate in macros Server Time
12 Aug 2024 13:22:02 EDT (-0400)
  computed rotate in macros (Message 5 to 14 of 14)  
<<< Previous 4 Messages Goto Initial 10 Messages
From: Spider
Subject: Re: computed rotate in macros
Date: 28 Feb 1999 17:31:41
Message: <36D9C24A.CF422173@bahnhof.se>
Thankyou.
Reading tutor now.
I have some linear algebra textbooks here, but I'm not good enough to actually
understand anything from it(and I have to finish that class soon. *sigh*)
I'll try the last one.


Rudy Velthuis wrote:
> 
> Spider schrieb in Nachricht <36D99EA7.F4436A97@bahnhof.se>...
> >Another one in this discussion, I have several rotate and a translate, as
> this :
> >
> >
> >rotate <nX,0,0>
> >rotate <0,nY,0>
> >rotate <0,nZ,0>
> >translate <0,nL,0>
> >
> >Now I wonder, is it possible to make this into only one rotate/translate,
> or,
> >even better into a matrix (I don't know the math, I only want to know if it
> is
> >possible, as so far.)
> >If it is possible to make only one matrix, can I combine two of them into
> only
> >one ?? (yes, macro :-)
> 
> Yes, you can, using matrix multiplication. There is a good tutorial
> somewhere on the web (John's Pov Matrix Page:
> http://www.erols.com/vansickl/matrix.htm). I would recommend reading this.
> It's good. You can also find this in any math textbook.
> 
> But you could *propably* just as well combine the rotations like this:
> 
> rotate <nX, nY + nZ, 0>
> translate nL * y
> 
> I think this is the correct order POV-Ray does this.
> --
> Rudy Velthuis

-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);


Post a reply to this message

From: John M  Dlugosz
Subject: Re: computed rotate in macros
Date: 1 Mar 1999 01:37:04
Message: <36da3590.0@news.povray.org>
Ken wrote in message <36D99775.CAF9A4D1@pacbell.net>...
>  The alternative is constructing the object at origin, rotating it,
>and then applying the translations you need to make. This will allow you
>to maintain any rotational attribute you have given the object.



That =is= what I'm doing.

You could write a macro like this:
    object {
        MyThing (/* controlling parameters... */  ,  Pos, Orientation)
        // ...

as an alternative to writing
    object {
         MyThing (/* controlling parameters... */)
         rotate Orientation
        translate Pos
        // ...

with the advantage that the macro =knows= about that information and can
adjust itself accordingly.

However, I would find it more convenient to specify the "Orientation"
information not as the kind of x,y,z angles you normally give to "rotate",
but as a vector that points in the object's "Forward" direction.  This is
much more useful for computing object details within the macro, and I want
to develop a general technique based on it.

So, how do I turn the Forward vector into something that the "rotate"
command likes?

--John


Post a reply to this message

From: John M  Dlugosz
Subject: Re: computed rotate in macros
Date: 1 Mar 1999 01:40:46
Message: <36da366e.0@news.povray.org>
Spider wrote in message <36D99EA7.F4436A97@bahnhof.se>...
>Another one in this discussion, I have several rotate and a translate, as
this :
>
>
>rotate <nX,0,0>
>rotate <0,nY,0>
>rotate <0,nZ,0>
>translate <0,nL,0>
>
>Now I wonder, is it possible to make this into only one rotate/translate,
or,
>even better into a matrix (I don't know the math, I only want to know if it
is
>possible, as so far.)
>If it is possible to make only one matrix, can I combine two of them into
only
>one ?? (yes, macro :-)




It sure is.  I don't know if it's worth doing it in POV script, though.
It's not exactly an object-oriented language.

    matrix M= I;  // identity matrix
    M.rotate (n*x);
    M.rotate (n*y);
    M.rotate (n*z);
    M.translate (whatever);
    // ... later
    someObject.rotate (M);  // do the whole thing as one step
    anotherObject.rotate (M);  // same value used here.

--John


Post a reply to this message

From: Spider
Subject: Re: computed rotate in macros
Date: 1 Mar 1999 12:41:59
Message: <36DACFFA.B2203C07@bahnhof.se>
I can't say I understand this. some more explination please.
As you do it, I get that M is anew matrix pointer at I, then you apply a rotate
to a matrix ???? Hmm, don't get that at all.

"John M. Dlugosz" wrote:
> 
> 
> It sure is.  I don't know if it's worth doing it in POV script, though.
> It's not exactly an object-oriented language.
> 
>     matrix M= I;  // identity matrix
>     M.rotate (n*x);
>     M.rotate (n*y);
>     M.rotate (n*z);
>     M.translate (whatever);
>     // ... later
>     someObject.rotate (M);  // do the whole thing as one step
>     anotherObject.rotate (M);  // same value used here.
> 
> --John

-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);


Post a reply to this message

From: John M  Dlugosz
Subject: Re: computed rotate in macros
Date: 1 Mar 1999 19:42:59
Message: <36db3413.0@news.povray.org>
A matrix does any kind of linear transform.  Rotate is one such transform.
Every rotate, translate, or shear is represeted as a matrix.  A point is
represented as a vector.  To transform the point, multiply the point by the
matrix.  To do two things, say a rotate followed by another rotate, multiply
the point by the first matrix, then multiply the result by the second
matrix.  IOW,
    result= p * M1 * M2;
Now it happens that you can also multiply the two matrices together, which
creates a single matrix that does the same thing!  IOW,
    result= p * (M1*M2);
the multiplication is associative.  (Note that it is not commutative,
though).
So you could write:
    matrix M3= M1*M2;
    result= p*M3;
and get the same answer, and reuse M3 many times with less work.

So in my notes, M.rotate is just a function that changes M to be whatever it
was before and the desired rotation on top of that.

Something like this:

    void matrix::rotate (const vector& input)
    {
    matrix rotX= (
        1,    0,    0,
        0,    cos(deg_to_rad(input.x)),    sin(deg_to_rad(input.x)),
        0,    -sin(deg_to_rad(input.x)),    cos(deg_to_rad(input.x))    );
    matrix rotY=  /// similar logic
    matrix rotZ= /// similar logic -- look it up in a Linear Algebra book.
    (*this) = (*this) * rotX * rotY * rotZ;
    }

This takes a vector holding separate x, y, and z angles in degrees, and
folds them into the original matrix.

--John



Spider wrote in message <36DACFFA.B2203C07@bahnhof.se>...
>I can't say I understand this. some more explination please.
>As you do it, I get that M is anew matrix pointer at I, then you apply a
rotate
>to a matrix ???? Hmm, don't get that at all.
>
>"John M. Dlugosz" wrote:
>>
>>
>> It sure is.  I don't know if it's worth doing it in POV script, though.
>> It's not exactly an object-oriented language.
>>
>>     matrix M= I;  // identity matrix
>>     M.rotate (n*x);
>>     M.rotate (n*y);
>>     M.rotate (n*z);
>>     M.translate (whatever);
>>     // ... later
>>     someObject.rotate (M);  // do the whole thing as one step
>>     anotherObject.rotate (M);  // same value used here.
>>
>> --John
>
>--
>//Spider
>( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
>#declare life = rand(seed(42))*sqrt(-1);


Post a reply to this message

From: Spider
Subject: Re: computed rotate in macros
Date: 1 Mar 1999 20:19:45
Message: <36DB3B43.43E150AF@bahnhof.se>
Thankyou.
I'm actually looking for a way to reduce the filesize of my tree macro creator,
preferable by removing some of the rotate, into either a single one or into a
matrix. I'm uncertain what would be easiest for me to do. I don't intend to do a
big time recode for a small saving, but if I can do it with some ease, I will.


-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);


Post a reply to this message

From: John M  Dlugosz
Subject: Re: computed rotate in macros
Date: 1 Mar 1999 23:06:24
Message: <36db63c0.0@news.povray.org>
That would be a way... concecutive rotate/translate and exotics (like shear
and perspecive distortions, which POV doesn't have primitives for) can be
collapsed into one "matrix".  However, a "matrix" with 16 parameters might
take more file space than a small number of rotate and translate commands.
So there is a break-even point.

And that might be a partial answer to my original question:  there is no
primitive to rotate the way I want, but I could use a POV matrix.

--John

Spider wrote in message <36DB3B43.43E150AF@bahnhof.se>...
>Thankyou.
>I'm actually looking for a way to reduce the filesize of my tree macro
creator,
>preferable by removing some of the rotate, into either a single one or into
a
>matrix. I'm uncertain what would be easiest for me to do. I don't intend to
do a
>big time recode for a small saving, but if I can do it with some ease, I
will.
>
>
>--
>//Spider
>( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
>#declare life = rand(seed(42))*sqrt(-1);


Post a reply to this message

From: Spider
Subject: Re: computed rotate in macros
Date: 2 Mar 1999 04:18:27
Message: <36DBAB72.5E598A1C@bahnhof.se>
I actually hope to save space with this, since there are three rotations in a
row, repeated some 3000 times in a .inc file. I know that POV doesn't take long
to compute it, but I'd still think it was a good idea to reduce them, for the
sake of filesize. the difference would not be as big with a matrix, since it
requires a few more numbers than a rotate, so perhaps a way to apply two rotates
in a single one. I still haven't worked on it, since I don't think I have the
skills required.


-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);


Post a reply to this message

From: John M  Dlugosz
Subject: Re: computed rotate in macros
Date: 2 Mar 1999 21:20:52
Message: <36dc9c84.0@news.povray.org>
Yes, two or three rotates can be turned into a single rotate.  But I'm not
certain that an arbitrary rotation can be expressed as a single POV rotate<>
argument.

To reduce the source filesize, why not use some macros?

Then again... (reading in a textbook) ... an arbitrary rotation can be
decomposed into five axis rotations.  Because one rotate<> command does
three such rotates (one on each axis), I can collapse that down to fewer
statements when consecutive rotates are performed in the proper order.  That
gives me three individual rotate commands.

So, an arbitrary rotation (any amount on any axis) can be expressed as three
rotate<> primitives in POV, or as one matrix primitive.

    rotate <0, 0, -theta>
    rotate <0, -phi, A>
    rotate <0,phi,theta>

where phi and theta are computed based on the desired axis of rotation, and
A is the amount to rotate along that axis.

--John

Spider wrote in message <36DBAB72.5E598A1C@bahnhof.se>...
>I actually hope to save space with this, since there are three rotations in
a
>row, repeated some 3000 times in a .inc file. I know that POV doesn't take
long
>to compute it, but I'd still think it was a good idea to reduce them, for
the
>sake of filesize. the difference would not be as big with a matrix, since
it
>requires a few more numbers than a rotate, so perhaps a way to apply two
rotates
>in a single one. I still haven't worked on it, since I don't think I have
the
>skills required.
>
>
>--
>//Spider
>( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
>#declare life = rand(seed(42))*sqrt(-1);


Post a reply to this message

From: Spider
Subject: Re: computed rotate in macros
Date: 2 Mar 1999 21:34:18
Message: <36DC9E38.2A2B99EB@bahnhof.se>
"John M. Dlugosz" wrote:
> 
> 
> To reduce the source filesize, why not use some macros?
because I try to get away from macros in this case, because the REALLY slow
parse time for them. and when I do this, I output to a .inc directly what the
macro would do, but it seemed that I should be able to reduce theese rotates to
a single one, thus reducing the filesize.

-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);


Post a reply to this message

<<< Previous 4 Messages Goto Initial 10 Messages

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