David H. Burns wrote:
> "Rad" and "deg" for angles and rotation 
> *would* be useful.

They're already implemented.

// Declares the variable rad to be 45 degrees converted into radians.
#declare rad = radians(45);

// Declares the variable deg to be 0.3 radians converted into degrees.
#declare deg = degrees(0.3);

-- 
Chambers

Post a reply to this message

This has come up before, and I've even seen a few include files written 
to standardize it.

The problem with standards, of course, is that they must be adhered to. 
  Unfortunately, none of the aforesaid include files really became popular.

Perhaps adding a "metrics.inc" to the standard include files, and 
requiring its use as part of the standards for the object library, would 
be a good idea.

-- 
Chambers

Post a reply to this message

Chambers schrieb:
> David H. Burns wrote:
>> "Rad" and "deg" for angles and rotation *would* be useful.
>
> They're already implemented.
>
> // Declares the variable rad to be 45 degrees converted into radians.
> #declare rad = radians(45);
>
> // Declares the variable deg to be 0.3 radians converted into degrees.
> #declare deg = degrees(0.3);
>
They're perfectly counter-intuitive for use in "rotate" though:

    // trying to express that I intend to rotate by 45 degrees,
    // with the effect of rotating by 45 radians instead
    rotate x * degrees(45)

    // trying to express that I intend to rotate by 0.3 radians,
    // with the effect of rotating by something particularly useless
    rotate y * radians(0.3)

Post a reply to this message

> It would be neat to have an "official" set of units, but I still favor 
> them as
> regular variables that are defined in terms of each other.  It could 
> simplify
> the use of other people's objects, which will become more of an issue as 
> the
> object collection grows.  A standard include for SI and commonly used 
> non-SI
> units?

It's not going to work...

Try and render this: (with some pigments and lights...)

#declare mm = 1;
#declare  m = 1000 * mm;
#declare km = 1000 * m;

sphere{ 0 , 6400*km }
camera{ location <3000,1000,25000>*km }

Even if you define m as 1 (which would seem the most logical choice to me) 
it still doesn't work.

For some reason POV doesn't like (not very) big numbers, and if you define a 
certain distance as "1", some scenes are bound to break.

Post a reply to this message

clipka wrote:
> They're perfectly counter-intuitive for use in "rotate" though:

True, they're meant for conversion rather than designation.

-- 
Chambers

Post a reply to this message

Chambers schrieb:
> clipka wrote:
>> They're perfectly counter-intuitive for use in "rotate" though:
>
> True, they're meant for conversion rather than designation.
>
... which makes my point, because I'd love to have some means of 
designation ;-)

Post a reply to this message

Chambers wrote:
> David H. Burns wrote:
>> "Rad" and "deg" for angles and rotation *would* be useful.
> 
> They're already implemented.
> 
> // Declares the variable rad to be 45 degrees converted into radians.
> #declare rad = radians(45);
> 
> // Declares the variable deg to be 0.3 radians converted into degrees.
> #declare deg = degrees(0.3);
> 

I had forgotten that.

Post a reply to this message

clipka wrote:
> Chambers schrieb:
>> David H. Burns wrote:
>>> "Rad" and "deg" for angles and rotation *would* be useful.
>>
>> They're already implemented.
>>
>> // Declares the variable rad to be 45 degrees converted into radians.
>> #declare rad = radians(45);
>>
>> // Declares the variable deg to be 0.3 radians converted into degrees.
>> #declare deg = degrees(0.3);
>>
> They're perfectly counter-intuitive for use in "rotate" though:
> 
>    // trying to express that I intend to rotate by 45 degrees,
>    // with the effect of rotating by 45 radians instead
>    rotate x * degrees(45)
> 
>    // trying to express that I intend to rotate by 0.3 radians,
>    // with the effect of rotating by something particularly useless
>    rotate y * radians(0.3)
True too. "Built in" unit definitions would be useful, maybe with a 
default that could
be set as in calculators?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> They're perfectly counter-intuitive for use in "rotate" though:

>     // trying to express that I intend to rotate by 45 degrees,
>     // with the effect of rotating by 45 radians instead
>     rotate x * degrees(45)

>     // trying to express that I intend to rotate by 0.3 radians,
>     // with the effect of rotating by something particularly useless
>     rotate y * radians(0.3)

#declare deg = 1;
#declare rad = radians(1);

rotate x * 45*deg
rotate y * 0.3*rad

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
> clipka <ano### [at] anonymousorg> wrote:
>> They're perfectly counter-intuitive for use in "rotate" though:
> 
>>     // trying to express that I intend to rotate by 45 degrees,
>>     // with the effect of rotating by 45 radians instead
>>     rotate x * degrees(45)
> 
>>     // trying to express that I intend to rotate by 0.3 radians,
>>     // with the effect of rotating by something particularly useless
>>     rotate y * radians(0.3)
> 
> #declare deg = 1;
> #declare rad = radians(1);
> 
> rotate x * 45*deg
> rotate y * 0.3*rad

#declare Foo = sin(45*deg);
#declare Bar = cos(0.3*rad);

FAIL.

Which is to say: POV-Ray's current system for representing angles is 
inconsistent, and a genuine built-in mechanism for specifying values as 
either degree or radians would be helpful to mend this.

Note that this isn't about "how powerful is the language", but "how easy 
is it to learn and use". Otherwise, we could simply refer to the 
Turing-completeness of the language and be done with it.

Post a reply to this message