Mray No flicker Final Gather/GI for fully animated characters with camera animation?


#1

Title says it all!

I’ve found a thousand tutorials for flicker free animation methods for fly-thru camera only animation but not one of any value for scenes involving characters that touch other characters and backgrounds/props.

“Rebuild On” is a must is the only piece of info I gathered.

Greatly appreciate any info!


#2

subscribed. I need to know this too. Astonishing how hard it is to find good info on the subject anywhere on the internet (that isn’t for Max)


#3

Do a CGTalk search for FGShooter (.mel)

Cheers,
G!


#4

File/Send to Softimage…

Joking aside, you’ll find this tutorial helpful:

http://www.digitaltutors.com/tutorial/890-Rendering-Flicker-Free-Final-Gather-in-Maya

I think there is a free trial period. It does go into the multi-camera trick.

The reason is for some cockeyed reason there is no brute force setting in Maya like there is for instance in Softimage . In Softimage there is an Exact setting which is useful otherwise you will be on the constant search for a way to tame flicker.

This guide will be a very helpful read. Even though it is for LightWave it gives you a very solid understanding of what is happening with interpolation.

http://www.except.nl/lightwave/RadiosityGuide96/index.htm


#5

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.


#6

So nobody has any production experience with this?


#7

There is lots of production experience with this. If you are like me you have searched the internet and followed the same threads that lead to dead ends or convoluted sounding solutions that usually are limited in terms of boxing you into a lighting corner or don’t work. Or require composting as a workaround.

Usually when people have pointed to flicker free solutions in Maya, to me they just look like over-lit crap.

The bottom line is you don't have control over flicker in the settings for FG in Mental Ray for Maya. It is just how he states it in that DT tutorial. The solutions in that tutorial are all that there is for Mental Ray in Maya.

Which is why the camera trick is the thing. Slow or not. Rendering flicker free in any app is slow. That is just how it is.

The other options are to use 3P rendering solutions starting with 3Delight - free with 2 cores, Final Render, Vray of course, Maxwell and so on.

That's how I understand it which is why I jokingly said the answer is File/Send to Softimage. Really. That's it. You can render flicker free in Mental Ray with Softimage for a price - render time.

The reason you are not getting answers is because you already got all there is.

If I am wrong, I am glad to be pointed just as you, to the solution. But, I think you know now why so many people use Vray or other 3P solutions for Maya.

I hand you this advice that comes from a year or more of testing, research and study on this very subject. I can give you more specifics on each solution if you would like.

Also, as you, I am open to ideas. But I have not found any in a year of searching.


#8

Thankyou so much for your answer. I predicted as much about the half-assed solution for mentalray for maya. I’m watching the render tests Maya’s spitting out now and I lucky enough to have fast enough motion where the flicker isn’t noticeable as much. I’m a 3delight man at heart and always get beautiful results, but unfortunately I am forced to use mentalray for this project.

I’ve done some tests in After Effects and I’ve got some decent results with a little tweaking. Sux.

Thank you for saving me days of searching forums.


#9

lol… yeah… it can suck up your time…

But all of that said, I am revisiting the Maya FG settings to see if there is not a trick buried in there to access the brute force FG that is in Mental Ray. It is there in in XSI. Seems to be no setting for it in Maya… but I am gonna try and crack it if I can.

So stay tuned… maybe not for this project… but just for the sake of knowing…I’ll post results good or bad here when I get something.:slight_smile:


#10

