View Full Version : Preprocessing is longer with Baked Radiosity with Animation

12-30-2014, 12:30 PM
LW 11.5.1 (can't upgrade due to Admin privileges at work). Have an interior scene that uses radiosity with the cache prebaked for the entire scene with animation checked and Locked. Camera slow pans with some elements in the scene moving a bit. I initially rendered without baking the radiosity and the scene took about 1 hr 5 min per frame (went up about a min per frame). Radiosity was at about 3 min per frame and preprocessing was about a minute or 2. After 3 frames, checked the render and noticed some initial flickering so I decided to try baking the radiosity first.

Now the first frame took 11 minutes longer. Radiosity at 2.2 seconds (good) Preprocessing now is a whopping 25 minutes! Looks like the next frame will be more of the same.

I though the baking process was supposed to speed things up? Or am I just screwed on this one?


12-30-2014, 12:59 PM
uncheck animation, rebake, lock, render.

12-30-2014, 01:04 PM
Just to clarify, I thought to avoid flickering we had to check the animation? Or does the baking take care of this?

12-30-2014, 02:33 PM
So far so good. Preprocess back down to around 4 min. This will be cooking over the new year and will have to check for any flickering on Friday.
Thanks RH

12-30-2014, 02:35 PM
If you have camera animation only... animation does nothing but eat up render time. Tbh... even if you have object or light animation... it can be a bit rocky. There's other techniques available that can be used to both reduce flicker and get faster rendertimes in such cases.

12-30-2014, 02:48 PM
Hi, speaking of GI, what is the correct cache settings for fast daytime time-lapse of interior with other dynamic lights and objects ?

01-02-2015, 07:14 AM
The render times are much better, coming in at under 50 min per frame and no GI flickering. Now I see I have to refine the render a bit better as I have many reflection / specular hotspots that are just too harsh and are creating a sort of "moving noise" from frame to frame. I seem to have three options or controls with which to improve this but I want to be mindful not to unnecessarily increase render times with a control that will do nothing to improve it.
I did a detail of the most problematic area (a chandelier (surfaced with the Dielectric node, a porcelain plate and some silverware). This is attached with three frames for example.

A. Min / Max Samples: Currently at 3 and 32 - Did a test at 6 and 96 with some improvements in the darker areas but need to test other frames to see if the moving noise is present.

B. Adaptive Sampling Threshold: Currently at .005 - When I go lower (to say .001) it really slows the render down, but if this is the only real solution, then I may have to bite the bullet...

C. Shadow and Light samples: Currently at 4 and 2 - Using a number of area lights and radiosity. Don't believe this will improve the hotspots or the moving noise issue, but not sure...

I know I have other surfacing issues that I'm not satisfied with but I'm addressing one problem at a time....

If anyone has any advice to improve I would be grateful.

01-02-2015, 09:46 AM
More AA/AS is, from the looks of things, the way to go.

If you see this video...


You'll see that you can experiment around with different sample levels, played off against one another to find where the sweet spot is render time wise, which'll help you optimise your renders.

01-02-2015, 10:14 AM
Thanks! I remember viewing this but I always forget things. WIll view it again. I did try a threshold of .001 but did not notice any difference from my .005 version. I did bump up the Min Max samples to 9 / 122 (back to .005 threshold) and saw an improvement.
On a side note, I tried to take off the dielectric node and place just a regular reflection and refraction to see if that was causing the overly hot spots on the chandelier crystals. The VPR gave an appearance that was more to my liking but the f9 test turned into something similar the the node. Not sure why.... Full shot is the vpr while the detail is what was rendered.....

01-06-2015, 12:58 AM
Is your VPR perhaps set to draft mode? That might explain the difference in appearance.

01-06-2015, 09:02 AM
I figured it out. Forgot to delete the radiosity cache and re bake since I changed the surface settings on objects. I'm wondering if VPR is ignoring the cache all together.... Making better progress with the overall surfaces and lighting now. Another test run over the weekend created render times between 35 and 40 min with decent quality.

01-06-2015, 12:09 PM
Sometimes Anim GI cach is a pain. However, it MUST be used when ANYTHING other than the camera is moving. And yes, it does take longer to render (and sometimes render times progressively increase), because every frame in between the cached frames (step greater than 1) must be preprocessed in full (all sample points recomputed each frame in order to "see" object/light motion). This is because, according to Exception's Radiosity Guide, Animated cache does not store shading info like it does for a static cache nor does it "stack up" or additively "compile" samples.

I do a LOT of animated MC GI network rendering and only have trouble when a globally seen object, such as a sky dome, is set Unseen by Radiosity. This is when you'll get what I'll call "GI Flash" on only the preprocessed (frame step) frames. The "flash" is either a slight lightening or darkening of some or all of the objects (usually those with surfaces that are shaded mainly by bounce-illumination). All the in between frames render as desired. So, the fix is to NOT have any "environment" type object set as Unseen by Radiosity. You'll also get this same GI Flash if you change the intensity or location of lights AFTER baking the scene. ANY illumination changes requires that the GI cache be rebaked from scratch (as in Delete the existing cache sequence files). And, of course, any edits to object geometry (add/delete vertices/polys) require rebaking the cache, otherwise you'll get flickering blotchy shading (3D location of samples in original cache do not coincide with new surface location).

Another help for me is to think of the static GI cache as a large pool of samples gathered and collected from all over the scene as seen by the camera. Preprocessing is much faster, because existing samples (drops of water in the pool) already exist and only NEW "drops"/samples are added when new, unseen surfaces/polys come into view or change orientation. Rendering is faster, because GI shading doesn't have to be recalculated for sample points already computed. This is why you can get away with far fewer primary rays... fewer rays = fewer samples = faster preprocessing/baking. The "missing" samples will be "recovered" as new samples are picked up by the change in camera view (drops added to the pool).