appleseed Users Forum

Lambertian Computation Problem (hit light shape)

In The Cornell Box Scene, there is one path as following image shows:
the yellow line is direct sample line. All material is BRDF material.
In my understanding, the process is :

the ray starts from eye, and hit tall box and then bounce to right wall and then to top roof and hit the cube light shape in top roof. But it do not stop!! It still bound from light shape to the right wall and in the end sample direct light from light shape to the hit point at right wall.

that is, the process is : 1->2->3->4->5

So , in this process the light shape is treated as normal lambertian material and bounce as normal object in my opinion.

I sample 1 each pixel, and all are lambertian, So I think

   radiance_out  = radiance_in * albedo 

and this works for other hit points. for example , the tall is white material, which is white

white: (0.737471521 g=0.738432944 b=0.738591731 )

the ratiance from 2 to 1 point is

radiance_in = (0.000767, 0.012300, 0.000171)

so the radiance from 1 to eye is

radiance_out = radiance_in * white = (0.000565, 0.009083, 0.000126)

the same process is correct for 3->2 and 2->1

but, the process is not correct for 4->3 and 3->2. the radiance from 4->3 is

radiance_in = (0.012569, 0.040196, 0.002296)

3 hit point is light and the BSDF is lambertian and reflectance is white, so radiance from 3 to 2 hit point should be

raidance_out = radiance_in * white =(0.012569, 0.040196, 0.002296) * white 
= (0.0092,0.0296,0.00169)

but the result from 3 to 2 is

radiance_real = (0.011293, 0.030782, 0.001987)

So, this is strange, the real radiance is bigger than what I computed. What is the problem of my computation?

I know next event estimation, but I am sure 4->3 and 3->2 is not next event estimation, 5->4 is next event. So this is not light sample problem

In the top images the rays are difficult to follow.

You should get in contact with Fusha on our Discord. He implemented a much improved ray visualization system for his GSoC project. Rays can be filtered with Light Path expressions and colored according to radiance and have variable transparency.
The code to build is on GitHub but not yet merged into appleseed-master.

See here for an illustration.

Hey! I do believe this is indeed a bug–one that I fixed near the beginning of GSoC! Depending what commit your build of appleseed is from, this commit may not have been merged yet… or there might still be a bug somewhere


Oh really? I have seen many books and articles and can not find teh reason. I am thinking reproduce the process the see the detailed code of computing this value. If you think this is a bug, Then what do you think the the problem of my quesion. For brevity:

1.the radiance from 4->3 is

radiance_in = (0.012569, 0.040196, 0.002296)

this the value show in the log info when I click some pixel
2. the radiance from 3->2 is

radiance_real = (0.011293, 0.030782, 0.001987)

this is the value in the log info when i click the pixel

But as I say , The light is white material and reflectance is

white: (0.737471521 g=0.738432944 b=0.738591731 )

And Sample number is 1, so the radiance shoule be

raidance_out= radiance_in * white = (0.0092,0.0296,0.00169)

which one do you think is wrong? radiance_out that i computed or radiance_real that shows in the log?

PS: I see some results, seems only indirect light that hit the light source have some problems

Okay so the way that the radiance at each vertex of the light path is computed is separate but linked to the main path tracer which creates the final image. As the main path tracer is working, it records some intermediate values; these go from the camera to the light, i.e. in reverse order. In order to compute the proper radiance at each part of the light path we need to go through and instead trace from the light to the camera in the forward direction, and add up contribution as we go. This is done in this file:

Now, before the pull request I linked above, the case where an object was both a reflector and an emitter was not handled, but only in the light path tracing code, not the main path tracer. That case would just be treated as a regular reflector, and as such it exhibits the behavior you’re seeing. However, with that pull request, I added this code into each of the event types which accounts for the possibility of there being a reflector which is also an emitter, and properly adds the radiance as it should.