Ray Tracing with POV-Ray: 25 scenes in 25 days (2013)
github.com
github.com
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.
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.
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...
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.
(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.)
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.
Making a plausible human face with just a text editor, on the other hand, I wouldn't know where to start.
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.
Look through the old IRTC archives, for instance: http://ftp.irtc.org/stills/index.html
People were doing stuff like this (http://oz.irtc.org/ftp/pub/stills/1999-04-30/13hystri.jpg) in 1999.
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.
Huh? POV-Ray has supported radiosity for literally decades, since sometime around 1995.
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.
That and their selfish issue being unable to acknowledge the 90's legacy and we could achieve in early 00's. For example their previous comment stating as if everything was invented in late 00's/early 10's and we were badly surviving with DOS and Amigas in late 90's, when, FFS, people began to emulate Amigas in '99 with UAE.
Man, we have Voodoo's and Geforce's exploded in late 90's, raytracing was done in software but we didn't do the crippled examples people is trying to show off to the rest as if it was what we truly do in the 90's. Not even close. Even a 286 could do these under half and hour or a full one, but that was the 3D lore from several years ago.
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.
Otherwise, the changes in lifestyle since 2010 have been incremental at best. 10 years ago I could buy most things online, watch YouTube videos, consulted Google maps, had smartphone text, audio and video chat. Now I can watch videos in 4K and the internet connection is faster, and although computer graphics have indeed improved, it is nothing like the leap from 1990 to 2000.
The only new exciting development is virtual reality, which is unfortunately still fairly niche.
There is a larger difference from 2000 to 2020, but you could do a version of the above in 2000, only in a more inconvenient and expensive manner than today, while they would be largely impossible in 1980.
Now almost everyone does that. That’s the difference.
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).
I remember looking at this entry in particular: http://www.irtc.org/ftp/pub/stills/2006-06-30/hideaway.jpg and thinking "how the hell is that possible?"
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
Year 2000. You don't know a lot, and I guess you didn't have a look on the PovRay's hall of fame.
Well, that and banding in the gradient of a sky. Those two things break the otherwise so realistic rendering quite commonly.
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.
Why do you think that is difficult? I think your attachment to csg might be wishful thinking, you still have to get arbitrary shapes out of primitives, work with deformations, figure out textures etc.
Converting it to polygons at a modeling or effects stage is workable but rendering it directly is unlikely to be widely valuable any more.
I asked 'how do you trace rays against it' because to do it directly is not fast, yet you are left with all the problems I stated that you skipped over. Think about what it would take to directly trace lots of overlapping primitives. What you gain from tracing it directly is minimal and what you give up is substantial.
Beyond that, again, you have to confront textures, motion blur, visualization and of course the elephant in the room, the fact that csg is not a good tool for arbitrary modeling to say the least. Think about these things before you reply "it's literally possible" again. Technically possible and useful for production animation are two very different things.
> 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.
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.
It of course depends on exactly what is being rendered, but typically texture maps of assets for high quality cg are done at roughly the expected resolution of the final renders (rounded to a square power of 2). Typical assets will have three or four maps applied to each group of geometry, with higher quality hero assets having more groups.
> RenderMan, for example, does adaptive tessellation of displacement mapped surfaces because they will run out of memory with a uniform displacement.
It is specifically screen space displacement and this has been effective, but was originally crucial in the days where 8MB of memory cost the same as someone's yearly salary. In PRman actually polygons are even less of a burden on memory because of this with micropolygon and texture caches for efficiency, even with raytracing.
The real point here though is that nurbs don't really have much of an advantage, even in memory, because polygons are already lightweight and can be smoothed. Subdividing of polygons is typically not going to be too different from burbs and heavy polygonal meshes are likely to be extremely difficult to replicate with nurbs.
Don't get too caught up in exactly what is technically possible, this is about why nurbs are not an ideal form of geometry that anyone is trying to use again. Their disadvantages outweigh their advantages by a huge margin.
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.
Some of the studios still don't even bother with crease weights and still "double-stop" ends with extra vertices/faces to create hard edges.
My original point was that it is possible to render subdivision surfaces without dicing down to micropolygon (i.e. you approximate the limit surface with Gregory Patches or something), but only if you don't have displacement: as soon as you need displacement, you pretty much need to dice down to micropolygons, and in this scenario, the geometry representation can be extremely expensive in memory with large scenes.
Yes, right, I know. I phrased that poorly, so I guess I should give BubRoss a break. The point I’m trying to make is that starting with the idea of polygon modeling, and starting with the idea of subdiv modeling, are two different things. If we’re talking about subdiv modeling, they it should be called subdiv modeling. Modeling “polygons” doesn’t just automatically produce decent looking smooth models and good connectivity and UVs, you have to use subdiv tools while you work.
That you can render subdivs without subdividing is related to what I was trying to say, that these surfaces are higher order, have an analytic definition, etc... they’re not just polygons. I guess it’s a good thing that subdivs are so easy to work with that they’re equated with polygons.
I can promise you they do. They are treated as the same thing. Everyone uses polygons knowing they will be smoothed/subdivided/declared as subdivision surfaces. Sharp edges, cusps and bevels are typically made by creating more subdivisions in the actual model instead of using extra subdiv data on the geometry, though pixar might be the exception.
> Some people still use NURBS too.
I think this is very rare. Maybe blue sky never transitioned away.
It really isn't. I think you want to drive home some distinction, but the vast majority of work flows model straight polygons and the only difference is that they know they are going to be subdivided and smoothed later by the renderer.
You say that there are all sorts of different issues with subdiv surfaces, but it just isn't true. Modelers and texture artists might look at everything smoothed to make sure there aren't any surprises in the interpolation and distortion in the UVs, but everyone deals with the raw polygons.
You can subdivide polygons without smoothing them, and people still do polygonal modeling without planning for subdivision, and produce models that aren’t intended for smoothing and wouldn’t smooth nicely, so it is important to be clear in your language that you’re talking about a subdivision surface and not just polygons. Why the resistance to just saying subdivision surface, since that’s really what you’re talking about? I agree with a lot of your points if I replace “polygons” with “subdivision surface”.
My issue with what you said far above is the claim that smoothed surface representations require extra tooling, and you claimed that “polygons” don’t have these issues. The problem with that is that a subdivision surface is a curved surface representation, and it does come with extra tooling. Just because it’s easier than NURBS, and just because you get to use a lot of polygon tools, that does not mean a subdiv workflow is the same thing as a polygon workflow. Hey it’s great if the tools are getting so good that people confuse polygons with subdivs. Nonetheless, a pure polygon workflow can mean things that aren’t compatible with smoothing or subdivs.
Creases are done by just making polygons/bevels/line loops close to the edge that needs to be sharpened.
> What if you want a creased edge smoothed and it’s part of two separate mesh groups?
Mesh groups don't have to mean their polygons don't share vertices and this is one of the reasons why - you need to be able to interpolate the attributes of the vertices, like normals.
> You can subdivide polygons without smoothing them, and people still do polygonal modeling without planning for subdivision, and produce models that aren’t intended for smoothing and wouldn’t smooth nicely, so it is important to be clear in your language that you’re talking about a subdivision surface and not just polygons.
I'm not concerned with what random people do. Professionals just say polygons in general and the workflow is all about working with the polygonal mesh directly. If two people are both making polygonal models and they will save them as .obj files, but one will be smoothed at render time , they don't say they are working with a different type of geometry. Technically there are actually many different ways to smooth polygons.
> My issue with what you said far above is the claim that smoothed surface representations require extra tooling,
No, I explained that nurbs require extra/different tools. Technically if someone (like pixar) were to use extra attributes like edge crease amounts on subdiv surfaces, some tools would need to address that, but that's not on the same level as the difficulty of working with nurbs.
> Nonetheless, a pure polygon workflow can mean things that aren’t compatible with smoothing or subdivs.
I think when you say things like this you are trying to salvage your confusion, but it really doesn't shake down like this. Any mesh can be smoothed and unless you have messed up meshes it works well and no one has an eye.
To recap: nurbs are a nightmare to work with, everyone works with regular polygons that could be saved as an .obj, they get smoothed at render time. Everyone calls them polygons because that is what they are working with and it has been this way literally for decades. Try not worry too much about it.
I’m sorry if you feel defensive. I was responding to your explicit inclusion of “other curved surface representations” besides NURBS here https://news.ycombinator.com/item?id=23043791 and here https://news.ycombinator.com/item?id=23044537
Really just pointing out that a subdivision surface is literally another curved surface representation, does have some conceptual differences from polygons, and can be ray traced without subdivision. Calling it polygons was confusing to me, but now that I understand what you mean, call it polygons if you want.
Agree in general about geometry memory though: in high-end VFX, displacement is pretty much always used, so you have to dice down to micropoly for hero assets (unless they're far away or out of frustum).
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.
If you think using polygons solves no problems, I'm guessing you haven't tried to make a pipeline with nurbs (not many have in this day and age). Texturing takes specific paint and texturing tools while the resolution difference between patches complicates things even further. Even getting the model detail is difficult. Everything about it is painful. It isn't even a contest, everyone transitioned to polygons and no one looked back.
(I edited the later editions)
(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.)
[1] https://books.google.be/books?id=g0CPF6MEFcUC&printsec=front...
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...)
POV-Ray was actually run in space by none less than Mark Shuttleworth when he was on the ISS in 2002.
Ah, the nostalgia. Thanks, David, and the entire POVRay team.
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!
May it live forever.
It's extremely counter intuitive to articulate a 3d scene in code. Maybe for some applications, exactness in the 3d scene via code is useful.
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.