John M. Dlugosz <joh### [at] dlugoszcom> wrote:
> I'll start with the bottom.  This "surface" is then general-purpose and I
> can use for sides of things too, like hampers.  Then I'll design the
> more-open sides.
>
> I don't know the terminology you used, as I never took basket-weaving in
> school.  But I see the straight (not bent) sticks running in one direction
> give it strength, and flat ribbons weave among them using a high "tension"
> parameter.  I see a blob_spline can be flattened like a ribbon, but I
don't
> see an option for torus_pipe_spline.  You mean flatten the entire shape
> after defining it?  That means I'll need to pre-compensate the amplitude.

I (compulsorily) wove a few baskets at school when I was 10 or so - I would
suggest you don't take me as any sort of expert on the subject!

As for the flattening, this is why I suggested stretching in the horizontal
direction rather than flattening in the vertical, e.g. for a cross section
that measures 5 x 1 units, use a radius of 0.5 and scale by <5, 1, 1>
(presuming the spline runs in the +z direction, weaving up and down in the
+y).  Otherwise, you can use inverse spline transformations, e.g.:

   object {create_spline_object (MySpline, spline_scale (1/<1, 0.2, 1>))
      scale <1, 0.2, 1>}

This way you can define the shape of the spline exactly as you want it,
because the transformations cancel out any effect on the shape of the spline
path itself (but still change the shape of the cross-section).

Post a reply to this message

> As for the flattening, this is why I suggested stretching in the
horizontal
> direction rather than flattening in the vertical, e.g. for a cross section

Oh, that would be easier.  In my tests, I found that a vector for
spline_radius did not work for torus, and pre-multiplied the amplitude (in
the vector parameter, not using spline_scale) and then reduced the scale.
On my next go, I'll scale up the other direction instead.

I've posted a test render on p.b.i. that shows flattened slats weaving
around fixed sticks.

I think to give a less orderly result, I can start with a grid of points
that represent the intersections, and peterb them a little.  The sticks can
bend too, but very slightly, using the same technology.  I can also vary the
tension a little from strip to strip, to simulate the effect of thicker or
thinner pieces.

--John

Post a reply to this message

Why does changing the spline_steps from 120 to 60 (1210 frame level objects
vs. 610, a factor of 2)affect the rendring time by a factor of 7.6?  It's
even slow on the blank "sky" area above the image and the blank "desk"
below.  Bounding boxes, where art thou?

--John

Post a reply to this message

John M. Dlugosz <joh### [at] dlugoszcom> wrote:
> Why does changing the spline_steps from 120 to 60 (1210 frame level
objects
> vs. 610, a factor of 2)affect the rendring time by a factor of 7.6?  It's
> even slow on the blank "sky" area above the image and the blank "desk"
> below.  Bounding boxes, where art thou?

Where indeed?  I don't specify any bounding boxes internally in the Spline
Macro File, as these will be overridden by POV-Ray unless the -UR command
line option is used.  Instead, each torus is clipped using boxes that fit
the desired segment as closely as possible.  Ideally, POV-Ray would the
bound each torus by its clipping box.  You may find it's best to perform
some manual bounding, however (at least for the union that forms the
weaving, to prevent slow rendering above and below).

Post a reply to this message

> Where indeed?  I don't specify any bounding boxes internally in the Spline
> Macro File, as these will be overridden by POV-Ray unless the -UR command
> line option is used.  Instead, each torus is clipped using boxes that fit
> the desired segment as closely as possible.  Ideally, POV-Ray would the
> bound each torus by its clipping box.  You may find it's best to perform
> some manual bounding, however (at least for the union that forms the
> weaving, to prevent slow rendering above and below).

Right, I thought POV will autobound just fine.  There is no way the empty
areas should be computing intersections with the clipped segments!  Why
would manual bounding be required?  Is POV falling down on this particular
shape somehow?  Is there an infinite object somewhere in your macro that
messes it up?

--John

Post a reply to this message

On Wed, 17 Jan 2001 08:48:48 +1000, Chris Colefax wrote:
>  Ideally, POV-Ray would the
>bound each torus by its clipping box. 

Isn't that what bounded_by{clipped_by} is for?

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On Wed, 17 Jan 2001 08:48:48 +1000, "Chris Colefax"
<chr### [at] tagpovrayorg> wrote:

>Where indeed?  I don't specify any bounding boxes internally in the Spline
>Macro File, as these will be overridden by POV-Ray unless the -UR command
>line option is used.  Instead, each torus is clipped using boxes that fit
>the desired segment as closely as possible.  Ideally, POV-Ray would the
>bound each torus by its clipping box.  You may find it's best to perform
>some manual bounding, however (at least for the union that forms the
>weaving, to prevent slow rendering above and below).

The easiest would be to bound each torus segment like this:

bounded_by { clipped_by }

and then use -UR in the command line. POV *might* just be doing
something wrong.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Peter Popov <pet### [at] vipbg> wrote:
: and then use -UR

  I understand why this feature was firstly added in povray 3.0: Because
most old scenes had manually made bounding objects which weren't necessarily
optimal ones.

  However, this was so long ago that I think a change could be necessary.
  Nowadays it's more a rule than an exception that if people define a
bounding box to an object, it's for a good reason.
  I think that the default should be changed, that is, by default povray
does NOT remove user-defined bounding objects, but you can, if you want,
make it remove them with +UR.

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
> Isn't that what bounded_by{clipped_by} is for?

A quick test shows that POV-Ray's automatic bounding is winning out for the
most part - on a torus spline with 100 segments (201 objects including
joining spheres), using manual bounds removal renders in 32 seconds compared
to 68 when bounded_by {clipped_by} is used with -UR.

The problem John is having might be something to do with the number of
objects he's rendering, or their CSG structure, and possibly highlights a
failing of the automatic bounding system - I'll leave it to John to post the
offending code...

Post a reply to this message

> The problem John is having might be something to do with the number of
> objects he's rendering, or their CSG structure, and possibly highlights a
> failing of the automatic bounding system - I'll leave it to John to post
the
> offending code...

Here is a complete file.

Post a reply to this message

Attachments:
Download 'test3.pov.txt' (3 KB)