|
|
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
|
|