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

Nicolas Alvarez wrote:

>> and this:
>> http://www.winosi.onlinehome.de/Gallery_t15.htm
> 
> But in terms of impressiveness, Gallery_t15.htm sure wins :)

True. But in the world of brute force renderers that is not _that_
impressive - quite impressive still. As all sources of light rays are
equal it is no wonder that we see regularly diffuse caustics and other
similar indirect effects. Light is always considered light - no matter
where it came from. This is the basis of all those very realistic images.

The same way I remember the time when 3dMax didn't know how to render
refraction or similar "simple" effects and POV-Ray could do it. After
using POV for quite some time it doesn't feel _that_ impressive :)

Ok, I admit it: it is quite impressive.

Post a reply to this message

> True. But in the world of brute force renderers that is not _that_
> impressive

You still haven't shown me your renderer do it >:)

Post a reply to this message

Severi Salminen wrote:
> Hmm. What kind of "interesting ideas" you mean? Do you have any links to
> sample images?

Here's the thread that gave me the idea:
http://news.povray.org/povray.binaries.images/thread/%3Cweb.4360929f30852916731f01d10@news.povray.org%3E/?mtop=10

Currently, there's a cap on how big things can be in Povray. More 
importantly, there's a limit on putting big things and little things in 
the same scene.

With high-precision geometry, you are free to model entire solar systems 
to scale. With arbitrary-precision geometry, you could model entire 
galaxies to scale! :-D

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

Now we know everything there is to know about ML, except how to program!
     -- Jeffrey D. Ullman, _Elements of ML Programming_

Post a reply to this message