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.
>> 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...
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.
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.)
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.
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
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
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
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.
Wow, the state of the art in 3D rendering has changed dramatically. The state of the art in open source 3D rendering has changed even more dramatically.
Compare these screenshots from 2013 (although I think POV-Ray was looking pretty dated by then) to renders that come out of Blender's Cycle renderer now.
The big change is that everyone has moved to "physically based rendering" that do path-tracing for propagating light through a scene. Old-school raytracing cannot know how light indirectly bounces off a wall, for example, leading to artificial-looking shadows and flat lighting.
Anyways, anyone interested in making neat little 3D scenes like in this GitHub should try out Blender - it's shockingly easy to make realistic renders compared to several years ago.
Edit: Blender's Cycles rendering engine seems to have been included with Blender since 2011. POV-Ray probably represents 2000s-era tech, although I think it can do more than what's demonstrated in this post.
It features a lot of effects (radiosity, HDR maps, etc.) which are added on top of its basic functionality. There's been a big shift in how rendering is approached, from the old way of adding a pile of special effects onto your original non-realistic renderer, to a newer way of simulating light as it physically works and using that as the foundation of the renderer.
And there's still a lot of in-between as well, but having gone from 3ds Max's scanline renderer to 3ds Max + Mental Ray, to Blender + Cycles, it feels very different to use.
There are still some effects that Mental Ray (and it looks like POV-Ray) can do that Cycles can't. Photon-mapped caustics seems to be one, although I think LuxRender is FOSS and can do that.
Yep, I'm tired of these kids saying PovRay coudn't do shit as if PovRay had in 1997 the same capabilities of an Irix machine from 1987. They couldn't even be more wrong with that.
I remember seeing photoreallistic images made with PovRay in 1997 you coudn't even do with a GPU today in real time.
Kids today have a lot of ignorance on the 90's technologies, guess why they confuse the 80's and the 90's a lot thanks to that shitty vaporwave culture, having fake nostalgia on something they never truly experienced.
Man, I was playing 720p video under a Divx code in early 00's with a Pentium3 and multimedia was on its heayday, thus, people showing up a CGA pallete has no sense, it already was retro back in the day, you had those in the old MSDOS games you were running under W98 or DOSEmu under Linux, among the rest of the emulators for the ZX Spectrum and MSX for example.
Sorry for my rant, but I had to say it. The late 90's had nothing to do with early 90's, the technology shift we've seen it was outstanding. From DOS under a 286 in my early Elementary school, to W98 emulating Pokémon in my pre-HS days among recording TV streams in a computer, all of that in 5-6 years.
From 30Mhz and 5 1/4 floppies to ~450/600 MHZ a bunch of GB in 1999. For sure PovRay could do a lot more than these kids think.
The explosion of JS and web development created a culture of people totally ignorant of the hard-learned lessons since the 1960s. That is why you see constant reinventions of the wheel, a shitty wheel at that.
> From 30Mhz and 5 1/4 floppies to ~450/600 MHZ a bunch of GB in 1999.
From rare instances of people accessing their local BBS at 9600 Baud to accessing a worldwide communications network as a matter of course, often at broadband speed.
The past 20 years really have been rather dull in comparison.
You are right, but the same can be said between 85 and 95. The evolution of realtime 3d graphics was insane. From some low FPS 3d line engines to full blown textured 3d engines.
Cycles (path tracers) do render caustics but because rays are traced from the camera to light sources the probability that caustics are rendered is very low. This results in noise and fire flies (thats why the glossy filter is set to high in Cycles).
The solution is bi-directional path tracing but this is very hard to implement in Cycles because of the way it is built (according to the developers).
That's like saying Flatland (the movie) was representative of the animation tech at the time.
Remember that The Third and The Seventh was done by a single person in 2009, and is entirely modeled and rendered with tech available back then: https://vimeo.com/7809605
I agree the quality of the render engine is much better with physical rendering, but I still love constructive solid geometry and the ideal of pure curves to define the scene geometry. All these meshes with their triangles! Whatever happened to using NURBS or metaballs or other non-polygonal modeling?
Polygons can be smoother and subdivided efficiently at render time without artifacts, which is how they are used now. Nurbs and other curved surface representations end up with huge problems pragmatically when it comes to tools, workflow, visualization, texture coordinates, keeping the surfaces together etc. The list is long. Polygons are very simple in all these areas and can be made smooth at render time so you get the best of both worlds. If you were in a production situation it wouldn't be long before you gave up these ideals.
Every time I see a pipe, bucket, goblet or round thing in a game with otherwise very realistic rendering, I'm reminded I'm just playing a rendered game, due to seeing polygonal shapes rather than a true round bucket/goblet/pipe, and wonder if a quadratic surface would not look better and be more efficient.
Well, that and banding in the gradient of a sky. Those two things break the otherwise so realistic rendering quite commonly.
I think you may have missed what the parent comment was saying—that the polygons can be made smooth before render time. This is not a question of just faking it with normals. Instead, you can actually just work with a polygonal mesh and then post-process it to make it actually smooth. The classic technique for this is Catmull-Clark subdivision. If you think polygons on screen are offensive, you can just run the algorithm until the individual polygons are under the size of a pixel.
The fact that you see polygons on an otherwise circular object in a game just means that the game isn’t giving you a more detailed mesh when objects are close to the screen. There are a lot of reasons for this, and it’s important to consider that you often get the best overall quality in modern real-time graphics with retopologized meshes. It’s easy enough to make these with a given quality and make lower-LODs from them, but just as a matter of consequence you won’t see higher-LODs than the retopologized version. And why bother making super-high-LOD models anyway? If you look closely at an object there’s a finite amount of texture/model/etc. detail that the game can present. Might as well make the LOD for the model complement the amount of detail in the texture.
The whole process is rather complicated these days, with different workflows (even different programs) for organic objects (like people, animals, demons, whatever) and hard surfaces like goblets, stone tiles, architecture, etc. The two main things people want to do when modeling are sculpt and create a sensible topology, and surfaces like NURBs (or worse, Bézier curves) turned out to be a bit cumbersome for both sculpting and creating meshes.
I'm not sure what you are trying to say here, constructive solid geometry does not solve any of the problems I mentioned and would have to be treated specially to be raytraced (while being likely being much slower).
Converting it to polygons at a modeling or effects stage is workable but rendering it directly is unlikely to be widely valuable any more.
Pragmatically, I think the real issue is editor tooling. Polygons are much simpler to subdivide and edit and are perfect for real-time interaction, at least much better for high-complexity scenes. At render time, though, you need to use a bunch of extra tricks to get the right smoothing - bump/texture mapping, increased subdivision, etc. But some of these other models might actually decrease the scene complexity and increase quality if you could convert the model at render-time.
> At render time, though, you need to use a bunch of extra tricks to get the right smoothing
Nurbs or any smooth geometry needs to be subdivided too. You can set levels, max size of polygons, smoothness constraints subdivide based on the pixel size from the camera projection or any combination. In practice this is not a problem for polygons or nurbs.
> - bump/texture mapping,
This is orthogonal to the geometry type, with the exception that UV coordinates are far easier to deal with with polygons.
> increased subdivision,
There isn't any increased subdivision, both geometry types need to subdivided. Blue Sky's renderer raytraced nurbs directly but this isn't generally as good as just tracing subdivided polygons.
Polygonal geometry, even subdivided, is typically not a big part of memory or time in rendering in all but the most pathological cases. 4k would still mean that one polygon per pixel would be 8 million polygons, which is going to pale in comparison to texture data typically.
> Nurbs or any smooth geometry needs to be subdivided too
Not true; lots of smooth surfaces, including NURBS, can be and are ray traced without subdividing.
> Polygonal geometry, even subdivided, is typically not a big part of memory or time in rendering in all but the most pathological cases.
I don’t buy this either, speaking from experience using multiple commercial renderers. It is true that texture is larger, but not true that polygonal geometry is not a big part of memory consumption. RenderMan, for example, does adaptive tessellation of displacement mapped surfaces because they will run out of memory with a uniform displacement.
The balance of geometry vs texture usages is also changing right now with GPU ray tracers, and geometry is taking up a larger portion because it has to be resident for intersection, while textures can be paged.
> Polygonal geometry, even subdivided, is typically not a big part of memory or time in rendering in all but the most pathological cases. 4k would still mean that one polygon per pixel would be 8 million polygons, which is going to pale in comparison to texture data typically.
Erm, at VFX level at least, that's not really true: once you have hero geometry that needs displacement (not just bump/normal mapping), you effectively have to dice down to micropoly level for everything in the camera frustum. And with path tracing (what everyone's using these days, at least in VFX), geometry caching/paging is too expensive to be used in practice with incoherent rays bouncing everywhere. Disney's Hyperion renderer does do that, but it spends a considerable amount of time sorting ray batches, and it was built to do exactly that.
Image textures, on the other hand, can be paged fairly well, and generally in shade-on-hit pathtracers (all of the commercial ones), this works reasonably well with a fairly limited texture cache size (~8 -> 16 GB). Mipmapped textures are used, so for most non-camera rays that haven't hit tight specular BSDFs not much texture data is actually needed.
Once things like hair/fur curves come into the picture, generally geometry takes up even more memory.
3delight also traces SDS and nurbs analitycally. In offline renderers geometry data constitutes to most of memory usage. Texture RAM usage is kept under a few GB by use of page-based cache.
This seems like a strange way to frame it. Polygons aren’t what get subdivided. Subdivision surfaces & NURBS are what get subdivided, and those are routinely used in production and have tooling. Polygons by themselves don’t get any smoother or provide the advantages you’re talking about, nor do they solve all problems of workflow, tex coords, stitching, etc.
You certainly can, that’s true. But without a higher order source model to work from, it doesn’t help you solve any of the problems @BubRoss mentioned above.
Tessellation is not just subdividing; it’s linearizing something else. You have to start from that something else for tessellation to be meaningful. The GP comment above was advocating polygons as a replacement for curved surface representations, but without a curved surface representation like a subdivision surface, tessellating polygons doesn’t make a lot of sense.
It holds a special place in my heart as well. In 2002, my parents gave me a book "Multitool Linux" [1] which wasn't a spectacularly well received one, containing a mix of wildly different topics, but this was exactly what I needed as a teen experimenting with Linux for the first time. One of the chapters was about POV-Ray, and I remember being amazed with this newly-discovered canvas. I spend hours looking at images others had created and wondering how they'd pulled it off. I think I never got much further than rendering small animations on my (if I recall correctly) 400Mhz pc. Good times.
(As an aside, I'd completely forgotten the title of the book, although vaguely remembering the cover and time frame. It's so hard to find older stuff using Google when only having some vague descriptions. I found it by remembering that I read a book review years later and after some digging around could locate the review back to https://www.linux.com/news/book-review-multitool-linux/ based on the style of writing, which I remembered. I must have read that book to pieces. The chapter using Wireshark was also amazing to me.)
My interest in POVRay helped me in my high school math classes: I was really into making animations in POVRay and at the time I was in calculus and it really made parametric equations "click" for me.
I credit POV-Ray with getting me into programming in the early 90s. A fascination with computer graphics led to Fractint, POV-Ray, and dreams of someday being able to play Kai's Powertools and SGI machines. I think I even had a subscription to some black and white POV-ray zine. Can't remember what it was called though.
POV-Ray was the reason that I wanted a 486 DX back in the mid-90's, and not a puny FPU-less 486 SX like my friends had.
I didn't do much with it, ultimately, but I really enjoyed noodling around w/ POV-Ray. Rendering a bunch of TGA files and then stringing them together into an animated GIF (or was it an FLC?) was a major exercise.
I recall 15 y/o me trying to explain it to the "oldster" who my father purchased the PC from (a guy who was probably in his late 30s). "No-- there's no camera. It's a virtual camera that I place in code for the scene. UGH! You don't understand!" (To be fair, this was a guy who mainly sold PCs and accounting software and wrote code for dBase/Clipper...)
I got into POV-Ray in the late 90s when I wanted 3D graphics for my Geocities page. I was in over my head in every dimension (scripting, math, artistic ability), but it was incredibly rewarding, and the newsgroup gave me a very positive early impression of what a community can feel like on the internet.
I entered some of those irtc comps. Povray appealed to the programmer and the artist in me. Writing algorithms (macros) in povray to create trees or place raindrops made you really look into how nature works. It's a challenge that requires a certain mindset.
I printed the source code of POV-Ray in 1989 when it was still called DKBTrace (named after its' author, David Kirk Buck) and studied it carefully over a few weeks. It was my introduction to the underlying implementation of (then) modern OO - Turbo C++ 1.0 was released in 1990. It was also my introduction to CSG.
Ah, the nostalgia. Thanks, David, and the entire POVRay team.
(Edit: oh wow, it’s really heartening to read how POVRay has such a positive impact on so many others as well, almost 30 years ago!)
There is a special place in my heart for POVray. After BBC Basic, it was the first coding I ever did all the way back in ‘94.
The thrill of changing an object from opaque to glass, and the anticipation of watching the ray scan grind to a treacle-like pace as it passed over any glass objects. Happier times, simpler times!
I'm not sure it's fair to compare a gallery of images created while learning the software with a gallery of images created by people who are very familiar with their software.
As far as I know, it's not. The turing-complete scene description language and the many ways of representing geometry that makes POV-Ray so powerful and fun to use also makes it very difficult to interoperate with other tools.
POV-Ray is mostly used by hobbyists, students, and people who need to visualize some data and need a tool that can be easily scripted for their needs.
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.