CGTalk > Software Specific Forums > Autodesk Maya
To minimize the ads you see on this page create a CGTalk account and log in HERE
Thread Closed share thread « Previous Thread | Next Thread »
 
Thread Tools Search this Thread Display Modes
Old 04-08-2013, 06:05 PM   #16
sentry66
Expert
 
sentry66's Avatar
portfolio
node crazy
USA
 
Join Date: May 2008
Posts: 1,980
I finally abandoned FG and GI because I got so sick of getting what appeared to be flicker free results in full quality test renders in the renderview with a photo exposure node, only to find out flicker would show up in post after colors would be adjusted. I don't know how many times I started rendering full quality frames with really high FG/GI settings only to find out the next day I had to trash them after certain views would show FG/GI noise

I'd zero everything out except the FG/GI and even disconnect the camera exposure node to make sure there isn't moving splotchiness, but it wouldn't matter even if that looked great. Especially the dark areas, certain areas of models just pick up flicker. I think really the flicker is always there on some level. It's just a matter of how far you need to tweak the exposure or gamma in the dark areas before you can see it.

Anyway, I've just gone back to the old-school setting up low intensity environment lights, because at least it's 100% predictable and renders fast. I've also started doing some tricks with SSS bringing in wider than normal SSS into my shaders to help with any areas that might appear harshly lit.

Last edited by sentry66 : 04-08-2013 at 06:12 PM.
 
Old 04-08-2013, 11:37 PM   #17
cineartist
Student Of The Craft
 
cineartist's Avatar
portfolio
Richard Culver
Hayward, USA
 
Join Date: Oct 2010
Posts: 652
Yes. You are 100 percent spot on in your observation and analysis.

There is no way to get rid of flicker with Final Gather unless you have access to the brute force method.

However, even with that in mind, I wanted to do some experimenting to see how far it could be pushed. I have a theory that it takes the same amount of time to really do it as brute force which is very expensive with render time. And I'll bet that most people are not willing to wait 1 hour per fame to find out on an interior scene. Because with the average computer - unless you are running a fast 6 core - that is about what it takes with brute force for a very dramatic scene with lots of dark areas

Also I am curious which parameters you were pushing.

As well, if you get the time, could you put those frames I have through your post process and see if they hold up?
 
Old 04-09-2013, 03:15 AM   #18
stallion151
constipated CG
 
stallion151's Avatar
M
Australia
 
Join Date: Apr 2003
Posts: 1,551
not exactly what everyone is talking about, but thought i'd add it into the mix too.
since contrastAA was mentioned.
Changing the sampling quality per rgb channel to something similar to the Maya defaults works great for resolving noise in general.
So in the miDefaultOptions change contrastR to 0.040, contrastG 0.030 and contrastB 0.060 and that will add a couple more rays but it's supposed to be more akin to how our eye works, we see green more so it gets more samples.
__________________

 
Old 04-09-2013, 03:34 AM   #19
Bitter
Also Highly Corrosive
 
Bitter's Avatar
David Fer Real
Fixer of things
USA
 
Join Date: Apr 2003
Posts: 1,720
I think all of this has gotten much too complicated. Any and all interpolation techniques will require some tuning. This is true in any render I have used with such a thing (mental ray, vray and the like)

1) If you are lighting with an HDRI, use the Environment Lighting Mode (Native IBL), reduce your FG rays (accuracy) accordingly. Usually a LOT. Maybe 8-32 rays depending on the scene.

2. FGshooter found on the Elemental Ray Blog. Easy setup script.

We typically render frames in about 15 minutes to 30 minutes a frame at 1080HD without flicker. For production using the above tools.

Brute force final gather will be very slow and wholly unnecessary with the Environment Light.
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.
 
Old 04-09-2013, 03:38 AM   #20
Bitter
Also Highly Corrosive
 
Bitter's Avatar
David Fer Real
Fixer of things
USA
 
Join Date: Apr 2003
Posts: 1,720
Sidenote: stop lighting with final gather. You don't get shadows this way, only an occlusion-like effect. Most people drop in an HDRI, turn on Final Gather and say "Look, my scene is lit!" Well no, it was maybe that way in 2000.

