I remember when this one came out and letting my computer spend insane amounts of time rendering images. There is something about POV-Ray, its limitations and interface (or lack of) seems to make it excel at this sort of half real impressionist style while never entering the uncanny valley. Or maybe POV-Ray just attracts people who work towards that style. I miss the POV-Ray community and spending weeks coding an image and 14 hours rendering an image just to find out you made one tiny stupid error and have to do it all over. Last I used it I had a 1.8ghz single core processor, I wonder what it is like on a modern computer.
back
4 comments
I think the author of "The wet bird", Gilles Tran, is one of the very few artists who were adept with both the more graphical, modeler-based workflow and the fully programmable code-based interface of the POV-Ray renderer, very successfully combining the best of both worlds (see eg. [1][2][3]). Unlike most POV users, Tran liberally used commercial tools like Poser, Terragen, as well as third-party models.
Programmatically composing mathematical primitives does only get you so far if your goal is to create art relatable to humans. For abstracts, surrealism, and "mathematical art" plain POV-Ray is great, as well as for many natural forms exhibiting some degree of fractalness, but for animals, humans, and many manmade things a mesh-based modeler – or at least the use of third-party meshes – is essentially a requirement.
---
Due to the end of Moore's Law, POV-Ray these days is not tremendously faster than what it was on late-00s hardware. It does fully support multicore, so there's that (and raytracing is famously an "embarrassingly parallel" problem). Modern SIMD could also bring a 2x to 4x performance boost; I'm not sure how vectorized/autovectorizable the current POV-Ray code is. If the shader language could be JITted, that might bring a nice benefit as well.
---
[1] http://www.oyonale.com/image.php?code=590
> [...] but for animals, humans, and many manmade things a mesh-based modeler – or at least the use of third-party meshes – is essentially a requirement.
That was/is not true. It could be even a CAD modeler. In fact, in the 90's, before the advent of subdivison surfaces (sds) in VFX production, everything you saw in blockbuster movies that was organic was NURBS patches. E.g. the dinosaurs in "Jurassic Park". Usually modeled in Alias PowerAnimator and then animated in Softimage.
Nowadays you can choose between polygon meshes, sds, T-splines also signed-distance-based modeling for organic stuff. In fact, even then you could do organic modeling from SDF primitives using the Oranica[1] modeler.
There were also many cheap or even free modeleres that supported bezier patch modeling at the time. Bezier/B-spline patches modelers were accessible to everyone on Windows and Mac OS at the time. And there were many renderers that could render those without artifact. I.e. REYES[2]-based.
You may have to mesh the SDF for further work (and then maybe render a Loop sds if you want a high order surface at render time). So mesh-based being the only choice was neither true when "The wet bird" was produced nor is it now.
I ran a small CGI shop (five people) a few years before this image was produced. We used Real3D/Alias PowerAnimator with a custom pipeline to do organic modeling with B-spline patches and rendering with PhotoRealistic RenderMan for Windows. No polygons were ever created (or harmed) producing any of the images we were paid for.
So yeah, the humans in that image were polgon meshes from Poser and exported to POV but that was just what the artist knew/choose.
[1] https://archive.org/details/organica-12 [2] https://en.wikipedia.org/wiki/Reyes_rendering
Pardon the slight inaccuracy. With "mesh-based modeler" I simply meant a GUI modeler, no matter what the primitives used are. (I would consider a model made of many X-spline patches still a "mesh", for the record.) But my point was that some type of modeler is a requirement for creating many photorealistic shapes; nobody is going to make a plausible human programmatically by composing geometry out of primitives like spheres, cones, and boxes. Or even blobs/metaballs or isosurfaces.
> [...] nobody is going to make a plausible human programmatically by composing geometry out of primitives like spheres, cones, and boxes. Or even blobs/metaballs or isosurfaces.
Actually that is exactly what people did in the aformentioned Organica modeler in the 90's. Yes, using a GUI modeling app but that is not a requirement here.
Some vids that show what is possible with a text editor and not much effort (if you have a lib of ready-made SDF components you string together in code):
https://www.shadertoy.com/view/3lsSzf https://www.shadertoy.com/view/WsSBzh
So yeah, I'd disagree with the 'nobody'. I wrote shaders for blokcbutser VFX as part of my job for over a decade. We regularly did some very complex SDF stuff there simply because we had to.
I think Gilles Tran especially would be the kind of person who'd do that sort of stuff[1] if the object in question was central enough to the image.
Which the motion blurred human figure in the "The wet bird" was not.
Your insistence on using the word "nobody" there is an absolute without evidence. You underestimate the visualization capabilities of savants. For my 3D game prototype, I created all of the meshes programmatically and wrote *and debugged* a mesh-slicing algorithm using only visualization in my own mind. Mostly I did indeed use primitives like spheres, cones, and boxes. Granted, huge caveats - I never finished a game from the prototype, and the meshes involved weren't that complicated; I was modeling imaginary robots not people.
It's painful for me to use GUI or CAD tools because they're so much slower and less capable than the Dall-E image generator/CAD modeler/Star Trek Holodeck I have inside my own brain. This is in some ways limiting, analogous to a mathematician refusing to learn to use a computer. Nevertheless back to your point, I'm fairly certain I could model a plausible human programmatically from geometry primitives, but I won't claim to until I try. However what I am certain of is somebody can.
I would call confusing the "what" with the "how" a "slight inaccuracy" a tad frivolous.
And I mean that in a very caring way as handn't wasted 5mins writing a reply to you if this was as obvious as you try to make it sound.
I am sorry for the confusion, but I did think it was pretty clear that the important part of "mesh modeler" in my comment was the word "modeler" because in the context it was used as the opposite to building scenes by writing code. I did genuinely forget that there exist modelers that work on splines rather than triangle meshes, but I don't really see the distinction as very important in this specific context.
>Programmatically composing mathematical primitives does only get you so far if your goal is to create art relatable to humans.
Of coarse, that is one of those weak areas you have to work around and ultimately helps define the style of povray, that incredible pathos of all those images devoid of people beyond the implied. This thread got me to install povray and start playing with it again. There is a fairly large speed increase, rendered the diffuse-back sample scene and it took 8 minutes, took hours on my old T42.
Same with me. I'd spend the late afternoon creating the file, then start rendering in the morning and watch the result after I got back from the university. I still have the images of the animation and they are like 250x250 pixels or something like that (they're on an offline drive).
I can't even remember how I turned them into an animation, or if I even got to do that.
I have fond memories of creating LEGO CAD models and running them through POV-Ray for hours on end to turn them into gorgeous renders.
Can't it use the GPU for rendering?
From what I understand the average GPU is optimized for meshes which is not the povray way so GPUs tend not to offer much improvement. Quick search for a more informed explanation.
The main problem here is that POV-Ray is primitive based, NOT mesh based.
GPU rendering is heavily mesh optimized. They can process in parallel,
but only if all threads need to use the same base code. With POV-Ray,
there is no universal geometry handling code : Each and every primitive
require different code and GPU just can't cope with that requirement.
I understand POV-Ray is optimised using SSE or AVX instructions. You can do arithmetic operations on vectors in GPUs in a much more efficient way. That's why crypto and AI are using GPUs. If you can divide your work in simple arithmetic parallel operations, the GPU will be happy to do it on a massive scale. You have things like CUDA to use but even a simple thing like a compute shader will help.
For a modern GPU a mesh is an abstraction. You can think of it like a collection of very basic CPU cores which only know do do a few basic operation on a massive collection of data. This is an over simplification but an useful mental model.
If I understand you correctly you are just elaborating on the bit I excerpted from the linked thread? This is out of my depth but it is interesting. It seems povray would have to drastically change how it works to really benefit from GPUs since in povray a sphere is an object related to pi and not a series of triangles which are arranged into the shape of a sphere where each triangle can be easily paralleled on a GPU since they are all handled the same way?
Or did I not understand and you are saying povray's performance could actually be improved by modern GPUs without reworking how it deals with its primatives?
Those were the 90s. Rendering on a GPU wasn't a thing back then.