Heavily snipped from Ib Rasmussen's post:  (the following had stuff where there
are blank lines)

>I would prefer one scene file. That should be a scene that uses as many

>To get around the problem of a slow enough scene for state of the art

>compile), the scene is rendered at several different resolutions (say
>from 320x240 to 3200x2400). On fast system you choose a high resolution,
>on slow systems a low resolution for running the benchmark. To avoid

The problem with using a single file, and multiple resolutions to try to
compensate for different machines is that it only compensates for differences
in the rendering time.  If you've got a scene that takes several minutes for
the wonder-machine to parse, then my lowly P1-133 with 24Mb memory might take
?hours? (or some large  amount of time anyways) to parse it, even though I'm 
only doing the render at 320x240.

The same with memory issues.  128 Mb is becoming a fairly standard amount of
memory in a new machine.  So to really test how POV performs for large memory
accesses, you should use a reasonable chunk of that.  Which is going to drive
my machine into swapping, since memory is as much a function of number of
objects in the scene as it is of rendering resolution.

Ultimately, for accurate testing, what's probably needed is several catagories
of test files (parse time, memory usage, render time, etc) at several different
levels (from 486-66 to drool-worthy-super-machine).  

You could then run up the scale of increasingly-demanding tests until you got
a meaningfull time (say order 10 min), and post your results indicating both
what time, and which test.

Admittedly, this gets complicated, in several terms: creating various test
files, probably create a utility to automatically run them and post the results
(that or very good directions), finding a good way to display the results,
etc.

Jamie

Post a reply to this message