clipka <nomail@nomail> wrote:
> - The algorithm described by Ward et al. is NOT radiosity either.

  The problem is that there are two things which have the name "radiosity":

1) By far the most widely accepted definition of the word "radiosity" in the
computer graphics industry and community is to refer to a very specific
algorithm, which is used to achieve diffuse inter-reflection of light between
surfaces. This algorithm is heavily based on using lightmaps, and usually
can only be feasibly implemented in a scanline renderer.

2) A much less widely used meaning is to use "radiosity" as the generic term
for any diffuse light inter-reflection algorithm. In POV-Ray the term is used
in this second meaning. However, most commonly in the computer graphics
industry the term "global illumination" is used instead. (Although GI can
refer to more complex lighting than simply *diffuse* inter-reflection.)

  A much more accurate name for Ward's algorithm (a variation of which is
used in POV-Ray) is "stochastic global illumination method" (or alternatively
"monte-carlo global illumination method", although I'm not 100% sure if
it really *is* monte-carlo sampling technically). However, people use
"radiosity" for historical reasons, because it's short, and because the
documentation uses it (and because it's the SDL keyword). The documenation
and the SDL keyword are technically wrong, but I suppose there's little
that can be done about that. (Although with a full rewrite perhaps a name
change could be fitting.)

> - The algorithm used by POV-Ray DOES come very close to that described by Ward
> et al.; there are a few differences, but none that would justify a complete
> rewrite. The core of the implementation is plain Ward et al.

> So I guess most people complaining that Radiosity works much better in other
> programs than in POV, and then maintain that it should be re-implemented
> according to Ward et al.'s paper, haven't read the paper themselves (or have no
> idea whatsoever about the internal workings of POV's implementation).

  In that case it would be interesting to know why it seems that Radiance
gets superb-looking, accurate and smooth radiosity with (apparently) no or
minimal tweaking, while in POV-Ray it seems to be a constant struggle to
get artifact-free radiosity which looks good and realistic.

  I have the impression that Radiance does something which POV-Ray doesn't
(or the other way around).

> For all those who still ask for TRUE Radiosity to be implemented in POV, I can
> give you one clear statement:

>     This will never happen.

  What do you mean by "TRUE Radiosity"? If you are referring to the
lightmapping precalculation technique, the only limitation to implementing
it in POV-Ray would be that it's more or less limited to polygons. It could
be conceivably be implemented in POV-Ray, assuming it's limited to work with
meshes only (for both the illuminated surfaces and surfaces which illuminate
other surfaces). Given how widely used meshes are, it wouldn't be all that
far-fetched to think that it could be useful even with this limitation.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   In that case it would be interesting to know why it seems that Radiance
> gets superb-looking, accurate and smooth radiosity with (apparently) no or
> minimal tweaking, while in POV-Ray it seems to be a constant struggle to
> get artifact-free radiosity which looks good and realistic.

http://radsite.lbl.gov/radiance/gallery/electric.html

Don't look any better than the best images in POV's HOF.  In fact, their focus
on technical correctness and lack of any artistic aesthetic makes them
downright ugly and aseptic to most povray users, I guess.

I've also seen scenes by Gilles Tran that used quite standard settings for
"radiosity" and still produced sublime results.  I wonder how much tweaking
he'd save on radiance's "radiosity" settings but instead call a long
command-line pipe with all the little radiance utilities needed to "compile" a
single image... it's a huge advantage of povray over radiance.  That and the
SDL.

>   What do you mean by "TRUE Radiosity"? If you are referring to the
> lightmapping precalculation technique, the only limitation to implementing
> it in POV-Ray would be that it's more or less limited to polygons. It could
> be conceivably be implemented in POV-Ray, assuming it's limited to work with
> meshes only (for both the illuminated surfaces and surfaces which illuminate
> other surfaces). Given how widely used meshes are, it wouldn't be all that
> far-fetched to think that it could be useful even with this limitation.

Yes.  I also wonder if photon mapping is not useful as a general GI method in
povray for the same reason of lightmapped radiosity...

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   In that case it would be interesting to know why it seems that Radiance
> gets superb-looking, accurate and smooth radiosity with (apparently) no or
> minimal tweaking, while in POV-Ray it seems to be a constant struggle to
> get artifact-free radiosity which looks good and realistic.

- Does Radiance actually use the "Ward algorithm" to achieve "radiosity"?

- How does the speed of Radiance compare to POV? If you invest enough computing
power, you don't have to do much tweaking either to get superb-looking,
accurate and smooth results.

I have no experience with Radiance whatsoever, so I can't make any statements
about this.

>   I have the impression that Radiance does something which POV-Ray doesn't
> (or the other way around).

Well, I already found some things that POV does differently from Ward et al.; no
really dramatic changes so far - just a few screws to tweak the algorithm. But
they're not exposed to the user, and they're possibly not well-chosen.

From those settings, I guess POV should perform well with scenes that have an
overall reflectivity (specular + diffuse) of 0.25 or below - which is probably
not realistic...

> It could
> be conceivably be implemented in POV-Ray, assuming it's limited to work with
> meshes only (for both the illuminated surfaces and surfaces which illuminate
> other surfaces). Given how widely used meshes are, it wouldn't be all that
> far-fetched to think that it could be useful even with this limitation.

Given how many people use isosurfaces or blobs...: No deal.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> - Does Radiance actually use the "Ward algorithm" to achieve "radiosity"?

Yes, it was its proof of concept and Radiance too is the brainchild of Ward.

> - How does the speed of Radiance compare to POV? If you invest enough computing
> power, you don't have to do much tweaking either to get superb-looking,
> accurate and smooth results.

Don't really know, but while POV-Ray was always more of a hobbyist program,
Radiance was being pushed by a well respected reseacher in the area, as well as
being used by companies in arch viz.

Post a reply to this message

> -----Original Message-----
> From: nemesis [mailto:nam### [at] gmailcom]
> Yes.  I also wonder if photon mapping is not useful as a general GI
> method in
> povray for the same reason of lightmapped radiosity...

I did some tests last year to that effect, and liked the results.  I
just never got around to doing anything with the source to make that
aspect easier, but I would love to see someone else pursue that.

...Ben Chambers
www.pacificwebguy.com

A render isn't slow unless it won't finish until after your next
birthday.

Post a reply to this message

clipka <nomail@nomail> wrote:
> > It could
> > be conceivably be implemented in POV-Ray, assuming it's limited to work with
> > meshes only (for both the illuminated surfaces and surfaces which illuminate
> > other surfaces). Given how widely used meshes are, it wouldn't be all that
> > far-fetched to think that it could be useful even with this limitation.

> Given how many people use isosurfaces or blobs...: No deal.

  So in your opinion, because many people use something else than meshes,
we should not offer those who do use exclusively meshes for their scenes
any additional tools?

-- 
                                                          - Warp

Post a reply to this message

> -----Original Message-----
> From: Warp [mailto:war### [at] tagpovrayorg]
>   So in your opinion, because many people use something else than
> meshes,
> we should not offer those who do use exclusively meshes for their
> scenes
> any additional tools?

Look at it another way.

If there were a feature that made boxes look a *lot* better by
performing lighting calculations differently, would you advocate it?
Remember, because the lighting is different, it probably won't be
possible to mix boxes using the new method with other geometry; that is,
you'll have to use *only* boxes to get the result.

Would you advocate the addition of such a feature?

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

On 27-Dec-08 21:24, Chambers wrote:
>> -----Original Message-----
>> From: Warp [mailto:war### [at] tagpovrayorg]
>>   So in your opinion, because many people use something else than
>> meshes,
>> we should not offer those who do use exclusively meshes for their
>> scenes
>> any additional tools?
> 
> Look at it another way.
> 
> If there were a feature that made boxes look a *lot* better by
> performing lighting calculations differently, would you advocate it?
> Remember, because the lighting is different, it probably won't be
> possible to mix boxes using the new method with other geometry; that is,
> you'll have to use *only* boxes to get the result.
> 
> Would you advocate the addition of such a feature?
> 
It's the wrong example, and you know it.
It is a difficult decision in this version of POV. Currently there are 
two important aspects of POV. One is the SDL and the other is the 
rendering engine. And they are coupled. If they weren't you could take 
the SDL and add another lighting method to derive another JustNotPOV 
with restrictions. Probably one can run it as a branch and expect that 
one day someone solves how to get the same result for algorithmically 
defined objects. Clipka would be fully justified to create that branch, 
but he doesn't want to. Branching off is not a decision to take lightly, 
and I am glad that he wants to add to the main stem.

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> It is a difficult decision in this version of POV. Currently there are
> two important aspects of POV. One is the SDL and the other is the
> rendering engine. And they are coupled.

Well, not precisely:

It's the *geometry model* and the lighting model which are tighly coupled.

The SDL is coupled with the two, but that's something irrelevant in this
context. The SDL could be adjusted accordingly.

Post a reply to this message

On 27-Dec-08 22:13, clipka wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> It is a difficult decision in this version of POV. Currently there are
>> two important aspects of POV. One is the SDL and the other is the
>> rendering engine. And they are coupled.
> 
> Well, not precisely:
> 
> It's the *geometry model* and the lighting model which are tighly coupled.
> 
> The SDL is coupled with the two, but that's something irrelevant in this
> context. The SDL could be adjusted accordingly.

The SDL is only relevant in the sense that if you would allow a version 
of POV with only triangles, effectively stripping all other primitives, 
it would not really be POV anymore. The reason why I called it coupled 
is that they are both in the same package and one does not exist without 
the other. That is of course quite different from being logically 
coupled in the source.
BTW I applaud it that you have found time to look at the source in an 
attempt to improve it. I wish I had time for that.

Post a reply to this message