Hello,

After the read a post about brute force rendering
(http://news.povray.org/web.478286cd8ffe2b1020776f0%40news.povray.org) I
started to play free unbiased renderers (http://www.indigorenderer.com/ or
http://www.luxrender2.org/).

It gives me the idea to patch the source code of MegaPov 1.2.1 in order to
handle Montecarlo Path Tracing.

The modification was surprisingly easy : 2 days for a quick and dirty
implementation without optimisation (only a pure Montecarlo Path Tracing).

Here the first acceptable results with a scene from Tim Nikias
(http://www.nolights.de/).

The lighting is done with a sky sphere with ambiant set to 20.

Any comments welcome.

Regards,
Fidos.

Post a reply to this message

Attachments:
Download 'prep4company_low_test.03.jpg' (122 KB)

Preview of image 'prep4company_low_test.03.jpg'

> Here the first acceptable results with a scene from Tim Nikias
> (http://www.nolights.de/).

Looks very nice, but it would probably be more useful to compare
it with a conventional render (the version on the website seems
to use very different lighting). Also, to compare the render
times between the two version (I assume introducing some
sort of randomness is intended to speed things up?).

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> > Here the first acceptable results with a scene from Tim Nikias
> > (http://www.nolights.de/).
>
> Looks very nice, but it would probably be more useful to compare
> it with a conventional render (the version on the website seems
> to use very different lighting). Also, to compare the render
> times between the two version (I assume introducing some
> sort of randomness is intended to speed things up?).

Here is a rendering with MegaPov 1.2.1 and with the radiosity settings has
provided in the original scene.

For the rendering time, it is around 6 times longer for the brute force
rendering  but there is a lot of rooms for optimisation...

Regards,
Fidos.

Post a reply to this message

Attachments:
Download 'prep4company_low_test_normal.02.jpg' (91 KB)

Preview of image 'prep4company_low_test_normal.02.jpg'

The results obtained are quite impressive, especially for a first 
'quick' implementation. I hope you will show some other renderings with 
different scenes.


Thibaut




> Christian Froeschlin <chr### [at] chrfrde> wrote:
>>> Here the first acceptable results with a scene from Tim Nikias
>>> (http://www.nolights.de/).
>> Looks very nice, but it would probably be more useful to compare
>> it with a conventional render (the version on the website seems
>> to use very different lighting). Also, to compare the render
>> times between the two version (I assume introducing some
>> sort of randomness is intended to speed things up?).
> 
> Here is a rendering with MegaPov 1.2.1 and with the radiosity settings has
> provided in the original scene.
> 
> For the rendering time, it is around 6 times longer for the brute force
> rendering  but there is a lot of rooms for optimisation...
> 
> Regards,
> Fidos.
> 
> 
> 
> 
> ------------------------------------------------------------------------
>

Post a reply to this message

fidos wrote:
> The modification was surprisingly easy : 2 days for a quick and dirty
> implementation without optimisation (only a pure Montecarlo Path Tracing).

So you simply shoot rays in random directions once you hit a surface to 
generate the lighting?

> Here the first acceptable results with a scene from Tim Nikias
> (http://www.nolights.de/).

Yup, I know that scene. ;-)

> The lighting is done with a sky sphere with ambiant set to 20.

How about a different colored skysphere, with a horizon and such? Either 
via a photograph, or just a simple gradient along the y-axis, I'd be 
curious as to how that'd look if the "ground" wouldn't emit white light 
(e.g. just the top dome of the sky-sphere).


> Any comments welcome.

Interesting idea, what are you planning in terms of optimisation? And 
how is your current technique working? Are you shooting several light 
rays per pixel, or are just reiterating the entire scene again and again 
and add up all the results?

Regards,
Tim

Post a reply to this message

Tim Nikias <JUS### [at] gmxnetWARE> wrote:
> > Here the first acceptable results with a scene from Tim Nikias
> > (http://www.nolights.de/).
>
> Yup, I know that scene. ;-)

BTW, Tim.  I've seen this wonderful scene before, just didn't know you released
the source for it!  You are a horrid marketeer!  Allow me to do the googling.

Yes, here it is, a wonderful scene to test lighting schemes full of nice
geometry and materials:
http://news.povray.org/povray.binaries.scene-files/thread/%3C453f8a68%40news.povray.org%3E/?ttop=260158&toff=50

I know you'll like it, Nicolas... ;)

the file comes with suboptimal radiosity settings, I'm playing with it to see if
I can come up with a scene just like the one with path tracing, except for the
noise and rendertime... ;)

Post a reply to this message

> I know you'll like it, Nicolas... ;)

Why? :)

Remember I can't use radiosity on the renderfarm due to the artifacts 
that appear on tiled radiosity renders. Two-pass rendering still doesn't 
make it perfect, and wouldn't be a good idea anyway if the radiosity 
file is too big.

So I tend to just stay away from radiosity here.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> So I tend to just stay away from radiosity here.

well, I guess we're all waiting for it coming out of alfa quality in pov3.7...

Post a reply to this message

> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> So I tend to just stay away from radiosity here.
> 
> well, I guess we're all waiting for it coming out of alfa quality in pov3.7...
> 

I'd just like "deterministic" radiosity. Which means, radiosity that 
doesn't change brightness when rendering in tiles, or resuming a render.

Maybe that will be improved in 3.7, since the multi-threading uses tiles 
internally :)

Post a reply to this message

Tim Nikias <JUS### [at] gmxnetWARE> wrote:
> fidos wrote:
> So you simply shoot rays in random directions once you hit a surface to
> generate the lighting?
Yes
>
> Interesting idea, what are you planning in terms of optimisation?
A good optimisation for a quicher noise reduction is to sample the lights after
projection on the hemisphere surrounding a hit point. An other one is to shoot
in priority on pixel with noise.
> And how is your current technique working? Are you shooting several light
> rays per pixel, or are just reiterating the entire scene again and again
> and add up all the results?
There is no light ray. At each object surface hit, I shoot n x n ray to sample
the hemisphere. When a ray hit a emmisive surface, I return the emmisive value.
The process is recursive and is stopped by the maximum allowed recursion depth
is reached (for the moment the max_trace_level). So only ray that hits a light
source contribute to the pixel color (it is the reason for such noise and so
long rendering time of this technique). The scene is rederered again and again
and the pixel values are accumulated. It is slowly converging, starting with a
very noisy picture.
>
> Regards,
> Tim

Post a reply to this message