POV-Ray : Newsgroups : povray.newusers : Rotations not working as expected Server Time
30 Jul 2024 12:25:29 EDT (-0400)
  Rotations not working as expected (Message 1 to 7 of 7)  
From: Alex Bame
Subject: Rotations not working as expected
Date: 19 May 2004 20:45:00
Message: <web.40abfeb5584f13db4980b800@news.povray.org>
I think I'm missing something in how the rotation mechanism is supposed to
work.  I'm attempting to model a system composed of 4 rods seperated by 90
degrees from one another (or rather, their projections into the X-Z plane
are) that are rotated off the Y axis by some angle theta.  The rods are
additionally rotated around the Y axis by some angle phi.  Halfway up each
of the rods is a spring connecting each adjacent rod.  I am using an
isosurface and the f_helix1 function to draw the spring, then I'm scaling
it to the appropriate length (thus maintaining a constant number of loops)
and translating it up the vertical axis and performing the same rotation
(with an extra 45 degrees around the vertical axis so that it's connecting
the rods rather than in the middle of them) but the springs seem to have
'missed', i.e. they seem to have rotated more off the vertical axis than
the rods have.  I've been poking at this for hours now and can't figure out
what I'm missing :-

Here's the code I'm using, thanks in advance to anyone who takes the time to
glance at it for me.

--SNIP--
#include "colors.inc"
#include "metals.inc"
#include "functions.inc"

#declare cyl_radius=0.07;
#declare spr_maj_radius=0.05;
#declare spr_min_radius=0.01;

#declare phi=0;
#declare theta=pi/4;

camera {
   location <0, 3, -3>
   look_at <0, 1, 0>
}

// The rods

cylinder {
   <0, 0, 0>,     // Center of one end
   <0, 2, 0>,     // Center of other end
   cyl_radius     // Radius
   texture {
      T_Chrome_3A // Pre-defined texture
      scale 4     // Scale by the same ammount in all directions
   }
   rotate <0, 0, theta*180/pi>
   rotate <0, phi*180/pi, 0>
}

cylinder {
   <0, 0, 0>,     // Center of one end
   <0, 2, 0>,     // Center of other end
   cyl_radius     // Radius
   texture {
      T_Chrome_3A // Pre-defined texture
      scale 4     // Scale by the same ammount in all directions
   }
   rotate <0, 0, theta*180/pi>
   rotate <0, (phi+pi/2)*180/pi, 0>
}

cylinder {
   <0, 0, 0>,     // Center of one end
   <0, 2, 0>,     // Center of other end
   cyl_radius     // Radius
   texture {
      T_Chrome_3A // Pre-defined texture
      scale 4     // Scale by the same ammount in all directions
   }
   rotate <0, 0, theta*180/pi>
   rotate <0, (phi+pi)*180/pi, 0>
}

cylinder {
   <0, 0, 0>,     // Center of one end
   <0, 2, 0>,     // Center of other end
   cyl_radius     // Radius
   texture {
      T_Chrome_3A // Pre-defined texture
      scale 4     // Scale by the same ammount in all directions
   }
   rotate <0, 0, theta*180/pi>
   rotate <0, (phi+3*pi/2)*180/pi, 0>
}

// The springs

isosurface {
   function {
      f_helix1(x, y, z, 1, 20*pi,
         spr_min_radius, spr_maj_radius,
         1, 1, 0)
   }
   max_gradient 3
   contained_by{ box {-1/2,1/2} }   // One unit long, this gives us a
constant
   texture {                        // number of twists in the spring
      T_Brass_3A
      scale 4
   }
   scale <1, sqrt(2)*sin(theta), 1> // Scale the spring to the proper length
   rotate <0, 0, 90>
   translate <0, 1, 0>
   rotate <0, 90, 0>
   rotate <0, 0, theta*180/pi>
   rotate <0, (phi+pi/4)*180/pi, 0>
}

