View Full Version : GI anim cache and LWSN 11.6.3

03-06-2015, 07:57 AM
(cross-posted to the ScreamerNet forum)

Not sure when this started happening and don't know what to do to track it down and fix, but LWSN (11.6.3) is NOT interpolating between baked GI anim cache files contrary to the console window status.

For example, I baked a simple cornell box scene with object and camera motion every 10th frame. The cache files are in the content dir /radiosity. They have the *.cac.# naming convention, where * is the base file name entered when selecting the shared network UNC path location in Layout's Render Globals GI tab and # is the frame step (0, 10, 20, etc).

When rendered IN Layout using these shared network UNC paths, the result is flicker-free goodness.

When rendered with LWSN on the same machine via BNR 5.15 (host node only - the rest of the farm disabled), the result is flicker-city badness.

The problem appears to be that LWSN SAYS it's reading the cache files, AND IT DOES SO ONLY for the frames matching the FRAME STEP (0, 10, 20, etc), but any OTHER frame between the steps (1, 2, 3, 11, 12, 13, etc) LWSN DOES NOT INTERPOLATE between the step frames ((because obviously there isn't any in between cache files), thus forcing the render engine to COMPUTE preliminary radiosity over again for each frame, resulting in flickering GI.

This is LWSN reading the cache on a frame step. Notice the render time and the lack of "Computing preliminary radiosity solution..." AND the speedy render time.

LightWave command: render.
Frame: 10.
Read radiosity cache: \\ast-32lxj02\d\_projects\db_xhr\radiosity\GI_Test.cac.1 0.

Rendering frame 10, segment 1/1, pass 1/1.
Rendering Time: 16.5 seconds.

This is the next frame where the render engine is SUPPOSED to interpolate between frame step file 10 and 20. Notice it SAYS it reads the non-existant frame 11 file and notice the presence of "Computing preliminary radiosity solution..." and the resulting near tripled render time as LWSN is forced to calculate a new solution and thus a new set of random samples, the source of the flicker.

LightWave command: render.
Frame: 11.
Read radiosity cache: \\ast-32lxj02\d\_projects\db_xhr\radiosity\GI_Test.cac.1 1.

Computing preliminary radiosity solution....
Rendering frame 11, segment 1/1, pass 1/1.
Rendering Time: 46.5 seconds.

Is there something I'm missing in the new version of BNR config? Is there something I'm missing when saving the scene?

Why does LAYOUT render GI just fine, but LWSN on the same machine doesn't?

03-06-2015, 08:06 AM
Forgot to add that I've edited the scene to point at the radiosity path in different ways, all to none effect. Also, Layout is configed to use the default, not custom, PATHS, of which "radiosity" is the default folder name inside the content directory for the cache files. The ONLY difference is the capital first letter in the config paths vs. lower case for the actual folder names. Works either way for objects, scenes, images, vertcache, etc. so I doubt LWSN sees any difference between "Radiosity" and "radiosity."

normal scene file:
RadiosityCacheFilePath radiosity/GI_Test.cac

edited for direct access:
RadiosityCacheFilePath //Ast-32lxj02/d/_Projects/DB_XHR/radiosity/GI_Test.cac

Maybe use back slashes instead?:
RadiosityCacheFilePath radiosity\GI_Test.cac
RadiosityCacheFilePath \\Ast-32lxj02\d\_Projects\DB_XHR\radiosity\GI_Test.cac

03-06-2015, 06:32 PM
Well, I tested anim GI cache on 11.0, 11.6, 11.6.2, and 11.6.3. It breaks at 11.6 when NT changed from a single file cache to individual files per frame step.

There's absolutely no flicker using 11.0 with the single file cache. Another item to note is that in 11.0 (haven't tested 11.5), baking the radiosity scene is magnitudes faster, because baking uses existing samples from the previous frame step and only adds new ones as they become visible to the camera. In 11.6.x, baking is approx. 10 times slower, because each frame step is recalculated from scratch and apparently does NOT use any samples from the previous frame step cache file.

How in the world could NT let this insanely HUGE bug last thru 4 versions (11.6.0, 11.6.1, 11.6.2, and 11.6.3)?? And more serious, why didn't _I_ notice this, since I've been rendering Interp MC all this time? Scene and object related? Some scenes with less complex or non-intersecting geometry fair better? Not using Texture Environment as the background ambient light source and instead using mapped sphere(s) = less GI artifacting? No use fogbugzing this now, since 2015.x is the current incarnation.

What to do now? 11.6.x's LWSN is broke for anim GI and 11.0 is too old and won't support the new features. ARGH!!!!

Can someone do a similar cornell box anim GI cache NETWORK render in 2015 and see if we're back to single file caching or confirm that individual frame step file interpolation is working and resulting in flicker-free renders? Simply add a rotating box with stacks of thin "plates" added to its sides plus some intersecting cylinders. Such geometry creates the most pronounced flicker along those thin edges and intersections for me at 2 bounces, 1000 RPE, 100 SBR, and frame step of 10, while the walls and simple shapes create very little flicker... more of a shimmer over larger areas.