Daren Scot Wilson wrote:
> Al Zimmerman wrote:
> >
> > Does anyone know if POV spends more time shading or performing ray
> > intersection ??  Assume the time spent traversing the database is
> > included with the ray intersection time.
> 
> Definitely, it's spending its time on intersection tests.  When I added
> the color dispersion feature to my personally hacked version of POV-Ray,
> I changed all the colors from float[3] to float[9] - triple-sized
> arrays.  This had to be done everywhere - pigments, reflection
> calculations, refractions, etc.   When i ran this new povray, it ran
> maybe only 5% slower - it wasn't easy to measure the difference, as my
> computer runs other things in the background all the time.  If shading
> calculations were taking up most of the time, the new povray would have
> run 2-3 times slower.

I've been running detailed benchmarks on POV-Ray lately, and it's
spending the lion's share of its time doing two things:  intersections
and lighting calculations (is this spot lit by this light source). 
There are actually some funky side effects of the implementation, such
as the fact that when tracing scenes like skyvase.pov (the "standard"
benchmark) or shapes.pov, it's spending something like 10% to 15% (!) of
its time in memcpy() [on an UltraSPARC, compiled with egcs-2.90.29
980515]!  Most of those memcpy() calls are implicit, in object copies
within block_point_light().  However, a significant amount of time is
also spent inside the Determine_Apparent_Colour() routine (which is
lighting-related).

Has anyone on the POV team run an exhaustive set of POV scenes under
Pure Atria's "Quantify", as I am doing?  It's quite enlightening.  I
wish I knew enough about ray-tracer structure to evaluate whether POV is
relatively slow or fast for its features (I've seen allegations that
it's quite slow, from someone who claimed to have written a scene-file
compatible tracer of his own that was MUCH speedier than POV.)

--
Chris Tate
cta### [at] worldstdcom

Post a reply to this message