sooperFoX wrote:

> Now I will try your scene again Severi with just Path Tracing (no MLT). I
> already tried it using BiPT overnight (8 hours) and still there was a noisy
> black area in the middle of the green glass boxes that was taking a long time
> to go away (where they overlap the most).


Naive question here, but do any of the existing unbiased renderers out 
there have any method that either a) kicks in at a certain point to try 
to detect noise and send a disproportionate number of rays into noisier 
parts of the image, or b) takes optional user input (even mid-render) 
and doing likewise?
Charles

Post a reply to this message

Warp wrote:

>> Do you know how it compares to Mersenne Twister speed-wise?
> 
>   Unfortunately I don't. However, I believe this RNG to be very fast,
> especially taking into account the high quality of the results.

Thanks for the code! Quick test shows that the two RNGs perform almost
identically. So I don't think I have a strong need to change the RNG.
Also the SFMT looks very promising:

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html

It should be a lot faster than basic MT which I'm using. But most likely
the random number generation is not a bottleneck anymore.

Post a reply to this message

Charles C wrote:
> b) takes optional user input (even mid-render) and doing likewise?

  That would be cool. If some part of the image is extra noisy, click
there and the renderer will then send more rays near that point. :)

Post a reply to this message

Charles C wrote:
> sooperFoX wrote:
>
> > Now I will try your scene again Severi with just Path Tracing (no MLT). I
> > already tried it using BiPT overnight (8 hours) and still there was a noisy
> > black area in the middle of the green glass boxes that was taking a long time
> > to go away (where they overlap the most).
>
>
> Naive question here, but do any of the existing unbiased renderers out
> there have any method that either a) kicks in at a certain point to try
> to detect noise and send a disproportionate number of rays into noisier
> parts of the image, or b) takes optional user input (even mid-render)
> and doing likewise?
> Charles

Yes, MLT (Metropolis Light Transport) spends most of its time doing the
"difficult" areas and is best for interior scenes that are lit mostly by
indirect light. You can set up a room that has only a very tiny crack in the
wall and the light on the other side of the wall, and it will find its way
through. MLT works on top of path tracing or bi-directional path tracing.

It does not take user input at any time, though.

As far as I know, Kerkythea is not the only renderer to support MLT. There is a
Java renderer called SunFlow which does the same, and there may be others.

Post a reply to this message

"sooperFoX" <bon### [at] gmailcom> wrote:
> Severi Salminen wrote:
> > You don't have to post the image but it would be interesting to know how
> > quickly Kerkythea renders the same image with pure path tracing to about
> > the same noise levels as my image.
>
> Rendering now on 3 cores across 2 machines.

> We will see :)

Well, here we are. After rendering for 11 hours we have an interesting result -
the black area did not go away! There is still also some noise left.. Your
renderer wins, Severi!

Unless I have just not set it up right. But I think the defaults specify 100
bounces...

I thought I would post the pic anyway so you can see what I'm talking about..

Post a reply to this message

Attachments:
Download 'kuva11_pt_11h.jpg' (100 KB)

Preview of image 'kuva11_pt_11h.jpg'

Severi Salminen wrote:
> Thanks for the code! Quick test shows that the two RNGs perform almost
> identically. So I don't think I have a strong need to change the RNG.
> Also the SFMT looks very promising:
> 
> http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html

  That's odd. I tested that and the isaac rng in identical conditions
(and compiled with g++ -O3 -march=prescott), and while the isaac rng was
able to generate 168 million numbers per second (with RANDSIZL=5), that
sfmt was only able to generate 81 million numbers per second. Still
considerably faster than std::rand(), but considerably slower than isaac.

  Maybe I didn't compile or use it right. OTOH, the isaac rng is that
fast without any special compiler fine-tuning, just a straightforward
optimized compilation.

> It should be a lot faster than basic MT which I'm using. But most likely
> the random number generation is not a bottleneck anymore.

  OTOH, using the fastest possible (high-quality) rng doesn't hurt
either. :)

Post a reply to this message

"sooperFoX" <bon### [at] gmailcom> wrote:
> Nicolas Alvarez wrote:
> > Also, could you please test this one? :)
> > http://www.winosi.onlinehome.de/Gallery_t14_01.htm
>
Interesting test scene. There is a PovRay version on the web site.
Here a rendering of 1h on one core of a Q6600 2.4 GHz with my MegaPov Montecarlo
Path tracing patch. Noise is important but there is no spikes.

Fidos

Post a reply to this message

Attachments:
Download 'illum2.jpg' (142 KB)

Preview of image 'illum2.jpg'

these are much more impressive:

total internal reflection:
http://www.winosi.onlinehome.de/Gallery_t13.htm

and this:
http://www.winosi.onlinehome.de/Gallery_t15.htm

Post a reply to this message

> these are much more impressive:
> 
> total internal reflection:
> http://www.winosi.onlinehome.de/Gallery_t13.htm
> 
> and this:
> http://www.winosi.onlinehome.de/Gallery_t15.htm

I posted Gallery_t14_01.htm because it has a dozen rendered images for 
comparison, and source available in a dozen formats too.

But in terms of impressiveness, Gallery_t15.htm sure wins :)

Post a reply to this message

sooperFoX wrote:

> Well, here we are. After rendering for 11 hours we have an interesting result -
> the black area did not go away! There is still also some noise left.. Your
> renderer wins, Severi!

W000t! Where can I get my prize? :-)

Few thoughts:

1. My program has no depth limit at all. Only a probability that a ray
will die/get absorbed when bouncing. So every now and then a ray might
bounce many times. A hard-coded depth limit induces some bias. 100
bouces, however should be enough.

2. What was the actual color value you specified for the green glass?
Maybe the glass is so dark that multiple layers simply don't let enough
light through?

3. My image seems to have less noise on the table and more noise on the
floor. Maybe on average they are on par. Anyway, I rendered one 1
core@3GHz for 8h. But then again, my renderer lacks many important
features which _might_ slow the renderer down when implemented.

4. Even small changes in the scene can alter the noise levels quite a
bit. Especially the light source size has a big impact on noise/time
figures.

So this is not very scientific result. At some point I'll make a better
test scene and post the dimensions. Or anyone else can do it. Maybe in
Pov-SDL so we can compare results from it too. And we can keep this even
remotely on-topic :-)

Post a reply to this message