Question about interior rendering

[forgeflow]

I have a question about rendering methods when rendering interiors partially lit by sun/sky lighting from outside.

To get the basics out of the way, Yes, I've placed portals in the windows, I'm using the "ghost glass" on single sided polygon window panes.

If I use "Mlt BDir" as the rendering method, everything renders great - i can see the sun come through the windows, light bounces around really realistically, everything (almost) looks great... except in this scene there are a few glass "display case" type objects. The light barely penetrates into the cases, and the interiors are dark and speckled. Based on my previous experience with the "BDir" option and poor/weird rendering of glass, I decided to try rendering the scene with just "Mlt".

Besides being slower to render, the major problem with this is that now the sunlight is entirely missing from the render - i can see the skylight, all of the interior artificial lights, but the sun itself... gone.

Are there solutions to this? Portals inside the display cases behind the glass? I've tried the ghost glass in the display cases, and it's much the same problem. Is there a "bounces" limit in the default rendering setup that I should monkey with? No images to demonstrate what I am talking about at the moment.. I'm still monkeying with different things in the scene but I thought I'd ask for help.

[zeitmeister]

Did you place the portals behind the windows? And do your single-sided windowglass-mesh-normals point inwards?

[forgeflow]

Did you place the portals behind the windows? And do your single-sided windowglass-mesh-normals point inwards?

Yes. Basically, it's SUN -> portal -> windowglass -> interior.

After a bunch of tinkering, I've found 3 things:

1) Increasing Max Num. Consecutive Rejections to 100000 and Max Depth to 20000 helped, without slowing down the rendering too dramatically.

2) I had the scale of the scene off by a factor of 7 (too small). Once I scaled the scene up to actual size, the glass panes in the display cases started acting more normally.

3) Samples Per Pixel is a meaningless metric if you have more than one light source. Looking at the rendered image, it looked clear, but looking at each of the light layers one at a time revealed that the smaller light sources were no where near clear - the more light sources, and the smaller and more distant they are, the longer they take to clear. So I'm doing a nice long render of this scene until the weakest, smallest light sources (some suspended spot lamps) actually clear to a smooth image. Even after 24 hours, that particular light layer is very "pointilistic" . The Sun layer is a bit clearer, because it's a stronger source, But its not as clear as the Sky layer, which looked clear within a few hours. I'm almost thinking that you'd have to divide the samples per pixel by the number of light sources in the scene to come up with a reasonable number to compare rendering "doneness" by.

Looking at it another way, too bad there's no way to assign priorities to the light sources. Even now, though the Sky layer is "done" to visible perfection, Indigo is still calculating values for that source -- time being robbed from some of the less "finished" looking layers. It'd be nice if Indigo could "sense" that condition and spend more time looking at my spotlights or my sun light at this point.

[lycium]

Glass poses a number of difficulties for unbiased renderers, which are either approximated or worked around in more "practical" renderers. We've looked into "arch glass", a hack which doesn't play well with the rest of the system, and more recently we're thinking of a new way to solve these issues efficiently.

For the moment, the behaviour you see can be explained simply: it just needs to render longer. MLT does a good bit of local exploration of light paths, so it won't do as broad a sampling of the scene as quickly as non-MLT would. This is a double-edged sword in that it can take longer for these events to get sampled at all, but when they do they get better sampled than they would otherwise.

We've been rendering some test scenes from our Revit exporter, one of them is a very complex conference centre, seen from the inside. The only light in the scene comes from the sun shining through many, many layers of glass... of course it's extremely slow to render, but the main thing we noticed is that it's basically impossible to render this without MLT. So, for the current unbiased methods, MLT is basically a must when dealing with scenes having lots of glass light paths, and that needs some time to fully sample.

[Pibuz]

HEY FORGE!
WHY THE HELL DON'T YOU POST AN IMAGE?!?!

..guessing is becoming way to difficult to me..

[forgeflow]

HEY FORGE!
WHY THE HELL DON'T YOU POST AN IMAGE?!?!

