Playing with the animation stuff, I produced this simple scene:

#version unofficial MegaPov 0.5;

camera
	{
	location <0.0, 0, -4>
	look_at <0.0, 0.0, 0.0>
	}

light_source
	{
	<-4, 8, -4>
	rgb .3
	}

text
	{
	ttf "ALIANNA.TTF",
	"RAYTRACING"
	1, <0.0, 0.0, 0.0>
	align_center
	pigment { color rgb <0, 1, 0> }
	rotate <0,-20*(sin(clock*360)),0>
	}

As I understand it, this should produce a nice loop; starting from no
rotation (clock = 0, sin(0) = 0), the right end of the text should be
rotated toward the camera while the left end falls away until a quarter
of the way through the animation, where the rotation reaches -20 degrees
(clock = ~.25, sin(360*.25) = 1). Then, it should rotate back the way it
came until halfway through (sin(360*.5) = 0) and then keep rotating that
direction until 3/4 of the way through the animation where it reaches 20
degrees (sin(360*.75) = -1). And finally, it should rotate back again
until it reaches no rotation.

Problem: it doesn't do this. It seems like the sin function is returning
incorrect values, since when I rendered the animation and dumped the
frames in a GIF animator, the animation didn't describe a full loop.
Instead, it acted as though the function had been sin(clock*270),
starting from no rotation and ending up at 20 degrees rotation.

Can anyone either explain what I'm doing wrong, or reproduce this bug?

-- 
Xplo Eristotle
http://start.at/xplosion/

"And then one day you find ten years have got behind you
No one told you when to run, you missed the starting gun"
    -Pink Floyd

Post a reply to this message

In article <39399F72.5F639DC0@unforgettable.com> , Xplo Eristotle 
<inq### [at] unforgettablecom>  wrote:

> As I understand it, this should produce a nice loop; starting from no
> rotation (clock = 0, sin(0) = 0), the right end of the text should be
> rotated toward the camera while the left end falls away until a quarter
> of the way through the animation, where the rotation reaches -20 degrees
> (clock = ~.25, sin(360*.25) = 1). Then, it should rotate back the way it
> came until halfway through (sin(360*.5) = 0) and then keep rotating that
> direction until 3/4 of the way through the animation where it reaches 20
> degrees (sin(360*.75) = -1). And finally, it should rotate back again
> until it reaches no rotation.

The trigonometric functions use radians which is clearly stated in the
documentation.  See the section about floating-point functions to find out
how to convert from degrees to radians.  However, you can probably solve the
whole thing without using any function and just use rotate (but I don't
understand what you want to do).


      Thorsten

Post a reply to this message

Xplo Eristotle <inq### [at] unforgettablecom> wrote:
> Playing with the animation stuff, I produced this simple scene:
[snip]
> As I understand it, this should produce a nice loop; starting from no
> rotation (clock = 0, sin(0) = 0), the right end of the text should be
> rotated toward the camera while the left end falls away until a quarter
> of the way through the animation, where the rotation reaches -20 degrees
> (clock = ~.25, sin(360*.25) = 1). Then, it should rotate back the way it
> came until halfway through (sin(360*.5) = 0) and then keep rotating that
> direction until 3/4 of the way through the animation where it reaches 20
> degrees (sin(360*.75) = -1). And finally, it should rotate back again
> until it reaches no rotation.
>
> Problem: it doesn't do this. It seems like the sin function is returning
> incorrect values, since when I rendered the animation and dumped the
> frames in a GIF animator, the animation didn't describe a full loop.
> Instead, it acted as though the function had been sin(clock*270),
> starting from no rotation and ending up at 20 degrees rotation.

Or, it seems the sin function is returning the correct values, based on the
fact that it accepts the input angle in radians rather than degrees.  Try
changing your statement to:

   rotate <0,-20*sin(clock*2*pi),0>

and things should work as you expect.

Post a reply to this message

Chris Colefax wrote:
> 
> Or, it seems the sin function is returning the correct values, based on the
> fact that it accepts the input angle in radians rather than degrees.  Try
> changing your statement to:
> 
>    rotate <0,-20*sin(clock*2*pi),0>
> 
> and things should work as you expect.

Radians? Gah! >_<

That explains a lot. Thanks.

-- 
Xplo Eristotle
http://start.at/xplosion/

"And then one day you find ten years have got behind you
No one told you when to run, you missed the starting gun"
    -Pink Floyd

Post a reply to this message

On Sun, 04 Jun 2000 02:43:37 +0100, Thorsten Froehlich wrote:
>The trigonometric functions use radians which is clearly stated in the
>documentation. 