After many product presentation animations using maya mental ray i also tend to “brute force” FG (in a meaning of pushing up certain values) to get it flicker free but that doesnt neccessarily mean that it will take much time. Also i dont think that you need Softimage to get good imagery out of mental ray. Here are some thoughts that might help:

  1. first get an enhanced Render Global Settins UI, for example http://www.creativecrash.com/maya/downloads/scripts-plugins/rendering/c/mentalray-3-9-native-integration
    this just gives you some additional controls compared to the standard Render Globals

  2. tweak Final Gather: progressive passes. Until maya2013 this option is only available using the enhanced UI. The default is set to 3 and this is good for the most cases, but sometimes one more adaptive pass is bit faster, depending on your scene of course. Its very usefull to check this out if much of your image area is covered by background or consistent color. If you render animation sequences and use a render farm, do not use multiple clients for a single image because this produces some delay between the fg progressive passes (all clients need to finish a pass before the next pass starts).

  3. a value of 1 for secondary diffuse bounces should be sufficient, deeper tracing wont result into much more noticeable improvements but will lead to higher render times

  4. set final gather mode to “multiframe” for animations, the rebuilt option of course set to on

  5. most important, the weighting between final gather accuracy and point density. Also here is the point where you can get something like a “brute force” setup. The value for accuracy is the amount of rays which is used to get the environment color for a single point sampled. The point density is the amount of sampled points which alltogether are finally interpolated to produce the FG result. So the wrong setting is: high accuracy and low point density, this tends to compute too less information for the interpolator for the final appearance of the “FG occlusion effect”. Might be sufficient for still renderings but leads to flickering in animations. Its much better to reduce accuracy and push up the point density. I usually set the accuracy to 30 - 100 rays and therefore the density to 5 - 10, sometimes if i need sharper FG details up to 30 - 50.

  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. Also you can use one of the switch shader to set its influence to only in fg calculation while the visible image is your original, unblurred image. But to reduce sources for flicker, consider a procedural shader (projected ramp etc) as input for the ibl node.


#11

Hey great post. Thanks for sharing all of that. Lots of useful information there.

Actually I am kind of tracking in the same direction.

Of course I was referring to the brute force setting - which I still don’t understand why is not implemented in Maya. :slight_smile:

Here is the Softimage setting:

Exact mode bypasses the final gathering point cache entirely and computes the full final gathering solution for every sample, rather than interpolate between final gathering points. This takes time but will yield superior results. The only Accuracy parameter used to control this mode is the Number of Rays.

Your post confirms testing I am doing right now. I don’t think you can get rid of the flicker but I think you can “brute force it” with point density. But also that said, you never really get a clean image out of brute force anyway. So I think at the end of the day it is the same result. As long as you can reduce the noise to a small enough level it looses visibility to the eye for practical purposes.

The only other thing I would add from my testing now is the interpolation setting. It makes sense to keep that to 1.

I think in general you want to stay away from anything that interpolates. So this is where Maya differs and the setting needs to go to 0 so you don’t have any interpolation.

Again as in here:

Exact mode bypasses the final gathering point cache entirely and computes the full final gathering solution for every sample, rather than interpolate between final gathering points.

And the Multiframe setting. That is an interpolation setting in Mental Ray.

Multiframe mode targets rendering of camera fly-through animations. To avoid picking up illumination from distant objects which is possible in the Automatic mode, set the Max Radius option to limit the maximal distance, within which, if sufficient finalgather points are not found, the illumination is smoothly faded to black. This mode is typically useful for animated scenes, but is not the best method for animation where flickering is not a problem. It can also be used for still images without animation.

                             The Accuracy parameters used to control this mode are the Number of Rays, the Max Radius, the optional View Dependent flag,                                  and the finalgather Points used for the interpolation.

That is the setting to avoid in Softimage Mental Ray for flicker free animation and I believe it is the same in Maya so I don’t see the advantage in using it.

I could be wrong. But…

Like you said, I think the most important is the point density.

And I would also add to that a low AA contrast setting to force the AA to pick up more subtle details in the interpolation and smooth those. That setting can make much more difference than higher AA.

In short, I think you want to basically try and replicate brute force (no interpolation) as much as possible.

Reduce the samples area as much as possible with point density and smooth it with AA. That is pretty much the brute force method.

Another smaller point. From my testing I think I am finding that point density caps out at a certain level and starts to do little if anything without higher Accuracy rays.

But… we are talking about characters… so I am going to do some testing and see how that pans out with deformations in MR for Maya with these ideas. Something on my list to get sorted here.


#12

