4722f06c@news.povray.org...
> Many of the global illumination (radiosity) scenes had posted times
> over 12 hours, when I'm sure equivalent scenes in POV would
> render in less time (usually) and not be grainy.

The problem being that doing equivalent scenes in POV-Ray (particularly 
interior scenes) is, from a practical point of view, impossible. Light 
sources in POV-Ray are much too primitive for that, there's no support for 
true area lights or good-looking blurred reflections and while there are 
situations where it's more or less possible to simulate this (using various 
tricks), in most cases it just doesn't work. Jaime is probably the POV-Ray 
artist who has done the most research in that, and his best results, 
impressive as they are from a POV-Ray perspective, are just not in same 
league and are plagued with radiosity artifacts and area light graininess.
http://www.ignorancia.org/en/index.php?page=Modern_interior

Even with the grain, the quality of the illumination in unbiaised renderers 
is unparalleled, simply because there's no cheating involved.

G.

Post a reply to this message

What unbiased methods give you is certainty. If you leave them long enough
they *will* approach the true solution. The rendering times usually needed
to reduce grain (without post-processing, anyway) are impressively long,
but if you add tweaking and re-rendering time to shift stubborn artefacts
from radiosity, I'm not so sure the comparison is much in POV's favour.

On the other hand, while path tracing et al are nice and all, I'm pretty
sure these methods could *not* be added to POV as it currently is without
massive internal changes. They require sophisticated sampling support for
all render steps to be practical at all. Is the effort worth it?

This thread and others have pointed out that there are actually plenty of
free renderers out there that make unbiased methods their specialty. Why
one more? Programs like PBRT were designed from the ground up to support
multiple approaches to solving the rendering equation, and it shows in the
code. POV wasn't, in fact it's tedious enough to make even minor
alterations to the way it currently works.

Instead I think there is something to be said for sticking to a ray tracer +
global illumination approach. Replacing the existing radiosity method with
something based on photon mapping would help tackle the artefacted GI
problem, but that would be the most major change needed that I can think
of. As a raytracer POV may not be exceptionally fast, but the
(non-commercial) competition I've tried out seem surprisingly slow, and
people still use them. I think there is still demand for fast raytracing
with some occasional GI, why not focus on that?

Tom

Post a reply to this message

Gilles Tran wrote:

> The problem being that doing equivalent scenes in POV-Ray (particularly 
> interior scenes) is, from a practical point of view, impossible. Light 
> sources in POV-Ray are much too primitive for that, there's no support for 
> true area lights or good-looking blurred reflections and while there are 
> situations where it's more or less possible to simulate this (using various 
> tricks), in most cases it just doesn't work.

Wait... since when does POV not have "true" area lights?

> Jaime is probably the POV-Ray 
> artist who has done the most research in that, and his best results, 
> impressive as they are from a POV-Ray perspective, are just not in same 
> league and are plagued with radiosity artifacts and area light graininess.
> http://www.ignorancia.org/en/index.php?page=Modern_interior
> 
> Even with the grain, the quality of the illumination in unbiaised renderers 
> is unparalleled, simply because there's no cheating involved.

Perhaps everybody else is looking at different pictures to me...? I 
think these ones look *better* than the ones from Indigo. (Sharper, more 
crisp, and more detailed. The colours seem more vivid too. I don't know 
whether this is an effect of the renderer or just better scene design...)

Seriously. I'm failing to see anything POV-Ray can't already do. 
(Especially if you leave it to render for *this* long!) Also, I was 
somewhat amused to see quite a few images that appear to be using 
polygons rather than real curves... No cheating? I think not.

Post a reply to this message

Tom York wrote:
> What unbiased methods give you is certainty. If you leave them long enough
> they *will* approach the true solution.

So will POV-Ray's radiosity system, if you turn the settings up high 
enough. (And wait a damn long time...) Your point?

Post a reply to this message

"Orchid XP v7" <voi### [at] devnull> wrote in message
news:47234bd4$1@news.povray.org...
> Gilles Tran wrote:
>
> > The problem being that doing equivalent scenes in POV-Ray (particularly
> > interior scenes) is, from a practical point of view, impossible. Light
> > sources in POV-Ray are much too primitive for that, there's no support
for
> > true area lights or good-looking blurred reflections and while there are
> > situations where it's more or less possible to simulate this (using
various
> > tricks), in most cases it just doesn't work.
>
> Wait... since when does POV not have "true" area lights?

