user_ibl_env usage

#1

Update! Simple tutorial here: http://elementalray.wordpress.com/2012/05/07/the-user_ibl-shaders-pt1/

Quick n’ dirty usage:

connect the user_ibl_env to the custom shader slot of an area light

Area light:
-turn on visible
-select custom

user_ibl_env:
-set samples (this is a literal value) I can get away with 4-8 using Unified Sampling and a basic daylight HDR, you may need more for a complex HDR

Now connect the user_ibl_env to the Environment slot of the camera. (you can still use the rayswitches and envblur with this shader.)

important

The samples (high AND low) of the area light must match the samples of the user_ibl_env shader or you may truncate the importance sampling. It’s easiest to just connect the high and low samples to the user_ibl_env samples attribute so they stay the same.

important

You must use the “light relative scale” string option with a value of 0.318 (1/pi) to correctly light materials, this shader is designed for BSDF so old materials will blow out some if this isn’t set.

Render.

Blog post coming at some point. :slight_smile:

Additionally: When lighting with this, use a filter on your Final Gathering and greatly reduce the accuracy. Only secondary bounces are calculated by FG when using the user_ibl_env. You can get away with values that are low, in my case 32 rays provides plenty.

#2

Performance warning:

-2013 exhibits faceting in the diffuse channel, it’s been fixed but not in Maya yet. Needs to be a Hotfix. This is a problem with the AD framebuffer system.

-Avoid using specular effects with the user_ibl. Use reflection instead. This is the default in the mia_material. Avoid defeating that. A large visible area light (like the user_ibl_env) will cause noise in the specular channel that is hard to resolve. Specular is meant as a fake to show small light sources and sample the light. This is not the case with the user_ibl.

#3

