POV-Ray 2.2 vs 3.7

Table of Contents

• Intro
• arches.pov
• cluster.pov
• crystal.pov
• eight.pov
• hfclip.pov
• illum1.pov
• illum2.pov
• iortest.pov
• lamppost.pov
• lpops1.pov
• lpops2.pov
• magglass.pov
• mtmand.pov
• pacman.pov
• pawns.pov
• planet.pov
• polywood.pov
• poolball.pov
• romo.pov
• room.pov
• skyvase.pov
• smoke.pov
• soft.pov
• spline.pov
• stonewal.pov
• sunsethf.pov
• tetra.pov
• waterbow.pov
• wtorus.pov
• Review
• Conclusion

Intro

Ever since the early days of DKBTrace, POV-Ray has evolved considerably over its multi-decade history, with each new milestone expanding the capabilities of this venerable ray tracer. Much like other creative software of a similar age, there's a lot of files out there that rely on legacy concepts and feature implementations. In my view, preserving these scenes accurately is important for understanding the evolution of computer graphics, in particular the specific aesthetic qualities of different generations of technology.

Fortunately not only have the POV-Ray team provided some level of backwards compatibility with old projects, but unlike most of its contemporaries, POV-Ray 2 is still very much capable of running in modern computing environments. This begs the question, just how accurate is that legacy support when compared to the real thing? In this comparison we'll put versions 2.2 (1994) and 3.7 (2013) head-to-head, to see just how much has changed in nearly 20 years of development. The scenes we'll be rendering are from the "level2" set included in this archive, all of which were designed for POV-Ray 2.x.

Each scene has been rendered once with each version and the program execution time recorded (note that this is different from the render time reported by POV-Ray itself). The POV-Ray command-lines are as follows:

povray2 +L<POV-Ray 2 include directory> +I<input scene file> +O<output image file> +FT +W640 +H480 +A0.1 +V
povray3 +I<input scene file> +O<output image file> +FT +W640 +H480 +A0.1 +MV2.2 +V

Here's a description of each parameter:

Now, with all that out of the way it's time for the showdown (click thumbnails to enlarge)!

"Arches" (arches.pov) by Dan Farmer

POV-Ray 2.2	POV-Ray 3.7
5.41s	4.32s

First up we have this classic scene from POV-Ray developer Dan Farmer. In the 3.7 image what immediately sticks out is that strange blue band on the horizon. You can also see that the textures have been generated/mapped differently, however we won't be penalizing renders for this, because of factors involving randomization which I'll explain later.

"Cluster of mirrored spheres" (cluster.pov) by Andy Fu

POV-Ray 2.2	POV-Ray 3.7
2.12s	1.95s

Initially I didn't know who made this one since the original source doesn't mention any names, but as it turns out there's an incredibly similar render created by Andy Fu using the Rayshade ray tracer, the POV-Ray 3 version of this scene suggests it was inspired by Eric Haines' Sphereflake. This time both programs have produced the same general output, excellent.

"Crystal" (crystal.pov) by Dan Farmer

POV-Ray 2.2	POV-Ray 3.7
3.82s	2.77s

According to DKBTrace creator David Buck, this scene was used to test the correctness of POV-Ray's refraction code, as his implementation in DKBTrace wasn't accurate to reality. To do this a friend of his made a physical checkerboard, placed a crystal ball on it and took a photograph, this photo became the point of reference for the scene. By comparing the images and adjusting the calculations, it was finally possible to get a match, POV-Ray's refraction code was now correct! As we can see this is still the case today, as both images look identical.

"Eight" (eight.pov) by Ville Saari

POV-Ray 2.2	POV-Ray 3.7
0.74s	N/A

A simple but effective scene. Unfortunately, POV-Ray 3.7 doesn't render it at all, so why is that? Let's look at the error message:

File 'eight.pov' line 60: Possible Parse Error: Unexpected EOF while reading IFF file
Fatal error in parser: Cannot access data in file.
Render failed

The IFF file in question is "eight_.iff", IFF or "Interchange File Format" is a general purpose container format that was popular on Amiga computers (hence why POV-Ray supports it given its Amiga origins). "eight_.iff" is an image texture (used to give the black ball its number), encoded using the ILBM image format created by Electronic Arts in 1985, who also created IFF in collaboration with Commodore.

The issue here is that POV-Ray 3.7's ILBM parser complains that it reaches the end of the data stream before loading the whole image, which would suggest that the file was corrupt in some way, if not for the fact that 2.2 has no issues rendering the scene. Given how old and generally obsolete IFF & ILBM are, it's not very surprising that the IFF parser has some code rot, though it is unfortunate.

"Broken dowel" (hfclip.pov) by Dan Farmer

POV-Ray 2.2	POV-Ray 3.7
2.03s	2.16s

