brainwagon

Apparently after two years of noodling around, the POV-Ray team has finally seen fit to release a new version of their rendering software. I can’t help but be mystified at how this project continues to generate enthusiasm among the amateur computer graphics community.

First of all, it’s code quality is uneven and quirky at best, and downright obtuse at worse. I haven’t looked at the newest release, but my copy of the 3.5 release contains some truly mystifying code. For instance, as I recompiled it just now (again, the 3.5 version), I get hundreds of these warnings:

povmsgid.h:203:44: warning: multi-character character constant

Whenever I see old, supposedly mature code exhibit such problems, I’m a teensy bit suspicious that the authors are careless. But beyond this, try looking at the overall structure of primitives. Here is the code that translates a torus, along with its comments:

/*****************************************************************************
*
* FUNCTION
*
*   Translate_Torus
*
* INPUT
*
*   Object - Object
*   Vector - Translation vector
*
* OUTPUT
*
*   Object
*
* RETURNS
*
* AUTHOR
*
*   Dieter Bayer
*
* DESCRIPTION
*
*   Translate a torus.
*
* CHANGES
*
*   Jun 1994 : Creation.
*
******************************************************************************/
   
static void Translate_Torus(OBJECT *Object, VECTOR, TRANSFORM *Trans)
{
  Transform_Torus(Object, Trans);
}
 

In other words, Translate_Torus is really no different than Transforming it, although the proud author Dieter Bayer sought fit to proudly proclaim that he is responsible for wiring this one function to another. What’s even more mystifying is that many primitives have precisely the same code in them, or code that varies only subtly. In general, POV-Ray could probably be reduced in size by half by judicious (or even cursory) refactoring of the code base.

And as for commenting, it simply doesn’t help. Most of the INPUT, OUTPUT, RETURNS, DESCRIPTION and CHANGES blocks in the code base are empty, so what use is it to have them there at all? As for attribution, use source code control to keep track of who is responsible for what code, at least that information will be reasonably correct and up to date.

Another thing that bugs me: what language does POV-Ray accept? The simple answer is that it is virtually impossible to know, since the grammar it uses is simply an adhoc chunk of code that is not documented.

But the thing which bugs me the most is that POV-Ray isn’t open source. From their license file:

This licence does not grant any right of re-distribution or use in any manner other than the above. The Company has separate license documents that apply to other uses (such as re-distribution via the internet or on CD); please visit http://www.povray.org/povlegal.html for links to these. In particular you are advised that the sale, lease, or rental of the Software in any form without written authority from the Company is explicitly prohibited.

In other words, don’t modify it, don’t distribute it, maybe we will take your work if you give it to us, but don’t expect us to give it back to you. Why would skilled open source advocates want to participate in such a project? This is part of the reason I suspect why even modest revisions are two years apart. They don’t want you to muck with their precious code base, even if it results in significant improvements in the many problems that the program itself has.

Oh, in case you might want to worry about something else, POV-Ray almost certainly violates Pixar’s stochastic sampling patents.