I used several sphere_sweeps in a recent IRTC entry, and yes, they
are rather slow to render. They are slow rendering creatures to
begin with but I initially felt there was a problem with
auto-bounding too. After recently reading some past problems others
had, I tried dropping the bounding threshold to 0 (my test cases
were all with one or two sweeps, so double duh to me), and
experienced results comparable to manual bounding of the same
object.

Still, if any given sweep extends across a significant portion of
your image, it'll be quite slow.  It's quite intensive calculating a
sphere swept along a multi-segmented spline. If you can simulate the
same effect by breaking it into multiple smaller sweeps each in its
own section of the image that might help somewhat (untested, but it's
an idea).

There was recently some mention of improved bounding for sphere_sweeps
(the words "heirarchal bounding" caught my attention), but that's an
unofficial patch that's being worked on. For the time being, just be
sure your sweeps are properly bounded and take up a second hobby.
Me, I'm teaching myself matrix math. :)


-- 
@C[$F];
The Silver Tome ::  http://www.silvertome.com
"You may sing to my cat if you like..."

Post a reply to this message

Charles Fusner <cfu### [at] enternet> wrote:

> Still, if any given sweep extends across a significant portion of
> your image, it'll be quite slow.  It's quite intensive calculating a

The problem with the current bounding of a sphere_sweep is, as you may
have guessed, that the whole sweep is put into one large bounding box.
In the worst case, if the sweep goes from say <-10, -10, -10> to <10,
10, 10>, this box will cover a unneccessary large volume. Every time the
box get hit, all segments (whose number depends roughly on the number of
spheres in the sphere_sweep description) of the sweep are tested against
the ray, which can be slow for cubic and b-spline sweeps.

> There was recently some mention of improved bounding for sphere_sweeps
> (the words "heirarchal bounding" caught my attention), but that's an
> unofficial patch that's being worked on. For the time being, just be

The idea behind this is to put each segment of the sweep into its own
bounding box. Much less space wasted, much faster calculations
hopefully. You can have the same effect with manual bounding, but it's
hard to figure out the correct boxes, as you seem to have noticed. :)

> sure your sweeps are properly bounded and take up a second hobby.
> Me, I'm teaching myself matrix math. :)

That's always good. :) A simple solution for b-splines is to put every
four consecutive spheres of the sweep description into a box. The sweep
can't be outside of this box. Same goes for linear sweep and two
consecutive spheres. Cubic (Catmull-Rom) sweeps are much harder to
track, though.

Jochen Lippert

-- 
No smilies were harmed in the making of this message ;)

Post a reply to this message

Jochen Lippert wrote:
 >>There was recently some mention of improved bounding for sphere_sweeps
 >>(the words "heirarchal bounding" caught my attention), but that's an
 >>unofficial patch that's being worked on. For the time being, just be
 >
 >
 > The idea behind this is to put each segment of the sweep into its own
 > bounding box. Much less space wasted, much faster calculations
 > hopefully.

Ah... I see. Yes, this sounds like a sensible approach given the
nature of the object.

  > You can have the same effect with manual bounding, but it's
  > hard to figure out the correct boxes, as you seem to have noticed. :)
 > [...]
 > That's always good. :) A simple solution for b-splines is to put every
 > four consecutive spheres of the sweep description into a box. The
 > sweep can't be outside of this box. Same goes for linear sweep and two
 > consecutive spheres. Cubic (Catmull-Rom) sweeps are much harder to
 > track, though.

Hmmm... this makes me idly ponder: until such time as there is
heirarchal bounding, perhaps one could use a macro to make
sphere_sweeps. This macro would take an array of control points and
build not one sweep but rather a lot of single segment sphere_sweeps,
duplicating control points at the appropriate places so that the ends
of the each segment smoothly connected to the next. Auto-bounding would
work it's magic on each individual segment instead of the whole group,
and the speed up effect might be comparable (?)

Don't know how much of a difference this would make in practice, but
this is an example...

// A utility macro called in Multisweep (below)
#macro _MultipleRadii(Num,RArray,This)
     #if (Num>1)
         RArray[This]
     #else
         RArray[0]
     #end
#end

// SplineType is a string, Nodes and Radii are arrays. Note, if you
// want only a uniform radius, declare one element in the Radii array.
// This would be more convenient that having to type a lot of values
// when you only want one throughout.
// Tolerance and material are a float and declared material as you'd
// expect.
#macro MultiSweep(SplineType,Nodes,Radii,Tolerance,Material)
      #ifndef(STRINGS_INC_TEMP)
          #include "strings.inc"
      #end
      #local ThisNode = 0;
      #local NodeCount = dimension_size(Nodes,1);
      #local RadCount = dimension_size(Radii,1);
      #while (ThisNode < NodeCount-3)
          sphere_sweep {
              Parse_String(SplineType)
              #if (strcmp(SplineType,"linear_spline")!=0)
                 4,
              #else
                 2,
              #end
              Nodes[ThisNode],
                       _MultipleRadii(RadCount,Radii,ThisNode)
              Nodes[ThisNode+1],
                       _MultipleRadii(RadCount,Radii,ThisNode+1)
              #if (strcmp(SplineType,"linear_spline")!=0)
                  Nodes[ThisNode+2],
                       _MultipleRadii(RadCount,Radii,ThisNode+2)
                  Nodes[ThisNode+3],
                       _MultipleRadii(RadCount,Radii,ThisNode+3)
              #end

              tolerance Tolerance
              material { Material }
          }
          #local ThisNode = ThisNode +1;
      #end