In this scene Dan demonstrates using a height field as part of a "clipped_by" modifier. Things seem good at first but there are some issues in the 3.7 render. First of all the shadow(?) in the bottom left corner is missing, then we can see that the CSG operation has resulted in slightly different geometry (it looks as though it's been shifted to the right a bit) and finally if we view the full images, we can see a small seam on the dowel that isn't there in 2.2.

"Illuminate 1" (illum1.pov) by Tom Price

POV-Ray 2.2	POV-Ray 3.7
17.72s	14.27s

This scene is quite appealing when seen as intended, but something has gone very wrong here, the lighting is all blown out in 3.7!

"Illuminate 2" (illum2.pov) by Tom Price

POV-Ray 2.2	POV-Ray 3.7
7.77s	4.58s

Tom Price is here again with a shiny sequel. 3.7 is correct this time!

"Ior test" (iortest.pov) by ???

POV-Ray 2.2	POV-Ray 3.7
1m15.31s	N/A

This cool scene demonstrates POV-Ray's index of refraction feature using "ior.inc". It also demonstrates another hole in the backwards compatibility. What's the issue this time?

File 'iortest.pov' line 12: Possible Parse Error: Cannot find file 'fov.inc', even after trying to append file type extension.
File 'iortest.pov' line 12: Parse Error: Cannot open include file fov.inc.
Fatal error in parser: Cannot parse input.
Render failed

A simple missing file error. "fov.inc" is an include file, which is the standard way to incorporate multiple source files into a scene. POV-Ray comes with many include files to provide a standard library of things like textures, colors and in this case field of view (FOV) values. These files have been added and changed throughout the history of POV-Ray and in the case of 3.7, "fov.inc" is no longer provided.

"Lamppost" (lamppost.pov) by Anton Raves

POV-Ray 2.2	POV-Ray 3.7
12.78s	10.62s

LEGO enthusiast Anton Raves brings us this rather minimalist render. The evolution of POV-Ray's lighting technology makes for the differences here.

"Lollipops 1" (lpops1.pov) by Tom Price

POV-Ray 2.2	POV-Ray 3.7
6.72s	4.11s

A very '90s scene from Tom. This one almost renders how it should, but the glass 'pop on the left seems to have lost its reflections.

"Lollipops 2" (lpops2.pov) by Tom Price

POV-Ray 2.2	POV-Ray 3.7
5.54s	4.88s

Price sure does like his sequels! Another absent reflection and clear skies in 3.7, where did the fog go?

"Magnifying glass created using POV-Ray's refraction" (magglass.pov) by ???

POV-Ray 2.2	POV-Ray 3.7
2.32s	N/A

Magnificent, but nothing to see in POV-Ray 3.7. The missing "fov.inc" is to blame once again.

"Mt. Mandelbrot" (mtmand.pov) by Dan Farmer & Tim Wegner

POV-Ray 2.2	POV-Ray 3.7
1.43s	1.71s

An abstract treat from two POV-Ray developers. This is very close but the height field and fractal bump map both come out slightly differently.

"Pac Man" (pacman.pov) by Ville Saari

POV-Ray 2.2	POV-Ray 3.7
1.26s	N/A

Perhaps one of the most iconic POV-Ray scenes, as Ville Saari notes: "Pac Man doing his favourite job". 3.7's aborted attempt is no mystery, the IFF parser fails to load the maze texture (pacman.iff).

"Pawns" (pawns.pov) by Douglas Otwell

POV-Ray 2.2	POV-Ray 3.7
52.43s	13.87s

Some glossy goodness to see here, but what happened to the checkerboard pattern in 3.7? Is this some new variant of Chess?

"Planet" (planet.pov) by Ville Saari

POV-Ray 2.2	POV-Ray 3.7
1.33s	2.16s

There's something very familiar about this scene, I can't imagine what it is. No complaints here.

"PolyWood" (polywood.pov) by Eduard [esp] Schwan

POV-Ray 2.2	POV-Ray 3.7
2.83s	2.67s

Another demo scene from a POV-Ray developer, showcasing the power of CSG, Eduard has even made some music videos with POV-Ray! This render seems fine to me.

"Pool balls" (poolball.pov) by Dan Farmer

POV-Ray 2.2	POV-Ray 3.7
0.93s	1.24s

This one is giving me Yakuza flashbacks. Top marks for 3.7!

"Romo" (romo.pov) by ???

POV-Ray 2.2	POV-Ray 3.7
5.10s	4.56s

Talk about strange, apparently this scene depicts "Fun reflections of a fertility symbol"? Looks like 2.2 and 3.7 are a match in this instance.

"Room" (room.pov) by Drew Wells

POV-Ray 2.2	POV-Ray 3.7
4.49s	3.82s

Pretty funky room we've got here, created by the original POV-Team leader. The render is mostly on point but that brown sphere looks completely different!

"Sky vase" (skyvase.pov) by Dan Farmer

POV-Ray 2.2	POV-Ray 3.7
5.62s	3.23s

This scene will be familiar to anyone who's looked at POV-Ray's Wikipedia page. Nothing to note about this render.

"Dark, smokey glass ball" (smoke.pov) by ???

POV-Ray 2.2	POV-Ray 3.7
0.86s	1.64s

Are you contemplating the sphere? The smoke effect is brighter in 3.7 for some reason.

"Demo of extended light sources" (soft.pov) by Steve Anger

POV-Ray 2.2	POV-Ray 3.7
6.68s	2.95s

Another developer demo, just as the name implies. Almost perfect but the light is a bit brighter in POV-Ray 3.7.

"Spline" (spline.pov) by Drew Wells

POV-Ray 2.2	POV-Ray 3.7
1.69s	1.55s

As is POV-Ray tradition Drew wrote his own tool to convert curves to spheres, quite abstract for a festive scene don't you think? The camera seems to be ever so slightly shifted in 3.7 but I don't think it's worth complaining about.

"Stone wall" (stonewal.pov) by Dan Farmer

POV-Ray 2.2	POV-Ray 3.7
5.18s	3.22s

According to Dan this scene wasn't really finished, but I quite like it for its simplicity. The output is as expected, sans texture differences which we'll be covering soon.

"Height field sample" (sunsethf.pov) by Douglas Muir

POV-Ray 2.2	POV-Ray 3.7
5.71s	4.52s

A lovely golden landscape from the man who implemented height fields (thanks Doug!). Height fields are also the area where this scene differs between versions, most apparent is an extra peak near the bottom left that appears in 3.7.

"Tetra" (tetra.pov) by ???

POV-Ray 2.2	POV-Ray 3.7
5.20s	3.27s

Amusingly the source for this one lists the author as "???" as well! This would make for a good album cover, no matter which version was used.

"Water bowl" (waterbow.pov) by Various and Sundry

POV-Ray 2.2	POV-Ray 3.7
5.53s	4.64s

I assume those aren't the actual author names, nice texture on the bowl here. These both look good to me.

"A single wooden torus" (wtorus.pov) by Dan Farmer

POV-Ray 2.2	POV-Ray 3.7
5.05s	2.05s

For our final scene Dan demonstrates the "wood" pigment in POV-Ray. A nice way to finish with 3.7 rendering as it should.

Review

With all of our scenes tested it's time to summarize what we have learned. Let's start with some stats:

What the data shows is that although POV-Ray 3.7 can render most scenes (with the 4 remaining requiring small fixes), unfortunately less than half of the 29 scenes have been rendered the same way that 2.2 does. On a positive note, 3.7 is generally much faster than 2.2 (that is except in certain circumstances), saving over a minute in time spent. This is because POV-Ray 3.7 introduced SMP (aka multi-threading) support, allowing it to use your CPU to the fullest extent. The speed increase isn't universal though, as two decades of extra development seems to have resulted in some additional baggage, allowing 2.2 to take the lead in lighter scenes.

Earlier I mentioned that I wouldn't be penalizing 3.7 for texture generation/mapping differences, this is because POV-Ray uses random number generation (RNG) in certain aspects of the rendering process. Back in the 2.2 days your system random number generator was used to seed POV-Ray's RNG, which meant that different operating systems would produce differing results, even when rendering the same scene. This is specifically mentioned in the official documentation (check "/povdoc/docs/povray.doc"), the solution suggested is to modify the source to incorporate a deterministic RNG from the "ibm.c" file, the 2.2 build used in this comparison has been modified as such and works as advertised. Check out my compilation guide if you want this build for yourself.

What this means though is that unless the author of a scene was using a build with that same random number generator, the only 100% correct as intended rendering of a scene, would be one that was rendered on the same OS used by its creator. As a result I can't criticize this aspect of 3.7's backwards compatibility, since it's an issue that can crop up even with POV-Ray 2.2. The good news is that modern-day POV-Ray uses deterministic RNG, so hopefully this specific issue won't be a problem when people are rendering 3.x scenes on future generations of the software.

Before we wrap things up I would like to point out a warning message that 3.7 gives when rendering in 2.2 mode:

Parse Warning: The scene finished parsing with a language version set to 3.1 or earlier.
Full backward compatibility with scenes requiring support for bugs in POV-Ray version 3.1 or earlier is not guaranteed.
Please use POV-Ray 3.5 or earlier if your scene depends on rendering defects caused by these bugs.

As we can see the developers themselves don't promise full support for old scenes. Now, you might be wondering if a showdown between 2.2 and 3.5 is in the works, unfortunately though my attempts to compile it have been unsuccessful. 3.5 depends on a very old version of libpng that is API incompatible with current releases, which means it's actually less accessible on modern systems than 2.2 is. Also, since the main advantage of 3.7 in this context (multi-threading) isn't featured in earlier versions, there isn't much point outside of curiosity. If anyone wishes to make the comparison themselves though then feel free, I would be happy to link to it here.

Conclusion

In conclusion, POV-Ray 3.7 makes a good effort when rendering legacy scenes, but it definitely isn't a replacement for 2.2. Fortunately, it doesn't need to be, as good programming practices mean that POV-Ray 2.2 should remain accessible on modern computers for the foreseeable future. I would like to clarify that this comparison isn't meant to belittle the efforts of POV-Ray's developers, 3.7 does a much better job than expected and outside of this particular context, is many magnitudes more powerful and advanced than 2.2 in every way. As it stands though, for retro scenes whether old or new, 2.2 is the tool to use.