On Wed, 27 Aug 2003 17:31:37 -0700, Patrick Elliott wrote:

> In article <pan### [at] internodeonnet>,
> pod### [at] internodeonnet says...
>> On Tue, 26 Aug 2003 17:24:02 +0100, Alan Smith wrote:
>> 
>> > Yes,  but not everyone makes that assumption. Some people "assume"
>> > that 1 unit is 1 inch and all their modelling is in feet and inches,
>> > or if say modelling a room of a house, others might choose to assume
>> > that 1 unit was 1m others may prefer to work in cm.
>> > 
>> > It would be nice if people were encoraged to work off the same system,
>> > and this would mean objects could be copied in an instant with a cut
>> > and paste between files.   It's also more readable in my view.
>> > 
>> > Alan Smith.
>> > 
>> > "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote in message
>> > news:Xns### [at] 204213191226...
>> >> ala### [at] aurora-ukcom news:3f4b68aa$1@news.povray.org
>> >>
>> >> > Am I correct that POV-Ray does not support units of measurement ie
>> >> > (mm, cm, m, km, in, ft etc)?
>> >> >
>> >> > Wouldn't it be nice if POV allowed something like :- box { <-2cm,
>> >> > -1cm, 10mm>,  <2cm, 1cm, 1cm> }
>> >>
>> >> I just assume at begin of file that i.e.
>> >>
>> >> // file ... by ...
>> >> // 1 unit = 1 cm
>> >> // 1 m = 100 units
>> >>
>> >>
>> But what is the ratio of say cm to POV units to be if it is built in? If
>> I am modelling a molecule I might use 1cm = 10^6 POV units, for a
>> planet, 1000km might = 1 POV unit.
>> 
>> I don't see how you could possible have built in units that suit all
>> purposes.
>> 
> That is why I mentioned that there should be some way to scale things as
> well. This might be possible as a set of macros, so you set some value and
> have the macros automatically adjust all of the numbers based off that
> value. The major problem with that is imho that having to have the macro
> reused each and every time that you need to use a unit is plain stupid.
> There might I supposed be some easier way, but what ever method used needs
> to calculate any change in scale you make 'once' and then us it from that
> point on.
> 
> However, this comes into a problem. Lets say that you are making a scene
> with objects in are defined by someone else in a different scales (like
> microscopic) and you want them to be 'visible' in a scene that you are
> making on a more normal scale of inches. Suddenly you have to shift
> definitions to properly include the smaller scale objects, but a normal
> include can't do that and one using macros takes extra parsing time you
> that could add up fast in a long animation. A built in method that you can
> rescale with one simple command would be far easier than using an include
> file.
> 
> Yes, there are non-built in solutions to these things, but they are often
> not as efficient. I prefer efficient. ;) Still, it is theoretically
> possible to do it in script, but only if you take into account all the
> ways some fool might try to use it. Most includes probably can't deal with
> something like the example I gave and still remain 'compatible' across
> different implementations of such a file.

Hmm maybe it would be possible (ie not too hard) to implement a scale
factor into the parser so that as objects are defined, their dimensions
are scaled.

e.g.
#declare scale_factor = 1.0;
box{-1,1}  //create a 2x2 box
#declare scale_factor = 10;
box{-1,1}  //create a 20x20 box

macros could use the old
#local old_scale = scale_factor;
#declare scale_factor = new_scale;
...
#declare scale_factor = old_scale;


I believe that this would do what you want without any need for defining
units such as cm, inches or cubits.

Post a reply to this message