As far as I have understood, "cubic spline" is a broad class of splines
while "catmull-rom spline" and "natural cubic spline" are specific spline
types.

The spline named "cubic_spline" used in prisms and lathes is more
specifically a catmull-rom spline. The spline named "catmull_rom_spline"
used in sphere_sweeps is also a catmull-rom spline. The fact that they are
identical splines and yet have different names is an inconsistency and it is
bound to be a cause of confusion.

Another inconsistency is the fact that the spline named "cubic_spline" used
in the spline{} feature is a natural cubic spline, but its name
"cubic_spline" is the same as the name for the catmull-rom spline used in
prisms and lathes, which is also called "cubic_spline". This too is
inconsistent and is bound to be a cause of confusion.

To avoid inconsistencies and confusion, identical spline types should have
identical names and different spline types should have different names, all
regardless of in which features they are used (prism, lathe, spline{},
sphere_sweep, and possible future additions).

My suggestion of names is as follows:

The catmull-rom spline will be called "catmull_rom_spline" in all features
where the catmull-rom spline is supported. This includes the spline in
prisms and lathes known as "cubic_spline".

The natural cubic spline will be called "natural_cubic_spline" in all
features where the natural cubic spline is supported. This means that the
currently named "cubic_spline" in the spline{} feature should be renamed to
"natural_cubic_spline".

Only in prisms and lathes the name "cubic_spline" will still be supported
and it will produce the same result as "catmull_rom_spline". This is for
backwards compatibility only, but backwards compatibility is not an issue in
spline{} and sphere_sweep, so the keyword "cubic_spline" do not have to be
supported there. The reason that the name "cubic_spline" should not be
widely supported is that it is the name of a whole class of splines, not a
specific spline type, and in POV-Ray more than one type of cubic splines are
used.

The above proposal will in my opinion make splines in POV-Ray more
consistent to understand and use. But even more so if in the future it is
decided to add additional types of cubic splines besides the two types
currently used.

The name "natural_cubic_spline" is only meant as a suggestion, if there's a
better term, then that should be used, as long as there's no risk of
confusion with other spline types.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
...

> The catmull-rom spline will be called "catmull_rom_spline" in all features
> where the catmull-rom spline is supported. This includes the spline in
> prisms and lathes known as "cubic_spline".

...

I'll just suggest shortening the names to "catmull_rom", "cubic",
"natural"... (it's used in splines, anyway, so no need to have spline in
the name, I think)

Fabien.

Post a reply to this message

"Fabien Mosen" wrote:
> I'll just suggest shortening the names to "catmull_rom", "cubic",
> "natural"... (it's used in splines, anyway, so no need to have
> spline in the name, I think)

"cubic_spline" should not be shortened to "cubic", as in my proposal, the
only reason to support that word in the first place is backwards
compatibility, so it doesn't make sense to change it.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3c72d35d@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> My suggestion of names is as follows:

Could you supply a "digest" version of your suggested changes?  That is, which
keywords in which object should be changed? (backward compatibility assured
were necessary, of course)

Is the following what you are suggesting:

prism
 cubic_spline -> catmull_rom_spline

lathe
 cubic_spline -> catmull_rom_spline

spline
 cubic_spline -> natural_cubic_spline

sphere_sweep
 cubic_spline -> natural_cubic_spline


    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

"Thorsten Froehlich" wrote:
> Is the following what you are suggesting:
>
> prism
>  cubic_spline -> catmull_rom_spline

Yes.

> lathe
>  cubic_spline -> catmull_rom_spline

Yes.

> spline
>  cubic_spline -> natural_cubic_spline

Yes.

And if we're lucky Mark Wagner will also add the catmull_rom_spline type, so
that spline will have both natural_cubic_spline and catmull_rom_spline.

> sphere_sweep
>  cubic_spline -> natural_cubic_spline

