 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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] mobilixnet dk> 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
|
|
| |
| |
|
|
|
|
| |