isosurface {
   function {
      f_helix1(x, y, z, 1, 20*pi,
         spr_min_radius, spr_maj_radius,
         1, 1, 0)
   }
   max_gradient 3
   contained_by{ box {-1/2,1/2} }
   texture {
      T_Brass_3A
      scale 4
   }
   scale <1, sqrt(2)*sin(theta), 1>
   rotate <0, 0, 90>
   translate <0, 1, 0>
   rotate <0, 90, 0>
   rotate <0, 0, theta*180/pi>
   rotate <0, (phi+3*pi/4)*180/pi, 0>
}

isosurface {
   function {
      f_helix1(x, y, z, 1, 20*pi,
         spr_min_radius, spr_maj_radius,
         1, 1, 0)
   }
   max_gradient 3
   contained_by{ box {-1/2,1/2} }
   texture {
      T_Brass_3A
      scale 4
   }
   scale <1, sqrt(2)*sin(theta), 1>
   rotate <0, 0, 90>
   translate <0, 1, 0>
   rotate <0, 90, 0>
   rotate <0, 0, theta*180/pi>
   rotate <0, (phi+5*pi/4)*180/pi, 0>
}

isosurface {
   function {
      f_helix1(x, y, z, 1, 20*pi,
         spr_min_radius, spr_maj_radius,
         1, 1, 0)
   }
   max_gradient 3
   contained_by{ box {-1/2,1/2} }
   texture {
      T_Brass_3A
      scale 4
   }
   scale <1, sqrt(2)*sin(theta), 1>
   rotate <0, 0, 90>
   translate <0, 1, 0>
   rotate <0, 90, 0>
   rotate <0, 0, theta*180/pi>
   rotate <0, (phi+7*pi/4)*180/pi, 0>
}

light_source { <2, 4, -3> color White }
light_source { <-2, -4, -3> color White }
--SNIP--

Sorry for the verbosity, while loops are next on my list of things to figure
out :)

-- Alex


Post a reply to this message

From: Severi Salminen
Subject: Re: Rotations not working as expected
Date: 19 May 2004 21:06:30
Message: <40ac0496$1@news.povray.org>
Alex Bame wrote:
> I think I'm missing something in how the rotation mechanism is supposed to
> work. 
[snip...]

You have a WAY too long example. Try to make it _as short as possible_. 
Remove all the unnecessary stuff like textures and try to give only one 
single object showing the problem.

The syntax of rotate is given in section 6.3.1.3 in the manual. In summary:

- rotation is done relative to each axis
- totation is done in degrees
- rotation is done using left-handed rotation system
- the order of rotations in one rotate statement is x,y,z

That should probably solve your problems?

Severi


Post a reply to this message

From: Alex Bame
Subject: Re: Rotations not working as expected
Date: 19 May 2004 22:50:00
Message: <web.40ac1bc7225a08e5b4980b800@news.povray.org>
Severi Salminen <sev### [at] NOT_THISsibafi> wrote:
> Alex Bame wrote:
> > I think I'm missing something in how the rotation mechanism is supposed to
> > work.
> [snip...]
>
> You have a WAY too long example. Try to make it _as short as possible_.
> Remove all the unnecessary stuff like textures and try to give only one
> single object showing the problem.
>
> The syntax of rotate is given in section 6.3.1.3 in the manual. In summary:
>
> - rotation is done relative to each axis
> - totation is done in degrees
> - rotation is done using left-handed rotation system
> - the order of rotations in one rotate statement is x,y,z
>
> That should probably solve your problems?
>
> Severi

I've read the section in the manual on rotations and I believe that I am
using the rotate command correctly.  It seems to be working fine for the
cylinders it's just the isosurface that is behaving oddly.  Of course the
isosurface also has a much more complicated placing so it's probably the
case that I'm simply misunderstanding something and making a mistake
somewhere.  I've trimmed as much as I'm able from the scene file,
unfortunatly the problem is one of relative rotations and so I need objects
against which to refrence.  Also, I'm still very new at this (I've only
been using POV-Ray for a week) so I'm not very clear on what is and is not
needed with these objects.  I tried removing the textures as you suggested
but then I couldn't see the objects when I rendered the scene.

The problem is that the spring (isosurface) should be rotated around the Z
axis as much as the cylinders are so that they line up, yet it clearly is
not.  I have aligned the camera so that this is easy to see.

Thank you for your time and suggestions, here is my shortened example scene.

