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

This would lead to more readable code, greater ease of 'real world' scene
modelling with mixed sizes of objects and, most importantly, greater scope
for sharing objects from other people who generously donate their source.

At the moment I achieve this by using suitable declares and coding as :-
box { <-2*cm, -1*cm, 10*mm>,  <2*cm, 1*cm, 1*cm> }


Which goes a long way to meeting my needs, but it still does not do anything
for supporting portability of coded objects between scene files.

This would surely be a simple modification to the parser and would still
leave the ability for people to work in a 'unit-less' fashion if they like?

Alan Smith.

Post a reply to this message

On Tue, 26 Aug 2003 15:03:21 +0100, "Alan Smith" <ala### [at] aurora-ukcom>
wrote:
> Wouldn't it be nice if POV allowed something like :-
> box { <-2cm, -1cm, 10mm>,  <2cm, 1cm, 1cm> }

That's possible with
http://www.imp.org/cgi-bin/viewcvs/viewcvs.cgi/*checkout*/escape/scenes/units.inc

ABX

Post a reply to this message

Many thanks for the link to the include file.   This is what I currently do
myself, however
I still make the point that it would be usefull to formalise it within
POV-Ray itself as this would
encourage its use and lead to greater code portabillity.

Alan Smith.

"ABX" <abx### [at] abxartpl> wrote in message
news:mdqmkvcggpr45qkt3bbji5aj7igdgodrkg@4ax.com...
> On Tue, 26 Aug 2003 15:03:21 +0100, "Alan Smith"
<ala### [at] aurora-ukcom>
> wrote:
> > Wouldn't it be nice if POV allowed something like :-
> > box { <-2cm, -1cm, 10mm>,  <2cm, 1cm, 1cm> }
>
> That's possible with
>
http://www.imp.org/cgi-bin/viewcvs/viewcvs.cgi/*checkout*/escape/scenes/units.inc
>
> ABX

Post a reply to this message

On Tue, 26 Aug 2003 15:17:55 +0100, "Alan Smith" <ala### [at] aurora-ukcom>
wrote:
> Many thanks for the link to the include file.   This is what I currently do
> myself, however
> I still make the point that it would be usefull to formalise it within
> POV-Ray itself as this would
> encourage its use and lead to greater code portabillity.

Could you elaborate on "encourage its use" and "greater code portabillity" ?
Personally I do not see those benefits but I can blind for something. In
particular what could be done with '1cm' which can't be done with '1*cm' ?

ABX

Post a reply to this message

By encourage its use I mean that if it is a formally accepted concept within
POV
then people are more likely to know its there and more likely to use it -
especially
when they see the benefits of re-using other peoples objects without any
re-scaling
required.    I did not know of the existence of Sonya Roberts "Units"
include file
until you pointed it out - what if someone else out there defined another
"Units" file
which other people used - the definition of mm,cm,m,ft & in might be totally
different -
standardisation has not been achieved nor generally portability of objects.
If I copy
an object from someone's scene using an alternative definition of the units
then it will
not just drop in to mine and work - yes I know I could scale it but that's
not the point.

lets say I have a scene with a toy train in it which you would like to copy
into your scene,
but I have defined

#declare in = 1
#declare ft = 12
#declare cm = 2.51
etc

in this scenario you would need to apply scaling to my object when you use
it, all I'm saying
is that if the system was formalised into the parser then a) it would be
more readable and b)
more people would use it as you could simply incorporate other peoples
objects without
having to do anything other than cut and paste.

Alan Smith.

"ABX" <abx### [at] abxartpl> wrote in message
news:d0rmkvk6ki62c2hq3h5frdkb1rbe1q5c1q@4ax.com...
> On Tue, 26 Aug 2003 15:17:55 +0100, "Alan Smith"
<ala### [at] aurora-ukcom>
> wrote:
> > Many thanks for the link to the include file.   This is what I currently
do
> > myself, however
> > I still make the point that it would be usefull to formalise it within
> > POV-Ray itself as this would
> > encourage its use and lead to greater code portabillity.
>
> Could you elaborate on "encourage its use" and "greater code portabillity"
?
> Personally I do not see those benefits but I can blind for something. In
> particular what could be done with '1cm' which can't be done with '1*cm' ?
>
> ABX

