Final Gather

[dprgb]

The final gather algorithm isn't a global calculation - it's view dependent. So, unlike photon maps, it has to be calculated for each view.

If you have the 'rebuild' unchecked, as you render it will continue updating and appending the final gather map file (you can watch it do this in Windows Explorer - each time you render, it will change the file date and make it larger in size). As you render more views, it will require less samples (as the samples have already been created from a different view), speeding up the renders. But, it will still have to go through a final gather calc to determine what samples it needs.

I just tried with the good ol' teapot on a plane with a camera. I rendered it out with final gather, save to a file, and rebuild checked. The first rendering was about 18 seconds. Then, I unchecked rebuild and rendered the same view. Now it was 3 seconds. Then I rotated the view about 90 degrees, the rendering time was 11 seconds. Then I rotated again, rendering time was 7 seconds. After that it started averaging out around 4 seconds or so, so as you can see it was caching the info as I rendered more views.

You could always set up a camera that moves/rotates throughout a scene and render the animation overnight to 'fill' a final gather file with data so the next day renderings would be quicker. I think it only works if the camera's the only thing moving throughout the renderings, if you have objects or lights moving you'll have to recalc the final gather map.

[Byteman3D]

I started writing this message before dapeter2's message is on, but by the time I've finished writing, I've seen he has already beautifully explained the situation. I just wish to post my message as well -just incase anyone might have additional benefits .

In order to achieve the full potential of final gather maps,
1. Uncheck "Rebuild"
2. Check "Use File" and assign a file name.
3. Optionally check "Fast Lookup" - Fast lookup creates a lookup table to reduce rendering time, at the cost of some wait at the GI calculation phase. (It changes the overall rendering time considerably)

Mental Ray's way of keeping final gather maps, is not just like rendering a map and reusing it in the next renders. Mental Ray benefits from distributing final gather points over time.

When you turn on fgmaps, it renders the frame with some number of fg samples and saves a fgmap. In the next frame you render, it uses the samples from the fgmap and adds some more samples as required for that current frame. Operation continues on each new frame.

Fgmap size increases as you render more frames and quality of the image also increases as you render more frames.
Since there is little amount of motion change between consecutive frames during a walkthrough, you leave yor scene to render and the first frame takes a long time, where the next frame time drops considerably, because it casts a limited number of samples for the newly introduced area. Nevertheless, your image quality also improves by time, because these samples are randomly distributed over the scene so an area which doesn't have enough samples on one frame, might -and will- have more samples in the next frames.

To give an example with numbers, one of my scenes rendered the first frame with 1000 samples and default radius values in 30 minutes. Next few frames took less than 10 minutes gradually going down to 3 minutes in about 50 frames. After this time the scene was stable, and after a rendering of 40 seconds of the animation, fgmap size was 120 mb's. With that fgmap in use, the first frame also renders in less than 2 minutes and image quality is great.
If I check rebuild and render the scene it -DELETES the fgmap file- again takes 30 minutes but image quality is worse.

From the above example you might notice, it's a good idea to have a precalculation render before the final render. This precalculation render might be done having lower antialiasing samples -to improve rendering times, but should NOT have a lower resolution. It degrades quality.

Sample radius is important for the amount of detail you wish to see on fg effects. If you wish to see fg type shades on very little details, you still have to keep sample radii values very low- at your detail level and fgmap doesn't help much to your rendering times. It helps, but still takes a very long time.

You might need a lot of experimenting with mental ray. If you are using two computers for example, and render the scene with fgmaps, you can't simply assign a portion of the animation to the other computer, because there might be a sudden change in quality. You might have that problem even when changing the order of rendered frames. (eg. You render from 100 to 150 first, then 0 to 99) There will be a quality difference between frames before 99 and after 100.

By the way be careful if you wish to change the radius values after saving a fgmap. In the previous versions of Mental Ray, changing radius was destroying the effect of fgmap data. Currently it seems improved but quality change is reflected to your scene - just like one portion of the wall having some quality and another portion having a different quality.

Good luck

[Scrat-D]

Thanks a lot guys! Your posts really helped!:)

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.