ABX wrote:
> 
> You mean like you wrote or :
> 
>   connection TYPE_OF_CONNECTION
>   TYPE_OF_CONNECTION: off | linear_spline | cubic_spline
> 
> what about replacing 'connection' with 'sweep_type' ?
> 

I find connection very intuitive.  sweep_type seems rather meaningless to
me.  Especially 'sweep_type off'.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <5gtrnu4hdr0h52c3kh4s5e3e0om32eqs46@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> Any idea for nice name for interpolation without interpolation ?

In the case of sphere_sweeps, don't you define a path it shall sweep on?  So
maybe call it "path" or "path_type".

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Tue, 10 Sep 2002 17:21:01 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> In the case of sphere_sweeps, don't you define a path it shall sweep on?  So
> maybe call it "path" or "path_type".

Yes, 'path' sounds nice. So one vote for 'connection' and one for 'path'. Any
other vote? My heart is now for 'path_type FLOAT' becouse it is made with
short words and I don't like that I have to reserve new token for every new
type of interpolation. There are also subtypes for interpolations when I can't
choose nice names. For example there are two toroidal connection types: one by
Ron Parker and one by Slime (IIRC). Making type float is better IMO. What do
you think?

ABX

Post a reply to this message

ABX wrote:

> On Tue, 10 Sep 2002 17:21:01 +0200, "Thorsten Froehlich" <tho### [at] trfde>
> wrote:
> 
>>In the case of sphere_sweeps, don't you define a path it shall sweep on?  So
>>maybe call it "path" or "path_type".
>>
> 
> Yes, 'path' sounds nice. So one vote for 'connection' and one for 'path'. Any
> other vote? My heart is now for 'path_type FLOAT' becouse it is made with
> short words and I don't like that I have to reserve new token for every new
> type of interpolation. There are also subtypes for interpolations when I can't
> choose nice names. For example there are two toroidal connection types: one by
> Ron Parker and one by Slime (IIRC). Making type float is better IMO. What do
> you think?
> 
> ABX
> 

