 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Any idea for nice name for interpolation without interpolation ?
In my rewrtitten sphere_sweep module I have added additional types for
interpolations. One of them is something like "no interpolation" - it makes
set of spheres without connections - then in fact it works for spheres just
like mesh for triangles - have own internal bounding hierarchy, shares data
between instances and reserves memory only for center, radius and pointer to
texture. My problem is that I don't know how to call this kind of
interpolation. I don't like the
no_interpolation
interpolation off
spline off
and have no language experience to choose anything better than
no_spline
So any help with this language problem? Note it should look readable when more
than one interpolation type is specified:
sphere_sweep{
// make rounded cylinder ...
linear_spline
sphere{x 1 pigment{rgb 1}
sphere{y 0.1 pigment{red 0.1}}
// ... and one additional separated sphere
no_spline
sphere{z 0.2 texture{My_Favourite}}
}
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
>
> Any idea for nice name for interpolation without interpolation ?
> In my rewrtitten sphere_sweep module I have added additional types for
> interpolations. One of them is something like "no interpolation" - it makes
> set of spheres without connections - then in fact it works for spheres just
> like mesh for triangles - have own internal bounding hierarchy, shares data
> between instances and reserves memory only for center, radius and pointer to
> texture. My problem is that I don't know how to call this kind of
> interpolation. I don't like the
> no_interpolation
> interpolation off
> spline off
> and have no language experience to choose anything better than
> no_spline
> [...]
I think it should have 'connection' somewhere. This clearly shows there
is no connection at all between the spheres and not just no interpolation
(which could mean anything).
How about:
connection off | linear_spline | cubic_spline | ...
BTW this sounds like a very interesting feature after all. I'm just
rendering a 6000 spheres mechanical simulation and it's taking ages (not
for the simulation but for the render).
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 10 Sep 2002 16:05:56 +0200, Christoph Hormann <chr### [at] gmx de>
wrote:
> connection off | linear_spline | cubic_spline | ...
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' ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
