Let's say I design a scene using centimeters.  You design a model using
meters, or some English unit.

Who would find a set of relatively automatic scale converters
useful?

The way I envision them, the scene builder calls one macro early in
the scene:

  ExpectMeters()

while the model maker calls another macro in their code:

union {
  sphere { pHere,rSize }
  // etc

  UseCentimeters()
}

The two macros work together to make sure that the latter item is
scaled properly (in this example, by 1/100).

Except for models using IK, the macros are pretty easy to do.  Any
takers?

Regards,
John

PS:  Pardon me if this has been done.

Post a reply to this message

In article <3F26A95E.4D3834F1@hotmail.com>,
 John VanSickle <evi### [at] hotmailcom> wrote:

> Let's say I design a scene using centimeters.  You design a model using
> meters, or some English unit.
> 
> Who would find a set of relatively automatic scale converters
> useful?

What I do is just define cm, mm, m, km, etc at the beginning of the 
scene. Then I just do something like "15.7*m" when specifying a 
dimension. A macro version could also work, something like: "km(45)"

I do use lowercase identifiers here, but I don't think a collision is 
likely for these and it helps separate them from the rest of the code.


> union {
>   sphere { pHere,rSize }
>   // etc
> 
>   UseCentimeters()
> }

I think this is a bit harder to read, putting the units separate from 
the values, and it might slow things down by forcing transformations to 
be evaluated unnecessarily, especially in the case of CSG.


union {
  sphere { pHere*cm, rSize*cm }
  // etc
}

union {
  sphere { pHere, rSize scale cm}
  // etc
}

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:

>What I do is just define cm, mm, m, km, etc at the beginning of the
>scene. Then I just do something like "15.7*m" when specifying a
>dimension.

What a simple, convenient, smart, clean way to do things.  How come I don't
think like that?

As long as others do, and I copy your ideas, I guess I'm ok.

Thanks for the tip.

I'll be using it a lot.

Dave Matthews

Post a reply to this message

John VanSickle wrote:
>Let's say I design a scene using centimeters.  You design a model using
>meters, or some English unit.
>
>Who would find a set of relatively automatic scale converters
>useful?
>
>The way I envision them, the scene builder calls one macro early in
>the scene:
>
>  ExpectMeters()
>
>while the model maker calls another macro in their code:
>
>union {
>  sphere { pHere,rSize }
>  // etc
>
>  UseCentimeters()
>}
>
>The two macros work together to make sure that the latter item is
>scaled properly (in this example, by 1/100).
>


Well, being UScentric, I have been using (usually) 1 pov unit = 1 Ft.  I
don't usually use other people's models so haven't had a problem, but as my
model collection grows I've been thinking about posting some of them to the
Pov-Ray object library, so I suppose others might find that useful.

I usually do basically what Chris described, defining my units at the start
of the file like #declare Ft = 1; #declare In = Ft/12; etc and using
something like 'translate x*14.25*Ft' or '#declare Rad = 5.5*In'.  Not sure
how your macro would handle that.

But this is something I have been wondering myself, how others deal with
different scalings and unit sizes.  I've tried to keep all of mine together
and right at the top of the file so if someone wanted to do their own
conversion it shouldn't be too difficult.

How do all you POV masters handle your units?

RG

Post a reply to this message

In article <web.3f26e01d9c12b543a0c272b50@news.povray.org>,
 "gonzo" <rgo### [at] lansetcom> wrote:

> But this is something I have been wondering myself, how others deal with
> different scalings and unit sizes.  I've tried to keep all of mine together
> and right at the top of the file so if someone wanted to do their own
> conversion it shouldn't be too difficult.

You could also base them all off of one value:

#declare m = 1;
#declare cm = m/100;
#declare mm = m/1000;
#declare km = m*1000;
#declare in = m/0.0254;
#declare ft = in*12;
#declare yd = ft*3;
#declare mi = km/1.607347;

This way, you only have one constant to change...the number of units in 
a meter, in this case. If everyone uses the same unit names, all you 
have to do is change that value. (or just remove it and place it 
elsewhere, such as in a "units.inc" file)

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

On Tue, 29 Jul 2003 16:53:22 -0500, Christopher James Huff wrote:

...
> #declare in = m/0.0254;
...

Hmmm... Are you sure about this Christopher ?

;)


Tor Olav

Post a reply to this message

In article 
<pan### [at] THISSHOULDBEREMOVEDhotmailcom>,
 "Tor Olav Kristensen" <tor### [at] THISSHOULDBEREMOVEDhotmailcom> 
 wrote:

> > #declare in = m/0.0254;
> ...
> 
> Hmmm... Are you sure about this Christopher ?

Ah...I guess that should be multiplication, shouldn't it...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

On Tue, 29 Jul 2003 19:11:54 -0500, Christopher James Huff wrote:

> In article 
> <pan### [at] THISSHOULDBEREMOVEDhotmailcom>,
>  "Tor Olav Kristensen" <tor### [at] THISSHOULDBEREMOVEDhotmailcom> 
>  wrote:
> 
>> > #declare in = m/0.0254;
>> ...
>> 
>> Hmmm... Are you sure about this Christopher ?
> 
> Ah...I guess that should be multiplication, shouldn't it...


Yes (Unless you have very long inches in the US)


Tor Olav

Post a reply to this message

Cool thread, it's always interesting to see how others handle common 
problems.
I use to define all my models in meters. And when it is not appropriate 
I define the object in centimeters for example and then I scale the 
whole model to meters. I do the same with models I get from outside.

JC

