CGTalk > Software > Autodesk Maya > Maya Rendering
Login register
Thread Closed share thread « Previous Thread | Next Thread »
 
Thread Tools Search this Thread Display Modes
Old 09-06-2012, 01:57 PM   #1
Ruthtog
Veteran
 
Join Date: Nov 2004
Posts: 38
Native IBL vs user_ibl_env, which is more approriate?

Hi guys,

Ive been experimenting with the Native IBL and also the user_ibl_env shader connected to an area light but I'm somewhat confused as to which is a better or more appropriate workflow. On the surfce it appears both do the same thing with similar controls, Im not seeing obvious drawbacks. Can someone elaborate on what the difference is and which is more appropriate?
 
Old 09-06-2012, 07:10 PM   #2
chuckie7413
"be distinct"
 
chuckie7413's Avatar
Richard Levene
USA
 
Join Date: Mar 2006
Posts: 340
Hi, this is what I have found when trying both out in our workflow.

Using the native ibl gives you a bit more control in the sense it will read the environment that is mapped to the old maya ibl node where you can map any texture (including procedural) to it. Being able to use the old maya ibl node also allows you to rotate the environment on more than one axis. The drawback I have however with that approach (ie when using the old maya ibl node to place my environment) is I do not have access to the ibl node to plug into rayswitch nodes, which is handy for me when test rendering with a backplate) so as an alternative i will use a mib_loockup_spherical node. This however gives me the same restriction like the env_ibl light in that it is restricted to one axis of rotation.

Other issues relate to environment processing. I find the env_ibl light a lot fast in processing a large hdr whereas the native ibl has to calculate the hdr image to build the importance structure. (not 100% on what is technically going on, maybe someone else can elaborate on that).

However with the native ibl, you have a resolution control, so what you can do is plug a 10k hdr into the environment and then set the resolution to something like 2k. This then makes the texture process speed a lot quicker, you lose a bit of quality in the way it samples the light but it is responds really fast when rendering with IPR. The env_ibl light does not respond as fast in IPR than that unless you load a smaller resolution of the hdr. So you would have to have two versions of your hdr, a small one for IPR rendering (quicker updates) and a large one for final render.

The next thing would be sampling. I do find the env_ibl easier to understand in terms of sampling as you just set the samples number whereas with the native ibl you have a quality controller but that is quite an arbitrary value. 0 low and 1 high. but it can go higher than 1. Not sure on number of samples it generates along the rang.

Those are my findings so far.

I am not convinced by either process as a nice workflow to be honest. The env_ibl really needs to add more features to it. Definitely 3 axis rotation control would be desired, a preview sphere (good script from Justin Jenkins that does it though) and ability to map any texture including maya procedurals would be good.

Best,

Rich
__________________
beDistinct RecomFarmhouse IMDB LinkedIN
 
Old 09-07-2012, 12:42 AM   #3
Ruthtog
Veteran
 
Join Date: Nov 2004
Posts: 38
Rich thanks an awesome summary, thanks so much!
 
Old 09-07-2012, 12:58 PM   #4
Redsand1080
43% Burnt
 
Redsand1080's Avatar
portfolio
Justin Jenkins
Senior Technical Artist
Camber Corporation
USA
 
Join Date: Jul 2003
Posts: 803
Send a message via AIM to Redsand1080
Great info Rich! Thanks for sharing.
__________________
If animation is the illusion of life, then life is the illusion of reality.


"On ne sort pas DU REVE."

 
Old 11-08-2012, 12:15 AM   #5
Bitter
Also Highly Corrosive
 
Bitter's Avatar
David Fer Real
Fixer of things
USA
 
Join Date: Apr 2003
Posts: 1,721
**When using either the Native IBL or user_ibl_env, you need to use the string option "light relative scale" with a value of: 0.318 (the inverse of pi) to correctly scale light with legacy shaders.**

I would prefer the Native IBL right now (Builtin, the string options)

It takes longer to start a render because it processes and re-bakes the texture as Rich mentions. This means it loses some detail but may make glossy reflection faster/less noisy.

You can retain information from that baking process by using "environment lighting shader samples" and giving it an integer value. I think the default is 4.

Native IBL also exposes samples as "Quality" like Unified. There is in fact an equation to derive samples but it's not exposed because this may change in future versions, making reliance on it a bit tricky.

Native IBL also point samples, this means it can bake procedurals. The user_ibl_env has direct access (no baking) to a texture, this means it preserves more detail but cannot use a procedural (unless first baked to texture)