Post a reply to this message

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




-- 
#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 Tue, 26 Aug 2003 15:56:04 +0100, "Alan Smith" <ala### [at] aurora-ukcom>
wrote:
> By encourage its use I mean that if it is a formally accepted concept within POV
> then people are more likely to know its there and more likely to use it - especially
> when they see the benefits of re-using other peoples objects without any re-scaling
> required.

But on the other hand for many works you do not need units at all so they are
unnecessary typing. Do you need units to draw graph? POV-Ray is known to be a
tool in scientific works to visualize processess. Some sciences operates on on
units, some not. And soon you incorporate units into language you will receive
complaining why other units are not supported. It is easier to change
units.inc than povray.exe

> I did not know of the existence of Sonya Roberts "Units" include file
> until you pointed it out - what if someone else out there defined another "Units"
file
> which other people used - the definition of mm,cm,m,ft & in might be totally
different -
> standardisation has not been achieved nor generally portability of objects.
> If I copy an object from someone's scene using an alternative definition of the
units
> then it will not just drop in to mine and work - yes I know I could scale it but
that's
> not the point.

There is no difference between various units.inc - as long as they use the
same letters for naming units and they preserve the same relations they are
compatible regardless base unit.

ABX

Post a reply to this message

As I said in my original posting, I would not want to force people to
have to use units on dimensions - it would be optional.
Quote - "This would surely be a simple modification to the parser and
would still leave the ability for people to work in a 'unit-less' fashion if
they like?"

You said there is no difference between various units.inc - I beg to differ.
Sonya Roberts "Units" include file is not deployed with the POV Ray
installation as
far as I know, so tomorrow (lets say) I'm going to release onto the Web my
own
comprehensive version of units.inc which contains :-

#declare in = 1
#declare ft = 12
#declare cm = 2.51
etc etc etc

A box{ <0cm,0cm,0cm>,<1cm,1cm,1cm>} written against Sonya Roberts include
file will
translate into a 1 unit cube by povray and under my Units.inc it would
translate into a 2.51
units cube within Povray.    Therefore any object taken from a scene written
using the former
include file will need scaling if incorporated into one using the second.
The situation is made
worse if someone has not even used any units in the first place.   Or
someone may have defined
their own unit declarations.

All I'm saying it that -

a) It would be nice if people were encouraged to use (but optional)
dimensional units
in 'real world' modelling and in a standardised way.
b) The above would be encouraged by formalising the concept into Povray so
everyone knows
and works of the same definitions.
c) It would lead to greater readability of the source file.
d) It would mean it is easier to cut and paste objects from other peoples
files.

Alan Smith.



"ABX" <abx### [at] abxartpl> wrote in message
news:d1umkv8cb5ictbfnknmuumcl0mnoks54hk@4ax.com...
> On Tue, 26 Aug 2003 15:56:04 +0100, "Alan Smith"
<ala### [at] aurora-ukcom>
> wrote:
> > By encourage its use I mean that if it is a formally accepted concept
within POV
> > then people are more likely to know its there and more likely to use
it - especially
> > when they see the benefits of re-using other peoples objects without any
re-scaling
> > required.
>
> But on the other hand for many works you do not need units at all so they
are
> unnecessary typing. Do you need units to draw graph? POV-Ray is known to
be a
> tool in scientific works to visualize processess. Some sciences operates
on on
> units, some not. And soon you incorporate units into language you will
receive
> complaining why other units are not supported. It is easier to change
> units.inc than povray.exe
>
> > I did not know of the existence of Sonya Roberts "Units" include file
> > until you pointed it out - what if someone else out there defined
another "Units" file
> > which other people used - the definition of mm,cm,m,ft & in might be
totally different -
> > standardisation has not been achieved nor generally portability of
objects.
> > If I copy an object from someone's scene using an alternative definition
of the units
> > then it will not just drop in to mine and work - yes I know I could
scale it but that's
> > not the point.
>
> There is no difference between various units.inc - as long as they use the
> same letters for naming units and they preserve the same relations they
are
> compatible regardless base unit.
>
> ABX

