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

> 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