John VanSickle wrote:
> Let's say I design a scene using centimeters.  You design a model using
> meters, or some English unit.
> 
> Who would find a set of relatively automatic scale converters
> useful?
> 
> The way I envision them, the scene builder calls one macro early in
> the scene:
> 
>   ExpectMeters()
> 
> while the model maker calls another macro in their code:
> 
> union {
>   sphere { pHere,rSize }
>   // etc
> 
>   UseCentimeters()
> }
> 
> The two macros work together to make sure that the latter item is
> scaled properly (in this example, by 1/100).
> 
> Except for models using IK, the macros are pretty easy to do.  Any
> takers?
> 
> Regards,
> John
> 
> PS:  Pardon me if this has been done.

Post a reply to this message

> #declare m = 1;
> #declare cm = m/100;
> #declare mm = m/1000;

I strongly suggest to use MUCH larger values if possible; see my
thread "Small is NOT BEAUTIFUL" in p.g, 11 Feb. 2003. Especially
transparency, almost-coincident surfaces and shadows are highly
problematic. For indoor scenes of "normal" scale I suggest to
use 1 POV-unit = 1 mm or less.

   Sputnik


P.S. If the sphere in the second "Small is NOT BEAUTIFUL" demo scene
     is removed, then all errors are reduced by about three orders
     of magnitude -- try with scale 0.004!

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote in 
news:3F26A95E.4D3834F1@hotmail.com:


> 
> PS:  Pardon me if this has been done.

Sonya Roberts did it in 1997 ;)  From micrometer to lightyear

http://www.imp.org/media/archives/units.zip



-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

Post a reply to this message

Also sprach Christopher James Huff <cja### [at] earthlinknet> -- Tue, 29 Jul
2003 12:41:45 -0500:


>
>What I do is just define cm, mm, m, km, etc at the beginning of the 
>scene. Then I just do something like "15.7*m" when specifying a 
>dimension. A macro version could also work, something like: "km(45)"
>
>I do use lowercase identifiers here, but I don't think a collision is 
>likely for these and it helps separate them from the rest of the code.

I do a similar thing.

#declare inches=1;
#declare inch=1;
#declare feet=12*inches;
#declare foot=feet;

which makes it nice to say
#declare blah=6*feet+4*inches;	// super American dumbkopf mode of measuring.

One of the important things (to me) in modeling is to remember to scale
*everything*.

This construct is guaranteed to cause trouble:
#declare mysize=4*inches;
difference {
	box {
		<-mysize/2,-mysize/2,-mysize/2>
		<mysize/2,mysize/2,mysize/2>
	}
	cylinder {
		z*-mysize/2-1, z*mysize/2+1			// <-- evil plus and minus 1
		1*inches
	}
}

I always used +/- 1 (or 100) when doing CSG, to avoid coincidence.
When i started rescaling my objects (#declare feet=1; #declare inch=1/12;)
these +/- 1s really bit me in the butt.  It's important to say

		z*-mysize/2-1*inch, z*mysize/2+1*inch



+++
I also have a couple of non linear predefines:

#declare pi2=pi*2;
#declare rot180=pi;
#declare rot90=pi/2;
#declare rot45=pi/4;

which are useful in sin and cos.

dik

Post a reply to this message

On Tue, 29 Jul 2003 14:01:39 -0700, gonzo quoth:

> How do all you POV masters handle your units?

I've got a file that I include called "units.inc" that defines assorted
units of measurement in terms of each other.  It defaults to 1 cm = 1 POV
unit, but if I change the definition of a centimeter before including the
file, it adjusts all units accordingly.  This way, I can mix inches,
centimeters, feet, and light years without any trouble.

-- 
Mark

Post a reply to this message

Christopher James Huff wrote:
>In article <web.3f26e01d9c12b543a0c272b50[at]news.povray.org>,
>
>You could also base them all off of one value:
>
>#declare m = 1;
>#declare cm = m/100;
>#declare mm = m/1000;
>#declare km = m*1000;
>#declare in = m/0.0254;
>#declare ft = in*12;
>#declare yd = ft*3;
>#declare mi = km/1.607347;
>
>This way, you only have one constant to change...the number of units in
>a meter, in this case. If everyone uses the same unit names, all you
>have to do is change that value. (or just remove it and place it
>elsewhere, such as in a "units.inc" file)
>


Yes, that is what I meant.  I define Ft = 1 unit, then everything else is
based on Ft.  So far I haven't used much past yards though... guess I need
to expand my horizons to get into light years ;-)

RG

Post a reply to this message

Mark Wagner wrote:
>On Tue, 29 Jul 2003 14:01:39 -0700, gonzo quoth:
>
>> How do all you POV masters handle your units?
>
>I've got a file that I include called "units.inc" that defines assorted
>units of measurement in terms of each other.  It defaults to 1 cm = 1 POV
>unit, but if I change the definition of a centimeter before including the
>file, it adjusts all units accordingly.  This way, I can mix inches,
>centimeters, feet, and light years without any trouble.
>
>Mark
>

Thanks all for the comments & insights!  I hope John got the info he needed
from this thread, but even if he didn't I certainly found it informative!

This was something I had recently been running up against since my
"architecture" IRTC entry. That one pretty much demanded a standardized
method of scaling, so I started using feet since most building specs (at
least here in the US) are in feet.

Once I started using that though, I found I had problems with earlier models
where I had hard coded numbers or used arbitrary unit sizes. Some were so
bad it was easier to build a new model than to convert the old one!

So now I have my unit standard, and it sounds like enough people are using a
system similar enough that conversion shouldn't be a major issue. (And I
should have some good objects to share in my surreal IRTC entry, as long as
I get it done in time...)

Thanks again!

RG

Post a reply to this message