3DS Max 9 Flickering Final Render

We've been working with 3DS for many versions back in the past, but this is the first project where we've been using Max 9 for a significant, detailed mental ray render. We've tried doing this with and without final gather maps, with and without global illumination, several other different render setting shifts in terms of quality, and yet cannot figure out why we're getting this frame-by-frame difference in the way lighting is being interpreted in the output.

We have a target camera moving along a path (which is what this is shot through): that is the ONLY animation going on in the scene. There are definitely only 2 different levels that we're seeing in the final output, one lighter, one darker. Small movie shows this:


Anyone seen this before with Max 9 and/or something similar? Any / all ideas would be GREATLY appreciated :)
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


I've definitely fought this issue a time or two. Can you please share your Final Gather settings?  

You may be shooting to few rays from your FG points.  You'll need enough rays from each FG point to ensure that you hit all light sources in the scene.

Since the camera is the only object animated in the scene, FG maps can be used to speed up rendering, but make sure that you DO NOT lock (read only) the FG map.  Since the camera is moving, new FG points will need to be written to the FG map as new geometry is exposed.  

Also, is the camera looking through glass or other transparent materials?
cgraefeyAuthor Commented:
I've attached 2 screen shots of our final gather settings. Even though this one is showing the map locked, we've run this without the lock with the exact same results. The Ray theory is interesting, will definitely run an experiment with that next. If you see anything else in the settings that appears GLARINGLY wrong, we're all ears :)

cgraefeyAuthor Commented:
I forgot to add: there are some transparent materials used in the scene, but the camera is not shooting directly "through" them in any way that I would expect to cause a problem (as in, the transparent materials are just objects in the scene).
Become a Certified Penetration Testing Engineer

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