Post a reply to this message

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
>
>
>
>
> -- 
> #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 Tue, 26 Aug 2003 17:06:21 +0100, "Alan Smith" <ala### [at] aurora-ukcom>
wrote:
> As I said in my original posting, I would not want to force people to
> have to use units on dimensions - it would be optional.
> Quote - "This would surely be a simple modification to the parser and
> would still leave the ability for people to work in a 'unit-less' fashion if
> they like?"

From what experience "surely" in that quote come? This is exactly my
opportunity. There is probably much work and the only benefit is that you
don't have to type "*" because "cm" still have to be typed. But some people
will complain that they do not want "1cm" - they want "1 cm" or "1 CM" or
"1centimeter". Moreover more possibilities, and making this unit optional
makes parser only more complicated internally and increases parsing time.

> You said there is no difference between various units.inc - I beg to differ.

Then you do not understand that text is translated into floats during _final_
parsing, not during posting scene or object via mailer. Simple, imagine you
have units.inc:

  #declare cm=0.75;
  #declare m=100*cm;
  #declare km=1000*m;

and a scene:

  #version 3.5;
  global_settings{assumed_gamma 1.0}
  camera{
    up 1*cm 
    right (image_width/image_height)*cm 
    direction z*1*cm
    location -10*z*cm
    look_at 0
  }
  light_source{90*m rgb 1}
  sphere{ 0 1*km pigment{agate scale .5*km}}

render it to image1.png. Now send it to your friend and ask to write own
units.inc. The only requirement is that it has to define cm, m, km in correct
_relation_. Now ask him for rendering to image2.png. Then compare result. Note
he don't have to cm as base. He can for example made his units.inc as:

  #declare m=12*76.13/143;
  #declare cm=.1*m;
  #declare km=1000*m;

And now tell me. Is result different ? :-)

ABX

Post a reply to this message

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

  Mixing unit types doesn't help readability either:

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

  Of course we could obfuscate this even more:

#declare Location = -2cm*3in*<3ft, 5cm*3in, 2km>;

  One could wonder what is "2 centimeters times 3 inches"...

  IMHO plain numbers are easier to read... :P

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Firstly, my experiance comes from having designed and developed
software since 1978, I wrote my first (of many) parser/compiler at
age 17, I have written my own Raytracer as a project more than
15 years ago, can program in more languages and several processors
assembly code than I can shake a stick at. I have A level (pre-university
level)
qualifications in Maths, Further maths and passed the "Special Mathematics
Paper",
I have a quality degree in Computer Science and currently own my own
sucessful software house with 20 staff!    So - I know
what is difficult and what is  not.  Anyone writing a parser that cannot
cope with a bit of whitespace (the difference between 1cm and 1 cm)
should not be writing parsers.

Secondly, you are clearly either too arrogant or too stupid not to read what
I am saying.   I am not talking about portability of complete scene files
but
portabillity of the objects defined within different files from different
people.
I clearly agree with your simple example - my maths skills do extend that
far,
but you have clearly or deliberately missed the point - which is that I
would
like to cut a 1 object from a room scene you have created and "drop" it
into mine along with several others from within other scene files -  without
modification and without worrying about what your units of measure are
compared to mine.

Lastly ... you are being deliberately contentious and a complete prat and
just
looking to score some childish points as illustrated by your "This is
exactly my
opportunity." statement.

