The Cornell Box Diaries

[TheDunadan]

On the noise problem... I might be terribly wrong here, but usually there is something like "photon radius". I know from Mental Ray that renders can turn out terribly noisy if the photon radius is too small,... I'd be very surprised if Mantra hasn't got a similar option. Have you tried playing around with these settings yet ?

Btw. Does anyone know if ray-labels are planed for mantra or already available in H7 ? They could make life much easier I reckon

Jens

[Marc]

I believe the 'photon sampling' setting is the radius. I could, however, be mistaken.

M

[Jason]

From my previous experience with Irradiance Caching - unless you blow away your cache file, nothing you ever do will change the sampling quality of the irradiance rays.

BEWARE THE CACHE, MY FRIENDS.

[Mario Marengo]

On the noise problem... I might be terribly wrong here, but usually there is something like "photon radius".

... I'd be very surprised if Mantra hasn't got a similar option.

13815[/snapback]

You know what?... strange... I haven't used GI in Mantra yet (did quite a bit of it with Entropy back in the day), and I can't check this out right now (swamped with work), but I don't think there is a gather radius for irradiance. I'm pretty sure there is for photons (from looking at the images), but for irradiance?.... nnnnnnn-I-don't-think-so... could it be?!?

I certainly don't see it as an option for the irradiance() function. There is an error metric in the ROP, but that's not the same; and number-of-samples is definitely not the same as a gather radius... very strange...

It should be pretty trivial to scatter a few thousand points in the scene as a point cloud, call irradiance() on each one, and do your own filtering over a given radius (the occlusion sample shader that Mark E. submitted does this with occlusion(), and the SS shaders do something similar as well). I'd imagine it should render pretty fast and not look that noisy...

Mario Puzzled-In-Toronto Marengo.

[Marc]

Well I must say I'm a little confused at this point too. To generate the photons (by the millions) takes a very short amount of time.

And as far as I know, all the renderer does is exactly that, raytrace the scene and filter the photons over a determined radius. I don't see why the filtering process takes so amazingly long... But then I am definitely a noob when it comes to render theory.

Ciao

M

[hoknamahn]

It's not truth what Mantra can't handle both photon mapping and irradiance or occlusion in one shader. We can calculate both and add or multiply them.

Photon gather radius in Mantra is a Photon Error Estimate parameter.

[Marc]

Day 4 update :

Here is my rendered image with both irradiance and photons in the same shader. Only one GI light. You'll notice that it's different from the one where there are two shaders with two lights.

The extra light shouldn't make a difference since it's not contributing any light into the scene.

So, granted.. it does work. It just returns different results.

M

[Mario Marengo]

So, granted.. it does work. It just returns different results.

13830[/snapback]

Damn! I wish I had some time to play with this stuff... but looking at the images, I'm curious: this last one is darker (less indirect lighting) due to? ... not as many photons/samples? or because of the all-in-one shader method? -- I'm comparing it to the last "double-shader-and-expensive" one you posted; and for a "Full GI" image, it's missig a great deal of; well... GI

<e.g: shouldn't the ceiling reflection on the chrome ball be brighter?... and the shadows lighter... feels like it's missing a chunk or something...>

Photon gather radius in Mantra is a Photon Error Estimate parameter.

This error estimate is specific to photons, and not related to the ROP's "Default Error" parameter for the irradiance cache, correct?