Vray recommends their dome light.
Arnold recommends their dome light.
mental ray recommends their "dome light" (Native IBL or user_ibl_env)

Using those tools to light the kinds of scenes I see here will make your life soooo much easier and faster.
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.
 
Old 04-09-2013, 03:47 AM   #21
Bitter
Also Highly Corrosive
 
Bitter's Avatar
David Fer Real
Fixer of things
USA
 
Join Date: Apr 2003
Posts: 1,720
Quote:
Originally Posted by stallion151
not exactly what everyone is talking about, but thought i'd add it into the mix too.
since contrastAA was mentioned.
Changing the sampling quality per rgb channel to something similar to the Maya defaults works great for resolving noise in general.


This applies to Anti-aliasing noise, not Final Gather.

In any case we would recommend using Unified Sampling in Maya 2013 and newer. Simple Quality control for anti-aliasing, depth of field, and motion blur.


Quote:
Originally Posted by sentry66
I finally abandoned FG and GI because I got so sick of getting what appeared to be flicker free results in full quality test renders in the renderview with a photo exposure node, only to find out flicker would show up in post after colors would be adjusted.


Don't use an exposure node or lens shader. Preview all renders using the built-in LUT and colorspace mechanism in the Maya render view. Render to 16-half RGBA and EXR. Doing this preserves the data and allows you to see the final image after correction to your desired colorspace. The lens shaders are for baking in the colorspace and not very useful for a pipeline where you will post process the work. (Baking these colors and colorspace makes your life much more difficult, and framebuffers passes are correctly maintained as linear anyway)

Quote:
Originally Posted by cineartist
There is no way to get rid of flicker with Final Gather unless you have access to the brute force method.


Not true, although it's probably more guaranteed that way. Below are examples rendered with standard Final Gather and maybe the FGshooter script without flicker:

http://www.youtube.com/watch?v=cniIVxaJMSY
http://www.youtube.com/watch?v=mdWkKKSckNk
http://www.youtube.com/watch?v=KN-scfzy_qg
http://www.themill.com/work/spotify-for-music.aspx

And more. . .

Basically:

Accuracy are rays shot into the scene, this helps resolve complex lighting situations
Density helps with lack of detail on complex geometry.
Interpolation provides more smoothing (for a render hit)

Avoid the legacy radius controls since they require much more tuning (which is why they are hidden under a rollout). You might also benefit from making the Filter = 1 if your lighting has some high range values bouncing off shiny objects.
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.
 
Old 04-09-2013, 03:56 AM   #22
stallion151
constipated CG
 
stallion151's Avatar
M
Australia
 
Join Date: Apr 2003
Posts: 1,551
yeah i know...but also, some of us are still stuck in the past on 2011
__________________

 
Old 04-09-2013, 04:03 AM   #23
Bitter
Also Highly Corrosive
 
Bitter's Avatar
David Fer Real
Fixer of things
USA
 
Join Date: Apr 2003
Posts: 1,720
Quote:
Originally Posted by egglybagelface
The fgshooter shader and digital tutor lessons i've used and watched... but they're not efficient for full character animation. It seems final gather must be calculated for each additional camera you plan to use. Slow.


Not (completely) true, it calculates from each angle but uses the same screen projection space. So for example: if before you were calculating 1920 x 1080, then you are still calculating based on the same number of pixels but SHARING that space (not multiplying) with other viewpoint.

Quote:
Originally Posted by cineartist
EDIT: Oh... right I know about that one. Did not realize it included the force setting though. And it is not compatible with 2013.5


Force setting has been available in Maya for some time, you can choose it under the Final Gather menu as "no caching"

The UI from the Google Code page does not work in 2013.5 (SAP) because of how they changed localization mel. Probably will skip that and move to 2014 if there's a need. (It DOES work in 2013 SP2 however.)

Quote:
Originally Posted by cineartist
But all of that aside the native ibl might very well be the answer. And I'd like to find out how to access the brute force in Maya with strings since the script wont work until it is updated for 2014.