"ABX" <abx### [at] abxartpl> wrote in message
news:gq1nkvsldnbj4ui2he626l1vto6t7qfb3k@4ax.com...
> On Tue, 26 Aug 2003 17:06:21 +0100, "Alan Smith"
<ala### [at] aurora-ukcom>
> wrote:
> > As I said in my original posting, I would not want to force people to
> > have to use units on dimensions - it would be optional.
> > Quote - "This would surely be a simple modification to the parser and
> > would still leave the ability for people to work in a 'unit-less'
fashion if
> > they like?"
>
> From what experience "surely" in that quote come? This is exactly my
> opportunity. There is probably much work and the only benefit is that you
> don't have to type "*" because "cm" still have to be typed. But some
people
> will complain that they do not want "1cm" - they want "1 cm" or "1 CM" or
> "1centimeter". Moreover more possibilities, and making this unit optional
> makes parser only more complicated internally and increases parsing time.
>
> > You said there is no difference between various units.inc - I beg to
differ.
>
> Then you do not understand that text is translated into floats during
_final_
> parsing, not during posting scene or object via mailer. Simple, imagine
you
> have units.inc:
>
>   #declare cm=0.75;
>   #declare m=100*cm;
>   #declare km=1000*m;
>
> and a scene:
>
>   #version 3.5;
>   global_settings{assumed_gamma 1.0}
>   camera{
>     up 1*cm
>     right (image_width/image_height)*cm
>     direction z*1*cm
>     location -10*z*cm
>     look_at 0
>   }
>   light_source{90*m rgb 1}
>   sphere{ 0 1*km pigment{agate scale .5*km}}
>
> render it to image1.png. Now send it to your friend and ask to write own
> units.inc. The only requirement is that it has to define cm, m, km in
correct
> _relation_. Now ask him for rendering to image2.png. Then compare result.
Note
> he don't have to cm as base. He can for example made his units.inc as:
>
>   #declare m=12*76.13/143;
>   #declare cm=.1*m;
>   #declare km=1000*m;
>
> And now tell me. Is result different ? :-)
>
> ABX

Post a reply to this message

On Tue, 26 Aug 2003 18:24:04 +0100, "Alan Smith" <ala### [at] aurora-ukcom>
wrote:
> Firstly, my experiance comes from having designed and developed
> software since 1978, I wrote my first (of many) parser/compiler at
> age 17, I have written my own Raytracer as a project more than
> 15 years ago, can program in more languages and several processors
> assembly code than I can shake a stick at.

Honestly, then I don't understand even more your feature request. On one hand
you can go to sources and check if it is easy to incorporate this feature and
if it is just do it. On second hand I really surprized you really think 'cm'
is more readable when you showed your experience. In my intuition it is
"useless by default" :-) The only benefit of adding some postfixes I can
imagine are those like in complex numbers in D language:
http://www.digitalmars.com/d/cppcomplex.html

> Secondly, you are clearly either too arrogant or too stupid not to read what
> I am saying.   I am not talking about portability of complete scene files
> but portabillity of the objects defined within different files from different
> people.

????? What's the difference ? Take _any_ part of example I posted, and insert
it into _any_ scene which was created according units.inc rules and it still
works :-)

> I clearly agree with your simple example - my maths skills do extend that
> far, but you have clearly or deliberately missed the point - which is that I
> would like to cut a 1 object from a room scene you have created and "drop" it
> into mine along with several others from within other scene files -  without
> modification and without worrying about what your units of measure are
> compared to mine.

Please, show me example working example of two scenes made over two various
units.inc where units.inc preserve _relations_ between units and objects are
not movable. The only problem I can imagine is left and right coordinate
system but it can be solved too.

> Lastly ... you are being deliberately contentious and a complete prat and
> just looking to score some childish points as illustrated by your "This is
> exactly my opportunity." statement.

That's a discussion forum, and in this _discussion_ I tried to convince you
that incorporating "cm" in "hard" way is pointless when you compare benefits
with current state of parser and tastes of many users. I'm sorry it sounded
like monology from prat - I tried to be _helpful_ like in whole story of my
contributing into community. I'm sorry my "foolish" hurt your person. As long
as you are talking about optional feature you are free to make a patch with
it. This can be considered for inclusion in MegaPOV. See
http://megapov.inetart.net/manual/internals.html for guidlines.

