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.

Thanks in advance,

Al

Post a reply to this message

In general, ray-tracers spend up to 90% of their time performing
intersection tests.  I know POV is very optimized, but I would be
surprised if it still didn't spend most of its time doing intersections.

For more information on ray-tracing in general, you can take a look at a
(non-technical) paper that I wrote about it for a class last semester. 
It is at:
  http://students.cs.byu.edu/~buck/raytracing.html

Anyone know anything more specific?

- Jamis Buck
  buc### [at] csbyuedu
  http://students.cs.byu.edu/~buck

Post a reply to this message

Jamis Buck <buc### [at] csbyuedu> writes:

> In general, ray-tracers spend up to 90% of their time performing
> intersection tests.  I know POV is very optimized, but I would be
> surprised if it still didn't spend most of its time doing intersections.
> 
[...]
> Anyone know anything more specific?

I've just run a profiler (quantify) on povray with the well-known skyvase.
The output for the most time consuming functions is:
12.51% Intersect_Plane
11.98% DNoise
10.16% memcpy
 5.72% All_CSG_Intersect_Intersections
 4.97% All_Plane_Intersections
 3.70% Inside_Plane
 3.22% Noise

Time consumption in memcpy is about
30% block_light_source
18% coloring
rest intersections

I also examined povray with a scene I'm working on. It is far more complicated
than the skyvase. It uses a lot of CSGs and layered textures. In this case
the relative time consumption for calculating intersections was even higher 
than in case of the skyvase.

ThW

-- 
Tho### [at] uni-konstanzde
http://www.informatik.uni-konstanz.de/~willhalm/
Tschieses lavs ju

Post a reply to this message

I have not measured anuthing, so I cannot say for definite, but try to
raytrace a nice scene (reasonably complex) first without textures and then
with nice textures (some layered). I bet you are going to see a huge
difference. In the first one you most probably had 95% to 100% intersection
testing, in the second one chances are you had much less than 30%
intersection testing.

I have noticed that some of the nice textures are very floating point
intensive, and you can explain that very easily if you use turbulence.

That's only what I think, but I don't thn=ink I'm far off.
Al.


Jamis Buck wrote:

> In general, ray-tracers spend up to 90% of their time performing
> intersection tests.  I know POV is very optimized, but I would be
> surprised if it still didn't spend most of its time doing intersections.
>

--
ANTI SPAM / ANTI ARROSAGE COMMERCIAL :

To answer me, please take out the Z from my address.

Post a reply to this message

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.
> 
> Thanks in advance,
> 
> Al



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.


-- 

Daren Scot Wilson
Member, ACM
dar### [at] pipelinecom
www.newcolor.com
---------------------------
"If we aren't supposed to eat animals, why are they made of meat?" 
                                            -- unknown

Post a reply to this message

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