PDA

View Full Version : Final Gather - Min Max settings...


Arcon
11-21-2005, 08:22 AM
I'm in the middle of a viz project right now, getting ready to do my first test render sequence. my method for radiosity will be using frozen FG maps, it all looks great so far the only thing which can kill me now is FG flicker ;)

basically i have 3 options with Min Max, leaving them at 0 and letting Maya calculate it, using values based on scene size (the only method i have experience with for animation), and the View method. (btw i'm using maya 6.5, one secondary diffuse bounce).

testing with stills indicates that neither method really looks better than the others. with 500 rays, most surfaces can look pretty good but on some smaller complex surfaces there can be a few blotches, nothing major. the only thing i'm really concerned about with the other methods is FG flicker. in my experience using scene-size Min Max values for animation, the result is predictable with no noticeable flicker. are both other methods just as predicatable...? what's the best settings for View... 1-5..? i did a test with those settings and it took *exactly* the same time as the scene-size method ;)

one last question... maybe a stoopid one :) when i'm rendering every 50 frames or so building up the FG map, does it matter what the camera starts looking at the beginning of the animation..? eg. initially its looking at empty space but then pans up to the building. i make sure to render a new frame whenever there a major camera change, like around a wall or objects etc.

any info much appreciated.

cheers

-Vormav-
11-21-2005, 08:50 AM
The automatic settings for FG sizes usually do the trick. But it can be unpredictable sometimes... I prefer to set the sizes manually, personally.
I also usually go for at least 1000 samples for FG when doing any animations. I've had too many cases where I've done quick render tests with lower settings, was convinced I had enough samples, and then ended up with flickering after 10 hours of rendering... :banghead:

Dealing with a panning camera and cached FG maps can be kind of tricky. People always tell me that, as the FG maps are camera-dependent, you *have* to re-calculate the FG every single time the camera moves. I don't know how accurate this is, as I've had a lot of cases where I've been able to move the camera and load an FG solution from the camera's previous position without any noticable problems. But if you're doing a pan, I think you'd need to calculate the FG from a view that covers the entire panned area, no?
If you're just doing a pan (no animated objects), and your geometry isn't too complex, maybe baking the FG into your objects would be better? That would at least completely eliminate the flicker problem, not to mention dealing with speed issues.

Arcon
11-21-2005, 09:47 AM
Dealing with a panning camera and cached FG maps can be kind of tricky. People always tell me that, as the FG maps are camera-dependent, you *have* to re-calculate the FG every single time the camera moves.


FG maps might be camera dependant but that's no reason for re-calculating FG every frame, quite the opposite. someone correct me if i'm wrong, (heh i'm pretty sure i'm not ;) ) but rebuilding the FG map every frame is almost guarantueed to get flicker problems, becuase you're 'rebuilding' the final gather - as the camera moves it samples new areas of objects AND it 'rebuilds' all areas, including the areas you've just rendered the frame before (the overall result will be slightly different). 2000+ rays can help but not always, and by the time it finished i would've rotted.

the solution is to append data to the FG file when the camera turns and you see a different aspect of an object, but don't overwrite the earlier FG data (render frame 1 with rebuild on, render every subsequent group of frames with rebuild off, the duration of the group of frames varies with the camera animation). after that's all done a 'freeze' render of the whole thing stops appending information, and basically does a normal render and MR just slaps on the radiosity info, render time per frame is then usually less than half of a rebuild frame. a global FG map file name needs to specified for this to work.

the thing i'm not sure about is starting out with everything out of the viewport, but i guess it should just append a lot more info as i render a few more frames... heh will find out soon.

obviously none of this works with animated lights ;) or objects for that matter, as soon as they move their FG data gets "stuck" in the map. but in viz work i find most animated objects don't really need radiosity, and can be easily faked on a per-object basis if needed.

baking in viz work is a BAD idea. it wastes an *immense* amount of production time, in the time it takes to do baking alone, for a typical viz scene with over 5,000 objects, i could do another contract ;) and the results look nowhere near as good, you have to be much more careful with UVs, even then then the radiosity just doesn't look as good as a render, and the amount of maps needed is huge.... oh one more bad thing, worst of all, no flexibility. after all that produciton time and the Art Director changes something, maps in the affected areas are worthless. heh i know i'm dissing baking but its cost me in the past.

anyway now that dual cores are here its really helped the rendertime situation :thumbsup:

-Vormav-
11-21-2005, 10:10 AM
baking in viz work is a BAD idea. it wastes an *immense* amount of production time, in the time it takes to do baking alone, for a typical viz scene with over 5,000 objects, i could do another contract ;) and the results look nowhere near as good, you have to be much more careful with UVs, even then then the radiosity just doesn't look as good as a render, and the amount of maps needed is huge.... oh one more bad thing, worst of all, no flexibility. after all that produciton time and the Art Director changes something, maps in the affected areas are worthless. heh i know i'm dissing baking but its cost me in the past.
Heh, yeah. I should've stressed the "not too complex" part. :p

I don't know how global FG are calculated, but it seems that, since FG rays are sent out from the camera, you'd *have* to have everything in the viewport. Maybe that works differently, though?
Well, hope it works for you.

Arcon
11-22-2005, 10:08 AM
I don't know how global FG are calculated, but it seems that, since FG rays are sent out from the camera, you'd *have* to have everything in the viewport. Maybe that works differently, though?

just tested today and it works perfect no matter where the camera starts. as you go through every 20th frame with rebuild off the new FG data is added anyway.

CGTalk Moderation
11-22-2005, 10:08 AM
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.