 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3979B575.F3DBCCD5@skynet.be>, Fabien Mosen
<fab### [at] skynet be> wrote:
> Problems with the current implementation :
>
> - The name of the splines are defined as a string inside the spline
> definition. This is inconsistent within POV-Ray syntax, and does
> not allow redefinition of a spline (a new spline with the same
> name). Thus, it does not allow the algorithmic generation of
> multiple splines.
>
> - Unability to "extract" values of the control points (for example,
> if I want to put a sphere at each control point)
>
> What would be a nice syntax ?
Why not just use the "other" spline patch, the one with this syntax:
#declare SplineIdent =
spline {
...
}
This could easily be extended to do the things you want, and has a much
simpler and more intuitive syntax which is fairly consistent with the
rest of the POV-Ray language syntax.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
| - suppress the "spline {..}" function, it became useless.
I'm afraid I must disagree. This spline is far more useful, and could fix
many of the problems you have. Also, it seems to be faster, and more
intuitive that the other method. It is also far more useful for
animations, as it can hold vectors, rotations, floats, etc. Give it a try.
I don't want to loose this baby.
H.E. Day
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kari Kivisalo wrote:
>
> My linear cubic spline macro works like this but you only get
> natural cubic spline. The linear part describes the fact that
> the parameter points linearily along the length of the spline.
Thank you very much, that's just what I needed ! And
it parses quite fast, too...
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> Why not just use the "other" spline patch, the one with this syntax:
> #declare SplineIdent =
> spline {
> ...
> }
>
> This could easily be extended to do the things you want, and has a much
> simpler and more intuitive syntax which is fairly consistent with the
> rest of the POV-Ray language syntax.
Well, I tried this one altogether, but it doesn't suit my current
needs : I need to evenly gather intervals along the spline, without
having to take care of the spline's "gradation" (the argument before
the vector), which is difficult with this "alternate" implementation.
I've just posted an example of what I need to do (and will be finally
able to do elegantly thanks to Kari's macro) in "binaries.images",
it shows well why I need it to work that way.
Thaks anyway,
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"H. E. Day" wrote:
>
> | - suppress the "spline {..}" function, it became useless.
>
> I'm afraid I must disagree. This spline is far more useful, and could fix
...
Well, you're right ! I did not think too much when saying that.
Sorry.
However, I'd like to see, in the future, a single spline function that
would elegantly cover all the needs.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <397AE320.4507A0A9@skynet.be>, Fabien Mosen
<fab### [at] skynetbe> wrote:
> Well, I tried this one altogether, but it doesn't suit my current
> needs : I need to evenly gather intervals along the spline, without
> having to take care of the spline's "gradation" (the argument before
> the vector), which is difficult with this "alternate" implementation.
It should be quite easy to make a macro to find a point a fixed distance
on a spline from a given one...and this syntax looks like it would be
more easily extended to allow these features to be added.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> In article <397AE320.4507A0A9@skynet.be>, Fabien Mosen
> <fab### [at] skynetbe> wrote:
>
> > Well, I tried this one altogether, but it doesn't suit my current
> > needs : I need to evenly gather intervals along the spline, without
> > having to take care of the spline's "gradation" (the argument before
> > the vector), which is difficult with this "alternate" implementation.
>
> It should be quite easy to make a macro to find a point a fixed distance
> on a spline from a given one...and this syntax looks like it would be
> more easily extended to allow these features to be added.
I gave it another try, but but but :
- it's impossible to pass a spline identifier as a #macro parameter
- it's impossible to #declare a point :
#declare Point = SplineIdent (Value);
I had to go trough sidepaths to achieve what I needed to do (e.g.
creating a temporary spline from a declared array within the macro)
- and I still miss the "linear natural cubic" quality of the other
splines. (and if I write a #macro to evenly distribute the "samples"
along the spline, the parsing times will go trough the roof, as it
does, alas, when using Kari's #macro).
(please consider this as a report, not a complain/request)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fabien Mosen wrote:
> - and I still miss the "linear natural cubic" quality of the other
> splines. (and if I write a #macro to evenly distribute the "samples"
> along the spline, the parsing times will go trough the roof, as it
> does, alas, when using Kari's #macro).
Until this feature is added to megapov try changing the tolerance
value near the end of the macro. I haven't tested this but reasonably
even distribution should be possible with 0.05.
#local err=0.001*slen;
K.K.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <397BB8B8.C551A8D3@skynet.be>, Fabien Mosen
<fab### [at] skynetbe> wrote:
> I gave it another try, but but but :
> - it's impossible to pass a spline identifier as a #macro parameter
> - it's impossible to #declare a point :
> #declare Point = SplineIdent (Value);
These are bugs, of course...hopefully they will be fixed soon. And I
think there is a workaround for the second one:
#declare Point = <0,0,0> + SplineIdent(Value);
> - and I still miss the "linear natural cubic" quality of the other
> splines. (and if I write a #macro to evenly distribute the "samples"
> along the spline, the parsing times will go trough the roof, as it
> does, alas, when using Kari's #macro).
And this is just a missing feature. The point I was trying to make is
that the *syntax* is far better, and that this spline patch could easily
be extended to do these things.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kari Kivisalo wrote:
>
> Until this feature is added to megapov try changing the tolerance
> value near the end of the macro. I haven't tested this but reasonably
> even distribution should be possible with 0.05.
Your macro works fairly well for me, but its parsed nature makes
it a little difficult to use when doing many (80+) splines, as
parsing times get loooong (well, at least too long for trial/error
testing).
I finally managed to get the things to work, using your macro
for the 3 control splines, and using the "alternate" spline
function for the numerous splines.
So, thanks.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
