View Full Version : LW 11.5.1 GI Anim Cache Render Times

08-14-2013, 07:54 PM
I have a 1200 frame 720 HD anim of a camera flying from outside of a box-like compartmented, mobile home-sized, air filtration unit, into and thru it, and back outside. A few parts have translation-only animation (no transparency or dissolves).

I've baked the GI anim cache at a 10 frame step (2 bounce MC at 500 rpe, 25 sbr, 2px min, 100 px max). I've used this setup many times before with good results.

What I have never noticed in the past when doing F9 test renders (cache locked after baking) in 11.5.0 was LW "hanging" for over 2.5 minutes during the "rendering polys" phase after having recalc'd GI samples. That is, in 11.5.1 the render progress freezes with a black preview for this length of time with CPUs at 100%. Then a single scan line will appear, followed by several 10 - 15 second "freezes" as a couple more threads are added at a time and finally all 8 appear (4 HT cores), but they render twice as slow compared to disabling the cache to force a fresh GI solution on the selected frame. It doesn't matter which frame is rendered... first, last, middle. Of course, some portions of the anim do take longer to render, but again, compared to non-cached, per-frame GI calc, they all take twice to three times longer WITH the cache enabled.

Anyone encounter this and/or have a solution? I really don't want to send this to my farm and have it take twice as long to render than prior jobs in 11.5.0 of a similar, near identical setup and scene.

08-14-2013, 08:25 PM
When you are baking to 2000 frames, LW goes through all the frames step to save all the sampling points resulting in a much denser sampling points as compared to single frame (without cache)

1. use radiosity flag (under render tab) to check your sampling points. chances are they are much denser than you expected.
2. normally I use a much lower density setting for long sequence like this (ie: double the min spacing) ...

08-15-2013, 07:12 AM
Come to think of it, I _may_ have had min px at 4 and a bit shorter anims in LW 11.5.0. Will rebake at min px of 5 (rad samples flag showed abnormal concentrations on a few parts).

Here's another observation: Is GI cache baking affected by ray trace settings? That is, are options that only bounce or bend rays required (iow not shadows)?

It appears yes. To speed up baking, I turned off all RT options, BUT after locking the cache and turning them back on, LW would NOT render... just hung on a black preview with CPUs blazing for 5 - 10 minutes, even though the frame only takes 4 min to render when baked with RTs on.

08-15-2013, 08:02 AM
Its not hanging... its still precalcing GI.

When you cache for a camera move, and lock the cache... low sampled areas will just be rendered as low sampled and no updating will be done. However, if things change, or move... then even with cache locked, you'll still get things needing to be updated as the reder progresses... this is whats happening during the "hang"... the only "bug" is that it looks like a hang, and nothing appears to be happening, as you can see, CPU use tells a different story though.

As for turning off tracing... this is a trick which helps get faster chache baking with "trace" heavy scene (lots of reflections, etc)... however after turning them back on and running the render, the GI still has to update to account for the new info... Again, it just sits there black while this is going on without telling you (because really the GI system wasnt "designed" to be tricked this way, its jsut a consequence of how the system works that lets you get away with it).

This, ofc, increases rendertime over just the chached render without turning the tracing back on... but overall its still faster than getting a full GI bake with reflections (etc) in the first instance.

More stuff on cache in the last part of this vid... http://www.youtube.com/watch?v=0YFZ2av-BLg

08-15-2013, 10:16 AM
I'm only setting cache mode to locked to test render inbetween frames so samples aren't added and saved to the cache.

I've read Except's Rad. Guide over and over. I see nothing about RPE affecting sample generation. So, I assume RPE is irrelevant when baking, yes?

08-15-2013, 10:37 AM
ofc not...RPE is RPE... its the value used for the rendering, baked or no, you use for that whatever you would for the render anyway... there's all'a that in the vid too. Basically, if youve got changes to the scene, post bake, either in terms of moving lights/objects, or alterations to basic rendering options (tracing/res etc), or to rad options... you will get different weird behaviours from the cached render... either in terms of the apparent hang ur seeing, or render artifacts.

08-15-2013, 11:18 AM
Re. "ofc not... RPE is RPE" hehe... well, just thinking out loud. So, yeah, I rebaked this scene in 30 min. with RPE = 1 compared to 2 - 3 hrs with it at 500 - 1000. This "Tip" needs to be in Except's guide for those whose light bulb hasn't lit up yet.

So, the part I'm still fuzzy on is what is happening AFTER the radiosity progress reaches 100% and "recalculating radiosity samples" changes to "rendering polygons." Is radiosity still being recalc'd (and if yes, in what way and why after rad. progress = 100% and polys supposedly start rendering?), because the "hanging" is happening after the cache has been read, samples recalculated, and polys are supposed to be rendering, but are not for a few minutes, but then start to. Per my OP, a segment of one scan line appears, halts for up to 30 seconds, proceeds a little farther, halts, yada, yada, until 3 minutes later it finishes while maybe one or two more scan line appear doing the same but a bit faster. Until finally all threads are up and running and rendering lickity split like a normal render. It's that 3 - 4 minutes of "inactivity" slowly progressing in fits up to "normal" speed that is perplexing. I don't recall this happening in 11.5.0.

08-15-2013, 12:03 PM
Wait! I think I got it now. The "recalc samples" is the PRE-process phase, which is just figuring out where interpolated samples are btwn sampled frames (frame step).

"Rendering polygons" without visible action in the preview window and time updating is the POST-process phase, when all secondary rays are fired and bounced around to calc surface shading. When that's done (several minutes in my case) THEN visible rendering commences, and for whatever reason in this case, threads are just taking a long time to split the frame evenly up btwn themselves and get on with their business. Yes?