A short history question: Was there a reason for using degrees with
rotate and radians with the trigonometric functions, or did just happen
that way?

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

>A short history question: Was there a reason for using degrees with
>rotate and radians with the trigonometric functions, or did just happen
>that way?


I'd say it's quite natural that the _functions_ take radians as parameters,
because in mathematics, you rarely use degrees to express angles and/or to
perform trigonometric oerations, to put it that way.

As for the rotations, the degrees is for many a more natural and intuitive
approach to orientation in space. You don't say "turn around pi", but "turn
around 180 degrees." Maybe it would be natural to have alternate
rotate-definitions, accepting radians?

If we started to use degrees instead of radians in the trigonometric
functions, people would be confused, as AFAIK every programming language use
radians. Also, it would be cumbersome to have triginometric functions that
behave differently than the usual. For example, the limit:

limit  sin (x) / x
x->0

is different for the two functions. Functions as arcsin, arctan and so forth
gets trickier to use.

Regards,
Simen Kvaal.

Post a reply to this message

Simen Kvaal wrote:
> 
> >A short history question: Was there a reason for using degrees with
> >rotate and radians with the trigonometric functions, or did just happen
> >that way?
> 
> I'd say it's quite natural that the _functions_ take radians as parameters,
> because in mathematics, you rarely use degrees to express angles and/or to
> perform trigonometric oerations, to put it that way.
> 
> As for the rotations, the degrees is for many a more natural and intuitive
> approach to orientation in space. You don't say "turn around pi", but "turn
> around 180 degrees." Maybe it would be natural to have alternate
> rotate-definitions, accepting radians?

It would be more natural, IMO, to have trig that accepts degrees. When I
was taking trig, we did plenty of work with degrees.. and in fact, since
we specify angles in degrees pretty much everywhere BUT in a classroom -
even my scientific calculator uses degrees by default - I don't see the
point of using radians, which almost no one is familiar with.

I don't WANT to rotate an object by 1/6th pi. I don't *NEED* to rotate
an object by 1/6th pi. But it would be nice to ask for sin(30) and get
.5 back.

(In the spirit of offering a solution, how about a "trig_units" keyword
in the global_settings, where a user could specify "degrees" or "radians"?)

-- 
Xplo Eristotle
http://start.at/xplosion/

"And then one day you find ten years have got behind you
No one told you when to run, you missed the starting gun"
    -Pink Floyd

Post a reply to this message

In article <slr### [at] tealhhjpat> , 
hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:
> On Sun, 04 Jun 2000 02:43:37 +0100, Thorsten Froehlich wrote:
>>The trigonometric functions use radians which is clearly stated in the
>>documentation.
>
> A short history question: Was there a reason for using degrees with
> rotate and radians with the trigonometric functions, or did just happen
> that way?

In article <393aa3bf@news.povray.org> , "Simen Kvaal"
<sim### [at] studentmatnatuiono> wrote:
> I'd say it's quite natural that the _functions_ take radians as parameters,
> because in mathematics, you rarely use degrees to express angles and/or to
> perform trigonometric oerations, to put it that way.
>
> As for the rotations, the degrees is for many a more natural and intuitive
> approach to orientation in space.

I think this is a good explanation and reasoning.


      Thorsten

Post a reply to this message

"Xplo Eristotle" wrote:
> It would be more natural, IMO, to have trig that accepts degrees.

I don't see the reason to change how it works or to make new keywords for
it. You can anywhere and anytime use degrees(X) to convert X from radians to
degrees and radians(X) to convert degrees to radians. It's very simple.

> I don't WANT to rotate an object by 1/6th pi. I don't *NEED* to
> rotate an object by 1/6th pi. But it would be nice to ask for
> sin(30) and get .5 back.

Ask for sin(radians(30)) and you get back .5

> (In the spirit of offering a solution, how about a "trig_units"
> keyword in the global_settings, where a user could specify
> "degrees" or "radians"?)

I think it will cause only more trouble. If your scene uses degrees and you
want to use an include file that uses radians you would have to change the
global_settings several times.

And when we in these groups want to help others with trig related problems
we would always have to ask things like, "Did you remember to set trig_units
to 'degrees'?".

I think it is fine as it is.

Greetings,

Rune

---
Updated April 25: http://rsj.mobilixnet.dk
Containing 3D images, stereograms, tutorials,
The POV Desktop Theme, 350+ raytracing jokes,
miscellaneous other things, and a lot of fun!

