 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnet dk> 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
|
|
| |
| |
|
|
|
|
| |
|
|
