"Patrick Elliott" <sha### [at] hotmailcom> wrote in message
news:MPG.19b6fb512886d4d9989883@news.povray.org...
> That is why I mentioned that there should be some way to scale things as
> well.

> 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.

What could be more built-in than "scale"?

Eg, let's say you have a room constructed at realistic dimensions (meters or
feet), and you want to show an object which is about 5 nanometers across.
If you want the object to appear as if it were 3 feet across, you would use:

scale(3*feet)/(5*nanometers)

Should do the trick, it's already built in, and it uses the include files
nicely.

--
...Chambers
bdc### [at] yahoocom
http://www.geocities.com/bdchambers79/
Images, 3 Player Chess, and More!

Post a reply to this message

Warp <war### [at] tagpovrayorg> writes:

> Alan Smith <ala### [at] aurora-ukcom> wrote:
> > Wouldn't it be nice if POV allowed something like :-
> > box { <-2cm, -1cm, 10mm>,  <2cm, 1cm, 1cm> }
> > 
> > This would lead to more readable code
> 
>   So tell me what this would mean:
> box { <-3cm, 4, 8mm>, <2, 14, 5cm> }
>[...]
>   IMHO plain numbers are easier to read... :P


If only lenghts were implemented, this indeed would be pretty useless.
A bigger benefit would come if other units such as lights and media
also used units and they worked together in a consistant way.


For example, If I could represent lights in terms of candelas a lot
less trial-and-error would result. Some real values for area lights
and ambient light sources (from the linux units file which credits the
IES Lighting Handbook)
    the sun at the zenith  = 1.6e9 cd/m^2
    the sun at the horizon = 6e6 cd/m^2
    the moon               = 2500 cd/m^2
    clear sky              = 8000 cd/m^2
    overcast sky           = 2000 cd/m^2
    clear sky              = 100e3 lux
    overcast sky           =  10e3 lux

and for the americans, we can talk about "foot-candles" - about as
much light as a candle reveals a foot away. :-)

Media objects like water can be described in units of turbidity
    clear mountain stream   = about 1NTU
    mississippi dry weather = about 10NTU
    mississippi rainy       = hundreds of NTU
(it's also measured in JTUs and FTUs but I don't recall what they
are).  Media objects like air are more often described in units of
"visibility" measured in km-of-visibility.

It would reduce trial-and-error quite a bit for some models if we
could just look up values and plug them into a scene.


I think it'd be really cool to place:

   A light source of 1 candlepower above a stick 
   made of media with a turbidity of 1000 NTU

and get the lighting for a candle-lit scene, or 

   an ambient light of 100 "ft-candles"

to get a typical office interior.

   Ron

(yes, I realize the dynamic range could make implementation tough all
around, and if the pov-"camera" were set up so you could see 10000
foot-candles of a sunny day, the 0.1 of a candlelight night scene
would be black)

for more fun with light units... http://www.bontronics.com/vol1-9.html

Post a reply to this message