ABX

Post a reply to this message

box { <-3cm, 4, 8mm>, <2, 14, 5cm> }
would mean exactly what you said, the non-unitised measurements
would be native POVRay units.   Of course you could build all sorts
of rule checking into the parser to provide warnings etc ... but I'm not
suggesting this, as I agree this would be a great deal more effort to code
and is taking things too far.

As far as :-
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!   A agree that if you
passed these kind of measurements to your local builder he might query
it, but again I'm not suggesting that level of sophistication in the parser
would be needed.   One has to rely on a little common sense.

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.

#declare Location = -2cm*3in*<3ft, 5cm*3in, 2km>;
We'll, like any language computer or otherwise it is always possible to
create
less readable or sensible but legitimate statements if one abandons common
sense and desires to do so.

I'm suggesting that if these units were incorporated as standard multipliers
into the parser, it would promote the quick interchange of objects without
the need for any scaling.

Alan Smith.



"Warp" <war### [at] tagpovrayorg> wrote in message
news:3f4b903a@news.povray.org...
> 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> }
>
>   Mixing unit types doesn't help readability either:
>
> box { <-2in, -5ft, 3m>, <3cm, 5in, -2ft> }
>
>   Of course we could obfuscate this even more:
>
> #declare Location = -2cm*3in*<3ft, 5cm*3in, 2km>;
>
>   One could wonder what is "2 centimeters times 3 inches"...
>
>   IMHO plain numbers are easier to read... :P
>
> -- 
> plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
> sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
> density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
> <1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

I tried setting units, gave it up.  Before I start a scene I just make a 
mental note whether I will be using the base unit as inches, feet or 
yards etc.  This seems more flexible to me but I can't say why.

Post a reply to this message

Instead of making a mental note why not make a real one in a comment.
Knowing what you intended always comes in handy later on.
I did some architectural modelling once in vicenzian feet, simply because
the dimensions on my source plans were given in that unit.

Had Napoleon been a little more succesful, we would at least all have been
metric.

Frans


"Jim Charter" <jrc### [at] aolcom> schreef in bericht
news:3f4ba0d3$1@news.povray.org...
> I tried setting units, gave it up.  Before I start a scene I just make a
> mental note whether I will be using the base unit as inches, feet or
> yards etc.  This seems more flexible to me but I can't say why.
>

Post a reply to this message

Actually.. It might be nice to have such a definition built in, but I 
would make it so that you have a default set of associations, but you can 
specify in the SDL a different value for one of them and have POV-Ray 
adjust all the rest to fit. The one thing Alan seems to have completely 
overlooked is that when you start dealing with something beyond a certain 
scale, either too small or two big, then the decimal places needed to 
deal with it become to imprecise to get it to work right. You need to 
have some way to adjust the scale so that if you are dealing with 
something on microscopic scales or solar system ones you can set your 
'base' 1 unit scale at some reasonable level where precision errors won't 
screw up the scene (or make it flat out impossible).


-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Patrick,

The issue of precision had occurred to me but I thought it too much to
mention and complicate any discussions, but I'm sure that you're right in
that it could be dealt with using some mechanism especially considering that
most copying of objects between scenes would be done at typically the same
rough order of magnitude of scale.    I just didn't want to add that level
of complexity.



Also I might mention (at great risk!) that if this was incorporated, then it
might also be conceivable that textures could be designed either unitised or
have a "designed for" type setting that would allow the (optional) automatic
scaling of textures such as wood to the target scene, or auto scale to the
target "'base' 1 unit scale" possibility you mentioned.   Again, I've not
mentioned this previously, as this would raise complexity when all I want is
to be able to cut and paste a desk and chair and all its associated items
from one scene to another regardless of scale, metrification or
 "imperialism" and lazily not have to re-scale.

