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

> 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.

This one has 4:3 ratio -- will work much better for wallpaper.

*changes wallpaper from kuva11 to kuva14*

Post a reply to this message

> 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.

This was a definite keeper. Works quite well in practice. See the image.
(Don't mind the odd noise. Image is scaled so the noise looks odd.)

Now I can select areas of interest and let the program render only that
area.

Post a reply to this message

Attachments:
Download 'kuva15.jpg' (187 KB)

Preview of image 'kuva15.jpg'

Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
> > 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.
>
> This was a definite keeper. Works quite well in practice. See the image.
> (Don't mind the odd noise. Image is scaled so the noise looks odd.)
>
> Now I can select areas of interest and let the program render only that
> area.

Fantastic!

Makes me want the QX9650 even more ;) But it's $1200.00 just for the CPU
alone...!! :O


You know that feature you just implemented would be great for when a render is
almost done but there are still 1 or 2 noisy areas (e.g. caustics, or in a dark
corner) and you could concentrate all the power just on that section -
brilliant!

By the way I've been meaning to ask you - where does the interesting striped
reflection in the pink glass box (next to the yellow/gold sphere) come from? I
couldn't replicate that when I tried to recreate your scene last time.

Regards,
sooperFoX

Post a reply to this message

sooperFoX wrote:
> Fantastic!
> 
> Makes me want the QX9650 even more ;) But it's $1200.00 just for the
> CPU alone...!! :O

True. But 9300 and 9450 are quite cheapish already :) I just wonder if
it is stupid to spend 300 euros just because one single program needs
the additional cores...naaah :)

> You know that feature you just implemented would be great for when a
> render is almost done but there are still 1 or 2 noisy areas (e.g.
> caustics, or in a dark corner) and you could concentrate all the
> power just on that section - brilliant!

I think so too. And in the test phase you can just render the
interesting objects without spending time on large uninteresting
surfaces - without the need to alter camera/image size settings. It
would also be easy to assign different areas for different threads. But
even this is usable now.

> By the way I've been meaning to ask you - where does the interesting
> striped reflection in the pink glass box (next to the yellow/gold
> sphere) come from? I couldn't replicate that when I tried to recreate
> your scene last time.

The pink tower is made of 6 smaller boxes which have just a small gap
between them. They also get "pinker" downwards. So it must be total
reflections/refractions the individual pieces cause. (If my code is
calculating them properly...).

Post a reply to this message

Back again!

I've been refactoring and restructuring the code. It takes time to
figure out what is "the best" program structure. And I'm sure I'll
restructure it many times more later on.

Still missing transformations and acceleration structures - which both
are desperately needed. I also improved the UI code and now it works
perfectly. The UI thread now takes only minimum amount of CPU time and
thus doesn't slow the rendering down at all. And is still responsive enough.

I did implement one cool new feature: Depth of Field. It works just as
in real life (well, I don't model complete multi-element lenses...).
There is a virtual lens and all rays are cast through random points of
it based on aperture size and focal distance. So the result is very
realistic. Now the aperture is a conventional circle but it would be
quite easy to implement other kinds of apertures which look like actual
lens apertures. See the sample image below. (There is another DOF image
on the webpage.) The implementation was, again, very easy with no "side
effects" at all.

I also setup a webpage about this program (it is called "ssRay" at the
moment ;-). All the images are shown there:

http://www.saunalahti.fi/~sevesalm/ssRay.html

Post a reply to this message

Attachments:
Download 'kuva.jpg' (55 KB)

Preview of image 'kuva.jpg'

Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
>
> I also setup a webpage about this program (it is called "ssRay" at the
> moment ;-). All the images are shown there:
>
> http://www.saunalahti.fi/~sevesalm/ssRay.html

Love the evolution!  Very impressive.

 - Ricky

Post a reply to this message

Severi Salminen wrote:

> I also setup a webpage about this program (it is called "ssRay" at the
> moment ;-). All the images are shown there:
>
> http://www.saunalahti.fi/~sevesalm/ssRay.html

I'd really really really love to see the code... :)

Ray

Post a reply to this message