Post a reply to this message

Xplo Eristotle wrote:
> 
> I don't WANT to rotate an object by 1/6th pi. I don't *NEED* to rotate
> an object by 1/6th pi.

Me neither.  I always do it this way:

  matrix <1,0,0, 0,sqrt(.75),.5, 0,-.5,sqrt(.75), 0,0,0>

-- 
ICQ: 46085459

Post a reply to this message

On Sun, 04 Jun 2000 12:46:20 -0700, Xplo Eristotle wrote:
>Simen Kvaal wrote:
>> 
>> >A short history question: Was there a reason for using degrees with
>> >rotate and radians with the trigonometric functions, or did just
>> >happen that way?
>>
>> I'd say it's quite natural that the _functions_ take radians as
>> parameters, because in mathematics, you rarely use degrees to express
>> angles and/or to perform trigonometric oerations, to put it that way.

Actually, in school, we used degrees almost exclusively. Radians are
a lot more logical way to express an angle (there is a good reason that
a full circle has 2 pi radians, but there isn't any good reason it has
360 degrees) and it makes a lot of formulas simpler, but in geometry
people don't think in radians, but in degrees.

>> As for the rotations, the degrees is for many a more natural and
>> intuitive approach to orientation in space. You don't say "turn
>> around pi", but "turn around 180 degrees." Maybe it would be natural
>> to have alternate rotate-definitions, accepting radians?
>
>It would be more natural, IMO, to have trig that accepts degrees. When
>I was taking trig, we did plenty of work with degrees.. and in fact,
>since we specify angles in degrees pretty much everywhere BUT in a
>classroom - even my scientific calculator uses degrees by default - I
>don't see the point of using radians, which almost no one is familiar
>with.
>
>I don't WANT to rotate an object by 1/6th pi. I don't *NEED* to rotate
>an object by 1/6th pi. But it would be nice to ask for sin(30) and get
>.5 back.

I agree. Well, actually, I don't care much whether angles are specified
in degrees, radians, hours, or whatever, but I would like to have the
same unit everywhere.


>(In the spirit of offering a solution, how about a "trig_units" keyword
>in the global_settings, where a user could specify "degrees" or
>"radians"?)

Not good. That would break existing include files. A pragma which
affects only the source file it is in, but not any included files might
be safer, but I'm not too sure about that. The only way I can see which
wouldn't break compatibility would be a second set of functions (e.g.,
dsin, dcos, ...) which uses degrees instead of radians. 

Oh well, might as well leave it as it is, it's a minor nuisance. 

	hp


-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

>
>Actually, in school, we used degrees almost exclusively.

=:O You had a BAD teacher!!

>Radians are
>a lot more logical way to express an angle (there is a good reason that
>a full circle has 2 pi radians, but there isn't any good reason it has
>360 degrees) and it makes a lot of formulas simpler, but in geometry
>people don't think in radians, but in degrees.
>

Hm. Yes and no. When using sin() functions, for example in physics
(modelling mechanical waves is an example), I really don't bother with the
degrees option. But I also say "the sum of the angles in a triangle is 180";
not pi...

Simen.

Post a reply to this message

Xplo Eristotle <inq### [at] unforgettablecom> wrote:
: It would be more natural, IMO, to have trig that accepts degrees.

  I would not mind if the rotate command would be changed to take radians
instead of degress. I would seriously mind if the trigonometric functions
would be changed to take degrees instead of radians.
  Mathematical functions are exactly that: Mathematical functions. There is
a very good reason to use radians for the trigonometric functions in
mathematics. For example the integral of 1/(1+x^2) is atan(x). You can
easily imagine why it would not not work with degrees.
  Changing the rotate command to take radians would make povray consistent.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:

>   Changing the rotate command to take radians would make povray consistent.

...but less intuitive for those with poor math backgrounds.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken wrote:

> Warp wrote:
>
> >   Changing the rotate command to take radians would make povray consistent.
>
> ...but less intuitive for those with poor math backgrounds.

... and let's not forget the rewriting of the couple of old scenes that used the
rotate command, silly them, they should have known better ;-)

G.

Post a reply to this message

On Sun, 04 Jun 2000 19:04:29 -0400, John VanSickle
<van### [at] erolscom> wrote:

>Xplo Eristotle wrote:
>> 
>> I don't WANT to rotate an object by 1/6th pi. I don't *NEED* to rotate
>> an object by 1/6th pi.
>
>Me neither.  I always do it this way:
>
>  matrix <1,0,0, 0,sqrt(.75),.5, 0,-.5,sqrt(.75), 0,0,0>

