Dfidos wrote:
> Hello,
> 
> In order to test the improvement in speed of the use of portal, I rendered again
> the Kitchen scene of Jaime Vives Piqueres (the untextured version). I put a
> sphere emitting light in the room and render it for 1h (on the 4 cores of a
> Q6600 with SMPOV). A portal was superposed to the light.

Is the result identical to a image rendered without the portal feature?

Post a reply to this message

nemesis nous apporta ses lumieres en ce 2008/02/10 14:40:
> hi, fidos!  I modified it a bit to work with current povray methods, radiosity
> and photon mapping.  Just a couple of minutes to render.  Main difference to be
> seen is the glass ball caustic on the floor, which seems to just render the
> pointlight source...
> 
> If anyone is playing with it, I suggest to put FINAL off and render GI 1 and
> PHOTONS 1 at separate passes.  When going to the final render, just turn FINAL
> on.
> 


> #if (1) //(PHOTONS | FINAL)
> light_source
> {
>   y*3+x*3, 1 fade_power 2 fade_distance 3
>   #if (FINAL)
>   area_light x,y,5,5 jitter adaptive 0 circular orient
>   #end
>   photons { reflection on refraction on }
Change the above line to:

photons{area_light}

reflection on and refraction on are not needed, ON by default.
> 
>   looks_like {
>  sphere { 0,1
>     pigment { color rgb 1 }
>     finish { diffuse 0 ambient 1 }
>  }
>   }
> }
> #end
> 


-- 
Alain
-------------------------------------------------
You *know* you've been raytracing far too long when you look at a heap of dirt 
and go "wow, that looks really realistic..."

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> could you give more details about this "portal" feature?

A portal is an area defined by the user. This area is sampled in priority during
the shoot of rays. If a portal is put around a small light source, it will speed
up the evaluation of the direct lighting (for instance for sharp shadows). A
portal on a window helps the rays shooted from inside of a room to reach the
outside lights. A portal around a glass ball may help to build the caustic (but
in these case the results are not so good).

Hope it is clear.

Regards,
Fidos.

Post a reply to this message

Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
> Is the result identical to a image rendered without the portal feature?

It should not change the end results (or the speed up is biased and breaks the
purpose of the montecarlo path tracing). It is only a speed up.

Regrads,
Fidos

Post a reply to this message

The same scene that the previous rendering but with texture. I was quite
disappointed because I leaved it running for 24h on 4 cores and still some
noise remain...

Any comment wellcome.

Regards,
Fidos

Post a reply to this message

Attachments:
Download '2nd-pass.04.jpg' (404 KB)

Preview of image '2nd-pass.04.jpg'

fidos wrote:
> The same scene that the previous rendering but with texture. I was quite
> disappointed because I leaved it running for 24h on 4 cores and still some
> noise remain...

My interested to this subject rose because I also want to make a simple
ray-tracer. Why? Because I can :)

I started my project just to learn C++. I made sphere-plane physics
simulator that works in realtime. (I love those balls bouncing on my
screen :). Now I'm turning it slowly to a brute force raytracer - thanks
to this thread by you. I simply love the idea of brute force rendering:
no need to tweak 30 parameters to get perfect results.

At present I can only draw the balls with one color by finding
ray-sphere intersections. So no lighting at all. But at least it works.

Ok, the question:

How many rays were shot to create your last image? I'm just wondering
how fast the code actually has to be in order to get any feasible
results. So how many rays one wants to shoot per pixel to get bearable
noise.

Thanks.

Post a reply to this message

> How many rays were shot to create your last image? I'm just wondering
> how fast the code actually has to be in order to get any feasible
> results. So how many rays one wants to shoot per pixel to get bearable
> noise.

AFAIK, this algorithm doesn't shoot rays per pixel, really. Just lots of 
rays, and starting from the light.

Note it's not the common "backwards raytracing" like POV-Ray has. This 
is forwards.

Post a reply to this message

Nicolas Alvarez wrote:

> AFAIK, this algorithm doesn't shoot rays per pixel, really. Just lots of
> rays, and starting from the light.
> 
> Note it's not the common "backwards raytracing" like POV-Ray has. This
> is forwards.

I think it actually does shoot rays from camera. The ray shooting
recursive function returns when an emitting surface (or certain depth)
is found. It actually doesn't matter (from physics point of view) where
you start: from camera of from the light as the ray paths are identical.

I think normal raytracers start from camera and go straight from first
intersection to light point. That is the difference here. In brute force
you keep on going (shooting random rays from diffuse surfaces) and you
hope you hit a light at some point. And that is why all light sources
must basically have surface to be able to hit.

Yes, I oversimplified and I'm still a n00b so please correct all the
mistakes.

Post a reply to this message

Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
> Ok, the question:
>
> How many rays were shot to create your last image? I'm just wondering
> how fast the code actually has to be in order to get any feasible
> results. So how many rays one wants to shoot per pixel to get bearable
> noise.
It is a good question but I don't have the answer. I will had a par counter to
keep the number of rays used...

Post a reply to this message

Severi Salminen <sev### [at] NOTTHISsaunalahtifiinvalid> wrote:
> Nicolas Alvarez wrote:
>
> > AFAIK, this algorithm doesn't shoot rays per pixel, really. Just lots of
> > rays, and starting from the light.
> >
> > Note it's not the common "backwards raytracing" like POV-Ray has. This
> > is forwards.
>
> I think it actually does shoot rays from camera. The ray shooting
> recursive function returns when an emitting surface (or certain depth)
> is found. It actually doesn't matter (from physics point of view) where
> you start: from camera of from the light as the ray paths are identical.
I confirm, the start is from the camera, not from light.

> In brute force
> you keep on going (shooting random rays from diffuse surfaces) and you
> hope you hit a light at some point. And that is why all light sources
> must basically have surface to be able to hit.
I can't explain better. A small adding : with the use of portals, the light
source can have null surface (like light point).

Regards,
Fidos.

Post a reply to this message