Cycles renderings are flickering (Bongo 3 animation)


I setup an animation of a product (HDRI+some lights) and now I did a test. But the output isn’t stable and I get a flickering between some frames so that I can’t use it for my client. Is it a known problem and is there a way to avoid this? Or should I send my project file for bug cecking? To the Bongo team or to @nathanletwory ?


You can start by sending to the Bongo team, they’ll poke me when necessary.

1 Like

Hi @nathanletwory

after a lot of test I found that Bongo 3 isn’t the reason for problem. Finally I tested a reduced scene with only two objects and Bongo 3 wasn’t loaded. If the spring is in the scene than the output is darker than if the spring is hidden - see my screenshot.

I glad to focus the issue to a simple test scene and hope the bug can be caught now and fixed soon. My client is waiting for the animation. I’m curious what you find.

Good luck,

I am unable to load the file without Bongo crashing (@Joshua_Kennedy , FYI - crash dump sent in, has a callstack in the comment), so I imported it into a new file, then saved it without

I exported the two objects without any bongo data. The spring was moved to a different layer, I switch that on and off while in Raytraced. I am not able to reproduce this:

CyclesFlickeringObsOnly.3dm (2.6 MB)

@Micha with the help of @Joshua_Kennedy I was able to reproduce the change in color. It somehow has to do with the transparency setting. I’ve logged it as RH-63705 Environment affects rendering differently when Transparent option is checked in Backdrop.

Here the scene without textures so it is quite small saved. It can’t be seen in raytraced viewport but if you press the render button. It’s a very critical bug for my current project - it’s freezed until the issue is solved.

CyclesFlickering2.3dm (1.6 MB)

@nathanletwory I’m not sure you have seen it - the logged bug RH-63705 could be an other issue than the flickering. Could check my last posted file please? A fix is very needed to finish a current project. Without a fix the work on the animation of the last weeks was in vain.

It looks like it has to do with the transparent background option being checked. Somehow this affects the results, but I don’t yet know what.

Perhaps you could do a “green screen” technique while I try to figure out what the problem is. Today went mostly into another critical bug.

Anyway, once the WCS bug is done I’ll be looking into this before going back to multi-device and RenderWindow/RenderInWindow bugs.

1 Like

Interesting - so it’s dependent from the background transparency and the visibility of a “special” object like the metal spring. Good luck.

@nathanletwory I tested a solid background (see screenshot for setup) and got the same issue like by transparent background. So, a green screen workaround will not work.

@Micha in a backup copy of your CyclesFlicker2.3dm file could you remove the materials #Gehäuse_silber and Metall_sat and replace them with the materials in the zip (1.2 MB)

Assign to the objects and see if they work now better. At least here I can no longer reproduce the difference in tint when hiding the spring.

If this works then the problem is somehow related to the IOR setting. In your materials it is 1.0, whereas in my manually recreated materials it is 1.52.

I don’t know yet why this happens, but if this workaround gives you the results you are looking for you should be able to finish your animation without having to wait for a fix. I have currently no idea why the difference happens, so I have no ETA for a fix.

edit: I can’t redo in a file created from scratch, but it still happens in your file :confused:

Here from my file created from scratch two renders subtracted

RecreatedFromObjs.3dm (6.6 MB)

For the recreated file I had originally the HDR Mechanik environment texture in, but that was too big so I swapped it out for a different one. Still no differences between with and without spring though. The materials are the same as from (1.2 MB)

I used your material but it’s still flickering. Also I deleted the materials from the spring and the case part but the flickering is there again.

As I enabled a background color I have seen that the whole rendering is dimmed by the bug. It’s like an exposure effect. Is there a hidden exposure automatic?

The IOR 1 is caused by creating a Rhino material “custom”. This materials get IOR 1 per default. Also if I create “metal” and switch to PBR than I see IOR 1.

No, there should be no such thing. Exposure is always the same.

Yes, I get it still in your 3dm file as well, but the 3dm where I recreated this from scratch (using meshes) I don’t get the problem.

I’m currently in the dark as to why this happens in your file.

At my project file there is a complex Bongo animation of several weeks work and I can’t start from scratch.

Is it not strange that the whole exposure is changed? Also I did two tests - I disabled all lights and I disabled the environment. In both cases I got the exposure change, so it seems to be not related to lights or environment only.

I wonder how hard it would be to copy just the bongo user data from one document to the other, @Joshua_Kennedy ?

Or is it possible to reset the render data by temporary disable Cycles? Maybe per plugin manager?

(The Bongo 3 animation contain new data like constrains and all this new stuff could be fragile.)

I tried a “Reset to default” of the render options but the exposure is still changing. Also it needs ~50s to start a rendering, before it was a few seconds. So, this is not a way. Only a new problem appears.

I assigned one of the black plastic materials to the spring, renamed it “Spring” and the rendering is fine.

Than I disable Fresnel reflectivity and I get the wrong result.

Should it not be possible to keep the fresnel mode but set a high IOR? I tried it but the IOR is limited at 2. From other render packages I know to free set the IOR.

@nathanletwory Good News!!! I found the bug. :slight_smile:
It’s the saved logarithmic tone mapping. In clamp mode it works, no exposure changes anymore. I hope now it can be fixed.

Well, if it is tone mapping it is out of my hand. I’ll create a bug report for this though.

I think it is @johnc who wrote the tone mappings.

edit: it indeed looks like it is logarithmic tone mapping. Good find!

edit2: Bug reported as RH-63729 Logarithmic tonemapping inconsistent output depending on scene.