--SNIP--
#include "colors.inc"
#include "metals.inc"
#include "functions.inc"

#declare cyl_radius=0.07;
#declare spr_maj_radius=0.05;
#declare spr_min_radius=0.01;

#declare phi=pi/4;
#declare theta=pi/4;

camera {
   location <0, 1, -3>
   look_at <0, 1, 0>
}

// The rods

cylinder {
   <0, 0, 0>,     // Center of one end
   <0, 2, 0>,     // Center of other end
   cyl_radius     // Radius
   texture {
      T_Chrome_3A // Pre-defined texture
      scale 4     // Scale by the same ammount in all directions
   }
   rotate <0, 0, theta*180/pi>
   rotate <0, phi*180/pi, 0>
}

cylinder {
   <0, 0, 0>,     // Center of one end
   <0, 2, 0>,     // Center of other end
   cyl_radius     // Radius
   texture {
      T_Chrome_3A // Pre-defined texture
      scale 4     // Scale by the same ammount in all directions
   }
   rotate <0, 0, theta*180/pi>
   rotate <0, (phi+3*pi/2)*180/pi, 0>
}

// The springs

isosurface {
   function {
      f_helix1(x, y, z, 1, 20*pi,
         spr_min_radius, spr_maj_radius,
         1, 1, 0)
   }
   max_gradient 3
   contained_by{ box {-1/2,1/2} }   // One unit long, this gives us a
constant
   texture {                        // number of twists in the spring
      T_Brass_3A
      scale 4
   }
   scale <1, sqrt(2)*sin(theta), 1> // Scale the spring to the proper length
   rotate <0, 0, 90>
   rotate <0, 90, 0>
   translate <0, 1, 0>
   rotate <0, 0, theta*180/pi>
}

light_source { <2, 4, -3> color White }
light_source { <-2, -4, -3> color White }
--SNIP--


Post a reply to this message

From: Mike Williams
Subject: Re: Rotations not working as expected
Date: 20 May 2004 00:04:25
Message: <KEnOvHAM3CrAFwi2@econym.demon.co.uk>
Wasn't it Alex Bame who wrote:
>I think I'm missing something in how the rotation mechanism is supposed to
>work.  I'm attempting to model a system composed of 4 rods seperated by 90
>degrees from one another (or rather, their projections into the X-Z plane
>are) that are rotated off the Y axis by some angle theta.  The rods are
>additionally rotated around the Y axis by some angle phi.  Halfway up each
>of the rods is a spring connecting each adjacent rod.  I am using an
>isosurface and the f_helix1 function to draw the spring, then I'm scaling
>it to the appropriate length (thus maintaining a constant number of loops)
>and translating it up the vertical axis and performing the same rotation
>(with an extra 45 degrees around the vertical axis so that it's connecting
>the rods rather than in the middle of them) but the springs seem to have
>'missed', i.e. they seem to have rotated more off the vertical axis than
>the rods have.  I've been poking at this for hours now and can't figure out
>what I'm missing :-
>
>Here's the code I'm using, thanks in advance to anyone who takes the time to
>glance at it for me.

Imagine your mechanism as an inverted pyramid. The slope of the edges of
the pyramid (theta) is not the same as the slope of a line running up
the centre of one of the faces. Let's call the slope of the centre line
"alpha". You need to rotate the centres of your springs upwards by
alpha, not theta. The length of the spring also depends on alpha, not
theta.

My trig doesn't seem up to calculating alpha, so I got POV to do all the
hard work for me. I calculated the points P1 and P2 that are half way up
the first two rods and told POV to run the spring between those points.

// Need this for Point_At_Trans
#include "transforms.inc"

// Calculate the endpoints of one spring
#declare P1=<sin(theta)*sin(phi), cos(theta), sin(theta)*cos(phi)>;
#declare P2=<sin(theta)*sin(phi+pi/2), cos(theta),      
        sin(theta)*cos(phi+pi/2)>;

// Calculate its length
#declare Length = vlength(P2-P1);