Native IBL is probably your best bet. PLEASE add the option for Light Relative Scale to your scene or legacy materials will be too bright. This is a bridge to newer lighting. You can use this with older materials with this setting without having to migrate shaders.

Again, look for the Non caching option in the Maya UI (the standard UI that comes with Maya) that is the "force" technique. This has been in the Maya UI for a few years now but poorly named perhaps.

Quote:
Originally Posted by zaskar
2. tweak Final Gather: progressive passes. Until maya2013 this option is only available using the enhanced UI.


Unless something has changed, that does not work in Maya. The translator overrides that string when exported. It's useful and works in Standalone. It's something Autodesk should include in Maya soon we hope.

Quote:
Originally Posted by zaskar
6. also important: the color source wich you use for the environment. An image with much variety in brightnes will create much noise in your scene and thus flickering. If you really need a hdr image for the env lighting, apply some (better: heavy) blur onto it to reduce the fg grain.


Correct, but unnecessary with Native IBL (Environment Lighting Mode)

Native IBL operates as DIRECT illumination from a smart area light. You should get better results with this. Final Gather will then ignore the environment light (already handled by the IBL) and instead only provide indirect lighting, object to object. You can see this effect in the Indirect Pass of your render.

http://elementalray.wordpress.com/2...ve-builtin-ibl/
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.

Last edited by Bitter : 04-09-2013 at 04:07 AM.
 
Old 04-09-2013, 04:05 AM   #24
Bitter
Also Highly Corrosive
 
Bitter's Avatar
David Fer Real
Fixer of things
USA
 
Join Date: Apr 2003
Posts: 1,720
Quote:
Originally Posted by stallion151
yeah i know...but also, some of us are still stuck in the past on 2011


Native IBL and the FGshooter are available at least. I think Native IBL was introduced in mental ray 3.8
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.
 
Old 04-09-2013, 05:50 AM   #25
sentry66
Expert
 
sentry66's Avatar
portfolio
node crazy
USA
 
Join Date: May 2008
Posts: 1,980
Quote:
Originally Posted by Bitter
Don't use an exposure node or lens shader. Preview all renders using the built-in LUT and colorspace mechanism in the Maya render view. Render to 16-half RGBA and EXR. Doing this preserves the data and allows you to see the final image after correction to your desired colorspace. The lens shaders are for baking in the colorspace and not very useful for a pipeline where you will post process the work. (Baking these colors and colorspace makes your life much more difficult, and framebuffers passes are correctly maintained as linear anyway)



That's what I was saying - don't trust the renderview.

Of course I render to 16 bit half EXR, that's where the problem comes in. EXR has so much more color range than what shows up in the render view. The only way to tune flicker is to render out EXR's then literally start composting your final look so you can see how far you end up pushing the darks and mid tones around.

The FG/GI workflow is such a joke at this point with a million hacks of which most are hidden.

composite first, render later
portal lights
different IBL env lights
multiple FG cameras
hidden attributes
hidden nodes
importons
FG
FG with specific animation settings, freezing and baking out FG maps
irradiance particles
renders that look great in the renderview, but flicker at the final compositing stage
renders that look great....until you zoom in for a close-up
renders that look great...until that dark corner is in view


12 years later and it still takes forever, still flickers, is more complicated than ever, and still doesn't produce accurate shadows.

The whole thing pisses me off that I've wasted so much time on such a mess of a feature, despite how great it can look.


I'm not kidding, one time my solution for killing the flicker and compensate for the slow render times was to render half the framerate and interpolate between the render frames to create a smoother transition so the flicker wasn't harsh and noticeable from frame to frame. It was one of those classic white background lit stages with perfect smooth plastic materials. Even with crazy cranked settings and 3 hours per frame on fast machines, the dark areas would still manage to flicker some. Rendering half the framerate and interpolating the missing frames saved the day since they were slow-panned shots.

Last edited by sentry66 : 04-09-2013 at 06:06 AM.
 
Old 04-09-2013, 06:15 AM   #26
Bitter
Also Highly Corrosive
 
