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 () {

    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 () {

>     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