My initial puzzlement had to do with not finding (which doesn't mean they are not there) any obvious hooks to filter the result of an irradiace calculation (not photons). Is there an "Error Estimate" hidden somewhere masquerading as a radius control for irradiance? For that matter, which Error Estimate control are you referring to?

Great stuff, Marc. Thanks! This should keep all of us Mantra-GI-nOObs, from having to re-invent the wheel^H^H^H^Htests

Cheers!

[Marc]

Damn! I wish I had some time to play with this stuff... but looking at the images, I'm curious: this last one is darker (less indirect lighting) due to? ... not as many photons/samples? or because of the all-in-one shader method? -- I'm comparing it to the last "double-shader-and-expensive" one you posted;

13832[/snapback]

The settings were identical the only difference being all in one vs seperate shaders/lights. I have no idea why they're different other than assuming that mantra interprets the photon/irradiance contribution differently if they're in one shader as opposed to seperate shaders.

and for a "Full GI" image, it's missig a great deal of; well... GI

13832[/snapback]

Yeah, isn't it? I don't know what's going on. I'm now doing tests without the sphere's to see if I can get some nice GI lighting in the room on its own. I would expect to see some colour bleeding from the red and blue walls.. but I'm not getting anything at all.

Great stuff, Marc. Thanks! This should keep all of us Mantra-GI-nOObs, from having to re-invent the wheel^H^H^H^Htests

13832[/snapback]

No problem . I may neaten this up into a tutorial of sorts. I know for sure that I'm going to need to go over it if I ever need to do some GI in mantra .

M

P.S. Does anyone know how much easier this kind of stuff is in other renderers (lightwave, entropy, mentalRay)?

Or are they all as finicky?

[Marc]

sigh.... I found the culprit

I neglected to turn off the consolidate points option in by cornell box. Hence the shading on the box itself is all wacky.

I'll do a few more renders and see how they turn out.

M

[hoknamahn]

Mario, yes Photon Error Estimate is a parameter for photon functions.

But I can't understand what is it "radius for irradiance" (if it's not an Error in Mantra's cache). Can you describe this method?

I would expect to see some colour bleeding from the red and blue walls.. but I'm not getting anything at all.

Maybe you set wrong parameters for the Russian Roulette?

Once I made a series of the tests with photon mapping. But so I did not reach the ideal result.

This pic made with one cone light without shadows and with photon maps.

Hummm... A problem with use photon mapping when it it is used for the global illumination in animation is flickering. Who knows, how to avoid it?

[TheDunadan]

I didn't read all the text of Marc properly yesterday and thought the noise was resulting from the caustics... that's why I suggested increasing the radius. :whistling:

On the lack of more obvious indirect illumination: There are two things that I noticed:

- in the real world, there is way less color bleeding than we might want to see for artistical reasons (and I'm not overly keen on it either really), but increasing the global tint intensity to something like 5 while decreasing the actual light intensity down, will result in very smoothly lit images with lots and lots indirect light (more similar to the ones of H. Jensen)

- the input geometry: at least the algorithms for GI/radiosity that I know usually first subdivide the geometry. If the algorithms works well, we have a fine (internally) tesselated geometry in the areas where we see lots of changes in the illumination and less where the lightening stays more or less the same. Anyhow, houdini seems to have some problems here: Subdividing the cornell box so that each side consists of 100 polys helps really and we see the color bleeding etc. Maybe someone with more indepth knowledge on mantras implementation can help us here a bit better

- If possible I'd much rather create a seperate simple cone light instead of the arealight for the GI part

Following Mario's suggestion using point clouds with filtering sounds to me like the best way really and can likely save us from those typical animation flickering

Jens

[Marc]

Well its all a bit of a shambles at the moment.

But here is Day 5's update :

After realising that my cube was rendering incorrectly I uniqued the points and then tried it all again.

Image1 is just photon mapping with no colour bleed (no photon shaders on the box itself). Image2 is the same thing but with photon shaders assigned to each wall to allow colour bleeding.

I had a really pretty version of it rendering with full GI and photons (with bounce) rendering, but I turned my GI sampling up way too high and it was still rendering this morning.

I'll put another one on and see how it goes, I'll post it here if it's worth it.

M

[Marc]

Day 6 : The end

Well it's been a crazy ride. Sadly, all good things must come to an end, and so too must the Cornell Box Diaries be closed. Who knows though, one day I may feel inspired to again pick up the pen and begin to write. While the diaries are closed, my continuing relationship with mantra and it's GI surely must go on, and so providing endless material for another round of....

The Cornell Box Diaries!!!

As it is though, here are my conclusions.

Mantra's GI still feels pretty new (even though it's been around for a couple of years now). There still seems to be a large amount of confusion as to what should be done and how much of it should be done to get some decent GI rendering.

Photon mapping seems to be the easiest to grasp at the moment, even though there are some settings that are known to exist in the photon mapping world, but don't seem to have Houdini counterparts.

All in all, I'm left with a feeling that it could be easier. Surely the gazillion lightwave, vray and brazil users out there aren't spending weeks tweaking the most obscure settings in a vain attempt to get some sort of decent GI out of the renderers.

For me, this is the general workflow when it comes to GI.

I start, get something almost immediately. Slowly change some settings to make the render look better. Render looks better and better until at some point something changes that makes it look like ass again. I then spend a couple of days trying to figure out which setting I changed that screwed everything up, only to start at the beginning again because it's easier.

While I never expect Houdini to be point and click, I do wish that all of the various elements linked up slightly better so that there was a clear path for me to follow to get from point A to point B. Right now I feel like I'm falling down the rabbit hole with no clear idea of how I got there and how to get back.

I think I may try and turn this into some uber-tutorial that will help guide everyone else along this narrow and treacherous path.

All right, I'm done.

M

[edward]

Hummm... A problem with use photon mapping when it it is used for the global illumination in animation is flickering. Who knows, how to avoid it?

13839[/snapback]

I think it's either you turn up the samples until it's high enough or don't use photon mapping.

[sibarrick]

Makes me wonder if Sesi decided that no one is really going to use GI for any serious rendering so they decided not to take it any further. The point cloud route seems to be a much more controllable route for faking lots of these types of effects quickly. Maybe faking still rules , does PRman bother with real GI?

[edward]

Why would you say that? Using GI in that sense seems to me a rather over generalizing. I imagine that one can also do irradiance stuff using point clouds. How is that not GI? All of CG is faking anyhow with respect to reality so I don't know how you would classify real GI vs. fake GI.

[stu]

I think it's either you turn up the samples until it's high enough or don't use photon mapping.

13863[/snapback]

One of the issues related to mantra and doing any sort of GI while using motion blur is that mantra shades first and then does the transformations second. This results in a solution that is by definition incorrect - the blurred object will be shaded as if it's in the position it was in half a frame ago (assuming the shutter is at .5). This is most unpleasantly demonstrated by burying a sphere within a cube and animating it so that the sphere, in one frame, leaves the inside of the box. If you render the first frame where the sphere is no longer within the box while using motion blur and the stock ambient occlusion settings, the sphere will be renderd black, as if it's still within the box.

I've already spoken with the powers that be about the issue - I don't know if this is the behaviour that is the cause of your problem, but it's good to know.

stu

[edward]

I somewhat feel that my comment was taken out of context here. I was referring to the "noisiness" of the images that one typically sees when rendering an animation using photon mapping. As far as I can tell, it's a universal problem shared by most if not all renderers.

[DaJuice]

It ain't over 'til the fat lady sings.

I found these pics on my hard drive, and they got me all excited about messing around with GI again. Below are pics of a real life cornell box built by Richard Rosenman, and I've tried my best to replicate the results with mantra (I took the liberty of taking screencaps and saving without the watermark for this exercise).

First the real life cornell box:

The renders:

super sample: 8x8 (just for the heck of it)

cornell box shading quality: 8 (to get rid of leaks at the cornell box edges)

objects shading quality: 3 (just to to be on the safe side)

irradiance caching default error: 0.3

sampling quality: 512

render time: 90 min each (800mhz P3)

Well, I think it

H7_Cornell_Box.zip