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

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