My vote, if you care, would go for 'path' but no float, a keyword for 
each type/kind. (do you really remember by looking at the SDL that there
is various projection for image (using map_type) and which number
correspond to what kind ?
I do not. If you do (without looking at the help file or code),
please fill the following form to describ map_type in image_map:

  default value:
  0 :
  1 :
  2 :
  3 :
  4 :
  5 :
  6 :

I will check it later against the documentation!!

Post a reply to this message

On Wed, 11 Sep 2002 12:13:45 +0200, Le Forgeron <jgr### [at] freefr> wrote:
> My vote, if you care

I care, just don't be angry if I choose otherwise :-)

> would go for 'path' but no float, a keyword for 
> each type/kind. (do you really remember by looking at the SDL that there
> is various projection for image (using map_type) and which number
> correspond to what kind ?
> I do not.

I do not either but I don't like so many keywords used so rarely. Apropriate
include file with identifiers assigned to floats could be enough. There are
two include files with identifiers assigned this way: "functions.inc" and
"const.inc" ?

One of my teachers at technical university learned me that I shoudn't remember
every equation, piece of kowledge, keyword. I should know how to find it if I
need it.

ABX

Post a reply to this message

ABX wrote:
> 
> Yes, 'path' sounds nice. So one vote for 'connection' and one for 'path'. Any
> other vote? My heart is now for 'path_type FLOAT' becouse it is made with
> short words and I don't like that I have to reserve new token for every new
> type of interpolation. There are also subtypes for interpolations when I can't
> choose nice names. For example there are two toroidal connection types: one by
> Ron Parker and one by Slime (IIRC). Making type float is better IMO. What do
> you think?

'path_type FLOAT' seems fine, i agree using a float to specify the type is
a good idea, like with image_map map_type.  

If you don't want to introduce a new keyword at all you could use 'method'
like in media but it would be quite difficult to understand.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

ABX wrote:

> On Wed, 11 Sep 2002 12:13:45 +0200, Le Forgeron <jgr### [at] freefr> wrote:
> 
>>My vote, if you care
>>
> 
> I care, just don't be angry if I choose otherwise :-)
> 


No problem, it's your patch...


> 
>>would go for 'path' but no float, a keyword for 
>>each type/kind. (do you really remember by looking at the SDL that there
>>is various projection for image (using map_type) and which number
>>correspond to what kind ?
>>I do not.
>>
> 
> I do not either but I don't like so many keywords used so rarely. Apropriate
> include file with identifiers assigned to floats could be enough. There are
> two include files with identifiers assigned this way: "functions.inc" and
> "const.inc" ?
> 
> One of my teachers at technical university learned me that I shoudn't remember
> every equation, piece of kowledge, keyword. I should know how to find it if I
> need it.
> 


That's ok for technical inclined people, not for user-friendliness.
Let's me have a last 'extrem' example with POV.

You know there is a poly object... From your teacher point of view, it 
is fine as it is. The order of the poly comes first, then the user must 
provide the right number of float value. It's all in the doc, so no 
problem (even if since the extension, the doc does not give the order 
for more than 7th order while the root solver can handle up to 15th!).

But from a user-friendliness aspect, when Joe user (with a degree in 
math, a.k.a not a mathemacaly ignorant) wants to have a poly equation to 
be rendered, he has to carrefully spot the place for all values, and 
simple things like x^6+y^5+z^4-10=0 turn into a nightmare of values.

If keyword, instead of positional syntax, had been used, it would be
far more easier to use the poly object, and p.b.i might be full of them.
Instead of a long collection of values (with a lot of zero), using 
keyword would have make it easier (*):

   poly { x6 1 y5 1 z4 1 const -10 }

If later the user wants to add a x^2yz^3 term, it's also far easier than
retrieving the correct position in the list:

   poly { x6 1 y5 1 z4 1 const -10 x2yz3 -3 }

As a bad thing is always worth something, I believe iso-surface wouldn't 
have been there so early if poly would have been easier in syntax, and 
their success might have been reduced...



*: Using the classical 'keyword value' paradigm, instead of the 
expectable (but more programmer-hostile) 'value [keyword]' which would
allow "poly { 1 x6 +1 y5 +1 z4 -10 }" (using the unary + for once !!!)

P.S: I removed the order of the poly in the example, but I'm not sure 
that's a good idea, even if the order could be computed at the end of 
the parsing of the poly. Anyway, It's only for the illustration, there 
is no real patch here.

P.S.2: the number of keywords needed for the 15th order poly is between 
800 and 900...(exact number is in the source code formulae) which also 
means good luck to try a 15 th order poly in pov now (that's only about 
800 zero to type and some rigthly placed other values!!!) [I do not want 
to debug your formulae!]

P.S.3: You might ask what the relation with your question... my answer 
is 'Think about user-friendliness, dismiss if you want, but think about it'.

Post a reply to this message

Le Forgeron wrote:
> 
> [...]
> 
> If keyword, instead of positional syntax, had been used, it would be
> far more easier to use the poly object, and p.b.i might be full of them.
> Instead of a long collection of values (with a lot of zero), using
> keyword would have make it easier (*):
> 
>    poly { x6 1 y5 1 z4 1 const -10 }
> 
> If later the user wants to add a x^2yz^3 term, it's also far easier than
> retrieving the correct position in the list:
> 
>    poly { x6 1 y5 1 z4 1 const -10 x2yz3 -3 }
> 

It is fairly possible to program this with macros, think of something
like:

Poly4(1*X6, 1*Y5, 1*Z4, -10*Const)
Poly5(1*X6, 1*Y5, 1*Z4, -10*Const, -3*X2YZ3)

X6, Y5, Z4 and all the others would be (4D) vectors:

#declare X6=<6, 0, 0, 1>;
#declare Y5=<0, 5, 0, 1>;
#declare Z4=<0, 0, 4, 1>;
#declare X2YZ3=<2, 1, 3, 1>;
#declare Const=<0, 0, 0, 1>;

And the macro would just have to analyze the components of the vectors and
place 'Vector.t' at the appropriate positions in the poly object.  I
currently don't have the time to write it, but it's really quite easy
(although it would take some time to parse for a 15th order poly).  

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <7e1unus8h9amgktm4ktrh7b1g77bgmevnb@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> Yes, 'path' sounds nice. So one vote for 'connection' and one for 'path'. Any
> other vote? My heart is now for 'path_type FLOAT' becouse it is made with
> short words and I don't like that I have to reserve new token for every new
> type of interpolation. There are also subtypes for interpolations when I can't
> choose nice names. For example there are two toroidal connection types: one by
> Ron Parker and one by Slime (IIRC). Making type float is better IMO. What do
> you think?

I find keywords much easier to read and write than numbers, I feel that 
you should only use a number for a numeric value. And I really hope you 
meant "path_type INT". (there's no difference as far as POV is 
concerned, but for documentation you would want to say it is an integer 
value)

I would do something like:
type multisphere
type catmull_rom
type cubic
type linear
...

"type" already exists, and spline names can be used for all splines 
instead of just in the sphere_sweep shape, so you aren't adding a huge 
number of one-use keywords.

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

On Wed, 11 Sep 2002 13:51:11 +0200, Le Forgeron <jgr### [at] freefr> wrote:
> That's ok for technical inclined people, not for user-friendliness.

I don't like user-friendliness at some places. While I agree that making tools
user-friendly increases market but at the same time it increases "stupidity"
when it is applied in wrong place - where some level of intelligence is
expected from user and additional tools like declarations and macros are
served.

> But from a user-friendliness aspect, when Joe user (with a degree in 
> math, a.k.a not a mathemacaly ignorant) wants to have a poly equation to 
> be rendered, he has to carrefully spot the place for all values, and 
> simple things like x^6+y^5+z^4-10=0 turn into a nightmare of values.

If HF_Sphere macro can create complicated smooth mesh from pattern why another
macro can't create poly object definition from apropriate input data ?

> As a bad thing is always worth something, I believe iso-surface wouldn't 
> have been there so early if poly would have been easier in syntax, and 
> their success might have been reduced...

:-)

> P.S.3: You might ask what the relation with your question... my answer 
> is 'Think about user-friendliness, dismiss if you want, but think about it'.

I think I think :-)

ABX

Post a reply to this message