[klodolph]

I loved POV-Ray in the 1990s and early 2000s. The thing is—it’s ridiculous to try and make something remotely complicated or organic with POV-Ray, unless you are using some modeling program that can export to POV-Ray format.

POV-Ray scenes were dominated by procedural textures and geometric primitives, for the most part. The rendering engine was very strong, and supported all sorts of features like area lighting, depth of field, motion blur, global illumination, caustics, volumetric lighting, etc. All of these were supported way back in the day before they became more common in other engines, and of course, using these features made your render times horrific back on early-2000s single-CPU machines.

The way a lot of us did modeling in POV-Ray was with a pencil and some graph paper. Without a good modeling program, you were setting yourself up for a ton of work. So I’d try to get the most out of simple models, and make it look as good as possible with lighting.

Funny enough, if you are used to CSG then you may need some time to adapt to modern workflows. Blender supports CSG, of course, but there are some caveats that you should pay attention to.

[CrLf]

POV-Ray was my introduction to programming, before actual programming. Graph paper and a lot of trial and error.

My longest render was 50 hours for a single 640x480 image, with caustics and area lighting. 50 hours of a Pentium 100 MHz buzzing near my bed.

[gorgoiler]

Pentium? Pentium! We were lucky to have half a 486 and even then it were powered by ferrets, wi’owt e’en DX floating point coprocessor to its name.

[phkahler]

>> Pentium? Pentium! We were lucky to have half a 486

I used to run it on DEC Alpha. I wrote a pair of scripts to generate include files of parameters and then render frames of an animation using those parameters. I had to hack POVRAY itself to output .tga files which I then fed to Dave's Targa Animator. A modest 20-30 frame animation took over night on that Alpha. University resources ya know...

[W-Stool]

Monty Python voice: "You were lucky!"

[holoduke]

How long would it take now on a modern machine? :) 5 , 10min?

[elihu]

If you ran exactly the same code on a modern machine I'd say that's a pretty reasonable guess.

You'd get a big speedup just by going from single-threaded to multi-threaded execution. Probably the biggest boost would be to use modern methods. It's possible to do path tracing at interactive frame-rates on modern hardware; some of the optimizations can include not doing very many samples per pixel but to rely on denoising algorithms that can take advantage of the redundancy inherent in the image to smooth out the graininess of course global illumination effects. There are a lot of other algorithmic improvements too; modern acceleration structures, techniques to preferentially sample rays that are most likely to impact the final result, etc..

POV-Ray is amazing software, but it wasn't really ever meant to be an interactive renderer. It kind of leans towards maximum extensibility over raw performance. Modern renderers are usually much faster.

[SomeoneFromCA]

I doubt you'll get any speedup from multi-threaded execution, unless it is also multi-core.

[klodolph]

It’s hard to find processors these days that aren’t multi-core. I can’t remember the last time I saw a single-core computer.

(Or are you talking about the difference between “multi-threaded execution” and “multi-core execution”? That wouldn’t make sense. Threads are how you execute code on multiple cores.)

[elihu]

That's what I meant; multiple operating systems threads, not hyperthreaded execution on one core.

I don't remember offhand what POV-Ray's support for multi-core execution is or was. Back in the 90's, there was PVM-POV which ran on a cluster. That's probably what you'd use if you had a dual-socket machine back then. I imagine there was probably an MPI version as well. I assume it supports multicore natively now, since practically all CPUs are multi-core now.

[TylerE]

Less than that even, since in the old days there was likely lots of swapping. A machine of that vintage was likely only on 4mb of RAM. Just the frame buffer would eat up about half of that

[dan-robertson]

Pentiums weren’t that old. It would depend a lot on gpu rather than cpu.

[TylerE]

POVray doesn’t use gpu. It is embarrassingly parallel though. I would expect say a 2000x speedup over a Penguin 1 though. Say, 40x the raw clock x 2-3x more per cycle x 12-16 cores

[0-_-0]

Those 1st generation Penguins were slow, not even a flight coprocessor

[gedy]

I really loved this aspect of POV-Ray back then. As a "normal" programmer it was really nice to be able to script very complex scenes procedurally. E.g. https://vimeo.com/105317159

[elihu]

The other side of that is that there are certain kinds of recursive organic structures that are very hard to make with a modeling tool, but can procedurally generated with a little bit of code. Making realistic trees is hard, but I've made cartoonishly-plausible trees in POV-Ray without much effort. (Define a level-0 tree as a leaf attached to a twig; i.e. a flattened sphere stuck onto a tapered cylinder. Define a level N tree as two level N-1 trees transformed and rotated to project from the end of a branch.)

Making a plausible human face with just a text editor, on the other hand, I wouldn't know where to start.