#end //Start_MultiSweep


-- 
@C[$F];
The Silver Tome ::  http://www.silvertome.com
"You may sing to my cat if you like..."

Post a reply to this message

Charles Fusner <cfu### [at] enternet> wrote:

> Hmmm... this makes me idly ponder: until such time as there is
> heirarchal bounding, perhaps one could use a macro to make
> sphere_sweeps. This macro would take an array of control points and
> build not one sweep but rather a lot of single segment sphere_sweeps,
> duplicating control points at the appropriate places so that the ends
> of the each segment smoothly connected to the next. Auto-bounding would
> work it's magic on each individual segment instead of the whole group,
> and the speed up effect might be comparable (?)

Not a bad idea at all. :) One problem might be the overlap between two
adjacent segments of this sphere_sweep-in-parts, but since there is a
similar problem with the implementation as it is now, this may work
quite well. Maybe the partial sweeps should be merged together, though,
or does this affect the bounding in a negative way?

Jochen Lippert

-- 
No smilies were harmed in the making of this message ;)

Post a reply to this message

Jochen Lippert wrote:
> 
> Not a bad idea at all. :) One problem might be the overlap between two
> adjacent segments of this sphere_sweep-in-parts, but since there is a
> similar problem with the implementation as it is now, this may work
> quite well. Maybe the partial sweeps should be merged together, though,
> or does this affect the bounding in a negative way?
> 
> Jochen Lippert
> 

Well, I just tried it out to see. Unions, of course, get split up
unless POV is told otherwise, so the bounding still works the same,
but merge, apparently can't be similarly split. On an aside, this
might at least contribute to the slowness of the merge vs. union.

Of course, this only affects transparency, but still, it limits the
usefulness of the macro sweep technique. It is, however, useful to
demonstrate the value that internal heirarchal bounding would provide.
Here are a few limited statistics all from an array of the same 14
spline points. The equivalent 14 point sweep (not through the macro)
is listed on the right for comparison purposes... This if, of course,
just some quick data on a single sweep (I'll attach the array of points
at the end), but it is promising as far as it goes. All tests on a P4 
1.6ghz with 512megs of memory (milage may vary :) )

Notes               With Macro  ...     Whole Sweep
linear_spline         6 seconds         10 seconds
cubic_spline         36 seconds         43 seconds
b_spline             27 seconds         38 seconds

linear as union       6 seconds          n/a
cubic as union       36 seconds          n/a
b_spline as union    27 seconds          n/a

linear as merge**    1 min 6 seconds     n/a
cubic as merge       1 min 53 seconds    n/a
b_spline as merge    1 min 43 seconds    n/a

So, as expected, merge did ruin the speed up, and in fact resulted
in much worse times than just using the whole sweep. Additionally
the ** beside "linear as merge" indicates some curious artifacts which
looked like the nodes between the segements were breaking up (all the
other tests ran fine, and looked largely indistinguishable from the
whole sweep.

Even this brief test shows between a 17% and 40% speed up. I think
it suggests that heirarchal bounding would be a large benefit to the
sphere_sweep object. In most cases the macro provides a temporary
workaround for it, thought it is less convenient to set up, and of
course, won't work properly with transparency. Here are the
camera, lights, and points array used in the test, FWIW. Mutlisweep()
used per my last post, and the whole sweep was just hand written from
the points given.

camera {
   location  <      5.318,      -3.000,       5.191>
   sky       <    0.00000,     0.00000,     1.00000>
   up        <        0.0,         0.0,         1.0>
   right     <    1.42078,         0.0,         0.0>
   angle         70.30414    // Vertical      52.728
   look_at   <     -0.041,       0.062,       1.087>
}

light_source {  <0.0, 0.0, 0.0>  color rgb <1.000, 1.000, 1.000>
   translate  <0.757616, -21.704405, 40.352578>
}

#declare Nodes =
array[14]
{
     <-0.464448, -2.841777, 0.275671>,<-1.154055, -1.827648, 0.275671>,
     <-1.913265, -1.005762, 0.525671>,<-2.159817, 0.085617, 0.775671>,
     <-1.827648, 1.154055, 1.025671>,<-1.005762, 1.913265, 1.275671>,
     <0.085617, 2.159817, 1.525671>,<1.154055, 1.827648, 1.775671>,
     <1.913265, 1.005762, 2.025671>,<2.159817, -0.085617, 2.275671>,
     <1.827648, -1.154055, 2.525671>,<1.005762, -1.913265, 2.775671>,
     <-0.085617, -2.159817, 3.025671>,<-1.302571, -2.443773, 3.025671>
}

#declare Radii = array[1]{ 0.2 } //i.e. used uniform radius



-- 
@C[$F];
The Silver Tome ::  http://www.silvertome.com
"You may sing to my cat if you like..."

Post a reply to this message