Alan Smith <ala### [at] aurora-ukcom> wrote:
> box { <-3cm, 4, 8mm>, <2, 14, 5cm> }
> would mean exactly what you said, the non-unitised measurements
> would be native POVRay units.

  The problem is that there's no clue about what is the relation between
native units and named units. Is 1 native unit larger, smaller or equal
to, for example, 1m? Who decides it? How can the user know?

> box { <-2in, -5ft, 3m>, <3cm, 5in, -2ft> }

> is would mean exactly what you said, some of the objects in my house
> including the room dimensions are in ft and in and many of my objects
> are clearly designed in cm & mm - so why not!

  But not in the same object, as in the example above.

> However,  in one of my scenes I have a very nice fancy plastic transparent
> ruler :- box { <0,0,0>, <31, 2.8, 0.3> etc etc}.   Wouldn't it be nice if
> you
> could just cut and paste it instantly into yours if I said :-
> box { <0,0,0>, <31cm, 2.8cm, 3mm> etc etc}.   Or any of my other office
> objects for that matter.

  Personally I don't find it fancy (but that's just my opinion). Mixing
units can get confusing and doesn't really add any relevant information.
  If knowing the exact real-life measures is important, you can just add
a comment at the beginning of the file like

// All units are in meters

  Then you'll know that "1" means 1 meter, "0.01" means 1 cm etc.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

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.

Post a reply to this message

In article <3f4c193f@news.povray.org>,
 "Alan Smith" <ala### [at] aurora-ukcom> wrote:

> If the whole world is moving forward in terms of standards such as XML, SVG,
> VRML, etc, it seems a shame that I cannot even cut and paste a simple object
> from one file to another and it not work!   Not because of the
> implementation I might add, but because the standard does not even allow a
> means for it to work.

But the standard *does* allow a means. Pick a standard set of unit names 
(mm, m, mi, in, etc...), and design all objects with these. No need for 
a patch...a patch would add absolutely nothing except a syntax that is 
shorter by 1 character. A units.inc file would do just as well, if it 
were adopted by a large segment of the community.

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

ala### [at] aurora-ukcom news:3f4b97b5$1@news.povray.org

> Firstly, my experiance comes from having designed and developed

And the URL to them is... ?

> Secondly, you are clearly either too arrogant or too stupid not to

I don't think that ABX is the arogant person in this discussion.

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

On 27 Aug 2003 14:25:02 -0400, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:


>
>I don't think that ABX is the arogant person in this discussion.

I agree with Rafal that ABX is not arrogant. His colloquial English is not
perfect i.e. when he said; "If community would think it is useless you will
notice not much discussions about it." I am sure he meant something like "If the

English speakers for the time and effort they put into framing their replies in
English. A few months ago I was offended by something he said and after a short
private correspondence we got it sorted out. He is, and tries to be a helpful
guy.


Regards
        Stephen

Post a reply to this message

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

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

In article <pan### [at] internodeonnet>, 
pod### [at] internodeonnet says...
> 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.
> 

Yes it would and is what most people do anyway, but that doesn't solve 
the issue that it is sometimes nice to know how big something really is 
in real measurements. Like when trying to duplicate a real world object. 
You can build a room and all the rest using 'normal' units, but then if 
you decide to add a glass into the scene you end up having to play with 
the scale, because the original scene didn't take into account real world 
sizes and you aren't entirely sure what an inch is in that context. 
Scaling is a crude and inaccurate way to handle precise measurements.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

"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