|
![](/i/fill.gif) |
On 25/06/2012 01:09 AM, nemesis wrote:
> Andy, andy... you won't be getting much popularity here tossing around these
> rough arguments...
I'm sure I can't be the only person feeling a little dissatisfied, or at
least a bit concerned.
>> And then, of course, I discovered POV-Ray.
>
> you discovered povray after Cinema 4D and quake... okey, dokey...
What, that's a problem somehow?
I didn't say they were /created/ in that order, merely that I discovered
them in that order. If I said that I discovered Queen before I
discovered Bach, nobody would be the slightest bit surprised, despite
the /several hundred years/ between these. :-P
>> While computer games amuse
>> themselves drawing polygons really, really fast, POV-Ray directly
>> simulates things like curved surfaces, 3D textures, reflection,
>> refraction, and so forth.
>
> yeah, now put povray to directly simulate the curved surfaces of a woman's body.
>
> You may use parametric surfaces if writing the right isosurface function is
> proving too much of a challenge.
Drawing such a thing is equally impossible with POV-Ray or with a mesh
renderer, so it's not a useful comparison. (Although, maybe if I had
infinite point-cloud dartah... :-P )
Saying that, you might be able to model something acceptable with blobs.
Or maybe if POV-Ray supported spline surfaces...
>> But now we have the so-called unbiased renderers, the path tracers,
>> whatever you want to call them. With POV-Ray I need to configure photon
>> maps and set up area lights and waste hours tweaking and tuning
>> radiosity parameters. And then I see a demo that runs IN A FRIGGING WEB
>> BROWSER which uses my GPU to almost instantly render a Cornell box that
>> would take multiple hours to draw with POV-Ray.
>
> Truth be told, a cornell box today doesn't take even a minute in povray...
Funny you should say that. I spent yesterday trying to set up an
animation of a Cornell box, and it appears that to get stable lighting,
I'm going to have to crank the radiosity settings up to the point where
it takes about 30 minutes per frame...
>> I will freely admit, however, that almost all of the actual demo images
>> are still suspiciously grainy. Which suggests that for "real" scenes,
>> rendering still isn't instant.
>
> Scenes like that may take several hours on CPU, just like raytraced scenes in
> the old days.
There's a /reason/ POV-Ray does all this complicated radiosity trickery
rather than just directly simulating the whole thing. It's to make it
render in less than a decade. ;-) The trick, it seems, is to use the GPU
to make it faster.
>> You'd need some insane radiosity settings to get that out of POV-Ray.
>> I'm not sure if it's even /possible/ to get that glow around the light
>> sources.
>
> the glow most likely is just a post-processing 2D effect.
Can you actually do that? I mean, automatically figure out all the parts
of the image which are bright enough to need glow? I suppose the only
way it would fail is if there's a curved reflection of something that
glows; the glow should be curved, but if it's post-processed, it
wouldn't be.
>> On the other hand, no one can deny the image is slightly grainy
>> in places.
>
> I prefer film grain rather than ugly splotches every corner.
Sure. Same here.
(I am surprised nobody has come up with a filter to estimate what's
sampling noise and attempt to filter it out... It can't be that hard.)
>> And then I see something like this:
>>
>> http://tinyurl.com/7r72o7k
>>
>> At first glance, this is an amazing, near-photographic image. And then I
>> notice THE POLYGONS! IT BURNS!!!>_< KILL IT WITH FIRE!
>
> I don't note any polygons in particular
You didn't notice that the table is hexagonal??
> but the surfaces are all too flat and
> regular, denouncing it as CG. Luxrender, like povray these days, is
> conspicuously lacking in true artists rather than programmers trying to show off
> the software.
Heh, well, I wouldn't hold that against it. ;-)
> That scene, I believe, took about 1 day or 2 to be that smooth if memory serves
> me well...
That's /a lot/ of render time, man... o_O
>> Now here's an interesting question: Does anybody know how this stuff
>> actually /works/?
>
> http://www.pbrt.org/
>
> The book explains all and source code for the renderer is GPLed. In fact, it's
> the base for Luxrender.
I'll have to go read that.
>> Wikipedia asserts "Contrary to popular myth, Path Tracing is /not/ a
>> generalisation of ray tracing." This statement makes no sense
>> whatsoever. :-P
>
> To me pathtracing looks as much of a generalisation of raytracing as raytracing
> was of raycasting
Indeed.
>> I'd almost be tempted to write a renderer myself - except that running
>> on a CPU, it will undoubtedly take several billion millennia to draw
>> anything. (There's a /reason/ nobody has tried this until today...)
>
> No, just a few hours or days like povray back in 1990's.
A day is a /long/ time to wait while debugging your code to see if it
works correctly. o_O
Post a reply to this message
|
![](/i/fill.gif) |