POV-Ray : Newsgroups : povray.beta-test : Spline inconsistencies Server Time
1 Nov 2024 21:21:41 EDT (-0400)
  Spline inconsistencies (Message 1 to 10 of 54)  
Goto Latest 10 Messages Next 10 Messages >>>
From: Rune
Subject: Spline inconsistencies
Date: 19 Feb 2002 17:36:13
Message: <3c72d35d@news.povray.org>
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

From: Fabien Mosen
Subject: Re: Spline inconsistencies
Date: 20 Feb 2002 12:56:50
Message: <3C73E2EE.6030105@skynet.be>
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

From: Rune
Subject: Re: Spline inconsistencies
Date: 20 Feb 2002 16:00:13
Message: <3c740e5d@news.povray.org>
"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

From: Thorsten Froehlich
Subject: Re: Spline inconsistencies
Date: 20 Feb 2002 16:30:27
Message: <3c741573$1@news.povray.org>
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

From: Rune
Subject: Re: Spline inconsistencies
Date: 20 Feb 2002 17:14:03
Message: <3c741fab@news.povray.org>
"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

From: Warp
Subject: Re: Spline inconsistencies
Date: 21 Feb 2002 09:59:01
Message: <3c750b34@news.povray.org>
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

From:
Subject: Re: Spline inconsistencies
Date: 21 Feb 2002 10:09:33
Message: <ua3a7uo6kugberl2pnovior8mvt2588382@4ax.com>
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

From: ingo
Subject: Re: Spline inconsistencies
Date: 21 Feb 2002 10:11:14
Message: <Xns91BCA4FA5AA36seed7@povray.org>
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

From: Thorsten Froehlich
Subject: Re: Spline inconsistencies
Date: 21 Feb 2002 12:48:26
Message: <3c7532ea@news.povray.org>
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

From:
Subject: Re: Spline inconsistencies
Date: 21 Feb 2002 12:58:41
Message: <e2da7u0peft4tmqk1ne6lgi5ne49te7h3k@4ax.com>
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

Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.