user_ibl_env usage

#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.)

#21

I am having some problems getting the user_ibl_env to work correctly with the mia_env_blur node. I am noticing a distinct brightening of the image when the user_ibl is used with the mia_env_blur. I’ve done a number of tests now and it’s consistent.

If I use the old school workflow of using one diffuse convolved map and one sharp map along with final gather only, the overall brightness of the scene is very similar to the user_ibl setup without the mia_env_blur. Using the old school set up, I can add and remove the mia_env_blur node with no change in brightness happening in my scene. If I do this with the exact same mia_env_blur node with the exact same settings to the user_ibl setup then there is a consistent brightening of the scene.

Have you noticed any of this behavior?

I am only inserting the mia_env_blur between the user_ibl and the environment slot of the camera. Tried inserting it in between the area light connection just to see and it was chaos. So I assumed that was incorrect.

I would like to use the mia_env_blur in conjunction with the user_ibl because it takes care of the fireflies in my light reflections. Even when I crank high on quality with Unified, without the mia_env_blur the reflections of the lights are still ugly.

#22

The mia_envblur connects to the camera environment. Then the user_ibl_env to the mia_envblur.

Be sure the materials are set to ‘single sample’ from the environment.

I have some high resolution maps at work so I have to go to 4096 on the resolution for the env blur. It’s a memory hog.

But I have not noticed a drastic change in lighting.

#23

I’m starting some explanation on on the way to writing up some tips on user ibl

http://forum.mentalimages.com/showthread.php?9470-Can-somebody-explain-new-user-ibl-shaders

#24

Awesome! Thanks for the heads up.

-Justin