bf/lc for animation

[super gnu]

ok so i generally dont use "the universal method" or brute force at all. but ive been toying with it recently for high quality animation with moving objects.. however what settings are people using for lightcache? ive followed the universal method instructions but it doesnt mention changing the lc subdivisions.. i get terrible noise in the gi, since the brute force is basing its calcs on a crap flickery lightcache. ive cranked up the lightcache to 7000 and reduced sample size, with a heavy pre-filter of 70, but still getting wobbly lighting. its a very simple interior with some moving boxes and flat shaded walls.


i thought the universal method was almost foolproof? i assumed this was good for animation too?

[sduck]

In the MultiScatter forum Karba suggests:

AA fixed rate 8 or more
Light - Dome Light
GI - Brute Force

in general - without any interpolation like Irr Map or LC

[super gnu]

hehe i can possibly, at a push, swallow the rendertimes for a bf/lc combination, on a simple scene. i dont think ive ever actually let a bf/bf render reach the end in my whole vray career.. takes an extraordinary amount of time, particularly on interiors where you need lots of bounces..

i may have been mistaken but i thought people had been using "the universal method" or a variation of it for animations with very good results?

[joconnell]

Does brute force use the lc map as a guide at all? As far as I'm aware brute force as a primary doesn't bother taking any other method as a "hint" since it's tracing every pixel anyway? What type of noise are you getting? If it's pixel level grain then it';snothing to do with your lc - the two are unrelated so you're just down to aa, gi samples or dmc settings.

[super gnu]

well youll notice you get a very different look (and rendertime) if you choose lc or bf for secondary, if youre using bf for primary, so it must be doing something!

as i understand it, primary bounces do the first bounce, from the camera, to all the visible points in your scene. if its imap, it does less, and interpolates, if its bf it does every pixel.

depending on the subdivisions, these initial samples shoot a number of rays out from each point. these rays hit other points on the model, not necessarily in view. since the secondary bounces have already been calculated, the lighting has been approximated for all surfaces, so the primary rays can take light measurements from those points. these are averaged together to get the primary lighting values for the visible points. this is why the secondary can be less accurate, since the primaries will average together hundreds of samples from various points in the secondary solution (plus any direct lighting that is hitting surfaces-hence "store direct illum", in lc speeds things up.. the primaries can take all their light info from the lc instead of bothering with the direct lights.)

i hope i understand it correctly cos im producing a course on this stuff

[super gnu]

-the noise im getting is flickery blotches around shadow gaps and stuff.. definitely not pixel level stuff.. ive cleaned it up by using very high lc settings and interpolation. ended up raising sample size and interpolation to blur LC, and increasing subdivs to 5000.. now it renders relatively clean, although if you look carefully.....

[joconnell]

Yep - brute force errors are pixel level grain common to ray traced brute force or area shadow sampling, blotches are common to the approximated or undersampling blurry methods.

You're totally right on the difference in look between bf or lc for secondaries. LC will almost do infinite bounces through your scene to fill it with light and be rather quick since it's doing an approximated version of the scene lighting. Brute force is far more accurate but a slower method due to far more rays being cast so you get a cut off for the amount of times the light can bounce in the scene before being stopped. The default of 3 is probably a good value where it bounces enough to fill up your scene with light but won't murder you on render times. If you were to up it to 4, you might find that while it'll add a lot to your render time, your image might only get a few percent brighter so it might not really be worth it. It can't compare however in terms of brightness to light cache which will bounce many more times than 3 and thus give you even more light again - a bf / lc render will always be brighter than a bf / bf render at default settings because of this.

Also the secondary can be less accurate since there's very little sharp detail in those bounces - The direct light will be nice and sharp with it's shadows, the first bounce will be nice and sharp since you have the first bits of rays spreading off similar angled surfaces and giving quite sharp details in corners as an example. The secondary bounce is the scattered rays of the scattered primary rays so from this point onwards it gets so soft and diffuse there's no major benefit from trying to use a really precise method - it'll just add in a huge amount of rays which will return a precise but ultimately quite grainy solution and it'll take either a lot of extra subdivision rays to get a proper solution for the lighting, or a tonne of aa to smooth out the grain. Ultimately when it's clean enough it'll probably look quite soft and diffuse, which is almost the same visual result as using one of the approximated methods except they'll take a fraction of the time.

I musty admit I've never had to go that high on LC samples though - perhaps it's necessary for long distance camera fly throughs in world space sample mode but I normally get good results from the default values.

[super gnu]

thanks for the pointers, unfortunately for me, im demonstrating the various techniques available for rendering animated scenes with gi.. so i made a nice difficult test.. small interior with flat light grey walls, very small window with a single ray of sunlight hitting the floor, and bright red boxes passing through the ray of light intermittently. just to make things more difficult i put chunky shadow gaps in the walls.

probably i should have designed an easier scene to light, but i wanted to show a real challenge.. hence the high settings i guess.

the main problem i have is that at default lightcache settings it shimmers terribly from frame to frame (not grain but blotches) , particularly around the shadow gaps, as i guess the lc is so bad, that the bf calcs are getting different measurements for every ray they send out. my final settings for the demonstration were 130 bf subdivs, 4000 lc with a large sample size and heaavy pre-filter of 45. this meant i had a very blurred, but relatively flicker free lightcache for the bf to gather lighting info from. ended up about 16 mins a frame at 600x400


done and dusted now.

[joconnell]

Exactly - it's a bit of a hell test alright. For stuff like that I'm generally tempted to break the render into a static object pass and a moving object pass and recombine them later on so you get the speed benefits of caching on the static elements and don't take the hit each time while working out the correct settings for the animated bits. I'd imagine that with your scene there's a pretty good chance that you're getting a few "rogue" lc samples hitting off your red box which are shimmering all over the place and only appearing for a frame or two.

[super gnu]

yep.. i covered bf/lc, imap/lc, imap/lc with animation mode, and precalculating the bg and comping in the moving elements as options.. none of them perfect but gives a range of options.. i guess it all depends wether you have no time to tweak, but a huge renderfarm, or time to tweak but not many machines. lucky you if you have time and lots of machines. the other option isnt really an option when youre doing moving objects!