This is taken from that link given by rmatt Just so you dont have to go looking for it…even tho reading the whole link will incredibly boost your knowlege of Final Gather, so get around to it sometime.
I was soo happy when I solved this problem!
[size=2]Reduce low-frequency flickering when using FG in animations
This is a two steps approach which requires mental ray standalone since Maya 6.0 does not provide support for the ‘FG only’ rendering mode use in step 1. ‘FG only’ just creates FGmaps on disk, no images are rendered when this mode is used. These maps will contain only FG precomputing points.
So, you are going to render an animation, say from frame.1 to frame.100 and the trick here is to pre-render in a first step one single FGmap or multiple FGmaps every n-th frames.
Notice that multiple FGmaps are useful in two situations:
[li]when single FG map size is too big [/li]> [li]when there are many hosts (more than mental ray can utilize effectively for multihosted rendering), so multiple FG maps are required to parallelize step 1 over many hosts. [/li]> [/list]If none of these apply, rendering with multiple FG maps is roughly same effective as rendering with one big finalgather map.
Either you have one or multiple FGmaps they will both act as helper(s) in the following Step 2, where we will use such FGmap(s) without evaluating any FG precomputation point (rebuild freeze), only eventual rendering points will be computed.
Step 1 - Rendering FG only
The first thing to do is decide if you want one single FG map or if you want to use n-FGmaps every n-th frames:
1.a - Rendering one single FGmap file
[li]set finalgather ‘only’[/li]
[li]set FG rebuild to ‘off’ [/li]> [li]specify one single FGmap fine name [/li]> [li]Render each n-th frame (n depends on the camera movement speed and the scene). [/li]> [/ul]You will end up with one single FGmap file which contains irradiance informations sampled every n-th frame allover our timeframe. Since rebuild is off we are sure we didn’t recompute any point, but just new points and those were appended to the single FGmap.
1.b - Rendering multiple FGmaps files (say we render every 10 frames, keep in mind the gap depends on the camera movement speed and the scene)
[li]set finalgather ‘only’[/li]
[li]set FG rebuild to ‘off’ [/li]> [li]render frame 10-th on host A with a FG name [“map010”] [/li]> [li]When this is ready, render frame 20-th on host A with [“map020”, “map010”] [/li]> [li]and simultaneously render frame 30-th on HOST B with [“map030”, “map010”] [/li]> [li]and so on…[/li]
With multihosted rendering, the idea is to render at least 1 frame on a single (or few with multihosting) host, and when render further frames using all maps which are already finished.
If possible, it is a good idea not to interleave subsequent frames across hosts, but make host A render maps for each 10th frame in the range 0 to 100, host B render each 10th frame in the range 101 to 200, etc. This reduces the amount of redundancy.
You will end up with n FGmap files which contains irradiance informations sampled every n-th frame, since rebuild id set to off each FGmap will contain only the new FG points compared to the previous FGmap, without recomputing any point. Obviously the first map will contain a complete set of points for its relative first frame.
IMPORTANT: In this phase no images are rendered: only FG map(s) are generated.
Step 2 - Rendering with rebuild freeze
In this phase you are not calculating any precomputation FG points, only rendering FG points, and those points won’t be added to the FG maps on disk. This logic should guarantee a more coherent set of cached irradiance points trough time, where extra points are gathered only when requested at rendertime, therefore producing less flickering.
[li]finalgather ‘on’ (or finalgather ‘fastlookup’ if you are also using GI) [/li]> [li]set FG rebuild to ‘freeze’ [/li]> [li]specify either the single FGmap name of step 1.a or all FG maps created in step 1.b (note that using as many of FG maps as possible is recommended). [/li]> [/ul]