Since always. Area lights are implemented as arrays of point lights

Post a reply to this message

> Is it possible to automatically know when a scene is good enough? Or 
> does it take human intervention to say "ok, stop now and move on to the 
> next frame"?
> 

On the only forwards-raytracer I have ever used (WinOSi), the rendering 
algorithm is two passes inside an infinite loop. You stop it when you 
want to. You can also render for a while on different computers, and 
*merge* the results.

Post a reply to this message

Gail Shaw <initialsurname@sentech sa dot com> wrote:
> Since always. Area lights are implemented as arrays of point lights

  I wouldn't say there's too much difference between having, technically
speaking, an array of (perhaps jittered) point lights and randomly shooting
samples towards an area light. They are extremely similar ways of doing
the same thing, although the minor differences introduce advantages and
disadvantages to both methods.

  A randomly-sampled "illuminating object" can have any shape, form,
brightness variation and surface coloration whatsoever, without any limit.
You can simulate this to some extent with the point lights idea, but with
very large free-form shapes it can become quite inefficient because you
would need hundreds if not thousands of point lights, and freedom of form
makes it more difficult to implement adaptive sub-sampling.

  OTOH a grid of point lights becomes much more efficient if the physical
size of the area light is small. The smaller the area light, the more
efficient it becomes compared to random sampling (because if the light
source is very small, the vast majority of random samples will miss it).

  Both methods suffer from speed/graininess tradeoffs. The less grainy you
want the result to be, the more it takes to render (even though the light
grid method becomes the faster the smaller the area light is).

  Perhaps the best "true area light" lighting method is radiosity (the
algorithm called "radiosity", which is related to calculating lightmaps,
not the stochastic sampling method used by POV-Ray), even though in this
case it's also a discrete sampling method because you are basically
calculating light maps which have a certain pixel resolution. The end
result are completely grain-free regardless of this resolution, though.
(The only artifact caused by low sampling is unrealistic smoothing).
This also suffers somewhat if the area light is very small, although not
nearly as badly as random sampling. (Another problem with radiosity is
that it cannot be used to calculate specular reflections caused by area
lights.)

-- 
                                                          - Warp

Post a reply to this message

> Why one more? Programs like PBRT were designed from the ground up to support
> multiple approaches to solving the rendering equation, and it shows in the
> code. POV wasn't, in fact it's tedious enough to make even minor
> alterations to the way it currently works.
> 

I said it on other threads, but why not repeat: I would like POV-Ray to 
support adding rendering algorithms with similar ease as adding objects 
or patterns or camera projections. As long as it involves shooting rays, 
it would be compatible with all existing objects and pigments. Finish{} 
would need to be customized for each lighting algorithm, and some 
algorithms can't use normal perturbations, but pigments should work.

I want a forward raytracer with the power of existing POV-Ray SDL and 
CSG. And isosurfaces. POV-Ray with an unbiased renderer "plugin" seems 
like the best candidate; better than rewriting the SDL parser and 
isosurface code on an existing unbiased renderer...

Post a reply to this message

> Even with the grain, the quality of the illumination in unbiaised renderers 
> is unparalleled, simply because there's no cheating involved.

Question is : is that kind of algorithm "compatible" with a 
'traditional' ray-tracing engine (like POV-Ray), so that radiosity
and other features could be treated that way, or would it be
like two different renderers in one ?

Could POV-Ray, in some future, integrate these algorithms without
a complete core change ?

Fabien.

Post a reply to this message

Orchid XP v7 wrote:
> Tom York wrote:
>> What unbiased methods give you is certainty. If you leave them long 
>> enough
>> they *will* approach the true solution.
> 
> So will POV-Ray's radiosity system, if you turn the settings up high 
> enough. (And wait a damn long time...) Your point?

Except you can't.  Turn the settings up high enough, that is.  POV 3.5 
has a hardcoded limit of 1500 radiosity samples.  Which hopefully will 
be (has already been?) fixed by the next version that has a compatible 
Moray to use with it.

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message