No, sphere_sweep don't use the keyword cubic_spline. It use the keyword
catmull_rom_spline, and this shouldn't be changed IMO. So no changes in
sphere_sweep.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune <run### [at] mobilixnetdk> wrote:
:> prism
:>  cubic_spline -> catmull_rom_spline

: Yes.

:> lathe
:>  cubic_spline -> catmull_rom_spline

: Yes.

  If the original keyword is preserved (besides supporting the new one) for
backwards compatibility, could it be a good idea to make that keyword
"deprecated"? A bit like in Java: If a class/method is deprecated, the
compiler warns about it and that it should not be used anymore, but it
will work for now (but may not work in the future).

-- 
#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 21 Feb 2002 09:59:01 -0500, Warp <war### [at] tagpovrayorg> wrote:
>  If the original keyword is preserved (besides supporting the new one) for
> backwards compatibility, could it be a good idea to make that keyword
> "deprecated"?

... or version sensitive ?

ABX

Post a reply to this message

in news:3c750b34@news.povray.org Warp wrote:

> If a class/method is deprecated, the
> compiler warns about it and that it should not be used anymore,

if #version => 3.5, yes.

Ingo

Post a reply to this message

In article <3c741fab@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

>> Is the following what you are suggesting:
>>
>> prism
>>  cubic_spline -> catmull_rom_spline
>
> Yes.
>
>> lathe
>>  cubic_spline -> catmull_rom_spline
>
> Yes.
>
>> spline
>>  cubic_spline -> natural_cubic_spline
>
> Yes.
>
> And if we're lucky Mark Wagner will also add the catmull_rom_spline type, so
> that spline will have both natural_cubic_spline and catmull_rom_spline.

In fact, I think the current implementation is flawed as it ignores everything
else in POV-Ray.  If catmull-rom splines cannot be added to 3.5 in time the
whole spline thingy should be dropped as the current implementation would only
cause needless confusion and conflict with everything else in POV-Ray.

>> sphere_sweep
>>  cubic_spline -> natural_cubic_spline
>
> No, sphere_sweep don't use the keyword cubic_spline. It use the keyword
> catmull_rom_spline, and this shouldn't be changed IMO. So no changes in
> sphere_sweep.

In this case, I think leaving "cubic_spline" as is and just changing the
keyword for the spline object to "natural_cubic_spline" or better
"natural_spline" is more appropriate.  In particular because natural cubic
splines seem to be less useful for modeling than Catmull-Rom splines.  This is
the obvious conclusion to draw from their use (or better lack of it) in
POV-Ray and elsewhere.

I also checked on the web and a few computer graphics books, and the use of
the term "cubic spline" as a name for a class of spline is not as frequently
used.  It might be mathematically correct, but if the widespread use is more
simplified in the field of computer graphics, my vote is for going with what
everybody else uses rather than the mathematically correct term.


    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 Thu, 21 Feb 2002 18:48:24 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> If catmull-rom splines cannot be added to 3.5 in time the
> whole spline thingy should be dropped as the current implementation would only
> cause needless confusion and conflict with everything else in POV-Ray.

