GI Flicker on ground from clouds

Started by MrHooper, April 13, 2010, 10:19:52 AM

Previous topic - Next topic


I have a short animation of storm clouds rolling in.  The GI flicker on the ground is still persistent, even with some pretty high settings.  720P frames are rendering at 2.5 hours (8-core xeon) with the following settings:

Detail: .8
AA: 3
GI detail: 3
GI sample quality: 4
GI blur rad: 40

quality: 1.3
samples 229
accel cache: none

samples: 200

These high smaples were needed to get the noise out of the render, but GI seems to be the problem to me.  Cranking the gi settings is getting out of hand... long rendertimes.  Any suggestions?

Here's a link to a small 11mb QT.  the flicker is less noticable here, since it's smaller, but believe me, in HD is is a problem.



I could barely notice anything.

Have you tried the ray detail region setting though? Increasing the padding around the frame?

This makes it render more of the cloud out of frame accurately, and thus keeps the shadows/lighting the same.  As my guess is clouds moving on/off camera are causing your issue.


That might be a good idea.  Didn't know about that.  I posted another version (HD) at the same link.  It shows the flicker more clearly.  Plus when I color grade this with more contrast and other bells and whistles, the flicker really stands out.

BTW, I'm working on obj lightning strikes in the distance.  Unfortunately, making a glowing shader on them doesn't scatter light in the clouds.  I'm kind of going with combinations of obj lightning with lights right above them inside the clouds to get the internal scattering.  It works, but I'd rather have the glowing shader of the lightning scatter light in the clouds if possible.



The problem you describe is related to GI.
The ray detail region feature will probably not help, because it does not affect GI, but only clouds.
It calculates shadows and reflections generated outside the frustum of the camera.
However, it does not implement/do this for GI.

I was wondering, have you enabled "detail blending".
This setting is vital for rendering animations, as it interpolates GI between frames.



Try bumping up the blur radius as well. The larger the blur, the less difference you'll see from sample to sample and frame to frame. The downside is that you might have slightly less GI detail, but since there isn't much small-scale stuff here, that shouldn't be a huge problem. - A great Terragen resource with models, contests, galleries, and forums.


Quote from: old_blaggard on April 13, 2010, 01:31:40 PM
Try bumping up the blur radius as well. The larger the blur, the less difference you'll see from sample to sample and frame to frame. The downside is that you might have slightly less GI detail, but since there isn't much small-scale stuff here, that shouldn't be a huge problem.

Exactly, that's also why I think detail blending is disabled. The GI settings as is are kind of overkill for a scene like this you'd think.


Thanks for the tips.  I'm not really understanding the detail blending tho.  It's not an enable or disable thing, it's a float value.  What would I set it to? 1?  That and when I do a search on detail blending, Matt describes it as this:

Detail Blending: During an animation involving camera movement, the subdivision levels used to create the micro-triangles will change. Detail Blending allows those micro-triangles to blend from one subdivision level to the next without a sudden pop. This blending requires more micro-triangles to be rendered, so it increases render time. It may also have a slight softening effect on the appearance of surfaces. You can reduce Detail Blending to improve render speed, but unfortunately it can also reveal very clear lines between subdivision levels on still images which often look bad and it is more difficult to control the detail levels in an image. I should be able to improve this in future by dithering the levels of detail from one micro-triangle to the next.

This doesn't seem to have much to do with GI flicker, but perhaps it does.  I'll try it, but render times are big, so it may take a while;)  The blur amt makes sense!


Regarding Matt's explanation. It definitely has to do with GI eventually. The subdivisions of surfaces between frames need to blended to get smooth transitions in lighting/shadows. Now there's no blending and for each frame there's a different subdivision and thus differences in shadows/lighting on the ground.

So, basically you can crank up your settings as much as you like, but without detail blending you will still get popping geometry and flickering.
I'd set detail blending to 1. It will increase rendertimes at least by half, but I'm pretty sure it will look fine then, especially if you raise the blur radius a bit along with it.
I think you might even be able to render this with GI 2/4 or maybe 1/6 to render this without flicker, but still with detail blending and increased blur radius of course.



I see the flicker you're talking about. I don't know if Detail Blending will actually help, but it's generally good to have it on during animation, and is worth a try. I do think your GI Relative Detail may be higher than necessary, especially with your blur settings (particularly if you increase it from 40), and that's giving you higher render time. You might try GI settings of Relative Detail 2, Sample quality 4 or even higher. Sample Quality is probably going to net you bigger gains for stability than Relative Detail.

If those settings and Detail Blending don't help, I'd like to take a look at the scene and see if I can do anything to improve the stability and render time. Let me know if you'd like to do that.

- Oshyan


but after all, as stating in various posts elsewhere in the forum, during animation or crop renders, we still have GI problem.
I had to deactivate the GI for my last animation and put several lightsources to fake it. maybe it could be another solution for you.


None of the suggestions have helped the flickering, unfortunately.  I'm wondering if I need to set my exposure higher to better sample the ground, which by default renders pretty dark.  I'm pushing the ground brightness up in post, so *maybe* sampling is not happening in full float?

Here's the file, if anyone cares to see what the heck is going on;)

The file is stormCloudsV05_post.tgd

I've stripped out assets like objs and textures so you can work with the lighter scene.


I'm looking into it. I'll see what I can do about the problem. But if you're doing post work (exposure/brightness) that could be done in TG2 anyway, might as well do it there as the results should be better.

Btw, one thing I notice in your file, a 4000MB cache allocation! You're probably getting nowhere near that since the scene is fairly simple, but if it did try to use all that, you'd crash because TG2 is 32 bit and 4000MB puts it beyond its usable memory (given other memory-using elements like image buffers, etc.). There's really little need to have more than 200MB *per thread* in most cases. So for you, with 4 threads, an 800MB cache ought to be fine. Even 400MB would suffice, but 800 might be a bit faster.

I'll let you know how my tests work out.

- Oshyan


Quote from: Oshyan on April 26, 2010, 04:10:15 AM
There's really little need to have more than 200MB *per thread* in most cases. So for you, with 4 threads, an 800MB cache ought to be fine.
Well, he states to use an 8-core Xeon, which means there are 16 render threads, so apart from the 32-bit issue, 3-4 GB cache do sound reasonable. Anyway, it might be a good idea to show a warning if the cache allocation goes beyond the size TG2 is able to handle at the moment. Including the suggestion of the 200 MB per thread as a kind of orientation.
Lang lang er vejen for Aslaug
Længe venter lykken på Kraka


It's not clear the 8 core Xeon is Nehalem-based, so maybe not 16 threads, but even if there were, 200MB per thread is more of a luxury than a necessity, and may not even have a benefit for render time. 100MB is generally sufficient. Even at 200MB/thread, it should still only be 3200MB, not 4000. That's really just overkill and asking for trouble. But the fact that it hasn't crashed on him yet just shows that it doesn't need that much cache anyway as it's not filling it up; if it were there'd be crashes. ;)

- Oshyan