"Patrick Elliott" <sha### [at] hotmailcom> wrote in message
news:MPG.19b57896a4efe84198987c@news.povray.org...
> Actually.. It might be nice to have such a definition built in, but I
> would make it so that you have a default set of associations, but you can
> specify in the SDL a different value for one of them and have POV-Ray
> adjust all the rest to fit. The one thing Alan seems to have completely
> overlooked is that when you start dealing with something beyond a certain
> scale, either too small or two big, then the decimal places needed to
> deal with it become to imprecise to get it to work right. You need to
> have some way to adjust the scale so that if you are dealing with
> something on microscopic scales or solar system ones you can set your
> 'base' 1 unit scale at some reasonable level where precision errors won't
> screw up the scene (or make it flat out impossible).
>
>
> -- 
> void main () {
>   If Schrödingers_cat is alive
>     call functional_code()
>   else
>     call crash_windows();
> }

Post a reply to this message

"Patrick Elliott" <sha### [at] hotmailcom> wrote in message
news:MPG.19b57896a4efe84198987c@news.povray.org...
> Actually.. It might be nice to have such a definition built in,

No, it wouldn't.  It would unnecessarily restrict the users.  The POV Team
is NOT Microsoft.

As it is, ABX is right.  Assuming they are written correctly, using *any*
units.inc file and interchanging them will work without a hitch.  I even
wrote one that allows you to define the actual unit size for inch, which all
others are based off of.

Ie, (pseudocode follows)

If inch is not defined,
    inch = 1/12

foot = inch*12
yard = foot*3
mile = foot*5280

etc

So you could scale them to fit objects which have not been unitized.

...Chambers

Post a reply to this message

Well, I *usually* use a unit system based on Ft=1 unit, but there are times
when I don't want that for some reason.  I think having the units in an
include is easier to work with since if I want a different scaling all I
have to do is change 1 variable and everything else is now changed, without
breaking compatibility between scenes.  something that is 4 Ft in one scene
will still be 4 Ft in another scene, regardless of what Ft is set to.  There
was some discussion of this recently
(http://news.povray.org/povray.general/32603/?ttop=32932&toff=50) and from
the feedback in that thread I gather that many POVers are using a similar
system.

As far as making objects portable, all I have to do is put the neccesary
unit definitions for that object in the include file, and if you want to use
it in your scene, set Ft to whatever works.  I think having it coded into
the parser would be less flexible.

And I suspect that there's no way around having to rescale some things,
simply because certain objects (i.e. height_fields, superellipsoids, etc...)
have a fixed size upon creation.  That's one of the primary reasons I don't
*always* use the same unit scaling.  If I'm building something from prisms &
lathes, using splines I created in a separate spline editor, then I'm going
to use whatever is easiest to work with those splines and the odds are that
it isn't Ft or Cm.  Also, meshes imported from other modelling software are
not standardised in their scaling, so depending on the ratio of imported
meshes to native POV objects, I may or may not use my standard units.

I'd say the only way such a system would really be practical is if not just
POV, but every modeler, editor, etc out there was standardised to it.   Good
luck!

And what is unit-less? Whether you give it a name or a number, POV expects
units, so why not keep it simple and let each artist work with whatever unit
they're comfortable with? And like I said above, if you want to share your
objects, just put the relevant definitions in your include. Then whoever
wants to use it can set 1 unit to whatever they like... change one variable
and everything works fine.

RG


Alan Smith <ala### [at] aurora-ukcom> wrote in message
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> }
>
> This would lead to more readable code, greater ease of 'real world' scene
> modelling with mixed sizes of objects and, most importantly, greater scope
> for sharing objects from other people who generously donate their source.
>
> At the moment I achieve this by using suitable declares and coding as :-
> box { <-2*cm, -1*cm, 10*mm>,  <2*cm, 1*cm, 1*cm> }
>
>
> Which goes a long way to meeting my needs, but it still does not do
anything
> for supporting portability of coded objects between scene files.
>
> This would surely be a simple modification to the parser and would still
> leave the ability for people to work in a 'unit-less' fashion if they
like?
>
> Alan Smith.

Post a reply to this message

I cannot see that allowing OPTION to unitise dimensions would "restrict"
users.

