www.kraytracing.com

before was with LWF and Reinhard.
Now only gamma 2.2
light source as lumi panel + caustic.

erwin zwart wrote:I made my scene from this data: http://www.graphics.cornell.edu/online/box/data.html

That's where I got the data from to do mine!

On the Cornell box site this is the original box, photograph and render next to each other can be seen here:
... measured photo ............................................................... simulated .........

note the mirror on tall block and some deflector to prevent the lamp light going to the lens of the camera

apparently they made a simplified version of the simulation back then that we all came to be known as THE "Cornell Box" that is shown here:


I made my LightWave scene look like that to try it in Messiah:Render in 2001.
In my earlier post you see the result on my new AMD dualcore, the dualcore computer I (just) had 4 years ago.
I tried a load-and-render of the original 2006 LWS (also included in my attachment) and saw that the rendertime was about 15 secs now (!!!?). So kray has become much MUCH faster itself, even if you halve the original 1core kray 1.6 time because it now uses 2 cores unlike kray 1.6. The old settings do not give the exact same result (many code changes since then) so I did some changes to bring it to 2009 standards:
After that I rendered it on my present computer (Intel Q6600 3GHz quadcore):
I learned a lot about photonmapping back then with this box, like using precomputed modes of kray to check if you have enough photons, cell size and back then we could not blur the maps yet so it was much harder to find a good balance.
What strikes me most now, is that this scene does not use any QLWF and tonemap blending and it just looks right in bounce with just gamma 2.2 on the endresult. But there are no textures to mess up and the colors of the walls and lamp are reverse engineered by me based on the original. Please all have a go with PM instead of LM and using lumi quad instead of arealight and QLWF and tonemap blending with other surface and light settings to see what happens. Enjoy!

He he "dot the i" 6 sec.

...and my 3 sec....

Johny_quick wrote:...and my 3 sec....

I won't be happy until you get it under 1 sec Johny!

Johny_quick wrote:...and my 3 sec....

looks like crap.. , see contact shadows of low box, just render my scene on your 8 core and it should take also 3 sec and look good.
I can make it faster but not without loosing accuracy.

erwin zwart wrote:

Johny_quick wrote:...and my 3 sec....

looks like crap.. , see contact shadows of low box, just render my scene on your 8 core and it should take also 3 sec and look good.
I can make it faster but not without loosing accuracy.

OK i give You 1 sec more....

They are still floating though..
Got to check how Erwin did it in 6.. thanks for putting the scene up.


Anyone of you do the current CgTalk lighting challenge?

Erwin, just found the time to check your scene and I'm impressed. Contact shadows are there and it holds up at 200% resolution quite well too. I don't get why you mix 35% light with a lumi poly... why do 2 at the same time? I can surely see that it looks alot worse when the light is turned off.. but... why? Why not go full on the area light and just have the lumi at 100% to make it white but not much more..?

I thought I understood PM a bit, but I don't I guess..
Photon map shoots from lights, Lightmap shoots from camera (nice confusion there )
All fine and all, but for instance your photonmap in that scene looks quite splotchy, but apparantly that matters very little... My issue was that I tried to make the photonmap look like the end result I guess.. Which apparantly is not really necessary..

I read a few things I could find around the net, but does anyone have a good "must read" on what Photonmap GI technique actually tries to do?

Jeroen wrote:Erwin, just found the time to check your scene and I'm impressed. Contact shadows are there and it holds up at 200% resolution quite well too. I don't get why you mix 35% light with a lumi poly... why do 2 at the same time? I can surely see that it looks alot worse when the light is turned off.. but... why? Why not go full on the area light and just have the lumi at 100% to make it white but not much more..?

I thought I understood PM a bit, but I don't I guess..
Photon map shoots from lights, Lightmap shoots from camera (nice confusion there )
All fine and all, but for instance your photonmap in that scene looks quite splotchy, but apparantly that matters very little... My issue was that I tried to make the photonmap look like the end result I guess.. Which apparantly is not really necessary..

I read a few things I could find around the net, but does anyone have a good "must read" on what Photonmap GI technique actually tries to do?

It does just what you said. It shoots photons from the lightsources. It is only approximation of global illumination for secondary bounces. Splotchines of photon map can influence final result but only if the difference between splotchess is big. Small difference won't matter much.

Did you read this?

Sure I read that, but it is still a tad vague. Other sources I found were too much in depth, with emphasis on the math..
I'll try to find some better in between description when I get the time, thx.

Jeroen wrote:Erwin, just found the time to check your scene and I'm impressed. Contact shadows are there and it holds up at 200% resolution quite well too. I don't get why you mix 35% light with a lumi poly... why do 2 at the same time? I can surely see that it looks alot worse when the light is turned off.. but... why? Why not go full on the area light and just have the lumi at 100% to make it white but not much more..?

(back from holidays and a very busy first 1,5 workweeks)
thanks, kray is indeed impressive huh. I am sorry I confused you, I unchecked the Lamp LWO (lumi quad) in Scene Editor, so it does not affect the result. It is in there to be able to compare lumilight with arealight for playing around.
Try to set Arealight to 0% and check Lamp on, then you see what happens to the photonmap.... much worse in Lightmap mode, then try that in Photonmap mode.

Jeroen wrote:I thought I understood PM a bit, but I don't I guess..
Photon map shoots from lights, Lightmap shoots from camera (nice confusion there )
All fine and all, but for instance your photonmap in that scene looks quite splotchy, but apparantly that matters very little... My issue was that I tried to make the photonmap look like the end result I guess.. Which apparantly is not really necessary..

I read a few things I could find around the net, but does anyone have a good "must read" on what Photonmap GI technique actually tries to do?

http://en.wikipedia.org/wiki/Photon_mapping does describe it pretty good.
http://graphics.ucsd.edu/~henrik/papers ... egwr96.pdf this is the mother of GI using PM, it is pretty deep, but if you read the first chapters and read around the formulas, you will get it.

see also figure 3 and 4 in this pdf , there you see that the photonmap does not have to be supersmooth to get a smooth endresult. The most important is that you don't get sharp-contrast large noise.
In kray in PM mode photonmaps are more smooth than in LM mode, but in LM mode it is easier to get (enough) photons in the camera viewing area.
Just try a lot of stuff with this Cornell box scene, because is basically a prototype of a room with a lamp or window and it teaches you a lot about GI res and shadows and where it goes wrong in contact shadows. (see Johny_quick's fruitless attempts to improve AND speed up my settings )

Because of this thread I also used the scene to test BNR farm rendering of hires stills.

I found that I get a very nice 4800x4800 result with splitting the frame in horizontal slices in BNR.
http://www.xs4all.nl/~ezwart3d/kray/Cor ... 20copy.jpg
For that I did Save a Shared GI file in Photons Estimate mode with Precomputed option in 480x480 res. That is a very fast preprocess and stores a photonmap in a file. This way all my quadcore nodes start with same photonshoot (that differs slightly every time you start kray in Independent mode) and this prevents seeing a difference in GI at the slice edges. I used a slight overlap in BNR because I saw 1 pixel black lines if I did not. Will report this to Paul Lord of BNR.
I rendered in Photonmapped Uncached (QMC) with FG min 200 max 800 with Shared GI file on Load after that on 10 different quads.
When you want to use Cached, it takes more time to generate and store a very fine FG sample grid (like in flying cam animation mode) on one system, I think I prefer rendering such stills in QMC, because there you have always right contact shadows and distribute the largest part of the computing time over the whole farm.

Erwin - I have sent you a PM, I would be really grateful if you could take a quick look right away!