"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

Nicolas Alvarez wrote:

> 
> I said it on other threads, but why not repeat: 

Indeed...repeat.  This time I got it.

Post a reply to this message

Gail Shaw wrote:

>> Wait... since when does POV not have "true" area lights?
> 
> Since always. Area lights are implemented as arrays of point lights

And this is observably different how, exactly?

Also, what about radiosity with a big square on the ceiling set to have 
a nonzero ambient figure?

Post a reply to this message

Warp wrote:
> algorithm called "radiosity", which is related to calculating lightmaps,
...
> calculating light maps which have a certain pixel resolution. 

My memory of the algorithm is that you could build it in a way that let 
the areas with lots of detail have finer resolution than the areas with 
less detail, and still get all the benefits of the "real" radiosity 
algoritm. Am I mistaken here?

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

47238d67$1@news.povray.org...
> Also, what about radiosity with a big square on the ceiling set to have a 
> nonzero ambient figure?

You still won't get specular highlights. Unless of course you give every 
material the physically correct blurred reflection necessary to obtain 
specularity. Good luck with that.

G.

Post a reply to this message