GI anim cache and BNR 5.15

Chrusion

Chrusion

gold plated 3D
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 path location in Layout's Render Globals GI tab and # is the frame step (0, 10, 20, etc).

When rendered IN Layout using UNC paths, the result is flicker-free goodness.
When rendered with LWSN on the same host machine (same scene) via BNR 5.15 (host node only - the rest of the farm disabled), the result is flicker-city badness.

The problem is 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). Any OTHER frame between the steps (1, 2, 3, 11, 12, 13, etc) LWSN DOES NOT (because obviously there isn't any in between files), but NEITHER does it INTERPOLATE between the step frames, thus resulting in forcing the render engine to COMPUTE preliminary radiosity over again for each frame, thus 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.
Code: 
LightWave command: render.
Frame: 10.
Read radiosity cache: \\ast-32lxj02\d\_projects\db_xhr\radiosity\GI_Test.cac.10.

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.
Code: 
LightWave command: render.
Frame: 11.
Read radiosity cache: \\ast-32lxj02\d\_projects\db_xhr\radiosity\GI_Test.cac.11.

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?
 
I'm not sure what the problem is but I had problems with radiosity cache too this week. I noticed that if I want to use cache on the BNR farm I needed to cache it with the 'save every frame' checkbox checked.
 
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
 
Nope... that didn't work. I'm pretty sure "Save After Each Frame" is for non-animated cache, since a non-anim cache is a single file and builds up samples as the camera view changes (objects must be static) and saving after each frame forces the file to be opened, written, and closed in case of a crash. Anim cache files are automatically saved since one file is created every step frame.
 
I think they might have changed something in 2015.2. I couldn't get LW to put out separate files for each frame. With everything I tried it LW kept saving cache to a single file.
 
Oh one thing I forgot to mention, I had to set the pre process to NEVER. Any other setting didn't work however the locked state is the LWSN state.
The weird thing is that according to the manual the save every frame doesn't have to do anything with the way radiosity is calculated. It says: Save After Every Frame - Particularly of use for people without a good, permanent connection
to where caches are saved This option will add to the cache fie at more regular intervals
 
LW kept saving cache to a single file
Click to expand...
This with Animation box enabled?

If yes, then that's reverting back to pre-11.5, which I much prefer. Don't like the individual frame step files.
 
It could be the LWSN mode you're submitting needs to change. I believe the default in BNR is LWSN -2. You could try LWSN -3. Or the opposite of whatever it's set to. This could also be a 11.6.
 
Why wouldn't Mode 2 be correct for BNR? BNR communicates with all the LWSN nodes via Job and Ack files. Mode 3 does not and instead uses start/end commandline params to set frame range. IOW, BNR needs to know what frame is rendering via the LWSN-generated Ack file in order to issue the proper frame rendering command, via Job files, based on the status of all the other nodes.

Also, Mode 3, even if set to render a single frame, does so on a one-off way... that is, LWSN launches, renders the frame(s), and exits. Mode 2 does not. It sits there waiting for commands via the Job files. Mode 3 would launch, render, and quit every single frame... way more overhead and time wasted for it's init, etc.
 
Last edited:
Every4th...

Baking with pre-process set to never didn't do any different. I'm still getting "Computing preliminary radiosity solution..." (and triple render times) on in between step frames. I think LWSN is simply broken.

I've been using 11.6.3 for over 8 months here at my new job and it wasn't until now that one of my anims had serious flicker. Looking back at other anims, there's flicker in them, too, but it was minimal enough to be ignored... some scenes less, some more. So, I guess I'll incrementally downgrade LW in order to find the version that isn't broken. What a hassle right in the middle of such a big project (dozens of anims) with a next week deadline.

For now, I'm compromising and reluctantly accepting the "film grain" effect of brute force non-interpolated MC GI (due to keeping rays super low (5) and ASAA at a level that gives 10 min/frm render times).
 
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 was 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.
 
Wow! Something VERY interesting just happened!

I decided to just go for broke and set frame step to 1 in 11.6.3 and amazingly, LW baked the scene SUPER FAST, just like 11.0! IOW, it was using the previous frame's samples as the base for the next frame. OK... didn't see that coming. I was totally expecting LW to crank on each frame from scratch like it does when frame step is greater than 1.

The next surprise came when I started up LWSN and seen that good ol' friendly status msg "Recalculating radiosity samples... Recalculating radiosity samples..."!!! Again, this is what 11.0 did before the change to cache sequence files in 11.6.

And finally, what floored me is that I was expecting to see 150 cache files for this 150 frame cornell box anim test. But what did my eyes see, instead? Yep, a SINGLE cache file far SMALLER in size than the total of the 15 cache sequence files when I baked the scene at a frame step of 10!!! The single cache file at frame step 1 = 3.1 MB, while the average size of the cache sequence files was 2 MB (times 15 = 30 MB). Cool!

So far, after only 10 frames rendered (single LWSN node at under 2 min/frame) the result is free of GI flicker, even though I turned all ray trace options Off, except shadows, in order to speed up GI baking that I was expecting to take 40 seconds/frame. Instead, it took 2 sec/frame! I thought the lack of ray traced shading would influence the preliminary GI baking calcs and cause flicker when those rays were turned back on, but apparently it doesn't!

Overall this makes me VERY happy! Even though my future GI bakes of complex production scenes will be every frame, I just might see a decrease in total scene bake time vs the render time of doing every 10th frame at the longer "from scratch" preliminary calc time. But, if the total bake time is longer doing it every frame, well, it'll be something I can live with knowing there won't be any flicker. Soooo, if and when NT fixes the broken GI cache sequence file issue in LWSN (works fine using Layout to render), this compromise will have to do.
 
You must log in or register to reply here.
Back
Top