clipka wrote:
> Some serious feedback on this anyone, before it gets swamped in posts about
> mutexes?

I think one of the best ways to start is to get the tree building and 
re-sampling working again in the single-render thread case. From there you 
can make progress towards multithreading.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> I think one of the best ways to start is to get the tree building and
> re-sampling working again in the single-render thread case. From there you
> can make progress towards multithreading.

I think it doesn't make sense to put any work into POV's radiosity without
having at least some rough idea how it will be operating.

And making a POV-version that will support SMP only for non-radiosity scenes
isn't worth the hassle in my eyes: To get my quad-cores working simultaneously
on a non-radiosity scene, I can always start four full-fledged render processes
to crunch away on the same scene, forcing them to produce different jittering
and merging the results later - so I can get away with less antialias / focal
blur samples and lower area light resolution to get the whole thing speed up.


Ah, speaking of it: 100% reproducibility seems a holy cow in POV, but there are
situations where one might deliberately want variations in jitter effects from
shot to shot. So it would be nice to have a command line / ini parameter that
basically says "add X to all jitter-related random generator seeds" (where X
may even be something derived from current system time).

Setting a different antialias jitter value helps in practice, but I think it's
not the cleanest approach.

Post a reply to this message

clipka wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>> I think one of the best ways to start is to get the tree building and
>> re-sampling working again in the single-render thread case. From there you
>> can make progress towards multithreading.
> 
> I think it doesn't make sense to put any work into POV's radiosity without
> having at least some rough idea how it will be operating.

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

	Thorsten

Post a reply to this message

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:

- Migrating from C to C++
- Introducing Multithreading
- Introducing some optimizations
- Changing some features
- Doing all of this at different paces for different components

In addition, the refactoring approach wasn't ideal. "TODO FIXME" is never a good
solution to problems that arise during refactoring, because you effectively
break the code and have to re-assemble it later. So you have a time in between
when you cannot do any regression testing on the "amputated" code, and when you
are able to do it again, the code may have changed too much overall to do any
sensible regression testing.

In the case of POV 3.7.0 beta, some parts of the radiosity code have been
amputated to ease the transition from C code (global data) to C++ code
(object-internal data storage). If that would have been the only changes for
now, things would be much easier for me: I could be sure that the beta must
produce exactly the same output as the 3.6.1c, up to the very last pixel.

Now I don't know: I get different output, but is it really wrong?. After all, as
a first step towards multithreading the picture is now pretraced in a different
order (block by block, instead of line by line), which changes the choice of
samples taken; even if I would change the processing order back, the main
render would still be done block by block now. I can't possibly change *all*
the code back to 3.6.1c.

Then there is the Gamma thing: The beta.29 seems to produce a higher contrast in
radiosity shots, but is that a radiosity bug, or do I see some effect of the
Gamma stuff here?

In addition, I find code that seems to do things differently than the 3.6.1 -
not on an overall design level, but in small details. Some are obviously
intended as features - but they reduce my ability even further to assess
whether the output I get is good or bad.

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.

The most perplexing thing is that I get these results at very low costs (for
reasons I don't even understand; at the moment I'm just skimming through the
radiosity code, leveling out everything that seems to have changed from 3.6.1c
and beta.29).

For example, a 640x512 pixel version of my radiosity-based "Claustrophobia" shot
for the TINA-CHeP competitiontakes 7830 seconds of CPU time with the beta.29 on
my machine, but just 2370 seconds with my modifications - less than a third of
the time. Both versions were running at full throttle. Both produced images
that seem to differ only in random details.

(see http://www.tc-rtc.co.uk/imagenewdisplay/stills/index151.html what kind of
scene I'm talking about)

The 3.6.1c still hasn't finished more than 60% of the shot after ~8000 seconds
of CPU time; I'm curious how the results will compare.


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.

Post a reply to this message

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