Whilst I'd be happy to join you in a Microsoft bashing session, I don't see
why this capability should be referred to as Microsoft dictatorship type
tactics, for example look at the W3C standard for SVG+CSS (a 2 dimensional
vector web presentation standard) that allows optional dimensional
specifications for lengths and positions etc.    This standard has little to
do with Microsoft (they've ignored it!); and it simply allows the
specification of two-dimensional layout (optionally) in a user friendly or
"real world" form (albeit pixels, in, mm and cm etc).



Whilst I agree with the concept include unit files being theoretically
equivalent as long as the conversion relationships are correctly expressed,
the reality will be that people would implement these themselves to
differing degrees of accuracy and this would introduce errors, which cannot
be quantified.   For example, supposing someone accidentally defined 1in =
2.51cm instead of 2.54 or just defined it as 2.5.   In addition the choice
of baseline (i.e. which real world unit corresponds to a POV unit of 1)
inch, mm or km in the inc file may also introduce errors due to
multiplication rounding and potentially differences due to arithmetic
precision.   In essence it cannot be escaped that it would in practise lead
to unnecessary differences.  It would be better to standardise based on a
built in POV facility or approved installed include file.     Whilst I know
that this will also add fuel to the fire, the other main problem comes from
the fact that textures etc would also need unitising.



Aside from this, my argument still stands - without any encouragement of
unitisation from a built in facility, the majority of POV scene files will
not use units and neither will the textures utilised by them and because of
this POV objects will not be portable without at least some effort.    I
also maintain that they are less readable.  Whilst I agree that the effort
is hopefully be minimal to port objects, it is less friendly!



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.

"Chambers" <bdc### [at] junocom> wrote in message
news:3f4beb60@news.povray.org...
>
> "Patrick Elliott" <sha### [at] hotmailcom> wrote in message
> news:MPG.19b57896a4efe84198987c@news.povray.org...
> > Actually.. It might be nice to have such a definition built in,
>
> No, it wouldn't.  It would unnecessarily restrict the users.  The POV Team
> is NOT Microsoft.
>
> As it is, ABX is right.  Assuming they are written correctly, using *any*
> units.inc file and interchanging them will work without a hitch.  I even
> wrote one that allows you to define the actual unit size for inch, which
all
> others are based off of.
>
> Ie, (pseudocode follows)
>
> If inch is not defined,
>     inch = 1/12
>
> foot = inch*12
> yard = foot*3
> mile = foot*5280
>
> etc
>
> So you could scale them to fit objects which have not been unitized.
>
> ...Chambers
>
>

Post a reply to this message

On Wed, 27 Aug 2003 03:36:13 +0100, "Alan Smith" <ala### [at] aurora-ukcom>
wrote:
> Whilst I agree with the concept include unit files being theoretically
> equivalent as long as the conversion relationships are correctly expressed,

I'm happy I convinced you about that. If they are "theoretically equivalent"
your feature could not deliver "easier to cut and paste objects from other
peoples files" as you stated earlier :-)

> the reality will be that people would implement these themselves to
> differing degrees of accuracy and this would introduce errors, which cannot
> be quantified. For example, supposing someone accidentally defined 1in =
> 2.51cm instead of 2.54 or just defined it as 2.5.

This kind of typo error affects hard written features as well. I made a patch
for POV I included in PoPOV and later in MegaPOV which standarized
coefficients of color->gray conversion. Previously for years POV used
different coefficients in many places. So sources are not free from such
errors as well.

If you want to convince community about usability of your function imo you
should follow this way:
1. use your skills to make a patch
2. release binaries
3. make initial library of interesting textures written with units
Soon people would find it usefull there would be more advocates for
incorporating it first into MegaPOV and later in POV. If community would think
it is useless you will notice not much discussions about it.

ABX

Post a reply to this message

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
Pov community think it is not very useful … ". We can only thank the non native
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 () {
  If Schrödingers_cat is alive  
    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 () {
  If Schrödingers_cat is alive  
    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