Looking at Bill Pragnell's wonderful trefoil knot work, I wondered if 
the same ideas could be generalized to other, more complicated knots by 
using splines from KnotPlot, and orienting via Spline_Trace.

The answer seems to be yes and no.  There's evidently some sort of 
glitch with v3.6, when it comes to repeated (looped) calls to 
Spline_Trace (see the thread in pov.general.)  The attached image was 
made with v3.5.  The concern that makes it also not so simple is that 
for general splines, they do not cover a fixed curve length per unit 
time, so that, by using a simple "while" loop, some parts (of a 
stairway, for example) will get crunched together, while other parts 
will be stretched out.  I'm puzzling over a macro that will re-divide a 
spline to cover curve length at a steady rate (or has this already been 
done?)

Also, has anyone else noted the strange behavior of v3.6 and 
Spline_Trans?  Is it a known bug? or not a bug?

Dave Matthews

Post a reply to this message

Attachments:
Download 'kp_sample02.jpg' (53 KB)

Preview of image 'kp_sample02.jpg'

Dave Matthews wrote:

> Looking at Bill Pragnell's wonderful trefoil knot work, I wondered if 
> the same ideas could be generalized to other, more complicated knots by 
> using splines from KnotPlot, and orienting via Spline_Trace.
> 

Argh.  I mean Spline_Trans, of course.

Dave Matthews

Post a reply to this message

Dave Matthews <ns### [at] nospamedu> wrote:

> The concern that makes it also not so simple is that
> for general splines, they do not cover a fixed curve length per unit
> time, so that, by using a simple "while" loop, some parts (of a
> stairway, for example) will get crunched together, while other parts
> will be stretched out.  I'm puzzling over a macro that will re-divide a
> spline to cover curve length at a steady rate (or has this already been
> done?)

I have done this for the latter instalment of my knot project. My algorithm
is slow (parse time > render time) but seems to do the trick. It entails
slowly moving along the path with very small increments in time, and
numerically integrating the distance travelled using repeated vlength()
calls. When the cumulative distance reaches a threshold, place an object
(in my case, a ring of bricks or a stair), reset the cumulative distance
counter and keep going.

This technique works perfectly, but there is still a small bunching effect
on the inside of steep curves where the ends of wide component objects
describe a shorter path than at the outside (e.g., large gaps between brick
layers on the outside of curves). I've partly solved this problem (for the
bricks, at least) by measuring the distance increment at various points
around the minor radius and scaling the objects accordingly. This too is
not fast :). See attached pic for results.

Bill

PS nice image! I might have to delve into higher-order knots for later
versions...

Post a reply to this message

Attachments:
Download 'trefoil6.jpg' (404 KB)

Preview of image 'trefoil6.jpg'

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> I have done this for the latter instalment of my knot project. My algorithm
> is slow (parse time > render time) but seems to do the trick. It entails
> slowly moving along the path with very small increments in time, and
> numerically integrating the distance travelled using repeated vlength()
> calls. When the cumulative distance reaches a threshold, place an object
> (in my case, a ring of bricks or a stair), reset the cumulative distance
> counter and keep going.

That's exactly the approach I've been working on.  If it's slow, that's ok,
after all, we're not being charged by the hour ;-)

> This technique works perfectly, but there is still a small bunching effect
> on the inside of steep curves where the ends of wide component objects
> describe a shorter path than at the outside (e.g., large gaps between brick
> layers on the outside of curves). I've partly solved this problem (for the
> bricks, at least) by measuring the distance increment at various points
> around the minor radius and scaling the objects accordingly. This too is
> not fast :). See attached pic for results.

That was my next concern, also.  The "bunching" would be especially
noticeable for relatively "thick" knots, like your image.  I suppose for
the spiral stairway, one solution is to measure the actual length of the
spiral spline, rather than the center one (?)

> PS nice image! I might have to delve into higher-order knots for later
> versions...

Thanks.  KnotPlot (http://www.pims.math.ca/knotplot/) is a great tool for
creating and manipulating knot splines.  It outputs to POVRay in bicubic
patches.  What I do with the patches is strip out one vector from each
patch.  This gives "N" splines, for the "N" patches in a cross-section.  I
then average these, section by section, to get a center spline that I work
with.  I posted up a sample in p.b.s.f. about a year ago (strangely, the
http news connection gives me a corrupted zip file that doesn't open, but
when I find and download it via my newsreader it still works fine.  Let me
know if you want a copy, and I can e-mail you one if the old posted one
doesn't work.)  I'd really like to see what you could do with other knots
(maybe whack 'em with a few cannon balls!)

Dave Matthews

Post a reply to this message

"Dave Matthews" <dav### [at] mnwestedu> wrote:
> That was my next concern, also.  The "bunching" would be especially
> noticeable for relatively "thick" knots, like your image.  I suppose for
> the spiral stairway, one solution is to measure the actual length of the
> spiral spline, rather than the center one (?)
But my spiral spline (which I use for the handrails) is already bunched,
because I calculate it using a translate-rotate transform combined with the
central path. In any case, I think the stairs are fine as they are. As long
as they don't turn into a continuous ramp, I quite like the idea of varying
steepness! This is one reason why I've made them simple planks without
risers in the version above. I think it looks quite medieval... :)

I've had a quick look at KnotPlot, but I think it'll be a bit of a haul
learning to use it and then extracting splines. On the other hand, I've
managed to find some examples of more complex knots expressed as parametric
equations - these would be ideal, because I can easily substitute them for
the trefoil in my SDL. All I have to do is increase the step count. This
would be better from an artistic point of view, too - I'd quite like to
have a viewpoint on or close to the stairs, and still have plenty of knot
in view. This would be perfect!

>  I'd really like to see what you could do with other knots
> (maybe whack 'em with a few cannon balls!)
I haven't tried that yet - but I will this week. I shall post anything that
looks good, never fear!

Bill

Post a reply to this message

Among other things, Dave Matthews saw fit to write:

>> I have done this for the latter instalment of my knot project. My
>> algorithm is slow (parse time > render time) but seems to do the trick.
>> It entails slowly moving along the path with very small increments in
>> time, and numerically integrating the distance travelled using repeated
>> vlength() calls. When the cumulative distance reaches a threshold, place
>> an object (in my case, a ring of bricks or a stair), reset the cumulative
>> distance counter and keep going.
> 
> That's exactly the approach I've been working on.  If it's slow, that's
> ok, after all, we're not being charged by the hour ;-)

I found a paper somewhere (in the internet) about re-parametrizing splines.
It came to say that, if you get a set of equidistant points along a spline,
you can use these points as nodes of a new spline that will: a) follow the
original spline closely, and b) have constant "arc-length speed". I could
try to find this paper again, but if anyone wants to try, it talked about
road design for simulations or something like that.

For a very different subject, unrelated to POV-Ray, I'm also trying to find
points at a given distance along a spline, but I do that with a standard
programming language, having the explicit parametric equations of all
segments of the spline. I perform the integrations with a Gaussian
quadrature and find the target points with the secant method.

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message