 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
As Warp has pointed out, it would be convenient if one was not forced to
specify T values for all the control points in a spline. I've tried making a
macro which fill in the missing T values. It takes an array as input.
But I had forgotten that arrays do not allow abbreviating vectors as floats,
as it is allowed almost everywhere else in POV-Ray. So the syntax is uglier
than what I had hoped. The idea is that specified T values are multiplied
with y, while unspecified T values are marked with an x. See below.
My question is - is the below syntax too ugly or would it be acceptable for
a macro included in the POV-Ray distribution?
#declare SplineArray =
array[7*2] {
0.0*y, <0,1,2>,
x, <1,5,0>,
x, <4,1,0>,
0.9*y, <0,2,1>,
1.0*y, <0,0,1>,
x, <6,5,4>,
2.0*y, <4,3,2>,
}
#declare Spline =
spline {
cubic_spline
SplineAutoT(SplineArray)
}
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 in message
news:3c784c61@news.povray.org...
> As Warp has pointed out, it would be convenient if one was not forced to
> specify T values
>
> But I had forgotten that arrays do not allow abbreviating vectors as
floats
Lost me on this whole idea. Looks like it would create splines with
multiple points for the same "time" value (x=1 and all). Making for some
odd pretzel shapes. ;-)
But if it does as you plan it to do it isn't too awkward, just not terribly
clean.
bob h
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c784c61@news.povray.org>,
"Rune" <run### [at] mobilixnetdk> wrote:
> But I had forgotten that arrays do not allow abbreviating vectors as floats,
> as it is allowed almost everywhere else in POV-Ray. So the syntax is uglier
> than what I had hoped. The idea is that specified T values are multiplied
> with y, while unspecified T values are marked with an x. See below.
>
> My question is - is the below syntax too ugly or would it be acceptable for
> a macro included in the POV-Ray distribution?
A suggestion: use macros for the entries.
#macro SE1(T, Point) y*T, Point #end
#macro SE2(Point) x, Point #end
array[7*2] {
SE1(0, < 0, 1, 2>),
SE2(< 1, 5, 0>),
SE2(< 4, 1, 0>),
SE1(0.9, < 0, 2, 1>),
SE1(1.0, < 0, 0, 1>),
SE2(< 6, 5, 4>),
SE1(2.0, < 4, 3, 2>),
}
Ugh, I don't like it either. The macro name needs to be short, since it
will be repeated so many times, but that increases the chance of name
collision. Maybe it would be better to use file I/O to read in a spline
file.
Using the vectors actually doesn't look that bad...'x' is pretty
standard as a standin for "unknown", but something better could be used
in place of 'y'...I don't think 'v' will work, POV might interpret it as
a 2D vector. Maybe #declare T = y;? It could easily be overwritten by
some scene variable though...
Hmm. How about this: use 4D vectors in the array. When the T value is to
be unspecified, give it some value like -1 that will indicate that it
needs to be interpolated. Or use 4D vectors and the present syntax, so
you can use "NNN*t" in place of "NNN*y".
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"bob h" wrote:
> Lost me on this whole idea.
The idea is that the macro fill in the unspecified T values for you using
linear interpolation.
The macro will convert this:
array[7*2] {
0.0*y, <0,1,2>,
x, <1,5,0>,
x, <4,1,0>,
0.9*y, <0,2,1>,
1.0*y, <0,0,1>,
x, <6,5,4>,
2.0*y, <4,3,2>,
}
Into this:
0.0, <0,1,2>,
0.3, <1,5,0>,
0.6, <4,1,0>,
0.9, <0,2,1>,
1.0, <0,0,1>,
1.5, <6,5,4>,
2.0, <4,3,2>,
You're only required to specify the first and last T value; the rest are
optional. In some cases that can make it easier to work with splines.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" wrote:
> A suggestion: use macros for the entries.
Good suggestion, though I think I'll only use one macro, and still use the
idea about using an x for unspecified. IMO that's actually *more* clear, at
least indention-wise. However, I can get rid of the *y part. It also has
another advantage: The user can abbreviate vectors as floats, which is
particulary useful when one only wants to interpolate floats in the first
place. That's not possible in the pure macro solution, as all elements in a
vector macro has to be explicitely written as vectors, i.e. 0.1 doesn't
work, only <0.1,0.1,0.1> or 0.1*<1,1,1>.
> Using the vectors actually doesn't look that bad...'x' is
> pretty standard as a standin for "unknown", but something
> better could be used in place of 'y'...I don't think 'v'
> will work, POV might interpret it as a 2D vector.
It won't work.
> Maybe #declare T = y;? It could easily be overwritten by
> some scene variable though...
Yes.
> Hmm. How about this: use 4D vectors in the array.
Then all the vectors have to be explicitely written as 4D vectors, also the
points. Not a good solution.
I'll see if I can make the macro approach work well.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3c784c61@news.povray.org Rune wrote:
> #declare SplineArray =
> array[7*2] {
> 0.0*y, <0,1,2>,
> x, <1,5,0>,
>
This is ugly. Why don't you take a linear (or other) spline as input for
generating the T-values?
And I think this discussion if off-topic here,
followup set to povray.advanced-users
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
How's this:
#declare Spline =
spline {
cubic_spline
SplineAutoT(array[7*2]{
(SCP( 0.0, <0,1,2>))
(SCP( x, <1,5,0>))
(SCP( x, <4,1,0>))
(SCP( 0.9, <0,2,1>))
(SCP( 1.0, <0,0,1>))
(SCP( x, <6,5,4>))
(SCP( 2.0, <4,3,2>))
})
}
Note that the extra parentheses are necessary as macros can't be called
directly in arrays without them.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" wrote:
> This is ugly. Why don't you take a linear (or other)
> spline as input for generating the T-values?
Because then you'd have to separate the list of T values from the list of
points. But have you seen my other posts in this thread? I've made a
different syntax.
> And I think this discussion if off-topic here,
> followup set to povray.advanced-users
It's not off-topic IMO as it's about a macro for possible inclusion in the
standard includes in POV-Ray 3.5.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok, new thinking - how about this:
#declare Spline =
spline {
cubic_spline
Spline_Points(7)
SCP( 0.0, <0,1,2>)
SCP( x, <1,5,0>)
SCP( x, <4,1,0>)
SCP( 0.9, <0,2,1>)
SCP( 1.0, <0,0,1>)
SCP( x, <6,5,4>)
SCP( 2.0, <4,3,2>)
Spline_End()
}
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hey, it just occurred to me that this syntax could be extended with other
options. Imagine the following:
#declare Spline =
spline {
Spline_Type(Cubic_Spline)
Spline_Points(7)
Spline_Speed(Constant)
SCP( 0.0, <0,1,2>)
SCP( x, <1,5,0>)
SCP( x, <4,1,0>)
SCP( x, <0,2,1>)
SCP( x, <0,0,1>)
SCP( x, <6,5,4>)
SCP( 2.0, <4,3,2>)
Spline_End()
}
I think this is beginning to be interesting! I hope you agree that the
approach shown here would fit well in the official include files?
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] mobilixnetdk> wrote:
> #declare Spline =
> spline {
> cubic_spline
> Spline_Points(7)
> SCP( 0.0, <0,1,2>)
> SCP( x, <1,5,0>)
> SCP( x, <4,1,0>)
> SCP( 0.9, <0,2,1>)
> SCP( 1.0, <0,0,1>)
> SCP( x, <6,5,4>)
> SCP( 2.0, <4,3,2>)
> Spline_End()
> }
That would be better than nothing.
Of course there are two things that are a bit bothering: You have to
specify the number of points at the beginning (as always with arrays) and
you have to write extra text ('SCP(...)' and those x's), but I think those
are things that can't be helped currently.
By the way, it could also be a good idea to add another macro:
#declare Spline =
spline
{ cubic_spline
Even_Spline_Points(array[5]{<1,2,3><4,5,6><7,8,9><10,11,12><13,14,15>})
}
or something similar.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnetdk> wrote:
> Spline_Type(Cubic_Spline)
I don't understand the reason for this one.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3c78dc4b@news.povray.org Warp wrote:
> or something similar.
>
Us it as you want it.
---%<------%<---
// The macro allways expects one point
// before t=0 and one after t=1, also for linear splines.
// Use: #declare SPL=BuildSpline(ArrayIdentifiers, "string")
// where string is C|c|L|l|Q|q
#macro BuildSpline(Arr, SplType)
#local Ds=dimension_size(Arr,1);
#local Asc=asc(strupr(SplType));
#if(Asc!=67 & Asc!=76 & Asc!=81)
#local Asc=76;
#debug "\nWrong spline type defined (C/c/L/l/Q/q), using default
linear_spline\n"
#end
spline {
#switch (Asc)
#case (67) //C cubic_spline
cubic_spline
#break
#case (76) //L linear_spline
linear_spline
#break
#case (81) //Q Quadratic_spline
quadratic_spline
#break
#end
#local Add=1/((Ds-2)-1);
#local J=0-Add;
#local I=0;
#while (I<Ds)
J
Arr[I]
#local I=I+1;
#local J=J+Add;
#end
}
#end
---%<------%<---
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think that it would be better if the macro just created the points, not
the spline itself.
spline { cubic_spline MakeThePoints(whatever) }
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> Rune wrote:
> > Spline_Type(Cubic_Spline)
>
> I don't understand the reason for this one.
More advanced macro options such as constant speed (I think that's the same
as you call even spline points) will need to know the spline type in order
to create optimal results. It also opens up the possibility of introducing
new spline types that the macros fakes using the existing 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> That would be better than nothing.
Well, that's something.
> Of course there are two things that are a bit bothering:
> You have to specify the number of points at the beginning
Actually you can just make the number plenty large and then you don't have
to worry about changing it every time you add a new point. As the array will
be bigger it will require slightly more ressources, but nothing of
importance. The point is that you don't get an error and that it gives the
same result.
> and you have to write extra text ('SCP(...)' and those x's)
Yes...
> #declare Spline =
> spline
> { cubic_spline
>
Even_Spline_Points(array[5]{<1,2,3><4,5,6><7,8,9><10,11,12><13,14,15>})
> }
>
> or something similar.
Do you mean evenly distributed T values or evenly distributed points of the
spline. The first is very easy while the second is slightly more tricky, but
I intent to make support for both.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c78ec3d@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> I think that it would be better if the macro just created the points, not
> the spline itself.
>
> spline { cubic_spline MakeThePoints(whatever) }
And you should be able to set the beginning and end T values. That way,
you could paste the spline data into an existing spline.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnetdk> wrote:
> Do you mean evenly distributed T values or evenly distributed points of the
> spline.
I meant evenly distributed T values (ie. just interpolate them between
0 and 1).
(Of course a more advanced option could make the macro to interpolate
the T values non-linearly.)
As for evenly-distributed points along the spline, I think that the only
feasible way of doing that is to make a macro which returns points for the
given spline (in the same way as the Colefax include does). Of course this
will make it a bit slow (because it has to approximate by sampling points on
the spline).
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> (Of course a more advanced option could make
> the macro to interpolate the T values non-linearly.)
I don't think I'll implement that. With both the T values and the points
being non-linearly interpolated, I'm not even able to figure out in my head
in what way the results would be different. And non-linearly interpolation
of strongly varying T values could cause the T values to go backwards at
times, which would mess up everything.
> As for evenly-distributed points along the spline,
> I think that the only feasible way of doing that is
> to make a macro which returns points for the given
> spline (in the same way as the Colefax include does).
I've done that before and it's not that slow. However, a solution I'd like
to try is to return a new spline which has many more control points than the
original and where those control points are arranged to give constant speed.
This too is just an approximation, but it would be faster, as the
calculations would only need to be done once, and it could also be made
completely transparent to the user, who will call the spline like normal,
without the need for macros once the spline has been created.
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] mobilixnetdk> wrote:
> I've done that before and it's not that slow. However, a solution I'd like
> to try is to return a new spline which has many more control points than the
> original and where those control points are arranged to give constant speed.
> This too is just an approximation, but it would be faster, as the
> calculations would only need to be done once, and it could also be made
> completely transparent to the user, who will call the spline like normal,
> without the need for macros once the spline has been created.
That's an interesting idea worth testing.
I just wonder if it will change the shape of the spline if you add
additional control points in the middle of it (even if they are exactly on
the original spline). Perhaps not, but you never know...
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> I just wonder if it will change the shape of the
> spline if you add additional control points in the
> middle of it (even if they are exactly on the
> original spline). Perhaps not, but you never know...
Oh, I'm pretty sure it *will* change the shape, but if you use enough
control points the changes will be barely measurable I think. This is what I
intent to do.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've currently gotten the syntax below to work. It's not nessesary to
specify the number of points, and it's possible to mix points that has
optional T values with points extracted from an array.
#declare MyArray = array[6]{
<4,5,8>,<5,7,3>,<5,1,2>,<6,5,2>,<7,5,3>,<2,0,6>
}
#declare Spline =
spline {
cubic_spline
SCP( 0.0, <0,1,2>)
SCP( x, <1,5,0>)
SCP( x, <4,1,0>)
SCP( 0.9, <0,2,1>)
SCP( 1.0, <0,0,1>)
SCP( x, <6,5,4>)
SCP( 2.0, <4,3,2>)
Spline_Add_Points(MyArray,2.5,4.5)
Spline_End()
}
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c7919a9@news.povray.org>,
"Rune" <run### [at] mobilixnetdk> wrote:
> I've done that before and it's not that slow. However, a solution I'd like
> to try is to return a new spline which has many more control points than the
> original and where those control points are arranged to give constant speed.
I've done that before, but never finished because of bugs in the spline
feature. Here are the (partially complete) macros:
// Persistence of Vision Ray Tracer version 3.5 Include File
// File: splines.inc
// Last updated: 2001.8.8
// Description: Spline-handling and interpolation macros
#ifndef(SPLINES_INC_TEMP)
#declare SPLINES_INC_TEMP = version;
#version 3.5;
#declare LINEAR_SPLINE = 0;
#declare QUADRATIC_SPLINE = 1;
#declare CUBIC_SPLINE = 2;
#macro SPLINE_TYPE(Type)
#switch(Type)
#case(LINEAR_SPLINE)
linear_spline
#break
#case(QUADRATIC_SPLINE)
quadratic_spline
#break
#case(CUBIC_SPLINE)
cubic_spline
#break
#end
#end
//Assumes spline T is in range [0, 1]
#macro Spline_Length(Spline, Intervals)
#local Len = 0;
#local PtA = 0+Spline(0);
#local J = 0;
#while(J < Intervals)
#local PtB = 0+Spline((J + 1)/Intervals);
#local Len = Len + vlength(PtB - PtA);
#local PtA = PtB;
#local J = J + 1;
#end
(Len)
#end
#macro Spline_Interval_Length(Spline, StartT, EndT, Intervals)
#local Len = 0;
#local PtA = (Spline(StartT));
#local J = 0;
#while(J < Intervals)
#local PtB = 0+Spline((EndT - StartT)*(J + 1)/Intervals +
StartT);
#local Len = Len + vlength(PtB - PtA);
#local PtA = PtB;
#local J = J + 1;
#end
(Len)
#end
#macro Constant_Speed_Spline(Spline, Type, Intervals, Samples)
#local SplineLen = Spline_Length(Spline, Intervals*Samples);
spline {SPLINE_TYPE(Type)
0, < 0, 0, 0>+Spline(0)
#local DistPassed = 0;
#local J = 0;
#while(J < Intervals)
#local IntLen = Spline_Interval_Length(Spline, J/Intervals,
(J + 1)/Intervals, Samples);
#local DistPassed = DistPassed + IntLen;
DistPassed/SplineLen, < 0, 0, 0>+Spline((J + 1)/Intervals)
#local J = J + 1;
#end
}
#end
#macro SPLINE_FindNextT(StIdx, Array)
#local PointNum = dimension_size(Array, 1);
#local K = StIdx;
#local Res = StIdx;
#while(K < PointNum)
#if(!VEq(Array[K][0], x))
#local Res = K;
#break
#else
#local K = K + 1;
#end
#end
(Res)
#end
#macro Spline_From_Array(Type, ConstantSpeedSamples, Array)
#local PointNum = dimension_size(Array, 1);
#if(ConstantSpeedSamples > 0)
#local Method = 3;
#else
#local Method = dimensions(Array);
#end
spline {SPLINE_TYPE(Type)
#switch(Method)
#case(1)
//No T values specified, autocompute all with even time
gaps
#debug "Spline_From_Array() method 1"
#local J = 0;
#while(J < PointNum - 1)
J/(PointNum - 1), Array[J],
#local J = J + 1;
#end
1, Array[PointNum - 1]
#break
#case(2)
//T values specified, autocompute only for gaps
#debug "Spline_From_Array() method 2"
#local J = 0;
#local NextTIdx = SPLINE_FindNextT(1, Array);
#while(J < PointNum - 1)
#if(VEq(Array[J][0], x))
#if(J > NextIdx)
#local NextTIdx = SPLINE_FindNextT(StIdx,
Array);
#end
#local LastT = Array[LastTIdx][0].y;
#local NextT = Array[NextTIdx][0].y;
#local Offset = (J - LastTIdx)/(NextTIdx -
LastTIdx);
#local TVal = (NextT - LastT)*Offset + LastT;
#else
#local LastTIdx = J;
#local TVal = Array[J][0].y;
#end
TVal, Array[J][1],
#local J = J + 1;
#end
1, Array[PointNum - 1][1]
#break
#case(3)
#debug "Spline_From_Array() method 3"
#warning "This method is not yet implemented"
//Ignore any T values specified, autocompute all for
constant speed
#local Reference = Spline_From_Array(Type, no, Array)
#local SplLen = Spline_Length(Reference,
PointNum*ConstantSpeedSamples);
#local DistPassed = 0;
#local J = 0;
#if(dimensions(Array) = 1)
0, Array[0],
#while(J < PointNum - 1)
#local IntLen =
Spline_Interval_Length(Reference, Array[J][0].y, Array[J + 1][0].y,
ConstantSpeedSamples);
#local DistPassed = DistPassed + IntLen;
DistPassed/SplLen, Array[J + 1],
#local J = J + 1;
#end
#else
0, Array[0][1],
#while(J < PointNum - 1)
#local IntLen =
Spline_Interval_Length(Reference, Array[J][0].y, Array[J + 1][0].y,
ConstantSpeedSamples);
#local DistPassed = DistPassed + IntLen;
DistPassed/SplLen, Array[J + 1][1],
#local J = J + 1;
#end
#end
#break
#end
}
#end
#version SPLINES_INC_TEMP;
#end//splines.inc
--
Christopher James Huff - chr### [at] maccom,
http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnetdk> wrote:
> #declare Spline =
> spline {
> cubic_spline
> SCP( 0.0, <0,1,2>)
> SCP( x, <1,5,0>)
> SCP( x, <4,1,0>)
> SCP( 0.9, <0,2,1>)
> SCP( 1.0, <0,0,1>)
> SCP( x, <6,5,4>)
> SCP( 2.0, <4,3,2>)
> Spline_Add_Points(MyArray,2.5,4.5)
> Spline_End()
> }
This is starting to be a lot closer to what I like. :)
(How did you get rid of the need to specify the amount of points?)
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> This is starting to be a lot closer to what I like. :)
Glad you're close to liking it. ;)
> (How did you get rid of the need to specify the amount of points?)
Initializing with an array of 100 elements and making it ten times bigger
whenever needed. It wastes a small amount of ressources, but in most cases
nothing worth mentioning. In cases where it's an issue it is still possible
to specify the number of points. It's optional.
BTW, I don't know what is worst - having many unused array elements or
resizing the array quite often (copying the elements into a new bigger
array). If unused elements are very bad I could resize the array often,
making it maybe 2 or 4 times bigger each time. If resizing the array is
worse, I could make the array maybe 10 or 100 times bigger each time. It's a
balance - currently I'm making it 10 times bigger each time but I'm open to
suggestions.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think that your current approach is ok. An array of 100 or even 1000
vectors doesn't take too much memory (in current computers we have plenty),
but copying arrays too often is too slow with POV-SDL (perhaps in pov4 we
will have dynamic arrays anyways, so it will not be a problem there).
If there are hundreds of splines, each one of them containing 101 points,
then the waste of memory is really considerably, so I think there should
be a way of telling the macro the amount of points to reserve (in a similar
way you can tell a std::vector in C++ to allocate space for a specific
amount of items).
This could be just a macro which is called before specifying the points
(like the one in your earlier suggestion). It could be used if you know that
the automatic space reservation will waste too much space.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> I think that your current approach is ok. An array
> of 100 or even 1000 vectors doesn't take too much memory
> (in current computers we have plenty), but copying arrays
> too often is too slow with POV-SDL
That was my impression.
> If there are hundreds of splines, each one of them
> containing 101 points, then the waste of memory is really
> considerably, so I think there should be a way of telling
> the macro the amount of points to reserve
As I said, this is already possible. To quote myself:
"It wastes a small amount of ressources, but in most cases
nothing worth mentioning. In cases where it's an issue it
is still possible to specify the number of points. It's
optional."
> This could be just a macro which is called before
> specifying the points (like the one in your earlier
> suggestion).
That's how it is. :)
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c796226@news.povray.org>,
"Rune" <run### [at] mobilixnetdk> wrote:
> Initializing with an array of 100 elements and making it ten times bigger
> whenever needed. It wastes a small amount of ressources, but in most cases
> nothing worth mentioning. In cases where it's an issue it is still possible
> to specify the number of points. It's optional.
I've never liked the "multiply size by N" method...I've always increased
arrays by a fixed amount, say 16 or 32 elements. As long as the
increment is big enough, you won't have much of a slowdown, but won't
waste as much memory either.
Also, I don't think this is a very time-critical area...the splines will
probably be generated once and then used throughout the scene. I doubt
it will be slow enough to be noticeable.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" wrote:
> I've never liked the "multiply size by N" method...
> I've always increased arrays by a fixed amount,
> say 16 or 32 elements.
Sorry, but that sounds very stupid to me.
If you have a spline with 3000 control point and you expand the array by 32
per expansion, then you'll have the array copied almost 100 times with an
average of about 1500 elements copied each time, which is in total about
150000 elements copied. If however you expand by 10 each time instead,
you'll have 4 expasions at most, with no more than 1111 elements copied in
total. That should parse more than 100 times faster. The memory you save
with your method really isn't worth that.
> As long as the increment is big enough, you won't have
> much of a slowdown
Statistically, the most likely value of "big enough" will increase as the
number of elements increase. Thus you multiply with a value every time
rather than adding a fixed amount.
> but won't waste as much memory either.
Depends on how much you increase it with per time.
> Also, I don't think this is a very time-critical area...
I think it is. You can easily imagine scenes with hundreds of different
splines.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c798771@news.povray.org>,
"Rune" <run### [at] mobilixnetdk> wrote:
> If you have a spline with 3000 control point and you expand the array by 32
> per expansion, then you'll have the array copied almost 100 times with an
> average of about 1500 elements copied each time, which is in total about
> 150000 elements copied. If however you expand by 10 each time instead,
> you'll have 4 expasions at most, with no more than 1111 elements copied in
> total. That should parse more than 100 times faster. The memory you save
> with your method really isn't worth that.
I'm not going to write a 3000 point spline by hand, and the macros
aren't that necessary for automatically generated splines. But just
don't hard code the step value, the user could tune it for their scene
then, if it really parses too slow. Actually, make both the initial and
step values user-defined...they can set the step to 1000 or the initial
size to 3000, and not waste 7000 array positions for the 3000 point
spline.
My guess is most splines will be in the 10's or low 100's, not 1000's.
> Statistically, the most likely value of "big enough" will increase as the
> number of elements increase. Thus you multiply with a value every time
> rather than adding a fixed amount.
I'm not so sure this is true. Past a point, the bigger the spline, the
less likely it is to get 10 times bigger, or even twice as big.
> > Also, I don't think this is a very time-critical area...
>
> I think it is. You can easily imagine scenes with hundreds of different
> splines.
More of a requirement for memory efficiency there as well...
I just don't think the spline code would be that slow. 100 times a small
number isn't a very big number...why don't we do some actual tests?
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote:
> Actually, make both the initial and
> step values user-defined...
Why? No-one will be using them anyways.
The optional way of specifying the exact amount of points is more than
enough to optimize the creation of the spline. I don't think any other
optimization is needed. It would just be overkill.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 24 Feb 2002 03:13:34 +0100, "Rune" <run### [at] mobilixnetdk>
wrote:
> My question is - is the below syntax too ugly or would it be acceptable for
> a macro included in the POV-Ray distribution?
>
> #declare SplineArray =
> array[7*2] {
> 0.0*y, <0,1,2>,
> x, <1,5,0>,
> x, <4,1,0>,
I don't like those vectors at begining. What about something like :
spline{
cubic_spline
SplineFrom(0)
SplineTo(.9,array[4]{<0,1,2>,<1,5,0>,<4,1,0>,<0,2,1>})
SplineFrom(1)
SplineTo(2,array[3]{<0,0,1>,<6,5,4>,<4,3,2>})
}
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c79a935@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Why? No-one will be using them anyways.
>
> The optional way of specifying the exact amount of points is more than
> enough to optimize the creation of the spline. I don't think any other
> optimization is needed. It would just be overkill.
Tell me, what is the difference between specifying the initial size and
specifying the "exact amount of points"?
And do you have any reasons not to let the user change the default step
size? Adding this ability would just take making it a separate variable
instead of hard-coding it.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote:
> And do you have any reasons not to let the user change the default step
> size?
I have no reason for not to let the user do that, but in my opinion no-one
will be using it anyways, so it will probably be a waste of time. (Besides
contamining the already-crowded namespace.)
It could be that increasing the array to 10 times the previous size is
a bit of overkill. Perhaps it could be better to just double the size.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"W³odzimierz ABX Skiba" wrote:
> I don't like those vectors at begining.
> What about something like :
Have you read the entire thread before replying?
Please read the branch in this thread called
"Re: Filling in T values in splines - update"
and then comment to that one.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" wrote:
> Tell me, what is the difference between specifying the
> initial size and specifying the "exact amount of points"?
You're right, in effect it's the same thing. So I don't know why you
requested it when it was already there, and I had made it pretty clear that
it was indeed possible.
> And do you have any reasons not to let the user change
> the default step size? Adding this ability would just
> take making it a separate variable instead of hard-coding it.
It's simply pointless. Either memory is an issue for a spline, or else it
isn't.
If it's not an issue you don't have to care about the step sizes.
In the few cases where memory is an issue, you must have a rough idea of how
big your spline is and then you should just set the number of points
accordingly or a little higher so you're sure there are enough available
elements.
It's just easier to tell the macro how many points your spline has rather
than telling it which approach it should take at guessing how many points
there are. There's no point in going the long way round.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" wrote:
> I've done that before, but never finished because of
> bugs in the spline feature. Here are the (partially
> complete) macros:
Thanks! This might be helpful to me if you provided information about which
macros are used for what, what data types each macro takes as input and what
they output, which macros are meant to be called by the user and which are
called by other macros, and at least one working example for each macro
designed to be called by the user.
(That's basically information I always expect to find when I need to look at
other people's macros. Without that, it takes me unreasonable effort to
figure them out.)
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c7a8bec@news.povray.org>,
"Rune" <run### [at] mobilixnetdk> wrote:
> Thanks! This might be helpful to me if you provided information about which
> macros are used for what, what data types each macro takes as input and what
> they output, which macros are meant to be called by the user and which are
> called by other macros, and at least one working example for each macro
> designed to be called by the user.
I should have commented the thing before...
The macros starting with SPLINE_* are internal macros, not meant to be
seen by the user.
SPLINE_TYPE(Type)
Takes an integer value 0, 1, or 2, and parses linear_spline,
quadratic_spline, or cubic_spline depending on the value. It is used
together with the LINEAR_SPLINE, QUADRATIC_SPLINE, and CUBIC_SPLINE
#defines to tell the include what type of spline it is dealing with. The
spline macros use this to generate splines of a specified type.
Spline_Length(Spline, Intervals)
Computes the length of a spline by dividing it into a number of
intervals and computing the length of each interval. Assumes the spline
starts at 0 and ends at 1.
Spline_Interval_Length(Spline, StartT, EndT, Intervals)
Does the same as Spline_Length(), but finds the length of a specific
segment of the spline, defined by beginning and ending T values.
Spline_Length() isn't that necessary, you could use
"Spline_Interval_Length(Spline, 0, 1, Intervals)".
Constant_Speed_Spline(Spline, Type, Intervals, Samples)
Makes a new spline that follows the path of a given spline, but has the
T values tweaked to give constant speed. It doesn't use the actual
control points of the original, but generates several points along the
original spline. The number of spline segments for the new spline is
given with Intervals, Samples controls the number of intervals used to
determine the length of each segment.
SPLINE_FindNextT(StIdx, Array)
Used by Spline_From_Array() to find the next array entry with a defined
T value.
Spline_From_Array(Type, ConstantSpeedSamples, Array)
Creates a spline from an array of points and possibly time values. I
used a 2D array to specify time values "next to" the points, instead of
specifying them in pairs in a 1D array.
If a 1D array is given, it is interpreted as an array of points, the T
values of the resulting spline are evenly spaced.
If a 2D array is given, the first "row" (Array[N][0]) is taken as the T
values and the second (Array[N][1]) as the points, but some of the
points may be specified without T values. (If the given T for a point is
< 1, 0, 0>, the previous and next specified T values are interpolated.)
If ConstantSpeedSamples > 0, any given T values are ignored, the macro
computes them itself to get constant speed. ConstantSpeedSamples
specifies the number of samples used per segment to get the length of
that segment. Specify 0 samples to turn constant speed off and use one
of the first two methods...you can use the built-in constants "false",
"no", or "off" as well as just plain "0".
These macros never got finished...as I mentioned, I couldn't test them
properly because of bugs in the spline feature, so I never finished or
documented them. I think the constant spline method works though...
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" wrote:
> These macros never got finished...as I mentioned, I
> couldn't test them properly because of bugs in the
> spline feature, so I never finished or documented them.
> I think the constant spline method works though...
Thanks for commenting them.
I will use these macros for inspiration but create some new ones from
scratch that work differently both for the user and internally. Where
applicable I want the macros to work like they are properties of the spline
that can be set, for example I want the constant speed option to be
specified inside the spline definition, like with the other macros I've
shown the syntax for so far. I also want to have the constant speed macro
have access to the control points specified by the user, so that even with
few samples and intervals it will at least go though the control points
specified by the user. When using linear splines, this gets crucially - a
linear spline based on "random" points from a different linear spline will
be all wrong. Instead, when linear spline is used I only want to modify the
T values.
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
|
|
| |
| |
|
|
|
|
| |
|
|
