"clipka" <nomail@nomail> wrote:
> So it was never actually intended to be true radiosity, but just a thing that
> did something similar. Therefore when refering to "the original paper" we
> shouldn't be talking about a *re-write* but a completely new feature...

Having just taken the time to read the original paper by Greg Ward et al., I'll
have to correct myself:

- The algorithm described by Ward et al. is NOT radiosity either.

- 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).

This misconception may have arisen due to some people rightly claiming that
"what POV-ray does is NOT radiosity", referring to Ward's paper as a witness to
their claim - which other people understood as that Ward's paper would describe
true radiosity. Well, it doesn't.


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.

From what I gather from Ward's paper, true radiosity requires the geometry to be
subdivided in - roughly - equally sized patches. This is easy to do with mesh
based geometry, but infeasible with the mathematical representation POV-ray
uses for objects.

That's the bottom line of it.

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> The original paper is not about radiosity either.

Ward's paper was a few minutes faster at telling me that than you were :)

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "nemesis" <nam### [at] gmailcom> wrote:
> > The original paper is not about radiosity either.
>
> Ward's paper was a few minutes faster at telling me that than you were :)

Seems like we were both reading at the same time, but I just got to page 2 until
realizing it and posting here first. ;)

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> Seems like we were both reading at the same time, but I just got to page 2 until
> realizing it and posting here first. ;)

Found a good version with all diagrams and formulae in it? I could only dig up a
PDF lacking the diagrams & formulae, or a series of .tif files of the scanned
document. Or a set of PostScript files.

Post a reply to this message

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