POV-Ray : Newsgroups : povray.off-topic : CGI : Re: CGI Server Time
29 Jul 2024 02:31:08 EDT (-0400)
  Re: CGI  
From: Invisible
Date: 25 Jun 2012 04:27:12
Message: <4fe820e0@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.