clipka wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>> Well, given the code mostly works, it is just a matter of fixing a few bugs
>> and then having a working reference implementation does make quite a bit of
>> sense...
> 
> As it seems to me, the problem with the code, as it is now, is that it was
> attempted to change too many things at once:

The code is not generating images remotely right. Just compare to 3.6 
output. Quality is much worse in 3.7 because something is missing. I never 
had the time to track it down though. It is a fairly simple problem for 
certain, but radiosity tests do take a real lot of time.

All this has nothing to do with multithreading or the use of C++ because the 
code was never changed for it. In fact, very little was changed in the 
radiosity code at all (and the lighting code has only been changed a bit). 
In short, a simple problem exists, it is just very time consuming to debug.

	Thorsten

Post a reply to this message

clipka wrote:
> Of course, last not least there is the problem that 3.6.1c radiosity was bad as
> well. I actually think that what I currently have produces significantly better
> results not only compared to beta.29, but also to 3.6.1c.

It isn't bad or broken at all in 3.6. It is just difficult to use <sigh>

> You mention that it's "just a matter of fixing a few bugs" - if that is so, it
> would be helpful to get some description of them.

Use the included sample scenes, and you will quickly notice the problems: In 
particular the darkness problems and similar artifacts. The sample scenes, 
which are very simple geometries, do make the issue very clear quickly. I 
would recommend trying them as the issue is not easy to track down in 
complex scenes with already complex non-radiosity lighting.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> It isn't bad or broken at all in 3.6. It is just difficult to use <sigh>

I tell you it *is* bad (although it's not all the radiosity code's fault).

One example: Smooth meshes. If you set recursion_limit to some higher value,
light "leaks through" them like a leaky bucket if they aren't heavily
subdivided. This is because with smooth mesh objects the "raw" normal isn't
actually "raw" at all.

For some strange reason, it seems that this "leaky bucket" effect isn't limited
to meshes, but also appears with CSG object (albeit less strongly).

It also seems to me that the 3.6.1 radiosity implementation makes bright light
"flow" along e.g. corners of a room in an unnatural way.

Another thing is that it seems to me as if the 3.6.1 radiosity code would pick
up object colours too strongly.

The beta.29 seems to pick up colour to less extent, but does have the "flow"
effect as well; my most recent version of the code doesn't have it, for some
reason I don't understand because I think I should actually be closing in on
3.6.1 status.


> Use the included sample scenes, and you will quickly notice the problems: In
> particular the darkness problems and similar artifacts. The sample scenes,
> which are very simple geometries, do make the issue very clear quickly. I
> would recommend trying them as the issue is not easy to track down in
> complex scenes with already complex non-radiosity lighting.

I'm currently using quite simple, radiosity-only scenes (well, the
"Claustrophobia" shot uses a *bit* of conventional lighting as an add-on, but
primarily it's radiosity based).

They're possibly a bit unusual in their radiosity use - for example, one is a
simple, unlit room that *should* be illuminated only by light seeping through
an almost-closed door (the light source itself is just an excessively bright
white background). But it makes a formidable scene to show that 3.6.1 radiosity
is messed up already.

Post a reply to this message

One possibility would be to rewrite the whole radiosity code from scratch.
Read the original paper by Greg Ward about the subject, and if possible,
study how Radiance does it "properly", and learn from that before the
rewrite.

  Of course this is a huge amount of work, and it would be perfectly
understandable if nobody would be ready to do it. (There might also be
some minor surprising issues, eg. something intrinsic in POV-Ray not being
completely compatible, for whatever reason, with Ward's algorithm, or
something else.)

  Radiance is a proof that the algorithm can be made to work well. It's just
a question of somebody doing it... :/

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> One possibility would be to rewrite the whole radiosity code from scratch.
> Read the original paper by Greg Ward about the subject, and if possible,
> study how Radiance does it "properly", and learn from that before the
> rewrite.

Heh! I want it to be in the beta *soon*...!

When I look at the code, I'm indeed tempted to do a complete rewrite - too many
tiny little screws tweaked for unexplained reasons; but I'm not sure whether
that is desired by the POV team at all, despite the old warning that "The
design and implementation of [radiosity] is LIKELY to change in future versions
of POV-Ray" (emphasis added).

Oh, speaking of "the original paper", here's a quote from the sources:


"(This does not work the way that most radiosity programs do, but it
accomplishes the diffuse interreflection integral the hard way and produces
similar results. It is CALLED RADIOSITY here TO AVOID CONFUSION WITH AMBIENT
AND DIFFUSE, which already have well established meanings within POV).

INSPIRED by the paper "A Ray Tracing Solution for Diffuse Interreflection" by
Ward, Rubinstein, and Clear, in Siggraph '88 proceedings."

(again, emphasis added)


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

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Oh, speaking of "the original paper", here's a quote from the sources:
>
> "(This does not work the way that most radiosity programs do, but it
> accomplishes the diffuse interreflection integral the hard way and produces
> similar results. It is CALLED RADIOSITY here TO AVOID CONFUSION WITH AMBIENT
> AND DIFFUSE, which already have well established meanings within POV).
>
> INSPIRED by the paper "A Ray Tracing Solution for Diffuse Interreflection" by
> Ward, Rubinstein, and Clear, in Siggraph '88 proceedings."
>
> (again, emphasis added)
>
>
> So it was never actually intended to be true radiosity, but just a thing that
> did something similar.

The original paper is not about radiosity either.

Post a reply to this message

"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