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.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message