> p.s. I've uploaded a sample image to:
>
> http://ray.bellis.googlepages.com/mc-balls-01.jpg
>
> A lot of the noise on that image is from the JPG compression.  This is from
> 1.75 hours of rendering on a MacBookPro (Core2Duo)

Nice! Maybe no accurate but the results look good. If you want better, see this:

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

(I have not implemented them yet, but some people use Blinn or Cook...) Anyway,
good that I'm not the only one interested in this madness :)

Post a reply to this message

Severi Salminen wrote:

> Ok, I'll try. Let's assume we have found the first intersection point
> along the ray. Instead of choosing a random new direction (if it is a
> diffuse surface) you can do this:
>
> 1. Pick a random point on a light source.
> 2. Check if it is visible or not.
> 3. If it is, add the radiance it contributes. You must take the
> cosine term into account as well as the ratio of solid angle of the
> source and hemisphere (the last one thus handles the distance of the
> light source).
> 4. After this you can continue tracing the path normally. But if the
> ray next hits the same light source, ignore it as otherwise you have
> calculated it twice.

Do you still trace some random diffuse rays too?  Otherwise how do you end 
up with diffuse inter-reflection?

In either event the maths sounds pretty tricky :(

It also appears to mean that you need to treat your light sources 
differently to normal objects.  At the moment my light sources are just 
high-ambient primitives.

Ray

Post a reply to this message

> Nice! Maybe no accurate but the results look good.

Thanks :)

> If you want better, see this:
>
> http://en.wikipedia.org/wiki/Specular_highlight

> (I have not implemented them yet, but some people use Blinn or
> Cook...)

I'm familiar with Phong, but I've not used any of the others.

Curiously these models all seem to describe ways to approximate the 
resulting light intensity fall-off for direct ray-tracing to light sources.

None of them seem to describe methods to actually perturb the normal to 
directly simulate micro-facets.

Hence my method (whilst not strictly accurate) produces blurred reflections 
of the entire scene, and not just specular reflections of the light sources.

I guess that's the advantage of the Monte Carlo method - if you're going to 
cast millions of rays you can afford to average out the results numerically, 
rather than use a mathematical approximation.

> Anyway, good that I'm not the only one interested in this
> madness :)

Indeed.

I'd also be happy to share my code...

Do you happen to have the geometry of your sample images available?  I'd 
like to try to create the same scenes to compare results.

cheers,

Ray

Post a reply to this message

> > 4. After this you can continue tracing the path normally. But if the
> > ray next hits the same light source, ignore it as otherwise you have
> > calculated it twice.
>
> Do you still trace some random diffuse rays too?  Otherwise how do you end
> up with diffuse inter-reflection?

Yes, that is the step 4 above. After you evaluate direct lighting component you
can continue normally to random direction. And at the next intersection you do
the same steps again. We definitely want to have global illumination...

> In either event the maths sounds pretty tricky :(

It is not really _that_ tricky. But I needed a pencil and a piece (or 2) of
paper to figure out how to calculate the solid angle thingy. And how to take
the object color into account during this incremental path creation.

> It also appears to mean that you need to treat your light sources
> differently to normal objects.  At the moment my light sources are just
> high-ambient primitives.

Yes, that is correct. The renderer has to have a list of light sources. I also
did first what you do now: light sources are normal objects with emission. And
all images on my page are rendered that way. This "new" method is great because
it improves speed so much. It is worth implementing.

Post a reply to this message

Severi Salminen wrote:
>> * Instead of shooting RGB rays, shoot photons of a particular wave
>> length, selected randomly from the spectrum of the light source at the
>> emission point;
> 
> Yes. This should be implemented at some point to enable accurate dispersion.

I should say that the weakness of this approach is that a surface that 
is supposed to be a uniform color will now appear to be a mixture of 
pixels that average to that color.

>> * A photon isn't drawn on the screen unless it hits the virtual film.
>> Then you calculate its RGB value, and add that to the pixel at that
>> point in the screen.
> 
> I start the rays from film plane so all rays always hit the film. I'm not sure
> if anyone does it the other way and how it works in practice.

So it traces from 'film' to light source, instead of the other way 
around?  I had assumed that it went the other way.  Maybe I could try 
writing a renderer that does that.

Regards,
John

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> > Yes. This should be implemented at some point to enable accurate dispersion.
>
> I should say that the weakness of this approach is that a surface that
> is supposed to be a uniform color will now appear to be a mixture of
> pixels that average to that color.

Then you just have to give it a few more days to render and the variance will go
away :-)