Yes but there can be only One who can control the Matrix so your point
has not been taken into account :))


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

"Peter J. Holzer" wrote:
> 
> On Sun, 04 Jun 2000 02:43:37 +0100, Thorsten Froehlich wrote:
> >The trigonometric functions use radians which is clearly stated in the
> >documentation.
> 
> A short history question: Was there a reason for using degrees with
> rotate and radians with the trigonometric functions, or did just happen
> that way?

While radians are a matter of trigonometry, degrees are more logical
when dealing with geometry.

Fabien.

Post a reply to this message

// From my own macros
// (not made public because they are either very simple or quite esoteric)
// (but I post them whenever someone might need them)
// Povingly,
// Philippe Debar



// Tired of degrees/radians conversions? try these!

#macro sind(A)
  (sin(radians(A)))
#end

#macro cosd(A)
  (cos(radians(A)))
#end

#macro tand(A)
  (tan(radians(A)))
#end

#macro asind(A)
  (degrees(asin(A)))
#end

#macro acosd(A)
  (degrees(acos(A)))
#end

#macro atan2d(A,B)
  (degrees(atan2(A,B)))
#end

Post a reply to this message

"Philippe Debar" wrote:
> // Tired of degrees/radians conversions? try these!

Nice and simple!

As an addition I just made the ones below.
They're not tested, but they should work.

#macro rotater(A)
   rotate <degrees(A.x),degrees(A.y),degrees(A.z)>
#end

#macro vrotater(A,B)
   vrotate(A,<degrees(B.x),degrees(B.y),degrees(B.z)>)
#end

#macro vaxis_rotater(A,B,C)
   vaxis_rotate(A,B,degrees(C))
#end

Greetings,

Rune

---
Updated April 25: http://rsj.mobilixnet.dk
Containing 3D images, stereograms, tutorials,
The POV Desktop Theme, 350+ raytracing jokes,
miscellaneous other things, and a lot of fun!

Post a reply to this message

Rune wrote:
> 
> #macro rotater(A)
>    rotate <degrees(A.x),degrees(A.y),degrees(A.z)>
> #end
> 

I usually add explicit vector promotion to such macros:

#macro rotater(A)
   #local An = A + <0,0,0>;
   rotate <degrees(An.x),degrees(An.y),degrees(An.z)>
#end

This is so you can use a float parameter like in regular rotate.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

In article <slr### [at] tealhhjpat>, 
hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:

> >(In the spirit of offering a solution, how about a "trig_units" keyword
> >in the global_settings, where a user could specify "degrees" or
> >"radians"?)
> 
> Not good. That would break existing include files. A pragma which
> affects only the source file it is in, but not any included files might
> be safer, but I'm not too sure about that. The only way I can see which
> wouldn't break compatibility would be a second set of functions (e.g.,
> dsin, dcos, ...) which uses degrees instead of radians. 

It should be pretty easy to implement an "#angle_unit" keyword that 
behaves like #version, you could get the current unit and save it, 
switch to your preferred unit inside your include file, and switch back 
without the user of the include knowing about it. Or you could use one 
unit in some places and another in others, depending on what you are 
doing. It could support degrees, radians, and whatever else you want, as 
well as a "standard" setting(degrees for rotate, radians for trig).

Most calculators allow you to do this, why not POV?

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message

On Fri, 23 Jun 2000 13:23:38 -0500, Chris Huff wrote:
>It should be pretty easy to implement an "#angle_unit" keyword that 
>behaves like #version, you could get the current unit and save it, 
>switch to your preferred unit inside your include file, and switch back 
>without the user of the include knowing about it. Or you could use one 
>unit in some places and another in others, depending on what you are 
>doing. It could support degrees, radians, and whatever else you want, as 
>well as a "standard" setting(degrees for rotate, radians for trig).
>
>Most calculators allow you to do this, why not POV?

Because we've heard of "locality of reference?"  Specifically, if I see
you taking the sine of an angle, how do I know which units you're in 
without reading the whole file up to that point?  Better to use macros
that make your intention clear.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <slr### [at] linuxparkerrfwicom>, 
ron### [at] povrayorg wrote:

> Because we've heard of "locality of reference?"  Specifically, if I see
> you taking the sine of an angle, how do I know which units you're in 
> without reading the whole file up to that point?  Better to use macros
> that make your intention clear.

True...it might make writing the files slightly easier, but it 
definitely wouldn't be of any help in reading them.
Macros or functions with different names would be the best solution.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message