"Warp" <war### [at] tagpovrayorg> wrote in message 
news:47d108a8@news.povray.org...
> Severi Salminen wrote:
>> It is just a little faint. Take your favorite photo editing software and
>> tune saturation up. You'll see some bleeding in the right places :)
>
>  I would expect it to be a bit more visible. Compare eg. to:
>
> http://www.winosi.onlinehome.de/Gallery_t14_10.htm
> http://www.winosi.onlinehome.de/Gallery_t14_11.htm
> http://www.winosi.onlinehome.de/Gallery_t14_17.htm

Maybe it would be better to compare with RL ?


-- 
-Nekar Xenos-

Post a reply to this message

Nekar Xenos escribió:
> Maybe it would be better to compare with RL ?

Do you have a room with that shape, some red and green paint, and some 
spheres? Feel free to send pictures :)

Post a reply to this message

"fidos" <fid### [at] wanadoofr> wrote:
> "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.

The same scene but in higher resolution and for 10h on 4 cores of a Intel Q6600.

Fidos.

Post a reply to this message

Attachments:
Download 'illum2.01.jpg' (242 KB)

Preview of image 'illum2.01.jpg'

Nicolas Alvarez wrote:
> Do you have a room with that shape, some red and green paint, and some 
> spheres? Feel free to send pictures :)

http://en.wikipedia.org/wiki/Cornell_Box

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

In Fig. 3.18 we define two local variables, four and twenty (no jokes 
about blackbirds, please).
     -- Jeffrey D. Ullman, _Elements of ML Programming_

Post a reply to this message

nemesis <nam### [at] nospamgmailcom> wrote:
> these are much more impressive:
>
> and this:
> http://www.winosi.onlinehome.de/Gallery_t15.htm
A test of diffuse -> specular light path as in the previous link with MegaPov
montecarlo path tracing.
3h rendering on 4 cores of a Q6600.

Post a reply to this message

Attachments:
Download 'test_06.04.jpg' (75 KB)

Preview of image 'test_06.04.jpg'

fidos wrote:
> A test of diffuse -> specular light path as in the previous link with MegaPov
> montecarlo path tracing.
> 3h rendering on 4 cores of a Q6600.

  It would be nice to see this with a bit of color in it. For example
the light could be color just slightly yellowish, and the sphere could
have a slightly greenish tint to it. Could make a cool image.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> fidos wrote:
> > A test of diffuse -> specular light path as in the previous link with MegaPov
> > montecarlo path tracing.
> > 3h rendering on 4 cores of a Q6600.
>
>   It would be nice to see this with a bit of color in it. For example
> the light could be color just slightly yellowish, and the sphere could
> have a slightly greenish tint to it. Could make a cool image.
Here you are ! With the same rendering time (3 h on 4 cores).

Post a reply to this message

Attachments:
Download 'test_07.01.jpg' (92 KB)

Preview of image 'test_07.01.jpg'

fidos napsal(a):
> Warp <war### [at] tagpovrayorg> wrote:
>> fidos wrote:
>>> A test of diffuse -> specular light path as in the previous link with MegaPov
>>> montecarlo path tracing.
>>> 3h rendering on 4 cores of a Q6600.
>>   It would be nice to see this with a bit of color in it. For example
>> the light could be color just slightly yellowish, and the sphere could
>> have a slightly greenish tint to it. Could make a cool image.
> Here you are ! With the same rendering time (3 h on 4 cores).
> 
> 
> ------------------------------------------------------------------------
> 
It's perfect, I like it!

Post a reply to this message

I had a nasty bug which resulted tens of percents of system time when
doing a 2 thread rendering as opposed to single thread rendering.
(System time means that the CPU cycles are going somewhere else than to
the user process.)

It basically meant that the additional thread (using a Core 2 Duo)
didn't improve the rendering speed at all! And brute force rendering is
supposed to be very easy to make multi threaded.

The reason? The damn random number generator which wasn't thread safe! I
didn't realize that the 2 threads shouldn't access the same RNG. I found
this out after implementing Mersenne Twister and getting segfaults with
2 threads. For some reason the default rand() worked ok, but resulted
the speed loss. Now I give each thread their own RNG and my renderer
scales perfectly by the number of cores. Thread specific RNGs is better
than one shared RNG with mutexes as they slow things considerably down.

You can guess how much I now want the new Intel Q9300 or Q9450 ;-)

Here is a sample image. Basically identical to previous with some small
additions. This was also about a 8h rendering but bigger image and
almost twice the passes -> less noise.

I've also been cleaning and restructuring the code so that I can start
to implement more features. I also received the book I mentioned about.
It is invaluable source of information.

Post a reply to this message

Attachments:
Download 'kuva14.jpg' (111 KB)

Preview of image 'kuva14.jpg'

Severi Salminen wrote:

> I've also been cleaning and restructuring the code so that I can start
> to implement more features.

Oh, one feature would be quite useful in test renderings: let the user
select a rectangular area in the image and the renderer starts to render
only that area until told otherwise. That way the user can quickly get
high quality renders from interesting areas. This should be a piece of
cake implementationally.

Post a reply to this message