..guessing is becoming way to difficult to me..

Alright, alright. I'm going to post several images to illustrate what I'm on about. I didn't model this scene - it's from 3dRender.com, one of their lighting challenges. I merely textured and lit the scene:

First of all, these images are after 37 hours of rendering, SPP of 21496 (so far).

The sky light layer.

The sky light layer is the largest contributor of light to the scene, and has rendered the most completely of all the light layers. Note that the interior of the display case on the left foreground is clearly rendered with no dots, and the reflections on the floor are all smooth.

The sun light layer.

The sun light layer is the brightest direct light in the scene. Because the sun itself is a small 'target' for the MLT routine, it has not cleared yet. Note the grainy reflection on the floor on the right side, and some of the direct light is still invisible through the glass of the T-Rex display case. It will eventually appear after a very long time of rendering.

The spotlights layer.

The spotlights are small disc area lights with an IES profile, placed partway up into the spotlight cannister. These are very small 'targets' for MLT and don't get very much sampling. Hence, the layer is basically a collection of randomly scattered point samples. This will take a VERY long time to clear.

The globe lights layer.

The globe lights are several (I think around 40 or so) small spherical light sources placed inside of transmissive light fixtures. This layer has not cleared completely in the floor reflections (as seen to the left side of the T-Rex display, or inside the display case on the right.

The carriage light layer.

The carriage lights are two small cylindrical light sources inside of glassed-in carriage light frames. They are also very small 'targets' for MLT to hit, and have not fully cleared at all. However, they do seem to have sampled better than the spotlights.

All of the layers more or less in balance.

All of the layers in balance with each other. Overall the image looks fairly clear, mainly due to the clarity of the sky layer. The stippling seen in the display case on the left, or the reflections in the floor on the right, are due to the contributions of the under-sampled spotlight and sun layers mostly.

That's it for this experiment, however. Annoyingly, Indigo crashed out on me as I was saving these images. My next experiment will be to render the spotlights without any other of the light sources and see how long they clear on their own.

[Zom-B]

Hey Forge,

the problem here is that U use light Layers!

For Light Layers Indigo uses a importance wighting system!
The higher the light source flux, the higher the importance!
If Light source A hast a flux of 10000 and light source B only of 100, the Indigo uses 100 times more samples for calculating light layer A...

I don't know how much this importance wighting contributes (or if it does!) to a rendering without lightLayers.

I hope this helps explaining a little


btw:
don't use any glass obstacles for light sources where they aren't visible anyway (like the lamps in the back or the ceiling windows for the sky!), this helps rendering your image faster!

[forgeflow]

Hey Forge,
the problem here is that U use light Layers!

Well, you gotta. There's zero chance of guessing the balance of the sources ahead of time.

don't use any glass obstacles for light sources where they aren't visible anyway (like the lamps in the back or the ceiling windows for the sky!), this helps rendering your image faster!

Yabbut... I might stick the camera back there for a different view. Also, the glass in the windows isn't glass. It's a metal phong with a very high IOR and Exponent, blended with null to make it transparent. All it does is catch some reflections, but there's no refraction going on.

My current experiment is to render each light "layer" individually, save them out as .exr, and blend them in Photoshop. So far, it's working. The spotlights on their own were better looking in a 3 min render than in the 37 hour render. They've been rendering for 4 hours now, and are nearly clear. If I can do that for each light layer, then I should have a completely clear set of light layers to fiddle with in photoshop in less time than it was taking Indigo to render them all at once. That's my hypothesis anyway... we'll see how it pans out.

[pixie]

Well, you gotta. There's zero chance of guessing the balance of the sources ahead of time.

You can have them having the same strength and calibrate afterwards the relative weight of each light.

[forgeflow]

Well, you gotta. There's zero chance of guessing the balance of the sources ahead of time.

You can have them having the same strength and calibrate afterwards the relative weight of each light.

That's where the light layers come in.

[fused]

awww, no party hats