Yes i also noticed that higher accuracy is needed to add further detail if the point density is already high. For animations we need to limit render time so my intention was to think about a “sweet spot” in accuracy/density because if you set a fixed amount of rays (sum of points multiplied by rays) there is a noticeable visual difference depending on the weighting of the number of rays/points.

edit: just had a look into the fg modes using the enhanced UI - and there is menu item called “force” which disables point density. Should be the true brute force trigger for maya…


#13

True.

Nice!

Is that enhanced UI compatiable with 2013.5?

And can these be accessed in another way say via strings?

Maybe I’ll have to look at that link

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


#14

Actually also I found this which I knew about before, but reading again realize it also may lead to a flicker free solution:

http://elementalray.wordpress.com/category/optimization/

Interesting information on the Native Ibl as a source of light to actually produce a brute force solution without final gather.

And also I am kind of experimenting more with the accuracy rays at extreme high numbers and going with much lower point density. It seems for test renders anyway you get a much better result for much less time. And in theory it might work to start with something like Accuracy of 20,000 and a point density of .2 and then work your way up in point density very gradually until flicker goes away. Accuracy has the effect of directing more rays where they are needed in the dark areas. I would think this would be the same for surface detail and hair as well. But it would take more experiments.

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.


#15

OK as promised here is the first test:

                 This is my theory:
                 
                 Two most important things:
                 
                 1) Accuracy.
                 
                 The accuracy setting is like a energy concentrator to the areas of the image that need calculation of light bounces. Primarily dark areas.
                 
                 In these examples you can see by the diagnosis, (little green dots) where the calculation is being directed to.
                 
                 Here is Point Density of .100 (point 100) and accuracy of 100. 

                 Here is Point Density of  .100 and accuracy of 500.

The distribution of rays is concentrated in the areas of darkness or areas that have noise.

                 By contrast here is point density of .500 and Accuracy of 100.

There are more rays cast in the scene but the calculation time is wasted returning values that do not contribute to a more accurate reading to lessen the noise.

                 Both take exactly the same time to render.
                 
                 However using Point Density of .500 and Accuracy of 100 is noisier:

And Accuracy 500 with PD of .100 is far less noisy for the same render time hit:

  1. Is basically just AA contrast setting low enough to have less contrast needed in order to apply filtering. This helps in the noisy areas that get flicker which are otherwise not enough contrast to get more filter applied.

               For this test that is basically it. 
               
               In a nutshell you can get far less noise for much less render time using Accuracy. I think in this case at least 4X faster. And it works on a moving character!
            
            The proof is in the test.
            
            The Test Scene:
            
            A moving character with ncloth dynamics. (Actually a scene from DT training on nCloth)
               
               To render this out it was a Point Density of .500 and 10,000 on the accuracy setting with AA  of 2 and a contrast of .010.
               
               Someone far more familiar with AA in Maya could probably tweak this better. But for this test it worked. Render times on my Machine were about 10 mins per frame. And that is leaving a lot of headroom for improvement. For a more demanding scene you could easy crank these levels higher. But for this scene it is basically stable with no visible flicker. It is there in the dark areas, but it is moving to fast to see. If could be reduced though with higher settings. But I found it very stable looking and nothing stood out as problematic. Even frame by frame nothing stood out as flicker that I could notice.
              
              The scene is just the standard Ibl with an hdri as the sole lighting source. Nothing fancy there. And no lights.
               
               You can download a packet of the frames I rendered out in .png here:
               
               [Dance Test](http://a360.co/10xBHt5)
               
               Load them up in fcheck and have a look.
               
               My next test will be to up the anti and add some bump mapping, textures and a more demanding lighting scenario. Perhaps even a character moving slower.
               
               My guess is that adding detail may require a higher Point Density. I will see.
              
              But overall I am actually eating my words. I am impressed with Mental Ray in Maya with this test in this scenario compared to other render engines I have done similar testing on. It is surprisingly stable.
    
 EDIT: Having a heck of a time with AD360. If there are probs seeing the images or DL the file let me know. 

Sigh… AD360 seems to keep turning off sharing on that file. Going to have to sort it.


#16

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.


#17

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?


#18

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.


#19

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.
  1. 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.


#20

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. :cool: