|
|
Mornin' all.
Here's a new knot. I've spent a bit of time generalising my code so I can
instantiate one of several different types; this is the second. It's ~2.5
times longer than a trefoil loop, which made parsing time jump up again
(>45 mins), so I've also changed the way the path is calculated.
Instead of integrating the knot lengths on the fly, now I have a separate
..pov file which outputs data files of angles for equally-spaced brick
layers and stairs. The main code simply reads these values to transform the
bricks and build the staircases. The advantage here is that most of the
parse time was due to the slow length-finding necessary for spacing
components out (over a billion tokens parsed per render!), which now only
needs to be done once per knot type. Lighting, camera and texturing tests
parse in a mere 12 minutes or so.
Nit pick: although I thought I sorted out the misalignment of adjacent brick
layers, it is still visible in two places in this knot. I think this is due
to the high rates of change of curvature (not just high curvature) in these
sections... more thinking necessary!
As an aside, I'm thinking of making the staircases less regular - i.e. only
one 'up' direction (which will probably halve my parse time, too), and have
gaps with annular gantries and platforms (maybe doorways and windows, too).
This may prove difficult...
anyway, enjoy!
Bill
Post a reply to this message
Attachments:
Download 'figureeight1.jpg' (225 KB)
Preview of image 'figureeight1.jpg'
|
|
|
|
Bill,
I've been following this series and I find it very intriguing. Partly due to
the math skills involved and partly due to the very imprseeive images as a
whole. I can offer no improvements, just a thought. Everytime I see one of
these images, I expect to see lamp posts lighting the walkway, especially in
your darker images.
Consider this just my 2 cents worth....I am very impressed indeed.
Tim
"Bill Pragnell" <bil### [at] hotmailcom> wrote in message
news:web.43e1e6f529cf83d1731f01d10@news.povray.org...
> Mornin' all.
> Here's a new knot. I've spent a bit of time generalising my code so I can
> instantiate one of several different types; this is the second. It's ~2.5
> times longer than a trefoil loop, which made parsing time jump up again
> (>45 mins), so I've also changed the way the path is calculated.
>
> Instead of integrating the knot lengths on the fly, now I have a separate
> ..pov file which outputs data files of angles for equally-spaced brick
> layers and stairs. The main code simply reads these values to transform
the
> bricks and build the staircases. The advantage here is that most of the
> parse time was due to the slow length-finding necessary for spacing
> components out (over a billion tokens parsed per render!), which now only
> needs to be done once per knot type. Lighting, camera and texturing tests
> parse in a mere 12 minutes or so.
>
> Nit pick: although I thought I sorted out the misalignment of adjacent
brick
> layers, it is still visible in two places in this knot. I think this is
due
> to the high rates of change of curvature (not just high curvature) in
these
> sections... more thinking necessary!
>
> As an aside, I'm thinking of making the staircases less regular - i.e.
only
> one 'up' direction (which will probably halve my parse time, too), and
have
> gaps with annular gantries and platforms (maybe doorways and windows,
too).
> This may prove difficult...
>
> anyway, enjoy!
> Bill
>
----------------------------------------------------------------------------
----
Post a reply to this message
|
|