Chris Huff wrote in message ...
>In article <3a07969c@news.povray.org>, "Mark Wagner"
><mar### [at] gtenet> wrote:
>I've never used POV_REALLOC()(or realloc())...maybe it is a bug in the
>pov_realloc() function. Did you get it working with realloc(), or did
>you try some other way?


POV_REALLOC() is just a wrapper for pov_realloc(), which itself calls
realloc().  My solution is to call POV_MALLOC() to create a larger array,
followed by memcpy() to copy the old array to the new, and POV_FREE() to get
rid of the old array.

>> #declare Spl[2].t = 0.4; // Sets the t value
>
>I think f and t are already reserved for filter and transmit...you would
>have to use something else.


As of POV 3.1g, t is only used for referring to the fourth component of a
four-dimensional vector.  Thus, it is available for using here, since all
splines are technically 5-dimensional vectors.

>> Arrays of splines would be treated as multi-dimensional arrays, with the
>> last dimension being the spline index.
>
>This probably would work...it certainly looks simpler and cleaner than
>my syntax, though a bit less clear in some rare circumstances.
>How about a similar syntax for getting textures, pigments, colors, etc.
>from blend maps?


Possible.  I don't know how difficult it will be to implement.

>These definitely need fixing...
>Hmm, another thing that would be nice is a larger assortment of spline
>types. Catmull-rom, b-splines, etc...


I'll do so if someone can point out some references for these, preferably
with C code examples.  I'm having enough trouble trying to decipher the
cryptic pseudo-code from my Numerical Analysis textbook to want to deal with
Fortran.

--
Mark

Post a reply to this message