Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ray Tracing with POV-Ray: 25 scenes in 25 days (2013)

github.com

Post reply on HN
Print view View original

81–90 of 112 posts

Re: Ray Tracing with POV-Ray: 25 scenes in 25 days (2013)

#81

Post by TylerE »

holoduke wrote: post #63
CrLf wrote: post #50

Earlier quoted context omitted.

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.

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

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

Re: Ray Tracing with POV-Ray: 25 scenes in 25 days (2013)

#82

Post by BubRoss »

TylerE wrote: post #61
BubRoss wrote: post #57

Earlier quoted context omitted.

I didn't say it was impossible, I'm talking about why these other geometry types aren't typically used instead of polygons. 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…

Look at the POV-Ray source code. It does it. Again, I am literally telling you how the software under discussion works. and you keep insisting it is not so. It's open source!

I'm guessing at this point you are purposely ignoring what I'm saying, but again, I'm explaining why it isn't used in production 3D very often. I know how to collide rays with csg, I'm trying to get you to think about how that needs to happen so you understand why it is slow. If you have a surface made up of lots of overlapping primitive shapes, what do you think the performance will be like when you need to intersect thousands of rays and figure out shading information for them?

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.

Re: Ray Tracing with POV-Ray: 25 scenes in 25 days (2013)

#83

Post by phkahler »

gorgoiler wrote: post #53
CrLf wrote: post #50

Earlier quoted context omitted.

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.

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.

>> 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...

Re: Ray Tracing with POV-Ray: 25 scenes in 25 days (2013)

#84

Post by BubRoss »

berkut wrote: post #74
BubRoss wrote: post #26

Earlier quoted context omitted.

It isn't just tooling. > 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…

> 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 ef…

The original thread was about nurbs not being used anymore over polygons. Displacement doesn't change the equation between polygons and nurbs of course because they both go in as high level primitives. Hair is a its own thing of course. I know you know this, but I think a lot of people missed the original point.

Re: Ray Tracing with POV-Ray: 25 scenes in 25 days (2013)

#85

Post by elihu »

klodolph wrote: post #33

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, dep…

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.

Re: Ray Tracing with POV-Ray: 25 scenes in 25 days (2013)

#86

Post by elihu »

holoduke wrote: post #63
CrLf wrote: post #50

Earlier quoted context omitted.

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.

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

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.

Re: Ray Tracing with POV-Ray: 25 scenes in 25 days (2013)

#87

Post by dahart »

holoduke wrote: post #70
dahart wrote: post #45

Earlier quoted context omitted.

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 can apply subdivision on any type of geometry. Even voxels. Tesselation is also a form of subdividing.

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.

Re: Ray Tracing with POV-Ray: 25 scenes in 25 days (2013)

#88

Post by dahart »

BubRoss wrote: post #84
berkut wrote: post #74

Earlier quoted context omitted.

> 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 ef…

The original thread was about nurbs not being used anymore over polygons. Displacement doesn't change the equation between polygons and nurbs of course because they both go in as high level primitives. Hair is a its own thing of course. I know you know this, but I think a lot of people missed the original point.

You keep saying “polygons”. Are you talking about subdivision surfaces? Films don’t model in “polygons”. Subdivision surfaces are a curved surface representation, not “polygons”. Some people still use NURBS too.

Re: Ray Tracing with POV-Ray: 25 scenes in 25 days (2013)

#89

Post by BubRoss »

dahart wrote: post #87
holoduke wrote: post #70

Earlier quoted context omitted.

You can apply subdivision on any type of geometry. Even voxels. Tesselation is also a form of subdividing.

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 c…

I'm not advocating, I'm explaining why it already happened twenty years ago. Polygons can be trivially subdivided to a rounded surface or converted to a subdivision surface. This is something anyone who has used maya, houdini, lightwave, softimage or 3D studio has seen their entire career.

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.

Re: Ray Tracing with POV-Ray: 25 scenes in 25 days (2013)

#90

Post by SomeoneFromCA »

elihu wrote: post #86
holoduke wrote: post #63

Earlier quoted context omitted.

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

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 denoisi…

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