|
 |
I said prior to 2.2, which introduced bounding as I understand. This is
part of the article in Ray Tracing News that I based my impression on:
...The POV developers sent me a beta of POVRAY 2.0 so that the snail's
pace of 1.0 could be (massively) improved...
Timings - default size SPD databases (i.e. up to 10,000 objects in a
scene), time in seconds on HP 720 workstation, optimized and gprof
profiled code. Includes time to read in the ASCII data file and set up.
Note that profiling slows down the execution times, so real times would
be somewhat faster in all cases (about 30%); plus, the profiler itself
is good to +-10%. Also, these timings are purely for this machine -
results will vary considerably depending on the platform (see David
Hook's article). Now that I've explained why these are useless, here
goes:
balls gears mount rings teapot tetra tree
Art/Vort 478 1315 239 595 235 84 381
Art/Vort +float 415 1129 206 501 203 72 327
Rayshade w/tweak 188 360 174 364 145 61 163
Rayshade w/grid 1107 412 174 382 145 61 1915
Radiance 289 248 165 601 150 42 197
Bob 402 747 230 831 245 50 266
RTrace 664 1481 813 1343 341 153 372
RTrace c6 m0 652 1428 811 1301 331 155 363
POV 2.0beta+ 588 1895 668 1113 306 56 542
POV 1.0 191000 1775000 409000 260000 45000 31000 250000
Here are timing ratios (i.e. 1 is the fastest time for a given test,
with the other timings normalized to this value):
balls gears mount rings teapot tetra tree
Art/Vort 2.54 5.30 1.45 1.63 1.62 2.00 2.34
Art/Vort +float 2.21 4.55 1.25 1.38 1.40 1.71 2.01
Rayshade w/tweak 1 1.45 1.05 1 1 1.45 1
Rayshade w/grid 5.89 1.66 1.05 1.05 1 1.45 11.75
Radiance 1.54 1 1 1.65 1.03 1 1.21
Bob 2.14 3.01 1.39 2.28 1.69 1.19 1.63
RTrace 3.53 5.97 4.93 3.69 2.35 3.64 2.28
RTrace c6 m0 3.47 5.76 4.92 3.57 2.28 3.69 2.23
POV 2.0beta+ 3.13 7.64 4.05 3.06 2.11 1.33 3.33
POV 1.0 1015.96 7157.26 2478.79 714.29 310.34 738.10 1533.74
...POV 2.0 has an efficiency scheme built in and so is comparable to the
others, so don't get freaked out by the POV 1.0 performance numbers.
-Mike
Ken wrote:
>
> Mike wrote:
> >
> > From the benchmarks I've seen for versions prior to 2.2, it would seem
> > there was plenty of time to read the docs ( and War and Peace, Moby
> > Dick, some Encyclopedias...)
> >
> > -Mike
>
> I'm not sure that's an altogether fair assesment. You
> have to remember a 386-33 was a fast machine when v2.2 was
> current. I still have v2.2 on my system and use it a couple
> of times a month. It is not that slow and believe it or not
> it handles large triangle files better than 3.1 does.
> Just before I logged on I was trying to get a 4 meg mesh
> file to render. I kept getting syntax errors up the wazoo.
>
> I think there is a problem with the way Pov reads the scene
> out of the memory buffer, once the first run is executed,
> instead of off of the disk for each render. I tried repeatedly
> to correct the phantom errors, saved the file, hit the render
> button and the corrected(?)syntax problem reappeared. The
> funny part is there is no real syntax problem in the scene.
> Pov just thinks there is. For some reason I don't think it
> is updating the memory buffer when the file is saved to
> disk. It only occurs on large files but it is frustrating.
>
> Anyway I gave up, changed the mesh to a union, changed a
> couple of minor version problems and fired up 2.2.
>
> Guess what !
>
> After fixing two degenrate triangles it rendered immediatly
> without so much as a hiccup <hic !>.
>
> ***And*** the render time was entirely acceptable.
>
> I guess dos handles memory better than windows does :)
>
> In conclusion I disagree with your statement.
>
> --
> Ken Tyler
>
> tyl### [at] pacbell net
Post a reply to this message
|
|
