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] tagpovrayorg> 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

On 29-Dec-08 11:18, Thorsten Froehlich wrote:
> 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 ;-)
> 

I think a relevant question here is: what is a distribution of source. 
If clipka sends the source or a binary by regular mail to e.g. Thomas is 
that distribution? or must it be publicly available to be one. If it is 
the first then collaboration to implement and test improvements of beta 
source is effectively impossible. I can think of reasons to do it that 
way. One would be that source in this beta (double beta?) stage should 
be coordinated by a POV team member. But, which one should that be? In 
this specific case of radiosity: who is coordinating that and would that 
person in this case give permission to create a test version for a 
selected group to use?

Another one: if clipka had started from the 3.16 source would that have 
made a difference?

Post a reply to this message

On 29-Dec-08 13:34, 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".
> 
If you know the shape of the desired distribution that should in general 
be possible.
Just curious, why should it not be evenly distributed (or should I read 
that paper)?

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> > 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

Having this weight "built into" the samples still has some benefits though. It
saves you some multiplications or - if you don't pre-compute the sequence -
even some trigonometrics; better yet: You also don't waste time shooting rays
that don't contribute much.

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> I think a relevant question here is: what is a distribution of source.
> If clipka sends the source or a binary by regular mail to e.g. Thomas is
> that distribution?

I bet it is.

I could send diffs though, because those portions are all my own work...

> Another one: if clipka had started from the 3.16 source would that have
> made a difference?

If it was in the current state: No; there's too much functionality missing
(compared to 3.6) in the current stuff I have, and reduced-functionality
versions may not be distributed either.

Post a reply to this message