You might check out Mitsuba (http://www.mitsuba-renderer.org/) and LuxRender (http://www.luxrender.net/). Both are more modern open-source renderers with Python APIs, and I know that Mitsuba is quite popular in the graphics research community (in part because that's where it comes from).
I enjoyed this article but I think it's worth pointing out that for simple animations like those shown in example 1 you may not even need Python - POVRay lets you use clock-dependent variables in your scene files and then set off a batch render.
It is interesting to hear that the author would prefer Blender over POV-ray in some way, and there are links in the comments to make that work (in terms of running Blender in a headless-like way).
I wonder if there are good resources to create Blender scenes in Python with the full rendering step.
To follow up with a working example of python via headless blender on the command line, the following 4 lines interactively get me an image of a sphere saved to /tmp/.png
My point in the post was more that the embedded Python in Blender isn't really a "binding", it forces you to use Blender's 'internal' Python installation, so you must reinstall all the packages that you need specifically for Blender's Python (I don't know how, but I think there is a way). Also, this makes it impossible to use virtualenv, I guess (not sure).
In short, it would be cool if it just "worked from Python".
I ran this on a Mac, should work on Linux as well. Since it may not be obvious, the "blender" command line executable is located within the regular Mac OS X Application bundle for blender that you would download from the web:
The Python library cgkit already supports Aqsis, Pixie, and 3Delight, by the way.
Cycles is also free, open source, and cross-platform, and Cycles seems to be both further ahead than either Aqsis or Pixie and moving faster. However, it could use someone to make a Python interface for it.
POV-ray is cool. I remember first using it back in high school when one of my friends introduced me to it. Back in the day, it was a total blessing for me as using a 3D modeling software would COMPLETELY slow down my Intel Celeron powered PC. :-)
Now, this tutorial gives me a good excuse to try out POV-ray once again...
You had a celeron, sounds like you were spoiled. :P I had my dads old 486 to play with POV-ray on. I remember getting up at 5 am to work on a scene and come back from school to see if it had rendered right. Do homework tweak and hit render just before bed. If I was lucky I'd finish something cool once a month or so.
I started with POVray on a 486... then I had a big animation to do, so I wrote a primitive filesystem-based job scheduler. I used 13 office computers (P60 or P66) working in parallel to get a 30-second animation done in only a weekend. I think it was about 2 hours rendering/frame.
While I love the way POV-Ray (And OpenSCAD, for that matter) does things, it bothers me that its language is more about specifying rendering than describing the objects in the scene. That is, the textual commands directly used for rendering, you can't use POV-Ray's language to define a scene and then export it to some 3D file format, to the best of my knowledge, which can then be rendered somewhere else.
Povray relies heavily on operations on primitives like spheres and cylinders, and uses procedural texturing. That can't easily be efficiently converted to triangles and texture maps.
It's hard to port scripting language to "just" data file. Povray's scene description language is so much more versatile (if's, cases, loops, imports...).
But the OP's complaint is also a little silly, given that his Vapory library works by writing a temporary scene file, then running the POVRay renderer executable to generate an image file. The same technique can be done with any renderer with a standalone executable, which includes Blender -- you don't need direct access to Blender's internal Python API.
In Blender's case, you might need to write a library to author .blend files, which is non-trivial. But it might also be possible to use Blender's .py script files as an ad-hoc scene description format.