> > I start the rays from film plane so all rays always hit the film. I'm not sure
> > if anyone does it the other way and how it works in practice.
>
> So it traces from 'film' to light source, instead of the other way
> around?  I had assumed that it went the other way.  Maybe I could try
> writing a renderer that does that.

Join the crowd! If you start from light sources you have to have some clever way
to get the rays inside camera view angle and then hit the camera. The other way
around you have to make them hit the light sources eventually. Both are
plausible but I have no idea how to prevent from shooting totally unnecessary
rays (ie. those just misses the camera) with the first method.

Post a reply to this message

John VanSickle nous illumina en ce 2008-09-13 23:53 -->
> Severi Salminen wrote:
>>> * Instead of shooting RGB rays, shoot photons of a particular wave
>>> length, selected randomly from the spectrum of the light source at the
>>> emission point;
>>
>> Yes. This should be implemented at some point to enable accurate 
>> dispersion.
> 
> I should say that the weakness of this approach is that a surface that 
> is supposed to be a uniform color will now appear to be a mixture of 
> pixels that average to that color.
> 
>>> * A photon isn't drawn on the screen unless it hits the virtual film.
>>> Then you calculate its RGB value, and add that to the pixel at that
>>> point in the screen.
>>
>> I start the rays from film plane so all rays always hit the film. I'm 
>> not sure
>> if anyone does it the other way and how it works in practice.
> 
> So it traces from 'film' to light source, instead of the other way 
> around?  I had assumed that it went the other way.  Maybe I could try 
> writing a renderer that does that.
> 
> Regards,
> John
> 
> 
All ray tracers go from the camera to the objects in the scene then to the light 
source(s). It's called backward ray tracing. Much more effecient that way.

-- 
Alain
-------------------------------------------------
If That Phone Was Up Your Butt, Maybe You Could Drive A Little Better!

Post a reply to this message

Alain wrote:

> All ray tracers go from the camera to the objects in the scene then to
> the light source(s). It's called backward ray tracing. Much more
> effecient that way.

Actually, many raytracers do a hybrid: they start simultaneously from
camera AND lightsource. At least bidirectional path tracing works like
that. They then connect the paths somewhere in between. That seems very
promising technique.

Post a reply to this message

Severi Salminen wrote:
> Alain wrote:
> 
>> All ray tracers go from the camera to the objects in the scene then to
>> the light source(s). It's called backward ray tracing. Much more
>> effecient that way.
> 
> Actually, many raytracers do a hybrid: they start simultaneously from
> camera AND lightsource. At least bidirectional path tracing works like
> that. They then connect the paths somewhere in between. That seems very
> promising technique.

I saw one that starts from the light sources (which are high-ambient
objects) bouncing rays around. When the rays hit objects, the "hits" are
saved in a buffer. When the buffer gets full, it does a normal backwards
raytracing (from the camera), collecting the buffered hits near the
intersection point of the bw-raytracing ray. Then the buffer is emptied and
process repeats.

Post a reply to this message

Severi Salminen wrote:

> Join the crowd! If you start from light sources you have to have some clever way
> to get the rays inside camera view angle and then hit the camera. The other way
> around you have to make them hit the light sources eventually. Both are
> plausible but I have no idea how to prevent from shooting totally unnecessary
> rays (ie. those just misses the camera) with the first method.

I would probably set the renderer so that after so many reflections, the 
current ray origin is tested to see if it is in the camera view.  If so, 
reflect the photon directly at the camera.  Otherwise, cancel the 
photon.  It probably won't help much, but it could help a bit.

The real weakness of the whole approach is that for animation work, the 
rendering has to be allowed to go on until the graininess is gone, and 
there isn't a reliable way to predict that.

Regards,
John

Post a reply to this message