"Xplo Eristotle" <xpl### [at] infomagiccom> wrote in message
news:3B1D8CC3.8DE0937E@infomagic.com...
> Warp wrote:
> >
> > Nekar Xenos <j-p### [at] citywalkcoza> wrote:
> > : A friend of mine is all excited about Flamingo that he says does radiosity
> > : faster and better than Pov.
> >
> >   The global lighting code of POV-Ray has still way to go, as it still has
> > some unknown problems (bugs?). AFAIK POV-Ray 3.5 will have basically the
same
> > radiosity code as MegaPov has.
> >   In many scenes it works like a charm, very fast and the result is
excellent.
> > However, it's quite usual that you just don't get it working in your
> > specific scene (either it's too dim or too bright or has annoying artifacts,
> > specially near corners; it also has this annoying tendency of working in
> > the way that if you set low quality you get good but unrealistic
illumination
> > (eg. no darkening in corners) and if you set high quality you get better
> > illumination but annoying artifacts in corners). These problems might be
> > caused by wrong or buggy code. Perhaps a total rewrite could be necessary
> > in order to get rid of the problems (it seems that currently no-one knows
> > where the problems are in the radiosity code)?
>
> If you imagine radiosity as being like shading being applied to the
> scene with a brush and diluted black ink, it becomes fairly easy to
> understand.. well, for me anyway. (This analogy is kind of a butchery of
> the way radiosity ACTUALLY works, but it's a fair description of its
> effect on a scene.)
>
> If you use a high error_bound, it's as if you were using a large brush,
> or a sponge, to paint the shading on. This gives good overall lighting,
> like a kind of "smart" ambient, but doesn't produce sharp shadows. It
> also doesn't produce obvious artifacts, simply because the artifacts are
> generally too large to be obvious. (Try lighting a "room" with
> radiosity, using a high error_bound and a really low count. There should
> be very noticible circles of varying brightness on the walls.)
>
> If you use a low error_bound, the effect is that of using a small brush
> to paint in the shadows with tiny strokes. Your lighting takes on a much
> more noisy, grainy look - including artifacts in the corners, where
> shadows "build up" - but shadow outlines are much more clearly defined.
>
> For this analogy, imagine count as a measure of how thorough you are in
> applying the ink with your brush. A low count represents strong ink,
> applied quickly and sloppily. As you raise the count, you make more
> strokes, using thinner ink, and the shadows take on more and more of a
> "blended" look until finally they become smooth.
>
> (The other parameters also have an effect on radiosity, of course, but
> none of them are particularly important to this analogy. Many of them
> are similar to count.)
>
> Now, if you, a human being, were to attempt to shade a picture this way,
> you would probably make an effort to put new splotches in the lighter
> parts, so that even if the shading were grainy-looking, it would at
> least be an even sort of graininess. But the computer makes no such
> considerations, and when you imagine the result of randomly-placed
> shading splotches, the reason for the artifacts becomes obvious...
>
> Judging from old radiosity pics and the way official POV radiosity
> works, I'd guess that whoever wrote the code never expected radiosity to
> be used the way it's often used today. So it's not that the code is
> buggy per se, it's just poorly-optimized for detail work, and what we
> probably need is a smarter algorithm.
>
> -Xplo

Thanks for this explanation. I've understood the basic principle of radiosity
without really knowing how to use it. This will really help me to use it better.

-Nekar

Post a reply to this message