Wouldn't it be nice if the next generation SDL allowed for something like this:

    sphere { Pos, 7.3 mm }

or

    box {
        -<10in, 7ft, 3ft>, <10in, 7ft, 3ft>
        rotate y * 1.7rad
        translate <10yd+3ft, 3ft, 0>
    }

or

    media { absorbtion 0.2/1m }

or even

    media { absorbtion 0.2/m }

or

    media { absorbtion 0.2m^-1 }

?

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Wouldn't it be nice if the next generation SDL allowed for something like this:
>
>     sphere { Pos, 7.3 mm }
>
> or
>
>     box {
>         -<10in, 7ft, 3ft>, <10in, 7ft, 3ft>
>         rotate y * 1.7rad
>         translate <10yd+3ft, 3ft, 0>
>     }
>
> or
>
>     media { absorbtion 0.2/1m }
>
> or even
>
>     media { absorbtion 0.2/m }
>
> or
>
>     media { absorbtion 0.2m^-1 }
>
> ?

It isn't immediately clear to me why you couldn't implement units like that on
your own.  One of the thinks that makes pov powerful is the fact that you can.
Consider something like this:

#declare mm = 1;
#declare m = 1000 * mm;
#declare in = 25.4 * mm;
#declare ft = 12 * in;
#declare yd = 3 * ft;


    sphere { Pos, 7.3*mm }

    box {
        -<10*in, 7*ft, 3*ft>, <10*in, 7*ft, 3*ft>
        rotate y * 1.7*rad
        translate <10*yd+3*ft, 3*ft, 0>
    }

    media { absorbtion 0.2/(1*m) }

    media { absorbtion 0.2/m }

    media { absorbtion 0.2*m^-1 }

Since all of the units depend on the value for mm, if someone else had a scene
with a different scale, then you'd only need to change the size of mm in pov
units and the rest of your items would scale accordingly.

I do use real world units in some of my scenes because it can make things easier
to picture, but I don't see the need for a change, primarily since the syntax
above has the potential for ambiguity:

#declare MyVar = 1.5;
sphere{ Pos, 1.5ft }   // ok, fine
sphere{ Pos, MyVarft } // wait, the value of MyVar used in feet, or MyVarft?

If we use a space or operator to avoid ambiguity, we haven't really done much
differently from using the units as a variable and providing a conversion
factor.


-Reactor

Post a reply to this message

"Reactor" <rea### [at] hotmailcom> wrote:
> It isn't immediately clear to me why you couldn't implement units like that on
> your own.  One of the thinks that makes pov powerful is the fact that you can.
> Consider something like this:

(1) I would want to eliminate the need for the "*" operator (being lazy), and
the #declare intro needed (at least for the most common dimensions).

(2) Though of course your approach is perfectly possible, it doesn't come with a
standard framework; for instance, someone may use "m" while someone else may use
"meter" (or "metre" :P).

(3) Having a standard framework for distances would also allow to interoperate
with features inherently dependent on actual physical distance (like the
experimental Subsurface Light Transport code).

> #declare MyVar = 1.5;
> sphere{ Pos, 1.5ft }   // ok, fine
> sphere{ Pos, MyVarft } // wait, the value of MyVar used in feet, or MyVarft?

Definitely MyVarft of course. Can't be implemented any different, and I guess it
wouldn't be difficult to explain this to users.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Reactor" <rea### [at] hotmailcom> wrote:
> > It isn't immediately clear to me why you couldn't implement units like that on
> > your own.  One of the thinks that makes pov powerful is the fact that you can.
> > Consider something like this:
>
> (1) I would want to eliminate the need for the "*" operator (being lazy), and
> the #declare intro needed (at least for the most common dimensions).
>
> (2) Though of course your approach is perfectly possible, it doesn't come with a
> standard framework; for instance, someone may use "m" while someone else may use
> "meter" (or "metre" :P).
>
> (3) Having a standard framework for distances would also allow to interoperate
> with features inherently dependent on actual physical distance (like the
> experimental Subsurface Light Transport code).
>

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?

-Reactor

Post a reply to this message

clipka wrote:
> Wouldn't it be nice if the next generation SDL allowed for something like this:
> 
>     sphere { Pos, 7.3 mm }
> 
> or
> 
>     box {
>         -<10in, 7ft, 3ft>, <10in, 7ft, 3ft>
>         rotate y * 1.7rad
>         translate <10yd+3ft, 3ft, 0>
>     }
> 
> or
> 
>     media { absorbtion 0.2/1m }
> 
> or even
> 
>     media { absorbtion 0.2/m }
> 
> or
> 
>     media { absorbtion 0.2m^-1 }
> 
> ?
> 
> 
Are you sure that this feature would not simply add unneeded and 
confusing complexity,
especially in simply dimensions? The ability to define absorotion as you 
suggest might
indeed be useful. But the screen dimension units don't correspond to any 
"real" units and it's
easy enough for the user to adapt them to his own arbitrary units. I'm 
not sure though,
if one now wants to use, say, feet and millimeters with a number of 
objects, the scaling
factor clutter up the code. "Rad" and "deg" for angles and rotation 
*would* be useful.

I suppose thr proposed feature would allow:
sphere{<1ft,2mm,1.5 angstroms>,3nm}

but what about
sphere{<1,2in,3mm>,2}
would that generate and error message? And what might it say?

David

Post a reply to this message

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