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

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