Cool !
Thank you as always for useful information.
Can I use maya`s procedural textures?

#4

It only accepts textures, you would need to bake a procedural into an HDR map.

#5

I looked through the string options in the docs but didn’t see one for light relative scale. I probably just missed it. Been a long day. :slight_smile: You wouldn’t happen to be referring to the Lighting Scale string option that is part of the Built-in IBL would you? If not, is it safe to assume that this string option is to the user_ibl_env what the Lighting Scale string option is to the Built-in?

Any chance you could post up the correct syntax for this string option so I make sure I get it right?

Thanks!

-Justin

#6

Also, is the faceting you’ve seen in the diffuse channel bad enough to render this shader unusable for production? Or is it only really noticeable in certain cases, but in others may be fine for production?

#7

Found the info I was looking for about the string option in another thread you posted in:

Name: light relative scale
Value: 0.318
Type: scalar

Still can’t find it in the docs, though. It’s not listed under the String Options section from what I can tell.

I haven’t been able to find much info on the user_ibl_env in the docs either. What I saw was extremely brief.

#8

The docs are pretty bad, it’s something they are re-writing.

Hopefully have an example on the blog after this weekend.

The faceting when doing compositing is pretty bad. Please report this to Autodesk and drop a Bug Number here. I haven’t been able to get onto Subscription yet where I am. Once there’s a bug number I can report it to nVidia and get the fix pushed through.

Always search Release Notes for things you want. It’s the most helpful section with string options, registry values, and more.

#9

Awesome. Looking forward to it.

I’m still confused as to how to use this correctly. I understand how to hook it all up and get it working thanks to your detailed instructions here, but I don’t fully understand its intended purpose. Is it meant to be used as a replacement for the Built-in IBL? So basically previous scenarios where I would have reached for the Built-in, I would use this shader instead?

Also, from my brief tests last night it seemed as if this shader has directionality to the lighting coming from the area light. The Built-in functioned as an infinite sphere around the scene. So if this shader is supposed to have directionality to the lighting I guess it’s not a replacement for the Built-in?

I know you’re going to post about this later on the blog but I figured I’d share what I was confused about anyways. Mainly because I enjoy sounding like I have no idea what I’m doing. :slight_smile:

-Justin

#10

Is it meant to be used as a replacement for the Built-in IBL?

Yes, except this requires a texture and does not ‘bake’ a procedural or ‘rebake’ a texture. This means it retains all the details of the texture.

Also, from my brief tests last night it seemed as if this shader has directionality to the lighting coming from the area light.

Don’t forget to make the light a ‘custom’ shape and attach the user_ibl_env to the mental ray environment connection of the render camera.

#11

Doh! That was it. Much obliged. Seems like a script may be in order so I don’t forget steps. :slight_smile:

#12

This is good info from one of your posts in another thread. I thought it would be nice to have this in the main thread for the user_ibl_env. I did this mainly for myself because I’m sure I’ll forget where this info is at some point.

On a side note, I just did a direct comparison between the user_ibl_env and the Native IBL. I think I am seeing some of the effects of the above quoted info. The Native IBL produced a much smoother result than the user_ibl_env. I imagine this comes from the loss of detail in the texture during the rebaking step. Since the user_ibl_env maintains that detail it’s giving me more noise. That’s my best guess from my limited knowledge anyways. Any thoughts?

Edit

One thing to note about the noise is the noise in the super bright glossy reflections of the lights remains exactly the same. The noise increases mainly in the more middle values of the image.

One other thing to note, the material is a polycarbonate with .75 glossiness. Only 1 glossy sample for brute force unified.

#13

Heya

Any chance to have a scene file to avoid any user fails?

Thanks, bye.

#14

Would this be the correct usage for this setup: one convolved env map for final gather and one sharp map for reflections?

Two area lights. User_ibl_env with sharp texture plugged into one light, user_ibl_env with convolved texture plugged into other area light. Convolved user_ibl_env has primary checked, sharp user_ibl_env has as reflection checked. Each user_ibl_env is then fed into a rayswitch as normal which is fed into camera as normal.

Also, when using this set up, would it be advisable to reduce the samples on the user_ibl_envs since there are 2 of them instead of one? So for example, if normally I would use 4 samples, should I drop that down to 2 samples for each? Or just keep both at 4?

Just want to make sure I’ve got this set up right.

Edit

After some initial tests it appears my first idea is not correct. I haven’t come up with the right approach just yet. Still experimenting.

Thanks,

Justin

#15

The ‘As Reflection’ option is the user_ibl_env does not mean that. It relates to how the environment image was captured and should be mapped to your environment.

If you shot your environment map using a mirror ball technique, so the environment is seen “As a Reflection” to you when you captured it, then you would select that option. If you captured your environment using normal nodal turn and shoot from origin out into your environemnt then you do not need to check that option.

I think with the importance sampling ibl method, the two environment map method is not really necessary anymore. You can light an exterior shot purely with the user_ibl_env light and not need to worry about flickering as it is now a direct light source.

If you want the extra bounce of final gather you can use it in conjunction with the ibl light as it will not sample the environment given that it is a direct light source. I think David says you should just set your FG Filter size to 1 just incase you have very bright values hitting your objects from your env light.

Best,

Rich

#16

Thanks for the clarification on the ‘as reflection’ checkbox. I totally misinterpreted that. Does it specify that in the docs? I didn’t see that explanation in there.

I totally forgot about David saying I should filter my final gather as a solution to the bright spot problem. I’ve now wasted an hour attempting to solve the problem in the wrong way. Wonderful. :slight_smile: At least now I can move on and quit trying to use the convolved diffuse map technique to get rid of those bright spots caused by the lights in the map.

Thanks!

-Justin

#17

Yeah it is not obvious as to what that option actually means or does. When I was testing it I just saw differences in the way it was rendering in the background (ie the mapping of it) No it does not specify that on in the docs yet. I am sure Bart or David/Brenton will post all the necessary details about the nodes soon.

Best,

Rich

#18

We’re working on a tutorial and examples. But I think it sounds like you have a good handle on how to use it.

Just remember that your FG can be less aggressive now. I use 32 rays for most of my scenes, some cases even less depending on the scene and what cannot see the user_ibl

#19

Any guidelines or rules of thumb for point density? I’m going pretty low at this point. I’ve used 0.5 and 0.3 with rays of 32 and filter on 1 and it’s looking good. Before the filter I was getting the nasty bright rings due to the bright point lights in the map. The filter totally got rid of it. Just worrying about stills right now. But I imagine it’s about the same thing for animations using your fg_shooter script or pre-calculating by hand.

#20

Since the IBL is doing your main lighting, the only thing you might risk from reduced point density is less detail in your indirect lighting. That would show in places where it’s your primary light source. (Holes, covered areas, crevices, etc.)