POV-Ray : Newsgroups : povray.general : sphere_sweep woes : Re: sphere_sweep woes Server Time
5 Aug 2024 18:23:01 EDT (-0400)
  Re: sphere_sweep woes  
From: Charles Fusner
Date: 19 Sep 2002 19:33:59
Message: <3D8A5F3E.90008@enter.net>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.