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

> 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