Native IBL will attempt to bake whatever is on the camera as an environment. Native IBL also uses Multiple Importance Sampling (MIS) when combined with BSDF shaders.

In either event you should greatly decrease the accuracy of your indirect lighting method (i.e. accuracy in Final Gather) as they only now contribute secondary lighting effects (bounces).
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.

Last edited by Bitter : 11-08-2012 at 12:38 AM.
 
Old 11-08-2012, 06:46 AM   #6
Bitter
Also Highly Corrosive
 
Bitter's Avatar
David Fer Real
Fixer of things
USA
 
Join Date: Apr 2003
Posts: 1,721
I see a new blog post on this in my future. . .
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.
 
Old 11-08-2012, 12:31 PM   #7
Libor
Expert
portfolio
Libor Batek
freelance cg artist
Freelance 3d artist
Praha, Czech Republic
 
Join Date: Jan 2002
Posts: 639
Send a message via ICQ to Libor
Question

Good topic guys, Im just playing with that...

Bitter> I though that you use user_ibl in production (mill) exclusively these days...so not?

Im also thinking whats the pros over standard IBL in render globals


whats really interesting I accidentaly left color management on default in hdri file node connected to user_ibl shader and it gave me 0.454 gamma correction on my ibl light

that wouldnt be so interesting but it completely change my lighting not just being much darker but also much more visible direct illumination efects! when I corrected the colormanagement settings to "linear" the image got right gamma but also bleached a lot and the nice illum effect with hard/soft area light like effect were gone! in the end it resembled standard ibl lighting in render globals.... so I started to be confused which is better in production

L.
 
Old 11-08-2012, 02:06 PM   #8
chuckie7413
"be distinct"
 
chuckie7413's Avatar
Richard Levene
USA
 
Join Date: Mar 2006
Posts: 340
Hi David.

Thanks for the extra info. I have a few questions on some things I still do not fully understand and find hard balancing to get sufficient render times.

Quote:
Originally Posted by Bitter
You can retain information from that baking process by using "environment lighting shader samples" and giving it an integer value. I think the default is 4.


What exactly do you mean by retain information from the baking process?

And how should this setting be used in conjunction with the other native ibl settings ie. if we give a low resolution, we put up the lighting shader samples? But then what about quality setting?

Quote:
Originally Posted by Bitter
Native IBL also exposes samples as "Quality" like Unified. There is in fact an equation to derive samples but it's not exposed because this may change in future versions, making reliance on it a bit tricky.


This is interesting. To be honest I am struggling quite a bit. I am trying to do a more brute forced approach with unified, but if I have the quality of my native ibl low at 0.2 I still get noisy results even with unified min and max of 1 - 700 and a quality of 3-4. (using 3.10.1.11)

My render times are still pretty long and if i put the native ibl quality up to say 0.7 render times really sky rocket but I still see noise not in the quality of the direct light but in glossy reflections.

I have tried to follow the diagnostics blog post you wrote along with the render times post but I still feel like I am not getting perfect results.

Once the project is done I will post some render stats etc and can see maybe where it is going wrong.

Best,

Rich
__________________
beDistinct RecomFarmhouse IMDB LinkedIN
 
Old 11-08-2012, 05:35 PM   #9
Bitter
Also Highly Corrosive
 
Bitter's Avatar
David Fer Real
Fixer of things
USA
 
Join Date: Apr 2003
Posts: 1,721
We aren't on 2013 at The Mill for everything. There are some issues.

Although you can use user_ibl in 2012. I am having a little bit of an uphill battle to get people to stop using Final Gather to light everything. . .

Quote:
What exactly do you mean by retain information from the baking process?


When the texture or procedural is resized, it may lose information just like it would in a Photoshop-like operation. If you increase the shader samples, it will take more samples per area before resizing. This means the result should retain more accuracy afterwards.

Quality is somewhat independent. It's just the quality of the light (grain reduction) I can typically live with 0.3 to 0.4

Quote:
My render times are still pretty long and if i put the native ibl quality up to say 0.7 render times really sky rocket but I still see noise not in the quality of the direct light but in glossy reflections.


Are you currently outputting a specular component somewhere? Avoid having a specular (direct glossy) sampling of the IBL, you want a glossy indirect (reflection) of the IBL instead. High samples are required to clear grain in direct glossy sampling of large area lights with the current shaders (car paint for example). mia_material has the option for "no highlight" from visible area lights; try not to defeat that.

