 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
[note : this is a user's point of view, I am totally unable to get
my hands on the actual c code. These suggestions comes from an
(unsuccessfull) attempt to make a special (but logical) use of the
spline function.]
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 ?
- the spline's data would be stocked into an ordinary declared array
of points
#declare MySpline = array[N]{Pt1, Pt2, Pt3,.. PtN}
this would allow both easy redefinition of data and extraction of
data for other purposes than splines. Also, it would be consistent
with common syntax.
- points on the spline would be retrieved by a function :
#declare Point =
eval_3D_spline (Identifier,[options : natural..],Position)
this allows using different options at different times, using the
same data.
And also :
- suppress the 2D spline function, the user just have to declare
points with one of the vector components set at 0.
- suppress the "spline {..}" function, it became useless.
Cheers,
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fabien Mosen wrote:
> - the spline's data would be stocked into an ordinary declared array
> of points
> - points on the spline would be retrieved by a function :
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.
K.K.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