// Declare the spring
#declare Spring= isosurface {
   function {
      f_helix1(x, y, z, 1, 20*pi,
         spr_min_radius, spr_maj_radius,
         1, 1, 0)
   }
   max_gradient 3
   contained_by{ box {-1/2,1/2} }
   texture {T_Brass_3A}

   translate <0,0.5,0>                // move one end point to <0,0,0>
   scale <1, Length, 1>               // Set the correct length
   transform {Point_At_Trans (P2-P1)} // point it in the P1-P2 direction
   translate P1                       // move one end from <0,0,0> to P1
}

// Make four copies
object {Spring}
object {Spring rotate <0, (pi)*180/pi, 0>}
object {Spring rotate <0, (pi/2)*180/pi, 0>}
object {Spring rotate <0, (3*pi/2)*180/pi, 0>}


-- 
Mike Williams
Gentleman of Leisure


Post a reply to this message

From: Alex Bame
Subject: Re: Rotations not working as expected
Date: 20 May 2004 01:40:00
Message: <web.40ac439e225a08e5b4980b800@news.povray.org>
Mike Williams <nos### [at] econymdemoncouk> wrote:
> Imagine your mechanism as an inverted pyramid. The slope of the edges of
> the pyramid (theta) is not the same as the slope of a line running up
> the centre of one of the faces. Let's call the slope of the centre line
> "alpha". You need to rotate the centres of your springs upwards by
> alpha, not theta. The length of the spring also depends on alpha, not
> theta.
>
> My trig doesn't seem up to calculating alpha, so I got POV to do all the
> hard work for me. I calculated the points P1 and P2 that are half way up
> the first two rods and told POV to run the spring between those points.
>
> // Need this for Point_At_Trans
> #include "transforms.inc"
>
> // Calculate the endpoints of one spring
> #declare P1=<sin(theta)*sin(phi), cos(theta), sin(theta)*cos(phi)>;
> #declare P2=<sin(theta)*sin(phi+pi/2), cos(theta),
>         sin(theta)*cos(phi+pi/2)>;
>
> // Calculate its length
> #declare Length = vlength(P2-P1);
>
> // Declare the spring
> #declare Spring= isosurface {
>    function {
>       f_helix1(x, y, z, 1, 20*pi,
>          spr_min_radius, spr_maj_radius,
>          1, 1, 0)
>    }
>    max_gradient 3
>    contained_by{ box {-1/2,1/2} }
>    texture {T_Brass_3A}
>
>    translate <0,0.5,0>                // move one end point to <0,0,0>
>    scale <1, Length, 1>               // Set the correct length
>    transform {Point_At_Trans (P2-P1)} // point it in the P1-P2 direction
>    translate P1                       // move one end from <0,0,0> to P1
> }
>
> // Make four copies
> object {Spring}
> object {Spring rotate <0, (pi)*180/pi, 0>}
> object {Spring rotate <0, (pi/2)*180/pi, 0>}
> object {Spring rotate <0, (3*pi/2)*180/pi, 0>}
>
>
> --
> Mike Williams
> Gentleman of Leisure

That's excellent :)

I was thinking of it as a cone, not a pyramid.  I see now that you're right,
this is exactly what was causing my problem.  I also like your use of the
#define for Spring and the rotate when defining objects, it makes the scene
file much easier to read.  The more I see of POV-Ray the more I like it,
it's an elegant and artistic blend of vector mathematics with computer
programming :)

Thank you very much, and thanks to everyone else who gave it a look too.


Post a reply to this message

From: Marvin T
Subject: Re: Rotations not working as expected
Date: 20 May 2004 14:03:51
Message: <40acf307$1@news.povray.org>
Mike Williams wrote:
> 
> Imagine your mechanism as an inverted pyramid. The slope of the edges of
> the pyramid (theta) is not the same as the slope of a line running up
> the centre of one of the faces. Let's call the slope of the centre line
> "alpha". You need to rotate the centres of your springs upwards by
> alpha, not theta. The length of the spring also depends on alpha, not
> theta.
> 
> My trig doesn't seem up to calculating alpha, so I got POV to do all the
> hard work for me. I calculated the points P1 and P2 that are half way up
> the first two rods and told POV to run the spring between those points.
> 
> // Need this for Point_At_Trans
> #include "transforms.inc"
> 