It would be sad step back for many POVers including me :-(

ABX

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote in message
news:3c7532ea@news.povray.org...
> In fact, I think the current implementation is flawed as it ignores
everything
> else in POV-Ray.  If catmull-rom splines cannot be added to 3.5 in time
the
> whole spline thingy should be dropped as the current implementation would
only
> cause needless confusion and conflict with everything else in POV-Ray.

Please do not do that!
Also, please just rename and not remove the current spline function used in
spline declaration. The ends might not line up as nicely as others, but the
even curve that it produces is very nice.

 -Shay

Post a reply to this message

"Thorsten Froehlich" wrote:
> "Rune" wrote
> > And if we're lucky Mark Wagner will also add the
> > catmull_rom_spline type, so that spline will have
> > both natural_cubic_spline and catmull_rom_spline.
>
> In fact, I think the current implementation is flawed
> as it ignores everything else in POV-Ray.

Tell me about it... I've been talking about it since the pre-beta stages!

> If catmull-rom splines cannot be added to 3.5 in time
> the whole spline thingy should be dropped as the current
> implementation would only cause needless confusion and
> conflict with everything else in POV-Ray.

In that case I really hope the catmull_rom_spline can be added for the
spline{} feature!

> > sphere_sweep don't use the keyword cubic_spline.
> > It use the keyword catmull_rom_spline, and this
> > shouldn't be changed IMO. So no changes in sphere_sweep.
>
> In this case, I think leaving "cubic_spline" as is and
> just changing the keyword for the spline object to
> "natural_cubic_spline" or better "natural_spline" is
> more appropriate.

Ok, that's in fact the way I had imagined it before I was repeatedly told
that cubic spline is a class of splines. If cubic spline is more often used
as the term for a specific spline type, then I definitely prefer the
approach below.

prism and lathe:
- cubic_spline remains cubic_spline

sphere_sweep:
- catmull_rom_spline is renamed to cubic_spline

spline{} feature:
- current cubic_spline is renamed to natural_spline and hopefully
cubic_spline (actually catmull-rom spline) will be implemented.

Is this what you meant?

This also won't have any backwards compability issues.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Thorsten Froehlich wrote:
>...
> In fact, I think the current implementation is flawed as it ignores everything
> else in POV-Ray.

How is it flawed ?


> If catmull-rom splines cannot be added to 3.5 in time the
> whole spline thingy should be dropped as the current implementation would only
> cause needless confusion and conflict with everything else in POV-Ray.
>...

No, please don't remove it.

(It isn't necessarily useless just because
some cannot see how it can be useful for
their own problem/applications.)


Tor Olav

Post a reply to this message

Thorsten Froehlich wrote:

> In fact, I think the current implementation is flawed as it ignores everything
> else in POV-Ray.  If catmull-rom splines cannot be added to 3.5 in time the
> whole spline thingy should be dropped as the current implementation would only
> cause needless confusion and conflict with everything else in POV-Ray.

I disagree that it should be dropped. It is still a useful feature even
if it doesn't match the spline type used in the lathe object.

Maybe the spline type used in the lathe object is the one that is flawed.
Anyone think of that?

-- 
Ken Tyler

Post a reply to this message

Thorsten Froehlich wrote in message <3c7532ea@news.povray.org>...
>In fact, I think the current implementation is flawed as it ignores
everything
>else in POV-Ray.  If catmull-rom splines cannot be added to 3.5 in time the
>whole spline thingy should be dropped as the current implementation would
only
>cause needless confusion and conflict with everything else in POV-Ray.

I'll try to get catmull-rom splines coded up over the weekend.  It shouldn't
be too hard -- I set up the spline code to make it easy to add more spline
types.

--
Mark

Post a reply to this message

"Mark Wagner" wrote:
> I'll try to get catmull-rom splines coded up over the weekend.

Sounds great! :)

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> It would be sad step back for many POVers including me :-(

  I personally don't like the current spline syntax at all. Forced time values
are a bother and make writing splines a lot more tedious. The most common
usage of splines (at least in my case) is with evenly-distributed time values,
which have to be calculated automatically. This means that the points have
to be put in an array and then the spline calculated automatically from it.
  But the several spline include files out there (eg. the Colefax's one)
already do this, and they support a lot more features than pov3.5's splines
do (eg. approximating evenly spaced points in the spline).

  I personally find the spline include files so much more useful than I'll
probably never be using the internal ones.
  It won't be a step back for me.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Shay <sah### [at] simcopartscom> wrote:
> Please do not do that!
> Also, please just rename and not remove the current spline function used in
> spline declaration. The ends might not line up as nicely as others, but the
> even curve that it produces is very nice.

  Why have an unfinished internal implementation with a lot to be desired
when there are excellent spline include files out there which support the
same features and a lot more, and are even easier to use?

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

Tor Olav Kristensen <tor### [at] hotmailcom> wrote:
> (It isn't necessarily useless just because
> some cannot see how it can be useful for
> their own problem/applications.)

  I don't think that "it's not useless" is a good-enough reason for keeping
unfinished and mediocre features.
  Halos were not useless, and yet they were removed. For good reason.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
> Maybe the spline type used in the lathe object is the one that is flawed.
> Anyone think of that?

  AFAIK the spline type used in the lathe object is the most popular cubic
spline type used generally. It also works in a more intuitive and predictable
way.
  I would certainly not call it flawed.

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

By the way, any chance of making the time values optional?
  Forced time values are a real bother, and they usually cause more trouble
than they are worth.

  The idea would be that you don't either give any time values, or you give
time values for at least two points (giving one is not legal).
  If no time values are given, then the time values are internally generated
by interpolating (eg. between 0 and 1).
  If at least two time values are given, the time values for the other
points are calculated by interpolating and extrapolating.

  Of course a change in syntax would be needed but that should not be a
problem since we don't have to worry about backwards compatibility right now
(in fact, the syntax should be thought now that we still have the chance to
set it to whatever we want).
  It could, for example, be so that if a point is enclosed with { and }, then
it has a time value, else it hasn't. For example:

spline
{ whatever_spline
  { 0, <1,2,3> }
  <4,5,6>
  <7,8,9>
  { 1, <10,11,12> }
  <13,14,15>
  { 2, <16,17,18> }
  <19,20,21>
}

  Of course the most common usage of splines (I'm sure) would be with no
time values (usually evenly-distributed time values are enough):

spline
{ whatever_spline
  <1,2,3>
  <4,5,6>
  <7,8,9>
  <10,11,12>
}

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

On 22 Feb 2002 03:31:59 -0500, Warp <war### [at] tagpovrayorg> wrote:
>  By the way, any chance of making the time values optional?

AFAIK with current syntax you can put points in any order and/or you can
assign spline with selective point replacement. Your ideas could be simple
realized via macros.

ABX

Post a reply to this message

"Warp" wrote:
>   I personally don't like the current spline syntax at all.
> Forced time values are a bother and make writing splines a
> lot more tedious.

Just make a macro that automatically assigns time values. This means that
the user has the choice of using time values or not. That's not the case
with Chris Colefax's include file.

>   But the several spline include files out there (eg. the
> Colefax's one) already do this, and they support a lot more
> features than pov3.5's splines do (eg. approximating evenly
> spaced points in the spline).

But for basic spline usage, the syntax and use is much easier with the
spline{} feature. And the more advanced things can be done with a
combination of the spline{} feature and macros. And did I forget to say that
the internal splines are much faster than splines generated by include
files?

I'm glad we have the spline{} feature.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

On Fri, 22 Feb 2002 10:25:49 +0100, "Rune" <run### [at] mobilixnetdk>
wrote:
> And did I forget to say that
> the internal splines are much faster than splines generated by include
> files?

And we shouldn't forget they can be used in functions/isosurfaces.

I think : 'experimental feature' is good stage. At this time opinions (like
Rune's problem) can be gathered and during 4.0 rewriting all splines in POV
can be joined as one internal engine with different interfaces and aplications
(post proces/spline/lathe/animation tools).

ABX

Post a reply to this message

Rune <run### [at] mobilixnetdk> wrote:
> But for basic spline usage, the syntax and use is much easier with the
> spline{} feature.

  I strongly disagree.
  Suppose that you are making a spline with evenly-distributed time values:

spline
{ cubic_spline
  0, <1,1,1>
  .25, <2,2,2>
  .5, <3,3,3>
  .75, <4,4,4>
  1, <5,5,5>
}

  You test this and you decide that you want one point more between <3,3,3>
and <4,4,4>.
  Oops! Now you have to modify *all* the time values to get them again
evenly-distributed. You end up doing something like this:

spline
{ cubic_spline
  0/5, <1,1,1>
  1/5, <2,2,2>
  2/5, <3,3,3>
  3/5, <3.5,3.5,3.5>
  4/5, <4,4,4>
  5/5, <5,5,5>
}

  Every time you add or remove a point, you have to modify *all* the time
values to get the desired result.
  If you do this long enough, you'll get tired and automatize a bit:

#declare Points = array[6]
{ <1,1,1>, <2,2,2>, <3,3,3>, <3.5,3.5,3.5>, <4,4,4>, <5,5,5> }

spline
{ cubic_spline
  #declare Ind = 0;
  #declare EndInd = dimension_size(Points, 1)-1;
  #while(Ind <= EndInd)
    Ind/EndInd, Point[Ind]
    #declare Ind = Ind+1;
  #end
}

  But with an existing macro you can achieve the same thing with a lot less
work. For example:

#declare Points = array[6]
{ <1,1,1>, <2,2,2>, <3,3,3>, <3.5,3.5,3.5>, <4,4,4>, <5,5,5> }

CreateSpline(Points)

  Using the current spline syntax is certainly not "much easier". In fact,
it's a lot more tedious and difficult.

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

W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> Your ideas could be simple realized via macros.

  How?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

On 22 Feb 2002 05:21:21 -0500, Warp <war### [at] tagpovrayorg> wrote:
>W?odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> > Your ideas could be simple realized via macros.
>
>  How?

#version 3.5;
#include "strings.inc"

#macro Make_List()
  #local N=dimension_size(Array,1);
  #local C=N;
  #while(C)
    #local C=C-1;
    From+C*(To-From)/(N-1) Array[C]
  #end
#end

#macro Distribution(From,To,Array)
  spline{Make_List()}
#end

#macro Add_Distribution(Spline,From,To,Array)
  #declare Spline=spline{Spline Make_List()}
#end

// create spline with first distribution
#local Spline=Distribution(0,1,array[3]{<0,0,0><1,0,0><2,1,0>})
// add distribution to spline
// note you can mix ranges, overwrite and mix
Add_Distribution(Spline,1,2,array[3]{<2,1,0><3,2,1><2,2,2>})

// testing

#debug VStr((Spline(0)))
#debug "\n"
#debug VStr((Spline(.5)))
#debug "\n"
#debug VStr((Spline(1)))
#debug "\n"
#debug VStr((Spline(1.5)))
#debug "\n"
#debug VStr((Spline(2)))
#debug "\n"

// ABX

Post a reply to this message

On Fri, 22 Feb 2002 11:38:53 +0100, W�odzimierz ABX Skiba <abx### [at] babilonorg>
wrote:
>// note you can mix ranges, overwrite and mix

// mix, overwrite and overlap

Note also I didn't write spline type in any place becouse it can be forced at
calculation stage.

The only thing I wonder about splines - why they are designed with { when they
are just vector functions.

And one feature request (it best fits in this thread): result is a vector -
why not allow to influence dimension of this result with dimension if input ?
I mean why not allow 2D or 5D vectors in input list ? First entry in spline
could describe dimension of result just like for arrays. This could extend
spline for use with rgbtf values and many other applications.

ABX

Post a reply to this message

Warp wrote:
> 
> [...]
> 
>   I personally find the spline include files so much more useful than I'll
> probably never be using the internal ones.
>   It won't be a step back for me.

And what about spline functions?

Not being able to use splines in isosurface functions would be really bad
IMO.

Christoph

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

Post a reply to this message

W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> #local Spline=Distribution(0,1,array[3]{<0,0,0><1,0,0><2,1,0>})
> Add_Distribution(Spline,1,2,array[3]{<2,1,0><3,2,1><2,2,2>})

  That's quite longer. And it needs you to repeat points (<2,1,0> above).
  Compare to the equivalent in my proposal:

#local Spline=spline{ {0,<0,0,0>} <1,0,0> {1,<2,1,0>} <3,2,1> {2,<2,2,2>} }

(And that {1,<2,1,0>} could just be <2,1,0>, but I wanted it to be completely
equivalent to your example.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> Not being able to use splines in isosurface functions would be really bad
> IMO.

  How do you use splines in isosurface functions?

-- 
#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 22 Feb 2002 06:16:10 -0500, Warp <war### [at] tagpovrayorg> wrote:
> That's quite longer.

But possible in simple way. And anybody can modify this macro to distribute
points of array with parameter distributed other way (t^2, sqrt(t)).

> And it needs you to repeat points (<2,1,0> above).

Well, is this realy problem ? You can create main keys as variables. There is
many solutions in POV basad on storing things in variables.

> Compare to the equivalent in my proposal:
> #local Spline=spline{ {0,<0,0,0>} <1,0,0> {1,<2,1,0>} <3,2,1> {2,<2,2,2>} }

looks like alternative and interesting solution

ABX

Post a reply to this message

Warp wrote:
> 
>   How do you use splines in isosurface functions?
> 

http://www.povray.org/working-docs/id000141.html#6_1_6_3
http://www.econym.demon.co.uk/isotut/more.htm

Christoph

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

Post a reply to this message

On 22 Feb 2002 06:18:24 -0500, Warp <war### [at] tagpovrayorg> wrote:
>  How do you use splines in isosurface functions?

http://news.povray.org/0fm17ucj8h2rpb7u6ia5r5kuvd7ql58jb2%404ax.com

ABX

Post a reply to this message

Warp wrote:
> 
> Christoph Hormann <chr### [at] gmxde> wrote:
> > Not being able to use splines in isosurface functions would be really bad
> > IMO.
> 
>   How do you use splines in isosurface functions?

http://www.econym.demon.co.uk/isotut/more.htm

-- 
Ken Tyler

Post a reply to this message

"Warp" wrote:
> Rune wrote:
> > But for basic spline usage, the syntax and use
> > is much easier with the spline{} feature.
>
>   I strongly disagree.
>   Suppose that you are making a spline with
>   evenly-distributed time values:

You keep talking about evenly distributed values. Suppose you want UNevenly
distributed values. That's *impossible* if you don't use the spline feature!

If you do want evenly distributed values, use a macro that takes an array as
input and fills in the time values for you. There you go, an easy solution
both with and without evenly distributed values. Tell me again how you do
that without the spline feature?

>   Using the current spline syntax is certainly not
> "much easier". In fact, it's a lot more tedious and
> difficult.

If you refuse to use a macro to fill in evenly distributed time values, then
you're right. But why would you do that?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote in news:3c761b7b@news.povray.org:

> But with an existing macro you can achieve the same thing with a lot
> less work. For example:
> 
> #declare Points = array[6]
> { <1,1,1>, <2,2,2>, <3,3,3>, <3.5,3.5,3.5>, <4,4,4>, <5,5,5> }
> 
> CreateSpline(Points)

Quoted code is from your own post:

#macro CreateSpline(cspoints)
// Keep parameter names lowercase to prevent
// name collisions with functions and other macros.

> spline
> { cubic_spline
>  #declare Ind = 0;
   #declare EndInd = dimension_size(cspoints, 1)-1;
>   #while(Ind <= EndInd)
      Ind/EndInd, cspoints[Ind]
>    #declare Ind = Ind+1;
>   #end
> }

#end

> Using the current spline syntax is certainly not "much easier". In
> fact, it's a lot more tedious and difficult.

Macros will fix that.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote in message news:3c75fe70@news.povray.org...
>   Why have an unfinished internal implementation with a lot to be desired
> when there are excellent spline include files out there which support the
> same features and a lot more, and are even easier to use?

Because I can accelerate and decelerate (or not) across the spline the way
that I want to.
Because I really like the form of the natural spline (this may be  part of
the includes you mentioned.)

 -Shay

Post a reply to this message

Warp wrote in message <3c7601ff@news.povray.org>...
>  By the way, any chance of making the time values optional?
>  Forced time values are a real bother, and they usually cause more trouble
>than they are worth.

No.  The time for feature requests is over, particularly for difficult
feature requests such as this.

--
Mark

Post a reply to this message

"Mark Wagner" wrote:
> The time for feature requests is over, particularly
> for difficult feature requests such as this.

As long as the feature is marked as experimental there's still hope for
future versions of POV-Ray... ;)

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3c761b7b@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   I strongly disagree.

So do I.


>   Suppose that you are making a spline with evenly-distributed time values:

Suppose you aren't.
I agree that this would be a nice option, but it isn't possible right 
now, and macro solutions are available. In the meantime, having the time 
values user-defined is far better than the spline forcing its own 
distribution. I generally don't construct splines the way you do, I 
define a few points that I want the spline to reach by a certain time, 
and fill in the blanks. The current syntax makes that quite easy, I can 
take a straight segment and add all sorts of loops and twists without 
having to add points elsewhere just to keep the distribution right. And 
the spline syntax has room for plenty of future extension. As it is now, 
it can provide a useful base for many spline macros, and is capable of 
many things macros can't do.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3c75fe70@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Why have an unfinished internal implementation with a lot to be desired
> when there are excellent spline include files out there which support the
> same features and a lot more, and are even easier to use?

I haven't seen any that are as easy to use, none that can do all the 
same things (the big limitation: spline functions). And all will be a 
lot slower. There's room for improvement, but what's there is a good 
start, and is very useful as is.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Rune <run### [at] mobilixnetdk> wrote:
> If you do want evenly distributed values, use a macro that takes an array as
> input and fills in the time values for you.

  That's what I am doing right now. I'm using Colefax's spline macros.

> There you go, an easy solution
> both with and without evenly distributed values. Tell me again how you do
> that without the spline feature?

  You didn't get my point: I was complaining about *forcing* each time value
to be specifically written.
  My suggestion was that time values were *optional*, and if a time value
for a certain point is not given, it's calculated automatically by
interpolation/extrapolation.
  This would make splines a lot nicer to use.

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

Christoph Hormann <chr### [at] gmxde> wrote:
> http://www.econym.demon.co.uk/isotut/more.htm

  That's a very clever use for it.

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

Christopher James Huff <chr### [at] maccom> wrote:
> There's room for improvement, but what's there is a good 
> start, and is very useful as is.

  Yes, but what I am saying is that the improvements should be made *now*,
not some time in the future, because improvements will most probably need
a syntax change which will break backwards compatibility.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Mark Wagner <mar### [at] gtenet> wrote:
>>  By the way, any chance of making the time values optional?

> No.  The time for feature requests is over, particularly for difficult
> feature requests such as this.

  Adding support for catmull-rom splines was a feature request, which is
being considered.
  I was just suggesting that as someone is going to make changes to the
spline code anyways, if he could go a bit further.

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

In article <3c77e8b4@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Yes, but what I am saying is that the improvements should be made *now*,
> not some time in the future, because improvements will most probably need
> a syntax change which will break backwards compatibility.

I don't think so...it would be fairly easy to support the current syntax 
along with a new one. Brackets (either {} or []) could be added now to 
prevent having to do this though...I'd use [] for consistency with 
*_maps.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

"Warp" wrote:
>   You didn't get my point: I was complaining about
> *forcing* each time value to be specifically written.

I think you didn't get my point: You are not forced to specifically write
each time value when you can have a macro do it for you.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune <run### [at] mobilixnetdk> wrote:
> I think you didn't get my point: You are not forced to specifically write
> each time value when you can have a macro do it for you.

  I think it would be quite difficult and a bit cumbersome to make a
macro which supports optional time values (ie. any point can have a time
value or not).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" wrote:
>   I think it would be quite difficult and a bit
> cumbersome to make a macro which supports optional
> time values (ie. any point can have a time value or not).

Then we must make such a macro and include it in the standard distribution
so the user don't have to fiddle with it. I volunteer to make it.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message