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

101–110 of 112 posts

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

#101

Post by elihu »

SomeoneFromCA wrote: post #90
elihu wrote: post #86

Earlier quoted context omitted.

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.

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.

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

#102

Post by TylerE »

CyberDildonics wrote: post #95
TylerE wrote: post #65

Earlier quoted context omitted.

You can do things like take shape A and then subtract shape B from it and all works, no matter how complex the intersection.

That is what it is, but how does it make any of the other parts of 3D easier? How would deforming it be easier than surface geometry for instance?

One major problem with surfaces is calculating which side is facing out. This is actually much harder than it sounds. CSG doesn't have this problem because it knows inside vs outside.

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

#103

Post by dahart »

BubRoss wrote: post #94
dahart wrote: post #88

Earlier quoted context omitted.

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.

> Films don’t model in “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…

Yeah, so you’re talking about subdivs, not just any polygons. Yes you create subdiv geometry using polygon modeling tools, but modeling pure polygon models, e.g., for games, is a different activity. Subdivs are easier than NURBS, it’s true, but they do come with their own whole set of connectivity, workflow, texturing, pipeline, etc. Just saying “polygons” is misleading.

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

#104

Post by dahart »

berkut wrote: post #98
dahart wrote: post #88

Earlier quoted context omitted.

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.

Subdivision surfaces end up as curved surfaces when rendered, i.e. an approximation of the limit surface, but the modellers most definitely do model them as polygons in the DCC apps. 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…

> but the modellers most definitely do model them as polygons in the DCC apps.

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.

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

#105

Post by thdrdt »

beering wrote: post #10
TylerE wrote: post #6

Earlier quoted context omitted.

That's rather unfair to POV-Ray. These are hardly representative of what it's capable of. 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.

Using this very nice POV-Ray render from Wikipedia: https://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Gl... 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 ph…

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

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

#106

Post by 0-_-0 »

TylerE wrote: post #80
dan-robertson wrote: post #78

Earlier quoted context omitted.

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

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

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

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

#107

Post by BubRoss »

dahart wrote: post #103
BubRoss wrote: post #94

Earlier quoted context omitted.

> Films don’t model in “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…

Yeah, so you’re talking about subdivs, not just any polygons. Yes you create subdiv geometry using polygon modeling tools, but modeling pure polygon models, e.g., for games, is a different activity. Subdivs are easier than NURBS, it’s true, but they do come with their own whole set of connectivity, workflow, texturing, pipeline, etc. Just saying “polygons” is misleading.

> modeling pure polygon models, e.g., for games, is a different activity

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.

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

#108

Post by CyberDildonics »

TylerE wrote: post #102
CyberDildonics wrote: post #95

Earlier quoted context omitted.

That is what it is, but how does it make any of the other parts of 3D easier? How would deforming it be easier than surface geometry for instance?

One major problem with surfaces is calculating which side is facing out. This is actually much harder than it sounds. CSG doesn't have this problem because it knows inside vs outside.

That is almost never a problem. It has to do with winding order and the only time you need to pay attention to it is when creating polygons from some sort of other data like lidar. Even then any groups of connected polygons can be made to have consistent normals.

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.

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

#109

Post by dahart »

BubRoss wrote: post #107
dahart wrote: post #103

Earlier quoted context omitted.

Yeah, so you’re talking about subdivs, not just any polygons. Yes you create subdiv geometry using polygon modeling tools, but modeling pure polygon models, e.g., for games, is a different activity. Subdivs are easier than NURBS, it’s true, but they do come with their own whole set of connectivity, workflow, texturing, pipeline, etc. Just saying “polygons” is misleading.

> modeling pure polygon models, e.g., for games, is a different activity 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…

Yes, exactly, knowing they’ll be smoothed is a big difference, it leads to different choices. Looking at a smoothed surface during the modeling process is an even bigger difference than looking a mesh all the way through. Knowing how they’ll be smoothed is important. What about creases? What if you want a creased edge smoothed and it’s part of two separate mesh groups?

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.

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

#110

Post by BubRoss »

dahart wrote: post #109
BubRoss wrote: post #107

Earlier quoted context omitted.

> modeling pure polygon models, e.g., for games, is a different activity 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…

Yes, exactly, knowing they’ll be smoothed is a big difference, it leads to different choices. Looking at a smoothed surface during the modeling process is an even bigger difference than looking a mesh all the way through. Knowing how they’ll be smoothed is important. What about creases? What if you want a creased edge smoothed and it’s part of two separate mesh groups? You can subdivide polygons without smoothing the…

> What about creases?

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.

Post reply on HN