 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
.... no, don't panic - I'll keep working on the radiosity as such.
But I definitely give up trying to get 3.7 radiosity exactly reproduce 3.6
functionality.
I have dug through the code multiple times, discovered several discrepancies
between 3.7.beta.29 and 3.6 causing differences in output, identified several
others that didn't seem to make a change, stumbled across some old flaws I
intend to fix, and for sentimentality's sake even re-introduced one flaw that
wasn't there in 3.7 due to slight differences in the software architecture
(don't worry, I'll take it back out again :)), all to try and re-create the
same output as 3.6.
I have come to the point now that plowing through the whole code over and over
again has ceased to surface any further discrepancies. And I definitely do
*not* intend to go through *all* the POV code and revert it back to exact 3.6
functionality (and after all, maybe some modifications may actually be in there
for good already :)).
So I conclude that any residual differences must be rooted in changes to some
other parts of POV-ray code: Media, photons, area lights, multi-layered
textures - whatever.
The remaining discrepancies with the scenes I used for testing are:
- minor difference in brightness on one of the cube's corners in "cornell.pov"
- differences in brightness on the object-mapped portion of the pill containers
in "object_pattern.pov"; tests strongly indicate that these are caused by the
object-mapped texture, not the radiosity per se
- differences in brightness of various shadowed parts in "balcony.pov"; tests
were not conclusive about the true origin of the differences.
- differences in a self-made scene designed to provoke black-splotch artifacts,
probably related to differences in trace-level counting (note that the
black-splotch artifacts will be eliminated anyway)
- differences in another self-made scene (the "Claustrophobia" shot), probably
related to black-splotch artifacts and therefore of similar origin
- totally different results with a self-made, very demanding radiosity scene
which hasn't actually worked as intended with any POV version at all - again,
possibly due to differences in trace-level counting.
From what I see, none of these differences do any general harm to the picture
(except for the pill-container issus); the pictures simply look different, and
I find it hard to judge which version is more realistic. I'd usually prefer the
new output.
Aside from visual differences, the most notable ones are differences in speed.
Compared with the MegaPOV 64-bit Linux binaries, some scenes take a bit longer
with the current code, some render a bit faster. It seems that overall,
radiosity-only scenes benefit, while non-radiosity scenes all render slightly
slower, and mixed scenes are somewhat indecisive. This is all pure CPU time
though, and real-time speed benefits a lot on multicore systems.
If it was my call, I'd say let's just fix the black-splotch thing, get a few
details more towards the original Ward paper, make a new beta of it, and see
what reports come in.
Main remaining issues:
- Loading/saving of radiosity samples simply doesn't work yet
- Radiosity shots are currently not 100% reproduci... duca... um... I mean, you
can't reproduce the 100% same result on every run.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph, that sounds like a very excellent idea. Now that you have done a
thorough analysis of the radiosity situation, some testing is in order. This
community is reputed to be very good at testing and falsifying, so go ahead
:-)
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> Christoph, that sounds like a very excellent idea. Now that you have done a
> thorough analysis of the radiosity situation, some testing is in order. This
> community is reputed to be very good at testing and falsifying, so go ahead
I would right away - but I'm not allowed to:
----------------------
1. This source file may not be re-distributed without the written permission
of Persistence of Vision Raytracer Pty. Ltd.
[...]
3. Binaries generated from this source file by individuals for their own
personal use may not be re-distributed without the written permission
of Persistence of Vision Raytracer Pty. Ltd. [...]
----------------------
So I'd need a written permission to re-distribute my current experimental
version - and I don't have one yet...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> schreef in bericht
news:web.49588d7ccd9d1e756f3e4e890@news.povray.org...
>
> I would right away - but I'm not allowed to:
>
> ----------------------
> 1. This source file may not be re-distributed without the written
> permission
> of Persistence of Vision Raytracer Pty. Ltd.
>
> [...]
>
> 3. Binaries generated from this source file by individuals for their own
> personal use may not be re-distributed without the written permission
> of Persistence of Vision Raytracer Pty. Ltd. [...]
> ----------------------
>
> So I'd need a written permission to re-distribute my current experimental
> version - and I don't have one yet...
>
>
We sit down, and wait in confidence... :-)
In my understanding, this should not be a problem to obtain as it is part of
the overall upgrading of povray.
Have I said this? I would like to extend my sincere appreciation for the
effort you are clearly providing towards the next stage of our all-acclaimed
rendered: POV-Ray. Hurray!
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot wrote:
> We sit down, and wait in confidence... :-)
>
> In my understanding, this should not be a problem to obtain as it is part of
> the overall upgrading of povray.
>
> Have I said this? I would like to extend my sincere appreciation for the
> effort you are clearly providing towards the next stage of our all-acclaimed
> rendered: POV-Ray. Hurray!
The redistribution of the beta source code is prohibited. There won't be a
permission for anyone to distribute the beta source code or binary in any
other form. The purpose of making the beta source code available is to get
submissions of bug fixes that will be added to the official beta source code
and beta binaries - assuming they work, of course ;-)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <nomail@nomail> wrote:
> If it was my call, I'd say let's just fix the black-splotch thing, get a few
> details more towards the original Ward paper, make a new beta of it, and see
> what reports come in.
Any chances of removing the upper limit of 1600 samples? While 1600 samples
is a lot, some people have encountered the limit and complained about it.
Unless I'm mistaken, those samples are precalculated and hard-coded into
the source. Removing the limit would probably mean that you need to calculate
new samples (above those 1600) by using a random number generator. If you do
so, the absolutely *don't* use rand() from <cstdlib>, but instead use a
high-quality fast RNG designed for stochastic sampling.
I have made a C++ version of Bob Jenkins' ISAAC random number generator,
if you are interested. It's fast (significantly faster than rand() or the
RNG used in POV-Ray), has a humongous period, and should be of very high
quality (way higher than rand() or the RNG used in POV-Ray).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> clipka <nomail@nomail> wrote:
>> If it was my call, I'd say let's just fix the black-splotch thing, get a few
>> details more towards the original Ward paper, make a new beta of it, and see
>> what reports come in.
>
> Any chances of removing the upper limit of 1600 samples? While 1600 samples
> is a lot, some people have encountered the limit and complained about it.
>
> Unless I'm mistaken, those samples are precalculated and hard-coded into
> the source. Removing the limit would probably mean that you need to calculate
> new samples (above those 1600) by using a random number generator.
Boost / ISO C++ 2009 STL provide suitable random number generators that
support distribution over a hemisphere as needed by radiosity code.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tag povrayorg> wrote:
> Any chances of removing the upper limit of 1600 samples? While 1600 samples
> is a lot, some people have encountered the limit and complained about it.
Yes, definitely a chance to do that. However...
(1) I expect quality to improve even with less samples
(2) It's not so high on my agenda as, say, saving & reloading sample data
(3) It still takes some time to develop something good. i don't like the MegaPOV
approach of user-specified sampling sequences, and actually I don't like the
whole concept of a fixed sequence anyway. There must be a smart way to
implement some adaptive algorithm. I also think it would be a good idea to flag
objects as "radiosity targets", like it is done with photons, to inform the
sampling algorithm about small but bright objects so it can shoot a few more
rays in that direction.
> Unless I'm mistaken, those samples are precalculated and hard-coded into
> the source. Removing the limit would probably mean that you need to calculate
> new samples (above those 1600) by using a random number generator. If you do
> so, the absolutely *don't* use rand() from <cstdlib>, but instead use a
> high-quality fast RNG designed for stochastic sampling.
Naah - speed is such an important issue with this that I'd rather precompute
directions like it is done now - although not at compile time, but at scene
startup instead.
If I'd need a RNG for that, I guess I'd use whatever is commonly used in POV
already. Speed is not really an issue for that job (nor is precision).
But I guess an even distribution is actually better than a random one for this
use.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> Boost / ISO C++ 2009 STL provide suitable random number generators that
> support distribution over a hemisphere as needed by radiosity code.
Distribution over a hemisphere is not enough for radiosity. There needs to be a
particular bias towards the "zenith".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>> Boost / ISO C++ 2009 STL provide suitable random number generators that
>> support distribution over a hemisphere as needed by radiosity code.
>
> Distribution over a hemisphere is not enough for radiosity. There needs to be a
> particular bias towards the "zenith".
For small samples sizes, yes, but for large sample sizes assigning a weight
to samples depending on their hemisphere location gives you the same effect.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
