 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trf de> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
