Not to hate on the job done here. But I think most people today (or even back in 2013) could have gotten further with Blender from an artistic perspective.
Blender 2.4 was kind of terrible to use from an animation perspective, but the controls for simple objects / cycles rendering was never really that difficult IMO. The key was having the knowledge to stay on the "nice parts" of Blender.
Blender 2.6 and 3.0 these days have made great strides at being easier to use from an animation and rigging perspective.
------
The harsh shadow lines could be made easier if you used area-lamps (in Blender) for example. They probably exist in POV-ray, but a 3d GUI to move-and-place these objects around grossly simplifies the effort, compared to placing the objects around with a text-based format like POV-Ray.
It's a different experience. POV-Ray is basically a programming language. If you want to generate geometry programmatically there's nothing quite like it. The "programming" features are primitive ("if" statements, loops, eventually they added macros that act like procedure calls...) but the way you describe geometry and textures is actually pretty nice.
POV-Ray is also very old. Turner Whitted's recursive ray tracing paper is from 1979. POV-Ray was released in 1991, but was based on an earlier raytracer called DKBTrace that was written sometime in the 80's. Blender is more modern and isn't built around the limitations of what was feasible to render in a reasonable amount of time on the computers of the 80's and 90's.
There were GUI's for POV-Ray too, Moray i used extensibly, and something for the Atari I forgotten what it was called, didn't use it much.
I started with my 8 MHz Atari, each test scene took at least 10 minutes for a stamp-size picture and then the sphere was in the wrong place and wasn't visible or the wrong texture. It took me soo long to get the hang of the coordinate system and the language. But fun it was!
I printed the documentation so I could read it while the computer was buzy rendering.
I also wrote a small program for my Atari Falcon that would turn of the graphics chip to give me more rendering speed. Since it was a shared bus it used up something like 25% CPU on full colour.
I think POV-Ray was probably more impressive in 2000 than 2013, but even today I like the method of creating graphics via text rather than a GUI. That's probably because I'm a programmer rather than an artist, but it's why I still think fondly of POV-Ray even though it really has been surpassed in almost every way by Blender.
The text-based format is certainly superior for a programmer, who can write a script to output POV-Ray data.
Blender of course has a Python API, but the text for POV-Ray is almost certainly easier to think and use. After all, Python's "print" statement is just easier to use than going into Blender docs wondering what bpy.context.blend_data is exactly.
------
That's probably POV-Ray's biggest feature. It is truly a domain-specific language for describing 3d worlds and objects.
a 3d GUI to move-and-place these objects around grossly simplifies the effort, compared to placing the objects around with a text-based format like POV-Ray.
This can depend on what you're doing and what background you bring to the work. ie: Just recently, I've found myself more effective developing 3D print designs using a textual language than via a drag/drop UI. (But I bring a programming background, like to think in abstractions, and was making designs that were quite inorganic...)
Comments
Not to hate on the job done here. But I think most people today (or even back in 2013) could have gotten further with Blender from an artistic perspective.
Blender 2.4 was kind of terrible to use from an animation perspective, but the controls for simple objects / cycles rendering was never really that difficult IMO. The key was having the knowledge to stay on the "nice parts" of Blender.
Blender 2.6 and 3.0 these days have made great strides at being easier to use from an animation and rigging perspective.
------
The harsh shadow lines could be made easier if you used area-lamps (in Blender) for example. They probably exist in POV-ray, but a 3d GUI to move-and-place these objects around grossly simplifies the effort, compared to placing the objects around with a text-based format like POV-Ray.
It's a different experience. POV-Ray is basically a programming language. If you want to generate geometry programmatically there's nothing quite like it. The "programming" features are primitive ("if" statements, loops, eventually they added macros that act like procedure calls...) but the way you describe geometry and textures is actually pretty nice.
POV-Ray is also very old. Turner Whitted's recursive ray tracing paper is from 1979. POV-Ray was released in 1991, but was based on an earlier raytracer called DKBTrace that was written sometime in the 80's. Blender is more modern and isn't built around the limitations of what was feasible to render in a reasonable amount of time on the computers of the 80's and 90's.
Programming is nice but for geometry you want a constraint solver.
There were GUI's for POV-Ray too, Moray i used extensibly, and something for the Atari I forgotten what it was called, didn't use it much.
I started with my 8 MHz Atari, each test scene took at least 10 minutes for a stamp-size picture and then the sphere was in the wrong place and wasn't visible or the wrong texture. It took me soo long to get the hang of the coordinate system and the language. But fun it was!
I printed the documentation so I could read it while the computer was buzy rendering.
I also wrote a small program for my Atari Falcon that would turn of the graphics chip to give me more rendering speed. Since it was a shared bus it used up something like 25% CPU on full colour.
I think POV-Ray was probably more impressive in 2000 than 2013, but even today I like the method of creating graphics via text rather than a GUI. That's probably because I'm a programmer rather than an artist, but it's why I still think fondly of POV-Ray even though it really has been surpassed in almost every way by Blender.
The text-based format is certainly superior for a programmer, who can write a script to output POV-Ray data.
Blender of course has a Python API, but the text for POV-Ray is almost certainly easier to think and use. After all, Python's "print" statement is just easier to use than going into Blender docs wondering what bpy.context.blend_data is exactly.
------
That's probably POV-Ray's biggest feature. It is truly a domain-specific language for describing 3d worlds and objects.
They do: http://www.povray.org/documentation/view/3.6.2/38/
This can depend on what you're doing and what background you bring to the work. ie: Just recently, I've found myself more effective developing 3D print designs using a textual language than via a drag/drop UI. (But I bring a programming background, like to think in abstractions, and was making designs that were quite inorganic...)
POV-Ray is a renderer. And just that. In fact you could (and probably still can) use POV-Ray to render your Blender scene.
Comparing POV-Ray to Cycles or Octane would make more sense.
The point of povray is that you program the scenes. Maybe something like "25 days of blender python scenes" would be equivalent.
From an artistic perspective, constraints drive creativity!