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