Have you reduced your Final Gather accuracy or quality? It's usually unnecessary when mostly lit by IBL.
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.
 
Old 11-08-2012, 07:04 PM   #10
chuckie7413
"be distinct"
 
chuckie7413's Avatar
Richard Levene
USA
 
Join Date: Mar 2006
Posts: 340
Hi David,

Specular is off for all my materials. Dealing with low glossy values of around 0.2/.3. I have the glossy samples for those at 2. Maybe need to increase them to 4.

My final gather is low. Maybe it could be lower. 100 accuracy and 0.1 density, with 40 approx. I can probably reduce accuracy down by half or more.

Thanks,

Rich
__________________
beDistinct RecomFarmhouse IMDB LinkedIN
 
Old 11-08-2012, 07:09 PM   #11
Bitter
Also Highly Corrosive
 
Bitter's Avatar
David Fer Real
Fixer of things
USA
 
Join Date: Apr 2003
Posts: 1,721
Few things might cause a problem there.

If the surface is perfectly smooth, no textural variation, and wide glossy, then you may need some more samples, 4 and up for reflection.

This is complicated if your HDR image is high contrast or the light sources are high values.

Other renderers provide a clamp for that in the sampling. mental ray assumes processing of the HDR in something like Nuke to lower those hotspots.
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.
 
Old 12-18-2012, 11:03 AM   #12
Jinian
Freelance 3d artist
 
Jinian's Avatar
portfolio
Jin Hao Villa
character artist/digital sculptor
Philippines
 
Join Date: May 2004
Posts: 534
How to flip HDR texture from within maya

Sorry for the noob question, but where is the user IBL you guys are talking about in maya 2012, and how do i use it? Would it be the mip_rayswitch?

And it is true the native IBL flips all my spherical hdr maps in reverse, but i have no idea how to flip the texture within maya. There is no option under its 2d texture node, and the environment sphere generated by the native IBL can be scaled to -1 but texture still remains as is.

I really dont want to save another copy in photoshop just to flip the texture. Any help be appreciated.

Thanks.
 
Old 12-19-2012, 04:28 AM   #13
Bitter
Also Highly Corrosive
 
Bitter's Avatar
David Fer Real
Fixer of things
USA
 
Join Date: Apr 2003
Posts: 1,721
Quote:
And it is true the native IBL flips all my spherical hdr maps in reverse


That is the "Maya IBL", the "Native IBL" is the builtin IBL (dome light) for mental ray. It bakes what is attached to the camera as the environment, this may include the Maya IBL which has a reversed HDR input. We flop it in Nuke before rendering.

The Native IBL is a string option introduced in mental ray 3.7 that allows you to bake (convert) an environment on the camera to a dome light, basically a smart area light for automatic lighting.

The user_ibl is only included with Maya 2013, this is why you don't see it in 2012.
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.
 
Old 12-19-2012, 07:17 AM   #14
Jinian
Freelance 3d artist
 
Jinian's Avatar
portfolio
Jin Hao Villa
character artist/digital sculptor
Philippines
 
Join Date: May 2004
Posts: 534
I see. What advantages does the user ibl have in 2013? I personally use SIBL GUI from hdrlabs. it's great quality using a mip_rayswitch and very fast to render as well.

So just for clarification, the maya IBL is the one located under the indirect lighting tab of your render globals with the "image based lighting" tab, the native IBL is the domelight created with you tick on "emit light" from your image based lighting settings of your hdr probe?
 
Old 12-19-2012, 08:28 AM   #15
Bitter
Also Highly Corrosive
 
Bitter's Avatar
David Fer Real
Fixer of things
USA
 
Join Date: Apr 2003
Posts: 1,721
I prefer Native IBL to user_ibl_env. Native IBL is a little more flexible and has less noise at the possible cost of detail.

Quote:
So just for clarification, the maya IBL is the one located under the indirect lighting tab of your render globals with the "image based lighting" tab, the native IBL is the domelight created with you tick on "emit light" from your image based lighting settings of your hdr probe?


No, that is still the Maya IBL, the "emit light" option is the Autodesk/Maya dome light. This is not the mental ray Native IBL. AVOID "emit light"

This is a bit older but has the basics, some of this has since been improved with Unified Sampling as well: http://forums.cgsociety.org/showthread.php?t=956710
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.
 
Thread Closed share thread


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 04:59 AM.


Powered by vBulletin
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.