Pretty similar to what I came up with, but I used macros in case the 
rods moved independently.  Okay, so it's not in the original 
description, but ... doh.

Anyway, try animating this w/clock [0...1].   BTW, can someone clue me 
in to why the springs seem to be too long?  I'm not seeing it...

M

--------
#include "colors.inc"
#include "metals.inc"
#include "functions.inc"
#include "transforms.inc"

#declare cyl_radius=0.07;
#declare spr_maj_radius=0.05;
#declare spr_min_radius=0.01;

camera {
    location <2, 1.25, -2.5>
    look_at <0, 1.25, 0>
}

// Make it move:
#macro theta(n) (pi*(2+sin((n)*2*pi))/8) #end
#declare phi = 0.0;

//
// Create a rod of length 2 that is rotated by ANG1 and ANG2 (radians)
// And set CPT to be the centerpoint of this rod.
//
#macro Rod(ang1, ang2, cpt)
    #local   _xx = cos(ang1)*sin(ang2);
    #local   _yy = sin(ang1);
    #local   _zz = cos(ang1)*cos(ang2);
    #declare cpt = <_xx,_yy,_zz>;

cylinder {
    0, 2*cpt, cyl_radius
    texture {
       T_Chrome_3A // Pre-defined texture
       scale 4     // Scale by the same ammount in all directions
    }
}
#end

#macro Spring( pt1, pt2 )
#local _leng = vlength(pt2-pt1);
#local _cpt  = (pt2-pt1)/2;

isosurface {
    function {
       f_helix1(x, y, z, 1, 20*pi,
          spr_min_radius, spr_maj_radius,
          1, 1, 0)
    }
    max_gradient 3
    contained_by{ box {-1/2,1/2} }
    texture {
       T_Brass_3A
       scale 4
    }
    transform {Point_At_Trans (pt2-pt1)}
    translate (pt2+pt1)/2
}
#end

// The center points.
#declare cpt0 = <0,0,0>;
#declare cpt1 = <0,0,0>;
#declare cpt2 = <0,0,0>;
#declare cpt3 = <0,0,0>;

// Declare the rods and get their center points.
Rod( theta(clock+0.0), phi+pi*0.0, cpt0 )
Rod( theta(clock+0.2), phi+pi*0.5, cpt1 )
Rod( theta(clock+0.4), phi+pi*1.0, cpt2 )
Rod( theta(clock+0.6), phi+pi*1.5, cpt3 )

// Stretch a string between adjacent centers:
Spring( cpt0, cpt1 )
Spring( cpt1, cpt2 )
Spring( cpt2, cpt3 )
Spring( cpt3, cpt0 )

light_source { <2, 4, -3> color White }
light_source { <-2, -4, -3> color White }


Post a reply to this message

From: Alex Bame
Subject: Re: Rotations not working as expected
Date: 20 May 2004 14:55:00
Message: <web.40acfe82225a08e5b4980b800@news.povray.org>
Another excellent example, thank you Marvin :)

I can see that I'll have a lot to learn while playing with POV-Ray over the
summer!


Mike Williams <nos### [at] econymdemoncouk> wrote:
> My trig doesn't seem up to calculating alpha, so I got POV to do all the
> hard work for me.

I got it worked out this morning, in case your're curious it winds up being
acos(cos(theta)/sqrt(1-1/2*pow(sin(theta),2))).  Had to use a right
triangle on the face of the pyramid using one of the rods and a line
dropped from halfway along the spring to the orgin (the angle between the
line coming up from the origin and the spring is a right angle since we're
bisecting an isocoles triangle) and another right triangle using the line
up from the origin along the face of the pyramid, the Y axis, and a
horizontal line connecting the two.

I worked out the angle since I'm doing this animation for a paper in my math
class, otherwise I would have definately done it your way :)



Thanks to the both of you for your suggestions, my computer is currently
chugging out 1000 frames using values of theta and phi from a numerical
solver.  I'd like to refrence the both of you in my paper for your help,
provided that you don't have any objections.  The paper (and the animation)
should be up on the web by the end of tomorrow if you'd like to see either.


Post a reply to this message

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