Animation Rendering Problems, noise and Loooong rendering times

[JOAN_LORD]

Hey everyone,

I am a visualiser for an architect company, I'm currently doing a minute long animation. I usually only do still Images so I never have a problem with noise or rendering times, So I am in very deep water to what I'm used to.

I did my pre calcs on Thursday last week, the LC only took 30 minutes but the IM took over 24 hours, which was a shock to me but at the same time it was a good 1400 frames with a day to night change with lots of lights etc...

Please see attached Images, is it because my LC & IM settings were not correct or was it because (and i'm only just realising now) that I had a very large plane in the model that shoots off into the distance for an aerial pass that's separate to this animation. the render times average between 6 minutes for the day shots, and 11 minutes for night time, is this normal? I'm using a 24 core threaded machine (at 3.6gz) with 24gig of ram.

Any help would be much appreciated. apologies for the censoring of some of the images, I cant disclose the location of this quiet yet, once it has a public consolation I'll be more than happy showing you guys the full animation, I'm really happy with the way this is looking, besides this annoying few glitches

Here's a list of my Settings:

Resolution of rendering: 1280 x 720
Image Sampler: Adaptive DMC - Min 2 - Max 6
Irradiance Map - Medium Animation Presets
Hsph Sub Divs - 25
Inter Samples - 50
Interopolation Least Squares
Sample Lookup Density Based

(I used add to incremental to LC then removed the LC from secondary Bounces) - I also rendered every 8th Frame for the IM.

Light Cache - Subdivs 6000, Sample size 20.00mm, scale world, num of passes 24. Use Glossy rays OFF, I used the fly-through Mode to calc LC.


Thanks

[LarsSonparsson]

One quick question. Do you have reflective caustics on in gi settings?
That could cause those light spots/leaks.

[JOAN_LORD]

Hi, No Caustics are switched off completely.

[JOAN_LORD]

I just thought, does the light cache as primary and secondary too add to increment (iradiance map) work when I have moving animated people and lights that move? what's another way I've heard of the brute force technique, how significant is the render time penalty to quality ratio on this, is it the only thing to use when im using moving objects and lights?

[JOAN_LORD]

Also - Any particular reason the Vray Sphere's are showing as black in the shadows? - Maybe because I used every 8nth frame for the I.M.? - I'm going to re do the animation using no plane for the boundary extents, so hopefully cutting out an extremely large catchment area for the LC and IM to calculate and not wasting Rays : ) also I'm going to reduce the reso to 1024 x 576, hopefully, with this and I'm going to also render every 2ndth Frame for the IM (even though I know it'll take a long time to calc) should reduce any noise? - or do I need to do EVERY frame if I am animating materials, people and lights that move and change with intensity?

I know I'm going on a bit here but one last thing...

When it comes to animating the intensity and visibility of a Vray Light, Do I use the Visibility in the track view or so I animate an intensity range from 0 to X?

Cheers everyone!

[super gnu]

to be honest 11 minutes a frame isnt out of the ordinary for animation work.. do you have a renderfarm to use? trying to render a 1400 frame seq. on a single machine (however powerful) is a bit of a downer. most of my animation work seems to end up taking about 1 hr a frame after ive cranked the quality up to final settings. but its generally massive (many sq km) masterplans and motion blur with hi aa settings at 1080p that does that.

regarding moving people or animated lighting changes, you cant use multiframe incremental to do the gi. it stores a static lighting solution thats based on (essentially) an average of the lighting throughout the animation..

to deal with animated geometry or lights, youre gonna need to use "animation mode" or brute force and lightcache (or if youre a masochist, brute force/brute force) the spot3d help files are useful to tell you what each mode is good for. all of these methods will likely drastically increase your rendertimes.

anything involving brute force is generally really slow. animation mode might be your best bet, but the imap will need to be done every frame, so youll have to drop your settings if you dont want it to take longer than your last one. it also increases rendertime so be prepared.

when Lasse asked if you had reflective and refractive caustics switched on, he was talking about GI caustics not photon mapped caustics. sorry if you already realised this.. its just refractive gi caustics is ON by default, and can cause blotchies like you have.. reflective gi caustics is even worse, but is off by default.

your blotches could be caused by your animated elements though.

[super gnu]

another option would be to render the part where the lighting changes from day to night, twice, once with the day lighting, once with night, then crossfade the frames after.. not perfect but avoids slow rendering methods.

to deal with moving objects that are small, i.e. people, i have a trick for you.


make sure the people have vray materials on them.

find the checkbox in the material "use irradiance map"

turn it off.

this means any objects with that material on will use brute force for their lighting.

do this for all people.

hide all people.

calculate lighting for scene.

unhide people


render!



the brute force subdivs are taken from the imap hsph subdivs setting in this case. after calculating lighting, you can drop this number if the people take too long to render.

you must either use brute force for secondaries, or make sure you have a saved lightcache loaded in the sec. bounces slot.


this way you get fixed lighting for the scene, but per frame animated gi for the people. a bit of AO will make up for missing gi effects of the people on their surroundings.

[MoonDoggie]

Hsph Sub Divs - 25
Inter Samples - 50

^

25 HSph? Those look like they're opposite of what I use, 50, 25... You're blending between a bunch of samples, leading to a really blurry GI solution. I would revisit these settings sometime if you have time.

[JOAN_LORD]

super gnu - Thank you very much with the reply, My Director has asked me to do another 2 animations after this one because he has enjoyed the samples I've given him, so I've shot my self in the foot now lol

So just so I understand you correctly, I should have BF for primary, and LC for secondary using flythrough mode? Or the Animation mode in IM and BF for secondary? - does this keep a stable solution or will it end up flickering?

Thanks Moon Doggie - I'll keep that in mind the next time I use IM, (very soon)....

[super gnu]

to do proper animated GI, you have 3 (well 4 but we can discount bf/bf as its rediculously slooow) options:

bf/lc: the lc should be on single frame, but play around with the settings to get as blurry but stable looking lc solution. to check this set lc/lc and do some test frames, see if it shimmers. if so, increase sample size, increase subdivs and increase filtering.. this will improve and blur the lc. once you have something that looks relatively glitch free (but low detail is fine) switch back to bf/lc and play around with the bf subdivs until its not too grainy. voila.. long rendertimes but accurate animated gi.

im with animation mode/lc: same rules apply for the lc. you could also try bf for secondaries, but it will probably take longer to render/ be a bit darker/ however may be cleaner. animation mode isnt perfect. you still need pretty high im settings to get a good result, and you have to precalc a map for every frame, which takes a while. it basically blends the lighting solution over the frames immediately before and after the one that is rendering. this reduces shimmering, or rather slows it down until its less noticeable.

im/ bf or lc all on single frame mode. this is the same settings youd use for a still. with high enough settings, this can work, but you really need very high settings.


basically to do animated gi you cant use anything involving incremental additions or flythrough mode.

also check the "use camera path" options in the im and lc as these can improve quality when animating scenes.


as moondoggie said.. 25 hsph subdivs is way too low for animated gi, or, well, anything really. default of 50 is too low really. depending on scene and method chosen, you may have to use a setting in the 100's


since you appear to have promised your boss more animation, just avoid animated lighting or geometry (or use my trick for small animated elements) then u can use simple multiframe incremental imap and flythrough mode lightcache. probably only calcing the imap every 15th or 20th frame. will be a world quicker and cleaner to render.

[JOAN_LORD]

Wow - thank you for explaining this to me some more, This scene is only over complicated as it has a music stage, so that's why i have all these animated moving lights, and animated people, the other's are ALOT more simple!

- I'll go with the IM & LC I think, as I think I know how to use these better....

SO Just so I understand.... I'll configure the secondary bounce first (Light Cache) - (changing both prim & sec to LC) Wack up the sub divs, I have used numbers such as 5000-6000 (Is this enough)?

With Sample Size Set to 10mm, Scale: World, Checked Cam path. Do I use light cache for glossy rays?

interp. samples set to 10.

[super gnu]

10 mm scale and world is very very small for a scene like this. id maybe switch back to default sample sizes and screen scale and increase sample sizes from there if youre doing animated gi. the idea of the secondary bounces is to provide an overall approximation of the scene lighting from which the primary bounces can take their averaged light levels. you dont need detail, you need smoothness and lack of glitches in this case. the bigger the samples and the more blurred they are the easier it will be to get a flicker free (within reason) lightcache. making the samples too big will cause its own problems, but making them small will require thousands of subdivs to get a clean result.

regarding the music stage, just calculate the gi with the stage lights off, then turn them back on for rendering. they can be animated to change the direct lighting around the stage, you dont really need animated gi effects from them.

[JOAN_LORD]

Ok Got you, so if I over complicate the LC it'll actually cause the flickering? - And Just so I get you, the LC will need to re-render with every Frame Right?

I've attached some LC renders of the settings, the more blur'd the better (within reason)?

I'm going to lower my final resolution to 1025 x 576, so it's atual size.



Thanks again for your quick posts!

EDIT - What happens when I do the Cal for the IM, I guess i'll have to calc the LC with every pass of the IM? - In which case does that mean I have to do the LC twice when I change the IM to render mode?

DOUBLE EDIT - lol - I just thought I guess when I render the IM pass it may not store / need the LC? - or is it the other way round and I should use the LC with the IM the first pass then switch LC off when rendering the final?

[JOAN_LORD]

I have a test sequence rendering at the moment (around 8 hours to complete) of about 10 minutes a Frame, So far, each frame looks great with no obvious noise, and I don't think I whacked the settings up to much either! - So going to wait untill tommorow to see how it looks in effects, if it does look acceptable I'll start sending the whole thing to pre-calc, and thanking you Super Gnu for your time and info!!!!

I'll also speak with Director to see if I can post full frames up to show progress. Cheers again, and stay tuned!

EDIT - Although knowing about if I need the LC on both times would be good to know, would save hours of pre calc on the LC! any clues?

[super gnu]

you need lc perframe when calculating the imaps. after that you can leave the secondary bounce slot empty for rendering, unless you use my trick for doing animated people, since then, you would be calculating primary bounces for those parts at rendertime, and would need sec. bounces for that calc.