cgraefeyAuthor Commented:
Not sure if this matters either (as we've been getting the same problems rendering on a single machine) but we are using Backburner on a farm of 5 XP64 PCs.
The only thing that seems to be too low is the FG Point Density.  I'm sure that you guys are trying to keep your render times low but fewer points will certainly result in a lower quality rendering.

Have you done a FG diagnostic before?  If not, click on the Processing tab in the Render Setup dialog box.  In the Diagnostics section, check Enable and choose Final Gather from the available options.  Then render the scene.  Your final render will show in green all of your final gather points.  

You should find very few FG points on the walls and other large surfaces (where most of the flicker is visible) compared to the more detailed areas - which is normal, but with a point density of .4, you'll only see 40% of the points than would normally be placed for a FG calculation.  Each point is probably shooting enough rays with a setting of 150, you just need more points for better accuracy frame to frame.  

You might even be able to lower your rays per point significantly (as long as you have enough points) to compensate for increased rendering time.

Increasing Interpolate Over Number of Points will also help to even out the lighting produced by FG (maybe 50 or so).

Another option is to calculate an FG map over a number of frames and then lock the map for use in your final render (as long as you don't lock a 1-frame FG map).  This link has a good overview of the process.

Hope this is helpful. Good luck!
cgraefeyAuthor Commented:
We may have a solution based on some of your advice (with the help of a photon map) -- don't want to jinx the render just yet, I'll let you know tomorrow how it worked out: thanks again for the fast responses, we'll wrap this thread tomorrow.
cgraefeyAuthor Commented:
OK, whatever the problem is, we're now thinking it's deeply rooted in 3DS or our lights... I have no explanation for how a strip render of a single frame with a LOCKED brand-new Final Gather Map could produce the attached single image. This seems to be the same problem, now playing out in single images instead of multiple frames. If we rendering on one machine, it's fine. But I don't think this is a Backburner issue, because if we do a multiframe render on a single machine, we can also reproduce the "2 sets of lighting" effect we seem to have here in a strip rendered by 5 machines.


We had another file that was having this problem (sudden, drastic lighting shifts at seemingly random points) that turning on Global Illumination solved. GI solves no problem here. We've tried messing with literally everything imaginable... we went through that flicker tutorial to the last letter detail, and it definitely smoothed things out, but this problem persists.

This is the first time we've ever encountered this in our several years of using this product without EVER seeing this behavior. STUMPED!

Very interesting.  Could this be an exposure problem?  Are you rendering with any exposure options other than logarithmic?  If so, that could be your problem - and it would certainly cause this.

I'm not sure what techniques you are using to troubleshoot, but I would do the following:

1. On a single machine, hide everything in your scene except the walls, floor, and ceiling (and maybe place a simple box or two in the scene to represent your shelving.  Everything should now render very fast for testing purposes.

2. Turn off GI and FG and render a test animation - just to make sure that your lights aren't flickering without indirect illumination. If you get flicker, then look to your light sources or perhaps your MR render settings (special camera shaders or effects).

3. Turn on FG with no FG map (try settings of .8 - 1.0 density, 100 or so rays, 30 or so interpolation, 0 bounces.  Render and animation and check for flicker.  If you get flicker, try making adjustments to these settings to fix the flicker (higher rays, point density, etc.) - If you still have flicker, I'd question possible file stability or some random render setting.  I've fixed some strange rendering issues just by switching to scanline and then back to mental ray.

4. If you rendering is good to this point, I'd try creating the fg map every few frames of the animation and then render the sequence.  If you have flicker, I'd question the fg map creation technique.

5. Next, turn on GI and test again with a new fg map.  If you get flicker, you can work with the GI settings to fix.

6. If all is good to this point, try a backburner rendering with the simple scene.  If you get flicker, make sure the FG map is being loaded by the other machines.

Other things to consider:
1. Are you using any rendering effects (Environment-Effects) or plugins that could be affecting the rendering.
2. Are there any animated materials that could be affecting lighting.
3. Are any aspects of the lights animated or use any animated maps
4. If area lights - are you using enough samples?
5. Is it possible that a light is too close to the ceiling - resulting in z-fighting...some frames the light emits, some frames don't.  z-fighting is pretty random.
6. Maybe try merging all scene geometry into a fresh max file.

Out of ideas. :)  I'd be happy to take a look at your max file but I'm sure you'd rather not send that out.

Good luck.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
cgraefeyAuthor Commented:
I will check out the Environment variables : we have been playing with those, but I do believe we're using logarithmic exposure. Some of these we've already tried, but some we haven't. I'm interested in this concept of "Z-fighting" and experimenting with taking out a few self-illuminating textures out of the scene. Again, I don't BELIEVE we did anything different with this model vs. others that have worked fine in the past, so it's very possible that we're simply dealing with a problem file, but definitely want to troubleshoot this to see if there IS something to fix -- the unsolved problem ALWAYS returns :)

Thanks again for all your help and patience as we resolve this.
Ha.  Yes, always something to fix in Max. :)  

If you decide to use exposure controls with your animation, Logarithmic is the only one you are supposed to use - as it is the only one that will produce consistent lighting from frame to frame.  I am not a big fan of it though and avoid exposure controls when possible.

By the way, the term z-fighting refers to the artifacts you see when 2 polygons share the exact same local z coordinate.  Which one gets rendered?  Since one may render on one frame and the other on another frame, we think of the polygons as fighting each other for rendering control.  

Lights can also share the same local z coordinate with polygons and the same issue can occur.  So, after I place my lights (autogrid or snapping), I always nudge them down from the ceiling a fraction of an inch as to avoid z-fighting.

I certainly feel your pain on this one as I have been in a similar situation more times than I care to remember.  Nice scene by the way.  You guys are very talented.

Good luck.
cgraefeyAuthor Commented:
So we're pretty sure in the end it's been a combination of the light choices AND the z-Fighting going on. Have a few more tests to run on the same model but the early ones look promising. I want to close this out  tonight, so again, THANK YOU for the suggestions and frankly a whole lot more advice / things to look for in the future. We have a much deeper understanding of several elements of this program we previously did not.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Game Programming

From novice to tech pro — start learning today.