Bitter's Avatar
David Fer Real
Fixer of things
USA
 
Join Date: Apr 2003
Posts: 1,720
You mention the photographic exposure node. If you use that then the Maya render view cannot show you the correct result unless you want it baked in. The render view also has an option for 32-bit viewing. This correctly tone maps the images like any other post software will provide. So bit depth should not be an issue.

I think if you tried the simple solutions like Native IBL, you'd be happier with the result. What I'm seeing suggested in this thread is a lot of legacy workflow that has been replaced. This will definitely cause frustration.
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.
 
Old 04-09-2013, 06:21 AM   #27
Bitter
Also Highly Corrosive
 
Bitter's Avatar
David Fer Real
Fixer of things
USA
 
Join Date: Apr 2003
Posts: 1,720
The YouTube links provide a few production examples. Do you have a scene you can share? It's not always easy but it can be at least easier. Anything that requires user input for measuring a scene will require more work than something brute force. The trade off is faster render times as opposed to sampling more.
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.
 
Old 04-09-2013, 06:27 AM   #28
sentry66
Expert
 
sentry66's Avatar
portfolio
node crazy
USA
 
Join Date: May 2008
Posts: 1,980
Yeah, I just went from maya 2009 to maya 2013.5 a few months ago and still haven't explored all the advances yet. I'll try out the 32 bit renderview mode.

So far, I've been underwhelmed at the MR development over the last 4 years. I'm struggling to think of anything that's significantly improved or become faster or easier.

Meanwhile, it doesn't seem like v-ray people are having much of an easier time with GI flicker
http://forums.cgsociety.org/showthr...09&page=1&pp=15

Last edited by sentry66 : 04-09-2013 at 06:33 AM.
 
Old 04-09-2013, 06:34 AM   #29
Bitter
Also Highly Corrosive
 
Bitter's Avatar
David Fer Real
Fixer of things
USA
 
Join Date: Apr 2003
Posts: 1,720
Flicker is the plague of interpolated schemes. No one is immune to that (including point based sss)

I think developers understand this problem and are working on flexible (and easy) alternatives. Bart from nVidia mentions the strengths of being able to blend between interpolated and brute force techniques in the future that could allow you to choose your desired workflow.
__________________
My opinions are always my own...and maybe a friend's, but never my employer's.
 
Old 04-09-2013, 06:38 AM   #30
cineartist
Student Of The Craft
 
cineartist's Avatar
portfolio
Richard Culver
Hayward, USA
 
Join Date: Oct 2010
Posts: 652
It is nice to finally have the big guns come in and set things straight.

And I feel like a completely idiot!

I was going to come here and post to that effect as I was reading the Mental Ray manual and then it hit me when it said force was "no cache". Looking back at the Maya interface I finally figured it out.
And I have seen so many threads of people trying to figure this out and no one mentioned it. Wow!

But now I also see that Bitter has set the record straight anyway.

It is right in the Maya Manual, I read it and thought that must be it, but for some reason it did not compute.

Under render settings:

Quote:
No FG Caching Select this option to disable final gather caching completely and always perform the full and accurate final gather computation. This option may reduce rendering time for simple scenes but increases rendering time for complex scenes.



Quote:
Native IBL is probably your best bet. PLEASE add the option for Light Relative Scale to your scene or legacy materials will be too bright. This is a bridge to newer lighting. You can use this with older materials with this setting without having to migrate shaders.


Bitter I am going to take your advice on the ibl thing. I got it figured out how to string it. But I was having an issue with the blown out shaders in a scene, so now I'll have to take a look at that solution.

I did enable the "environment lighting scale" but things still looked strange in that scene.

I suppose the Light Relative Scale is different?

And it is Scalar I suppose... I can not find it in the MR manual off hand. So I am not sure how to set it up.

And I am a little confused on the IBL Caching strings. Are they necessary? I assumed that would not be the same for asnimated scenes.... but I think I am confusing that with writing cache files. Seemed to work find without them. What is the advantage here?

Anyway, glad to finally get some answers.
 
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 02:30 AM.


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